Python conf in Kharkiv, Nov 16 with Intel, Elastic engineering leaders. Prices go up 21.10

Agile, который вначале радует, а затем вызывает депрессию

На дворе был лихой 2007-й год

Примерно в это же время некоторые IT-компании Украины начали перенимать западный опыт и внедрять на своих проектах новую методологию разработки софта — Agile (aka «методика гибкого увертня-программиста»).

Вся наша команда гордо собиралась каждый день в 11 утра на SCRUM-митинге, где каждый рассказывал о текущем положении дел и о том, что он планирует за сегодня сделать. Эти собрания обычно занимали не больше 10-15 минут, но к ним также нужно было хоть немного подготовиться. Тем более что заказчики — швейцарцы, а значит, общение на английском. То есть ещё минимум 5-10 минут уходило на то, чтобы прикинуть, о чём говорить. Но чаще всего накануне возникал какой-нибудь аврал, и утром нечем было похвастаться. А значит, для подготовки к SCRUM-митингу нужно было еще больше времени, чтоб объяснить причины своего не такого бравого продвижения в работе. В итоге вся эта эпопея с номинально короткими собраниями занимала от получаса реального времени.

Но нам нравилось. Все эти разноцветные листочки для каждой задачи, с написанными поверх них именами и количеством часов, эстимейшн покер, парное программирование, минимум документации и такой боевой темп с реально работающим прототипом продукта — это всё привлекало. Мы так поверили в Agile и SCRUM, что пару человек из нашей команды даже заказали себе домой по SCRUM-доске из пробки.

XP

Что касается экстремального программирования, то народная мудрость гласит — «безопасную вещь экстремальной не назовут». Короткие циклы «деливери» — это экстремально, да, но насколько оправданно? Одно дело, если релиз происходит каждые две недели, или раз в месяц, но ведь бывают и крайности. Например, я знаю одну геймдев компанию, где релиз происходит чуть ли не каждый вечер. То ли у них очень недоверчивый клиент, то ли они хотят стимулировать сотрудников ежедневно пушить свою работу, чтобы было видно, кто над чем работает — сложно сказать. И вот каждый день они выделяют одного человека — билд-инженера, который занимается сборкой. А программисты, конечно же, по полдня занимаются проверкой своего кода, который вечером пойдёт в продакшн. Клиент доволен — у него реал-тайм картинка ситуации на проекте и работающий код. Но сколько лишних телодвижений делают при этом программисты и тестировщики? Лично я бы предпочёл один раз принести одно тяжелое ведро воды, чем сто раз ходить за водой с кружкой в руке.

TDD

Оно у нас на проекте было скорее номинальным. То есть, сначала мы писали функционал и тестили его, и только затем покрывали его тестами. Я так и не приловчился мыслить и работать согласно принципам TDD, то есть никогда не начинаю с тестов, поэтому мне сложно судить о положительных и негативных сторонах TDD. Могу лишь предположить, что истина, как всегда, находится где-то посередине. Но для нас, зелёных юнцов, написание тестов было в радость, особенно когда загоралась зелёная полоска.

Парное программирование

Парное программирование не могло не вызывать восторг. Во-первых, вдвоём думается быстрее, да и вторая пара глаз довольно эффективно ловит орфографические и логические ошибки в коде. Во-вторых, нет лучше способа подтянуть человека в программировании, чем посадить его в пару с более опытным разработчиком и научить его думать по-другому. Мы с удовольствием пользовались этой возможностью поучиться друг у друга, потому как если бы не Agile и XP, начальство смотрело бы на нас как на тунеядцев. Но разве для парного программирования так уж обязательно брать на вооружение XP?

Когда я более чем год назад пришёл на новую работу, то с удивлением обнаружил, что никто там не молится на Agile. Более того, разработка велась в классическом Waterfall. И в то же время я регулярно видел случаи парного программирования. Ребята не стеснялись никого, а наши мудрые начальники наоборот поощряли работу в связке. Так что совсем не обязательно слепо следовать популярным методологиям в разработке софта, когда можно взять для себя лишь самое полезное и необходимое.

Agile почти рифмуется с «выгорай»

Но недели сменились месяцами, и мы начали ощущать на себе некоторое «выгорание». Дело в том, что какой бы идеальной ни была методология — всегда будут вылезать незапланированные баги, которые требуют больше времени, чем планируется. Чтоб латать все эти дыры и в понедельник выглядеть так, будто у тебя всё идеально, приходилось работать на выходных. Почти ежедневные овертаймы даже не обсуждались — каждый думал над тем, что ему нужно будет говорить на следующий день на SCRUM-митинге. И ситуация была такова, что никто не хотел выглядеть на собрании «слабаком». Поэтому каждый старался побольше сделать вечером и пораньше прийти на работу, чтобы успеть к 11 что-то закончить и сказать что-нибудь в духе — «Этот функционал готов, но его нужно потестить» или «Новый сервис работает, но у меня не было времени его полностью проверить». И звучит вроде бы хорошо — что-то работает, что-то готово, что-то функционирует, осталась лишь мелочь, ерунда — потестить.

Мы как будто собирали «лайки» от заказчиков. Им нравилось, что у нас дело спорится и вертится. Мы, будучи зелёными студентами, ловили их одобрительные кивки и вдохновлялись работать дольше, больше, лучше. Но в этой погоне за словами «я это сделал» и «оно работает» всегда скрывалось и кое-что другое — множество хвостов, и накапливающаяся из-за стресса вечных дедлайнов усталость. Почти никогда не бывало так, чтоб можно было перевести дух и работать в обычном режиме. Завтра митинг, в пятницу релиз. Так шли месяцы, пока проект наконец не закончился и мы не слезли с Agile-иглы.

И хотя я в будущем встречал Agile и в менее фанатичной форме, мы с друзьями пришли к выводу, что Agile — это фактически белко-колёсное предприятие, которое ориентируется в первую очередь на клиента, загоняя при этом своих сотрудников в утомительные циклы регулярного «деливери». Так или иначе, я сделал скидку на своё личное пресыщение этой методологией и успешно позабыл об Agile на несколько лет. До вчерашнего дня.

Ложка дёгтя в виде 10 минут SCRUM-митинга

Вчера я встретил Антона — разработчика одной киевской IT-компании, который, хоть и не пил алкогольного, но был в подавленном состоянии. Я начал расспрашивать его о жизни и о работе. Оказалось, что в жизни всё неплохо. На работе тоже всё хорошо. Кроме одного. И тут я услышал давно забытое слово «Agile». Антон — весьма общительный молодой человек, еще студент, при этом прекрасно справляется со своей работой. От чего же его удручает Agile? Почему его не радует работа так, как могла бы? Оказывается, дело в банальных собраниях. Но каким образом всего лишь 10-минутный SCRUM-митинг может отравлять программисту жизнь?

Может, у Антона всего лишь обострённое чувство рациональности? Что, если он понимает, что митинги — как маленький театр, где каждый играет свою роль? Что если он, как и я, не любит участвовать в этой гонке «я сделал больше всех» и «я единственный из команды, кто реализовал такой сложный функционал» (особенно если это удаётся далеко не всегда)? А может, всё дело в том, что не бывает ежедневных собраний по расписанию, без которых — совсем никак. Ведь все это понимают. SCRUM-митинги больше напоминают бюрократический ритуал, чем насущную необходимость. Для галочки. Чтоб на встречах с клиентами гордо говорить о том, что, мол, «У нас всё в топленом шоколаде — по канонам Agile и SCRUM». Может, весь этот Agile существует для того, чтобы держать сотрудников в ежовых рукавицах, давить из них соки и поить им клиентов? Хотелось бы верить, что есть и более гуманные способы поднять продуктивность.

Поэтому интересно ваше мнение:

  1. Нравится ли вам Agile? Насколько эффективен этот подход к разработке?
  2. Как вы относитесь к SCRUM-митингам?
  3. Какую методологию вы использовали бы (или используете) в своём стартапе?
LinkedIn

Лучшие комментарии пропустить

У мене для вас є новина.
Те, про що ви розказали — не Аджайл. Що завгодно, але не Аджайл.

1. Скрам-мітинги проводяться в середині команди. Якщо у вас там з’явились замовники, то не вже не скрам-мітинги.
2. XP не є частиною Аджайлу. Це інженерна практика, а не управлінська. Мені, правда, здалось, що ви мали на увазі CI — continuous integration, але не зрозуміло, чому у вас білди збирали люди, а не Дженкінс.
3. TDD — розробка через тестування. Написання юніт-тестів після функціоналу не є TDD.
4. Аджайл — це якраз проти вигорання. Команда має працювати в зручному, рівномірному режимі. Інакше ви не зможете метриками користуватись.
5. Скрам-мітинги — необхідність. Нагадаю, що їх основою є три питання: «Що зробив?», «Що зроблю?», «Які є проблеми?». Два перші не просто так сформульовані у доконанному часі. Программіст цілком може сказати: «Нічого не зробив». Скрам — це не звіт про те чим займався. Це саме оновлення статусу і прогнозоване оновлення статусу. Неспівпадання їх допоможе виявити проблеми навіть тоді, коли розробник каже, що проблем немає.

Ну і відповіді на питання:
1. Так подобається. Ефективний.
2. Проводимо регулярно.
3. Звісно, що Аджайл.

Не хочу образити, але ваш пост нагадав анекдот: «Фігня цей ваш Бітлз, мені Петрович по телефону насвистів».

Скрам-митинг должен быть быстрым и честным. «Что сделал», «что собираюсь сделать», «что мне мешает». Всё остальное неуместно.

Если программист вчера весь день тупил на DOU и лайкал котиков в фейсбуке — значит, на скрам-митинге так и надо говорить. Всякое бывает и это не повод для огрвыводов. Опытный тим-лид знает, что равномерная производительность труда редко встречается и что оценивать производительность труда программиста надо за какой-то заметный период (хотя бы за пару недель).

Отдельный нюанс в том, что надо говорить «что сделал», а не «что делал». Не надо рассказывать «весь день писал большой модуль, почти дописал». Если за день не удалось сделать ни одного цельного результата, значит, задача недостаточно хорошо разбита на подзадачи (и у неё наверняка кривой estimate).

Менеджерам вход на скрам-митинг запрещён. Менеджер захочет услышать о том что всё хорошо. Не надо менеджерам видеть внутреннюю кухню.

Чувиха с которой мы начали встречаться ранней весной пару лет назад. Ах! Романтика. Я носил ей конфеты, она ходила в веночках из цветов. Через время мы поженились — такая красивая свадьба была! Потом прошли года, она превратилась в жирную стерву, и вместо утреннего кофе фигачила меня сковородкой...
.. ой, кажется я не туда пишу.

А я то думал стенд-ап для того, что бы узнавать чем занималась/будет заниматься команда, что бы удачней коммуницировать на протяжении дня.

Уберите со стендапов заказчика, перестаньте выпендриватся перед друг другом, перейдите на общепонятный и получите весьма полезные 15 минут рабочего времени, не проведенного на пятой точке.

Если делать это для галочки, то, естественно, это будет удручать, потому, что вы сознательно бесполезно проводите время.

Знаете, слово «заблуждение» — это пожалуй самое слабое определение того, как вы охарактеризовали методологии и работы.
1. Смешаны термины. Agile — это подход, если хотите, то философия. Скрам — управленческий framework. XP -тоже отчасти управленческий framework, а вот TDD и парное программирование — это инженерные практики. Вы, по незнанию, объединили их в одно общее слово «agile», подразумевая, вероятно, методологию.
2. Agile и Scrum в примере с «выгорай» опять рассматриваются как равносильные понятия, что в корне не верно. Тем более, что показана классическая ошибка скрам-мастера (хотя сомневаюсь, что он у вас был), когда не определены Definitions of Done и команда вместо potentially shipable product поставляла «лайки.
3. TDD повеселил. Просто от души. Кратко: «Мы не делали TDD и дальше его не делаем. Почему? Хотим мыслить позитивно» :).

Вывод: вам не повезло в том, что вы не видели хорошо работающий процесс. Все аргументы, которые вы привели хорошо известны опытному скрам-мастеру (рутина, выгорание, неприятие и т.д.). Просто тот хаос, который по ошибке назвали «Отжайлом», вы приняли за чистую монету, не удосужившись погрузится в тему. В таком варианте он ГАРАНТИРОВАНО работать не будет. И не ищите поддержки этой мысли в сообществе.

144 комментария

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

немного с запозданием: лично я фанатик водоворота

Почитал коменты,... перефразирую :-) : «Аджайл — все о нём говорят, но мало кто ним занимается». :-)

Ключевой вопрос — не сколько в методологии, подходах и т.д. Проблема в применении. У многих складывается совершенно неадекватное и превратное представление о Agile.
Люди творя бардак и хаос, при этом прикрываются модным лозунгом
И когда в некой команде возникает ситуация, когда «тяп ляп и в production», каждый день трепы с заказчиком с целью показать как все красиво и другой бред ... это называется бардак и виноваты в нем не методология, концепция и т.д.
Виноваты в этом бардаке конкретные люди, которые по разным причинам (непонимание — часто основная) смешивают понятие «хаос» и «Agilie»

Scrum-but термін вже є, пора розширювати до Agile-but?
хоча «в теорії теорія і практика збігаються, а на практиці...»
можна і так дивитися. тим більше що є експерти які кажуть щось схоже:
One Hacker Way, a Rational Alternative to Agile.

Я бы вот ко всем уважаемым комментаторам хотел обратиться — а давайте писать не «хороший/плохой аджайл», а «мой печальный проектный опыт», текст можно оставить как есть — тогда будет ближе к правде :) Потому как множество упомянутых проблем действительно были есть и будут много у кого, и они болезненны, и конечно же надо их исправить, но вот к аджайлу они мало относятся — разве что малая часть, и то косвенно — например в случаях с криворукими имплементаторами этого самого аджайла.

Правильный Scrum как и вообще Agile хорош ещё и тем, что он склонен к самоусовершенствованию путём retrospective meetings, на которых следует делать выводы о позитивах и негативах и по возможности изменять процессы в сторону усовершенствования. Потому если каждый спринт имеет повторяющиеся проблемы, то их не списывают на недостатки Скрама, их стараются исправить.

Анализ процессов показал их отсутствие. Что тут добавить то

Проблема не столько в аджайле, сколько в его рекламе. Она, как и любая реклама вообще, рисует нереалистичные картинки счастья для каждого с точки зрения конкретного участника процесса.

В результате есть как минимум 2 разных аджайла — один для заказчика и один для разработчиков. В том, что для заказчика, есть частые релизы и предсказуемость, а в том, что для разработчиков — отсутствие работы, которая становится ненужной за время выполнения проекта и возможность оценивать сложность задач не в самом начале проекта, а в процессе.

Получается, что теоретически давление на программистов как раз должно уменьшится, особенно с учетом того, что его частично «экранирует» скрам-мастер. Но это происходит только в рекламной версии для программистов, так как заказчик требует с них так, как ему рассказали в рекламе. Да и заказчик обещанный порядок и предсказуемость получает далеко не всегда, ведь программисты хотят обещанной им независимости.

Реально, конечно, всегда выходит что-то среднее и, если не перегибать палку, оно для большинства участников процесса довольно комфортно. Если подходить ко всему с умом. Если...

1. А зачем нравится? Скрам это свод правил, как его применяют так он и работает. Вам Уголовный Кодекс нравится?
2. Вообщето daily(scrum meeting) — это сердце скрама.Как еще можно к нему относится.Почитайте что такое скрам и какова его структура.
3.Так смотря какой и что хочется. Инстаграм,по моему, вообще писался тремя людьми,без всяких мастеров,П.ванеров и прочей магии.

Мне кажется у вас просто плохая команда.
1. Да, надо уметь его использовать
2. Нормально, при правильном подходе это работает
3. XP
Что-бы скрам работал надо что-бы все члены команды его понимали и хотели использовать. аджаил из под палки как вы описали работать не булет по определению

1. Видели мы ваш Аджайл, идея хороша, но как по мне, обычно скатывается в бардак, разброд и шатание)
2. Любой митинг должен быть обоснован, иначе это трата времени и отвлекалово.
3. Лучшее от Аджайла и Вотерфола — отсутствие лишней формализации и бюрократии + понятная и четкая организация процессов и планирования)

Разброд и шатание начинаются, когда требований либо нет совсем, либо они абсурдны, как, например, начертить 7 красных линий синего цвета, перпендикулярных друг другу.

Вы считаете, все держится на требованиях?
Из последних ярких примеров из личного опыта — маленькая контора, разработка и тестирование всего 5 человек (которые меняются как и все в этом мире) включая бестолкового манагера, три основных продукта с кастомизацией для разных клиентов.
Несколько разных версий продакшена, причем на каждом пофикшены разные баги, на деве фиксов может и не быть вообще. QA environment отсутсвует как класс, все тестится на деве) QA самолично собирает билд каждый день, иногда по нескольку раз — после каждого фикса. Документации нет, человека, пилившего еще первые версии тоже уже нет. Как работает часть функционала не знает никто. Требования тестами не покрыты, баги непонятно на какой версии найдены, непонятно когда будут (и будут ли) пофикшены. Версий нет, номеров билдов тоже.

Ща пытаются наводить порядок) Добавлять документацию, делать билды, следить за версиями и не вставлять костыли в прод)

Да, я считаю, и вполне справедливо, что качественное начало спинта — это залог успеха. Если требования не готовы, то какой смысл их имплементировать? Чтобы потом переделать? А потом ещё пару раз? Чтобы в итоге получить в свой адрес критику со стороны тестеров и менеджмента за то, что не явил дар ясновидения и не предугадал желания заказчика?

Знаете что программисты говорят о комментариях к коду? Качественный код не требует комментариев. Когда мне говорили на код-ревью всё переделать — я переделывал. То же я могу сказать о работе аналитиков и менеджеров — качественные реквайрменты не вызывают вопросов. но почему-то когда просишь нерадивого продакт овнера переделать то, что он и так должен был сделать хорошо — получаешь лишь суровый взгляд в духе «хули тебе не нравится».

Т.е. требования есть и больше ничего не надо? Вы одноразовые продукты лепите, без поддержки и развития в будущем? И после имплементации жизненный цикл по завершен?)

Нет, почему же? Просто не люблю копать «отсюда и до обеда». Предпочитаю заниматься более полезными вещами. Дебаты по поводу реализации и задавание вопросов уместно до начала спринта, но никак не после. А брать в спринт непойми что — это безответственно и тупо. То есть, вы обещаете клиенту сделать нечто, о чём даже представления не имеете. Или, не зная деталей о том, как вы это будете реализовывать, вы обещаете ему вложиться в какие-то сроки. Неудивительно, что при таком подходе команда часто не успевает всё сделать к релизу, начинаются овертаймы и прочие «прелести» нерадивого менеджмента. Сразу вспоминается история о человеке на воздушном шаре.

Я вам третий раз пытаюсь донести, что сбор, описание и реализация требований лишь часть всего процесса разработки, который можно превратить в бардак при неправильном понимании и использовании Аджайла. И утверждать, что достаточно все собрать и описать, как-то сильно поверхностно и опрометчиво.

Я не говорил что всё держится на них, но всё от них сильно зависит.

Вы считаете, все держится на требованиях?
Да, я так считаю, и вполне справедливо.
Однако.
Добавлять документацию, делать билды, следить за версиями и не вставлять костыли в прод)
о, да. branch policy — что во что мерджить, подсистема окружений для тестирования и предсказуемая работа билда — это, конечно же, проблема скрама и дейли-митингов. не провтык архитектора или кто там в ваших проектах должен планировать техническую часть.
если жесткий диск не справляется, а продукт адски тормозит и не расширяем изначально — это тоже проблема скрама?
UPD или это иллюстрация «не все упирается в требования»?. ибо с этим сложно спорить: действительно, при идеальных требованиях, если код будет писать полуумный бабуин, проект сам по себе не заработает.
проблема скрама и дейли-митингов
Причем тут митинги? Я говорю о том, что в погоне за гибкостью и скоростью люди забывают про необходимые процессы, при несоблюдении которых наступает хаос.
UPD или это иллюстрация «не все упирается в требования»?.
Это иллюстрация того, что порядок должен быть. И планирование должно быть. А не хуяк-хуяк и в продакшен, как обычно происходит с Аджайлом.

Аджайл виноват, что у вас нет Definitions of Done? Если так, то у вас не Аджайл, а «хуяк-хуяк и в продакшн». Умоляю, не называйте ЭТО Аджайлом, придумайте своё собственное название, как первооткрыватель.

Что возвращает нас к моему стартовому коменту —

1. Видели мы ваш Аджайл, идея хороша, но как по мне, обычно скатывается в бардак, разброд и шатание)

А что это такое — «ваш Аджайл»? По вашим же рассказам, менеджеру, считающему ЭТО аджайлом, про аджайл, максимум, «Рабинович напел»

С другой стороны, в вашем рассказе есть рациональное зерно — к сожалению, ни в Скраме, ни в XP толком не говорится о конфигурационном управлении, а без него вот такой бардак вполне может получиться.

«ваш Аджайл»
это то, во что превращается обычный Аджайл в реальном мире с очень высокой вероятностью
Это иллюстрация того, что порядок должен быть. И планирование должно быть.
как на меня, «как организован процесс разработки» и «как подготовлены инструменты» — это ортогональные понятия.
если не поднято окружение для тестирования — ватерфол вместо скрама ничего не изменит.
так же, как если не работает сеть. или компьютер не позволяет локально поднимать инстанс Оракла.

Agile — фреймворк для построения непрерывно само-улучшающихся организаций. Сам по себе он не решает проблем с требованями, конфигурационным менеджментом или тестированием.

Зато поможет быстро увидеть реальные проблемы (и отличить их от надуманных), планомерно внедрить изменения с контролем успешности, и в конце-концов перейти от хуяк-хуяк к спокойной работе.

1. Конечно нравится, но очень важно правильно организованный Agile. Потому что если он организован не правильно, то будет происходить то, что описано в статье.
2. SCRUM митинги не должны быть формальностью. И они не должны проводится в форме отчета перед начальством. Начальство узнает о прогрессе 1 раз в спринт на демо. Ежедневный скрам митинг только для коллаборации в команде, чтобы все знали какой прогресс у каждого учасника в команде, и решения проблем если таковые имеются.
3. Классический SCRUM (четко по гайду от создателей www.scrumguides.org/...-Guide-RUS.pdf.
Очень важно в каждый спринт привносить какие нибудь небольшие изменения, чтоб не приедалось, для чего должен быть выделет один из членов команды, как SCRUM-мастер. А идей для скрама с интернете пруд пруди. Причем то, что может быть эффективно для одних команд, может быть совсем не эффективно для других, и наоборот. SCRUM очень гибкий, и об этом нужно не забывать, так что если у вас в команде не прижился Agile, значит вы просто «не умеете его готовить».

«Тащи с завода каждый гвоздь, ты здесь хозяин, а не гость». Считаю, менталитет людей добавляет порядка 50% к фейлу. Менталитет, которым формировался десятками лет, а может даже столетиями, если раньше тоже было много халтурщиков.

Иными словами все любят попинать, но т.к. это не приветствуется, перед скрамом резво ищут себе отмазку: читал DOU подымал кластреный томкат! Или играл неделю в телефон, а в пятницу после обеда завел баг и поднял всех на уши требуя фикса прям щас.

Планирование в большинстве своем не просто хромает, оно — безногий инвалид. А без грамотного планирования ничего хорошего не создается. Как по-другому можно пояснить затаскивание фич в спринт по критерию заказчика. Это может и выглядит круто, но вначале разумно сделать core модуля, а лишь потом обшивать его перделками. Это как клеить обоить в комнате без потолка, потом другая бригада случайно разольет сверху пару ведер краски и можно переклеивать по новой.

Agile работает хорошо на однородных фичах, когда «скелет» уже есть, иначе — нет. Потому что реализация многих скелетных фич занимает больше спринта и спешка здесь вообще ни к чему. В гонке за релизом получается спагетти код с кучей потенциальных багов, мины-ловушки и велосипеды с квадратными колесами. И все ради чего? ради галочки в JIRA? Ну это странно.

Я понимаю, что заказчик платит деньги, за это он рассчитывает получить продукт и решение своих проблем. Но считаю, что то, что он влазит в процесс производства пользы не несет. Ну вот представьте что заказчик придет на завод BMW и скажет: «а приделайте сначала колеса, а потом кузов и только потом покрасить все, пока я буду сидеть внутри и немного погазую» Это ведь ненормально. Также как и пациенту глупо требовать от врача перестать мыть руки перед осмотром/операцие, т.к. он торопится. (Для любознательных, врачи в основном не мыли руки до 1847-го года, т.к. у них было слишком много работы).

IT пора вырастать из коротких штанишек и становится mature отраслью, чего пока не наблюдается.

Понравилась метафора про работу врачей или завод BMW :)

вначале разумно сделать core модуля, а лишь потом обшивать его перделками
реализация многих скелетных фич занимает больше спринта

Как сказал по этому поводу Скотт Амблер (в моем вольном переводе): «Если вы прямо сейчас не работаете над кодом, решающим задачи предметной области — вы пишете инфраструктуру. Не делайте этого». В том смысле, что «скелет», инфраструктуру по-максимуму нужно использовать уже готовые.

Но даже если и приходится писать части инфраструктуры самим, то ее можно наращивать ровно в том объеме, в котором это нужно для запланированных на ближайшее время фич. Пока непонятно, почему это должно приводить к спагетти-коду и т.п. — просто не нужно сразу же в инфраструктуре предусматривать «все, что может понадобиться». Принцип YAGNI — как раз об этом.

Все вышесказанное, тем не менее, НЕ отменяет продумывания заранее высокоуровневной архитектуры и интерфейсов между крупными модулями. Это однозначно то, что стоит делать на больших проектах.

Это опять домыслы теоретиков-консультантов. Приведу пример: нужно добавить полнотекстовый поиск, берем готовый движок Solr, ElasticSearch или что-то другое и прикручиваем. Казалось бы нормальный подход сделать по требованиям чтобы работало, приделать кластерную реализацию с zookeeper-ом, обкатать на определенной версии и только потом тулить рюшечки...Как бы не так!

Сначала мы за 1 спринт приделаем глючную standalone версию шоп було шо показать, потом 2-3 спринта пободаемся над мелкими багами: «не находится какая-то хрень», это же супер-критикал надо пофиксить, ко-ко-ко. Потом надо же делать кластерную реализацию, окажется что версия поискового движка не поддерживает фич или самого кластера (мы же делали standalone в спешке за 1 спринт), или zookeeper старый, надо повышать версию. В это самое время супер-критикал баги на еще недоделаный функционал летят как из ведра, и кто-то их подпирает костылями, ведь код на выброс. Сам код представляет собой дикое спагетти и мешанину от поддержки старого и нового подхода. Хорошо если удастся получить требуемый функционал и убрать старую standalone версию, но зачастую оказывается франкенштейн, когда старую версию убрать стремно, а новая тоже нужна, особенно если разные версии. Вечный сапорт обеспечен.

Я предлагаю такие фичи делать по водопаду, понять 80% функционала и за 5-6 спринтов запилить качественно уже на кластерной версии, подключить zookeeper, протестить в облаке и т.д., и ТОЛЬКО СЕЙЧАС обшивать перделками. Поменялись важные требования в середине реализации? Ну извините, когда вы поставили пирог в духовку забыв положить дрожжи, вы какой ожидаете результат?!

Если заранее известно, что реализация должна быть кластерной, то почему бы не запланировать technical story по исследованию, какая версия Solr с какой версией ZooKeeper нормально работают? И потом спокойно пилить вначале standalone реализацию, не беспокоясь о том, что она впоследствии не заведётся на кластере, если кластерное решение вообще понадобится.

Это, скорее, вам теоретики-консультанты напели, что принцип YAGNI исключает анализ рисков и последующее ими управление на проекте.

В предлагаемом же вами подходе, когда радостный девелопер сделал последний коммит рабочей версии и уже готов отдавать билд тестировщику, вдруг выясняется, что бизнес-концепция поменялась и кластерная реализация поиска уже нафиг не нужна. А денежки на ее реализацию-то уже тю-тю...

Поймите, пожалуйста, что «понять 80% функционала» возможно только тогда, когда эти 80% функционала заранее известны. В современном софтостроении это, чаще, исключение.

Ну если нет 80% требований для крупных фич, то это странно и как говорится «Без ТЗ результат ХЗ» и получается именно то, что я описал. Agile хорошо подходит в случаях, когда есть миллиард non-critical багов и мелких импрувментов, типо уползающих кнопок и стилей, которые по своей сложности примерно равномерны, можно их затаскивать в спринт и делать. Для крупных и серьезных фич без достаточных требований Agile не работает и получаются невнятные поделки.

Крупные и серьезные фичи без достаточных требований в любом случае рискуют превратиться в невнятные поделки. Agile снижает эти риски.

Короткие итерации, регулярные демо, регулярный пересмотром приоритетов — значит меньше вероятность построить то, чего заказчик не хотел.

Если нужно принять сложное архитектурное решение, обкатать новый фреймворк — в рамках обычного спринта можно запланировать задачу на R&D, Proof of concept, все что угодно что поможет убрать неопределенность.

Agile — это концепция, философия, принцип. SCRUM — инструмент, бюрократия.
Если использовать инструмент без понимания зачем он вам нужен — получите ситуацию, которую вы описали выше в статтье. Также скорее всего если нет Команды (именно с большой буквы) любой SCRUM и Agile будет только противопоказан. Нужно в первую очередь строить Команду.

По вопросам:
1. Да, ультраэффективен, НО только при правильном подходе.
2. Они нужны только при необходимости и обязательно без заказчика. Даже если вы работаете мега-прозрачно и эффективно, к стендапам с заказчиком нужно готовится. Уже не говоря о том, что вряд ли кто-то из девелоперов осмелиться заявить вам о косяках/багах на таком стендапе при заказчике.
3. Leankit/Kanban. Для стартапа и бутстраппинга самое то.

Профессиональный кухонный философ — кладезь статей и методик на все случаи жизни: психология, учеба, инсайты о работе мозга, а также суровый разбор полетов, непреклонный вывод на чистую воду и борьба с догматами общества. ©

Topic Closed.

Эй, это же с моего сайта!
Что оно делает здесь?

В каждой команде методология меняется в зависимости от того, как именно ее понимают участники, часто вырождаясь в что-то очень странное. Но где взять эталон? ИМХО, нужно больше доверять себе (лично) и подвергать все сомнению — apply common sense. Для меня, например, больше работает техника GTD.

То есть, сначала мы писали функционал и тестили его, и только затем покрывали его тестами.

так это POUTing, а не TDD

1. Да. сейчас это стандарт де-факто почти везде
2. Нормально. раздражает только когда митинги затягиваются на час вместо 15 минут, из-за того что некоторые сотрудники любят троллить коллег и находят в этом удовольствие
3. х..к х..к и в продакшн

Насчет дейли стендапов наблюдал следущую картину: просто монолог каждого человека. При попытке задать вопрос человеку получил гениальный ответ — ты чего мне задаешь вопросы, я же тебе не задавал.В результате стендапы превратились в то, что можно было нести что угодно — врать о каких-то мифических проблемах, делать задачу на 3 дня 2 недели и прочее. Дейли скрам митинги просто превратились в никому не нужную формальность. Имхо, дело не стендапах — просто надо доверие людей и тим спирит, а не отчитался, а дальше хоть трава не расти.

Ты сейчас про дейли скрам в скрам проектах или просто стендап в не-скраме ? Просто в рамках скрама стендап имеет чёткий и понятный всем смысл, а соответственно — и суть, и формат. Скрам, когда он нормальный — един в многообразии своих проявлений (митингов/артефактов/ролей/принципов) — есть цели и приоритеты, есть соглашения и методах и подходах работы, критериях готовности, определённые объёмы и сроки работ, модели поведения в тех или иных ситуациях. Соответственно — и дейли скрам/стендап, подчиняющийся общей концепции, понятен до мелочей и полезен всем (причём абсолютно прозрачным образом). В не-скраме, всяческих околоаджайльных процессах, для того, чтобы такой митинг был эффективным, должно быть чётко определено, зачем нужен этот митинг, какая должна быть входящая и исходящая информация, как и кем она будет использоваться, кто должен участвовать и когда какие действия предпринимать, и почему именно такие данные/участники/методы выбраны и как именно они будут полезнее других. Плюс, естественно, общее, одинаковое понимание всего описанного и соглашение так работать. Иначе — маемо тэ, що маемо.

Соответственно — и дейли скрам/стендап, подчиняющийся общей концепции, понятен до мелочей и полезен всем (причём абсолютно прозрачным образом)
Ну вон не понятен. Чем он полезен? Можно без общих слов и «пойди почитай книжку» (ведь читал же)?

Не буду предлагать почитать, но расширенно процитирую. Дейли Скрам помогает команде, в одно и то же запланированное время («пульс», все дела),достаточно часто (таки ежедневно!) для значительного уменьшения рисков, получить общее, синхронное видение (ага, transparency) их прогресса на пути к достижению Цели(-ей) Спринта. Позволяет понять текущую ситуацию, получить информацию о рисках и проблемах, из-за которых Цель может быть не достигнута и оценить, необходимы ли изменения «тактических» планов работ на следующие дни в спринте. Поскольку значительную часть управления осуществляет сама команда — является базой для принятия управленческих решений, или же эскалации проблем/помех Скрам Мастеру, который должен помочь команде в решении таких вопросов (в том числе, помочь корректно скоммуницировать Продакт Оунеру и/или прочему менеджменту, а также организовать изменение каких-либо планов и нормальную работу после их изменения, в само собой напрашивающейся на пример ситуации, когда «жопа, всё сломалось, ничего не успеваем»). При чём тут вопросы «что делал/что буду делать» ? (про проблемы, кажется, очевидно) — при том, например, что если команда проводила нормальное планирование своих будущих работ в спринте, разбив взятые юзер-стори (или другие PBI) на подзадачи, то все понимают объём работ по каждой подзадаче и их взаимосвязи — соответственно, краткий апдейт по прогрессу по каждому из маленьких «кусочков» даёт достаточно информации, чтобы получить представление о том, насколько команда продвинулась в целом, и прикинуть, насколько планирует продвинуться в ближайшее время. Доски, бёрндауны и бёрнапы помогают прогресс визуализировать, но не являются заменителем нормальной коммуникации. И да, очевидно, но многие сомневаются/спорят — поскольку Спринт, как мини-проект, планируется на довольно короткое время, ежедневный апдейт общего статуса жизненно необходим — хотя уточнять детали по каким-то конкретным пунктам никто не мешает хоть по 10 раз на дню, если это поможет команде, а не вызовет желание набить «уточнятелю» морду. Я ответил на Ваш вопрос?

Дейли Скрам помогает команде, в одно и то же запланированное время («пульс», все дела),достаточно часто (таки ежедневно!) для значительного уменьшения рисков, получить общее, синхронное видение (ага, transparency) их прогресса на пути к достижению Цели(-ей) Спринта.
— Тогда у меня вопрос. Как быть, если вопрос возникает, скажем... через два часа после SCRUM-митинга? Записать на листочке и ждать до следующего дня? Нет же — спрашивать «по месту». Вопрос — почему синхронизация должна происходить в одно и то же время дня, если она и так происходит по 10 раз в день?
Вы свой телефон с компом синхронизируете каждый день в 11:00? Лично я — когда нужно. Так же и с митингами. Есть вопрос — проводим митинг. Всё гладко — зачем отрывать людей от работы?
— Тогда у меня вопрос. Как быть, если вопрос возникает, скажем... через два часа после SCRUM-митинга? Записать на листочке и ждать до следующего дня?
Это кто вам такую глупость сказал? А как же аджайл манифест, аджайл принципы, лучшие практики скрама, здравый смысл наконец? Пойду напьюсь...
Нет же — спрашивать «по месту». Вопрос — почему синхронизация должна происходить в одно и то же время дня, если она и так происходит по 10 раз в день?
Вы свой телефон с компом синхронизируете каждый день в 11:00? Лично я — когда нужно. Так же и с митингами. Есть вопрос — проводим митинг. Всё гладко — зачем отрывать людей от работы?

А) Нехорошо изменять свой вопрос после того, как на него ответили
Б) Не «происходит», а «может происходить». И по точечным вопросам, а не общему статусу.
В) Не путайте тёплое с мягким, а обсуждение проблем с апдейтом статуса
Г) У кого «всё гладко» ? Кто это сказал? Кто об этом знает?

И небольшой бонус от Капитана Очевидность — даже для не синьор-девелопера, работа — это не только код писать ;) Так то!

Я ответил на Ваш вопрос?
В целом да. И я даже понимаю почему это может работать некоторых типах проектов. Однако по прежнему считаю, что на тех проектах, где работал я, он был (бы) бесполезен и даже вреден.
Дейли Скрам помогает команде, в одно и то же запланированное время («пульс», все дела),достаточно часто (таки ежедневно!) для значительного уменьшения рисков, получить общее, синхронное видение (ага, transparency) их прогресса на пути к достижению Цели(-ей) Спринта
А если мне неинтересно это общее видение? Если я не скучаю за очередной веб-страничкой, коих понаделал штук двадцвать за последний месяц, а закапываюсь в глубоком ресерче занимающем всю мою оперативную память? Перебираю инструменты, ищу подводные камни, фикшу внезапно всплывшие баги, а мои коллеги занимаются тем же самым и все что мы можем сказать про задачи друг друга «слава Богу, это не моя проблема»?

Для саппорта лучше Канбан. Ну и в целом, если результатом работы не должен быть регулярно доставляемый инкремент продукта — то не факт, что скрам будет оптимален там. Хотя многое почерпнуть из него всё же можно.

Ну и в целом, если результатом работы не должен быть регулярно доставляемый инкремент продукта
Вот-вот. А зачем он должен быть регулярно доставляемым раз в две недели? Маленький или большой продукт, новый или старый, как правило, в целом он всегда рабочий. Конечно, случаются и сломанные ночные билды и нестабильные модули в не нерелизных ветках, но в целом он вполне работоспособный, чтоб не мешать девелопить, но недостаточно работоспособный для релиза. Все тоже самое, что при разбиении на спринты.
Для саппорта лучше Канбан
Так не обязательно ж саппорт. Любой продукт, где велика доля ресерча, не обязательно существующего кода, а алгоритмического или по интеграции с чем-либо, плохо эстимируется в крупном масштабе, следовательно, плохо нарезается на спринты и редко имеет ежедневный апдейт выходящий за рамки I still working on it.
Как раз на чистом саппорте с этим всем гораздо проще, большую часть тасков можно примерно оценить по сложности, а самое главное сами таски — большинство из которых баги, — как правило, не надо придумывать.

К слову, название Канбан я первый раз услышал два года назад и оно уже успело, как и SCRUM обрасти своими ритуальными танцами. И это несмотря на то, что по такой схеме работали еще до моего рождения.

Вот-вот. А зачем он должен быть регулярно доставляемым раз в две недели?
Это уже выходит за рамки обсуждаемого вопроса. Из разряда того, когда в обсуждении, что же лучше для конкретной компании друзей с конкретными планами — ехать в Европу на машине или лететь — кто-то спрашивает «А на хрена нам эта Европа сдалась? » Так что спасибо, дискуссию закончим.
Вот-вот. А зачем он должен быть регулярно доставляемым раз в две недели? Маленький или большой продукт, новый или старый, как правило, в целом он всегда рабочий.

Потому что код, который написан, но не работает на нужды бизнеса — потерянные деньги. Поэтому идеальная поставка — даже не раз в 2 недели, а непрерывно, по мере готовности фич.

Это если вы пишете интернет-магазин. Если же вы пишете софт с длительным циклом поддержки и с большой стоимостью ошибки, то с одной стороны ваши клиенты не станут апдейтится раз в две недели (некоторые вообще могут не апдейтиться годами, вспомните, например, Windows XP), с другой — вы сами не сможете обеспечить за две недели настолько качественное тестирование, чтоб гарантировать успешный апдейт, скажем, с 14-й итерации 2010-го года на 17-ю итерацию 2014-го во всех возможных окружениях.
Хорошим примером софта с регулярным апдейтами есть VirtualBox — продукт в котором на протяжении минимум полудюжины релизов сломан базовый функционал: в некоторых версиях сломан 3D в CentOS 7, в некоторых — в CentOS 6, а в некоторых — NAT сеть. Это только то, на что я наткнулся сам. Причем пока не поставишь конкретную версию, снеся предыдущую, о проблеме не узнаешь. Разительный контраст с VMware, где релизы выходят редко, зато эти релизы обрастают KB и становятся предсказуемыми. Собственно, именно поэтому VirtualBox — игрушка, а VMware — ынтырпрайз.
Другой хороший пример (из того с чем приходилось работать) софта который апдейтится не когда стОит, а по графику (раз в квартал) — Perforce. Его GUI перманентно сломан, если под «работает» понимать нормальную работу на всех заявленных платформах.

А с Google Chrome что не так?

Никто не говорил что continuous delivery это просто.

Не знаю, я им не пользуюсь.
Я просто хочу показать, что есть софт — оси, платформы виртуализации, софт для бекапа, те же PBX, платформы для видеонаблюдения и прочие, где важна бесперебойность и предсказуемость, — который, как правило, никто не апдейтит без крайней на то необходимости и никто не выпускает в жизнь без тщательного тестирования. Continuous delivery для него бессмысленен.

который, как правило, никто не апдейтит без крайней на то необходимости
вне зависимости от частоты релиза, правда ведь?
я знаю конторы, где все еще живет Windows XP, и встречаю банкоматы с Windows NT. не говоря уже о предприятиях с базой на FoxPro.

Правильно, вне зависимости от частоты релиза. Просто потому что клиенту такого софта в первую очередь важно, чтоб софт работал железобетонно. И только во втором — какие-то новые фичи (которые нужные тем меньшему числу клиентов, чем более софт зрелый).
Поэтому и релизить часто необходимости нет.

Windows XP и FoxPro — зрелый софт, ок.

Банкоматы — устройства с кучей ограничений и небольшим набором функций. К внутреннему софту относятся как к «прошивке» в роутере или игровой приставке. Используют, пока не отработает свою стоимость.

Сравните с современными банкоматами: тач-скрины, миллион функций, постоянные обновления. Это ж всё дополнительная прибыль. Делают, когда железо позволяет.

Сравните с современными банкоматами: тач-скрины,
Вы много таких банкоматов видели? Где-нибудь вообще видели?
... миллион функций, постоянные обновления. Это ж всё дополнительная прибыль. Делают, когда железо позволяет.
Вы в банкоматах и прочих POS хоть разбираетесь? Примерно. Или в чем-нибудь, кроме агиле...

Это ведь важный нюанс последнего: можно чисто технически ни в чем реально технически не разбираться.

ЗЫ: а что вы знаете об обновлениях прошивок в роутерах? Насколько часто Cisco свои обновления выпускает? О роутерах вообще? Об игровых приставках? О виндоус и его «незрелостях»?

Очень даже осмысленен и полезен. Continuous delivery снижает риски, повышает качество и убирает потери по всей цепочке от постановки требований до конечного пользователя. Вопрос только в том, насколько это оправдано финансово в конкретном случае: нужно вложиться в простроение процессов и автоматизацию.

Через несколко лет будет такой же мейнстрим, как сейчас Continuous Integration и DevOps. Есть куча видео и литературы, рекомендую запрыгивать в поезд ;)

Да не будут никогда админы апдейтить инфраструктуру раз в две недели.

Через несколко лет будет такой же мейнстрим, как сейчас Continuous Integration и DevOps. Есть куча видео и литературы, рекомендую запрыгивать в поезд
Этих поездов с десяток на моей памяти было: ноутбуки убьют PC, мобильные платформы убьют десктопы, все уйдут в облака, управляемый код убьет нативный, ажайл спасет мир, всё будет виртуализовано и т. д. Многие из вагончиков этих поездов, в которых приходилось работать, я за свою всего лишь шестилетнюю карьеру разработчика уже даже успел пережить.
Да не будут никогда админы апдейтить инфраструктуру раз в две недели.

Что админам бизнес скажет, то они и будут делать. Это как «да не будут разработчики никогда писать тесты».

Что админам бизнес скажет, то они и будут делать.
Это с точки зрения неграмотного чисто технически агиле так. А с точки зрения самих админов и самого бизнеса есть объективные технические рамки, не говоря уже о технологических и организационных и финансовых.
Continuous delivery снижает риски, повышает качество и убирает потери по всей цепочке от постановки требований до конечного пользователя.
Да не вопрос. Сколько установленных копий скольки продуктов и версий скольки пользователям вы поставляете?
вы сами не сможете обеспечить за две недели настолько качественное тестирование, чтоб гарантировать успешный апдейт, скажем, с 14-й итерации 2010-го года на 17-ю итерацию 2014-го во всех возможных окружениях.
если нет автотестирования, такой кейс в принципе не возможно проверить за разумное время.
олсо, есть разница между "закончили фичу и протестили её"(разработка) и "проверили на всех-всех-всех окружениях, провели цикл регрессионного тестирования, провели тестирование производительности, сформировали в сервис-пак и выложили на скачивание"(деплой)

Вот-вот и предлагается эти два этапа делать «непрерывно».

Канбан тоже можно легко превратить в порнографию. Как говорилось в одной хорошей методичке о нём — в Канбане очень мало требований, но если вы нарушаете одно из них, не говорите, что это Канбан.
Вот давеча беседовал с одним приятелем, у кого на проекте он самый. И вот что интересно, даже понятия об ограничении количества задач в Work In Progress, да и вообще ограничения количества задач в определённой стадии, у них нет.

Канбан тоже можно легко превратить в порнографию.

Это ведь не проблема Канбана, да?

я маю хороший і не дуже хороший (як і описано в статті) досвід зі скрам. На мою думку, справа в команді. Якщо ваша «команда» — це випадкова група людей, то весь аджайл перетворюється на виставу, у якій хтось «тягне ковдру» на себе, на мітінгах лиють воду, як «задтрот» на екзамені, а хтось, просто відсиджується. Таке трапляється (лише з могу досвіду), коли люди набираються в компанію загалом, а не тімлідом у свою конкретну команду.
Скрам може вам гарно служити, якщо ви маєте свободу підбору людей у команду, які б розділяли вашу командну ціль.
І ще, скрам перш за все — це фреймворк (для організації процесу), а не методологія (організований процес). Думаю, що через це не можна давати загальні судження про його вдалість. Десь гарно налаштували — а десь ні , от і все.

Скрам это фреймворк, но аджайл — методология

думаю, Ви дещо помиляєтесь на рахунок «аджайл» — це лиш узагальнюючий термін для ітеративних/інкрементних процесів налаштованих з використанням фреймфорків (скрам, канбан..) та технік, як ТТД, парне програмування і т.д ( хоч ці техніки можуть використовуватись і не в аджайл методологіях)

Чувиха с которой мы начали встречаться ранней весной пару лет назад. Ах! Романтика. Я носил ей конфеты, она ходила в веночках из цветов. Через время мы поженились — такая красивая свадьба была! Потом прошли года, она превратилась в жирную стерву, и вместо утреннего кофе фигачила меня сковородкой...
.. ой, кажется я не туда пишу.

А я то думал стенд-ап для того, что бы узнавать чем занималась/будет заниматься команда, что бы удачней коммуницировать на протяжении дня.

Уберите со стендапов заказчика, перестаньте выпендриватся перед друг другом, перейдите на общепонятный и получите весьма полезные 15 минут рабочего времени, не проведенного на пятой точке.

Если делать это для галочки, то, естественно, это будет удручать, потому, что вы сознательно бесполезно проводите время.

Согласен с этим.
На самом деле если убрать с этой 15-минутки заказчика, то никому не надо ни чем выделываться, готовится и так далее.
Мы просто рассказываем, кто что делал вчера и планирует делает сегодня. Обсуждаем текущие задачи друг с другом, что бы быть в курсе, что вообще команда делает. Особенно это актуально с учетом того, что половина команды в одном, а половина в другом городе.

Если не относится к этому всему слишком серьезно, то ничего страшного нет.

П.С.
А частые овертаймы зло. Мне кажется проблема была не в Agile, а именно в них. И в беганье, как белка в колесе, когда в итоге появляется и накапливается чувство вины, что я что-то не так сделал или не доделал.

Знаете, слово «заблуждение» — это пожалуй самое слабое определение того, как вы охарактеризовали методологии и работы.
1. Смешаны термины. Agile — это подход, если хотите, то философия. Скрам — управленческий framework. XP -тоже отчасти управленческий framework, а вот TDD и парное программирование — это инженерные практики. Вы, по незнанию, объединили их в одно общее слово «agile», подразумевая, вероятно, методологию.
2. Agile и Scrum в примере с «выгорай» опять рассматриваются как равносильные понятия, что в корне не верно. Тем более, что показана классическая ошибка скрам-мастера (хотя сомневаюсь, что он у вас был), когда не определены Definitions of Done и команда вместо potentially shipable product поставляла «лайки.
3. TDD повеселил. Просто от души. Кратко: «Мы не делали TDD и дальше его не делаем. Почему? Хотим мыслить позитивно» :).

Вывод: вам не повезло в том, что вы не видели хорошо работающий процесс. Все аргументы, которые вы привели хорошо известны опытному скрам-мастеру (рутина, выгорание, неприятие и т.д.). Просто тот хаос, который по ошибке назвали «Отжайлом», вы приняли за чистую монету, не удосужившись погрузится в тему. В таком варианте он ГАРАНТИРОВАНО работать не будет. И не ищите поддержки этой мысли в сообществе.

Agile у меня был в связке со SCRUM, XP и другими практиками и подходами. Поэтому лично мне сложно оценить отдельно тот или иной ингредиент этого винегрета. Так уж сложилось, что и XP, и SCRUM и TDD относятся к Agile. И все эти вещи удобнее называть одним словом «Agile», чем каждый раз перечислять все эти аббревиатуры. Говоришь человеку «Agile» и ему сразу становится ясно, что если Agile, то может быть и XP, и TDD, и pair programming и прочие радости.

По поводу выгорания и Agile я с вами соглашусь, что дело здесь не столько в методологии, сколько в правильном менеджменте. Потому как работая на разных проектах, где была разная жёсткость этих самых Agile и SCRUM, я заметил, что устаю по-разному. В приведённом в статье примере был указан именно первый опыт работы по Agile, SCRUM и XP.

Просто тот хаос, который по ошибке назвали «Отжайлом», вы приняли за чистую монету, не удосужившись погрузится в тему. В таком варианте он ГАРАНТИРОВАНО работать не будет. И не ищите поддержки этой мысли в сообществе.
— Но я её нашел. Буквально два дня назад. Когда общался с Антоном, которого вгоняли в печаль всего-лишь жалкие SCRUM-митинги. И в его ушах слово «Agile» тоже почему-то отзывалось болью. Быть может, и у них на проекте SCRUM-мастер работает спустя рукава — не знаю.

Может в вашем случае, и в случае Антона основной проблемой есть не SCRUM митинги, а овертаймы?
И постоянная беготня за тем, кто больше сделает и расскажет об этом?

Можно просто расслабиться и стать флегматиком.
Никак к нему не готовится.
А зачем?
Просто рассказать в паре слов, что ты делал, и что будешь делать сегодня.
Ах да. Заварить перед митингом чай, и просто потихоньку пить его во время митинга :)

Не знаю. Как-то дико напрягают собрания по плану. Даже если на 10 минут. Ну ладно раз в неделю, но зачем каждый день? Висит же эта SCRUM-доска, где всё написано — кто чем занимается. Что-то непонятно? Подошёл к одному человеку — уточнил. Подошёл к другому — поговорил, проверил. Очень надо что-то обсудить втроём? Пожалуйста. Но только когда это нужно, а не по расписанию. Но я конечно понимаю, все эти митинги, даже 10-минутные, заставляют всех казаться такими важными)) особенно с кружечкой чайку ;-)

А зачем казаться важными?

Возможно стоит просто поменять к этому всему отношение — улыбнуться и воспринимать как возможность минут 10-15 пошариться, попить чайку, и пообщаться с коллегами.

У нас перед митингами на прошлой работе мы вообще сначала иногда шутили и рассказывали анекдоты, потом это все плавно переходило в то — что кто сделал и будет делать сегодня.
Но все с веселым выражением лица и улыбками.
Ведь никто никому ничего не должен.
Все просто делают то, что им нравится — любимую работу :)

На нынешней работе у нас коллы по скайпу — часть команды в другом городе — все просто сидят на рабочем месте, рассказывают кто что делал, и иногда спрашивают друг у друга что-то, дают советы как что сделать, если кто-то чем-то занимался, но не смог сделать.

з дошки не завжди очевидно, над чим людина працює (ну на приклад можна зробити фічу без рефакторингу, про який домовились, а можна все разом, чіпляючи інші ділянки коду) і 100% не видно, де в людини затик. а так всі почули, хто що робить, і знають де яка проблема може виникнути. плюс ПО може підказати, що половину фічі поки-що можна викинути, якщо це так довго (так ПО буде ходити і заглядати що кожен робить — по-моєму це гірше, ніж зійтись всім разом на 10 хв).

якщо на дейлі скрамі виникає бажання виглядати важливим — you are doing it wrong, треба бити скрам мастера за хренову організацію процесу.

10 хвилин на одного, 10 на іншого , помножте на кількість членів команди.
Денний стендап — це точка синхронізації команди. Де ми знаходимось відносно цілі, чи нас не блокує щось.
А люди яких дратує зібратись раз на день зазвичай ховають своє заняття чим завгодно лише не роботою.
Ти не один в команді і для будь-якого дещо складнішого за хелловорд проекту є залежності між завданнями і знання коли ти завершиш свою роботу є критичним чи твій колега вчасно завершить свою.

ніколи не працювала в аджайл з XP і парного програмування майже не було. з аджайлом в мене не асоціюється ні ікспі, ні тдд.

в принципі в коментах вже все більш-менш написали, я на всякий випадок спробую сформулювати від себе:

для замовника команда має бути чорним ящиком з продукт овнером (і іноді скрам-мастером) на вході. для продукт овнера під час спрінта команда теж має бути чорним ящиком, з входом через скрам-мастера. іноді ПО може сказати «раз задача забирає стільки часу — давайте її спростимо». все решта він має вирішувати зі скрам мастером і виносити на ретроспективи, навіть якщо застає вас за постійним перегляданням ютуба і т.п.

дейлі скрам мітинг — що реально робив, що буду робити, які проблеми. і мотиваційний: прийшов на роботу, зразу послухав як всі ділом зайняті, зразу сам зарядився сісти за роботу. ніяких звітувань за те, що/чому зробив/не зробив. питання бажано виносити за межі дейлі.

працювати потрібно спокійно і без надривів, не звертаючи уваги на оцінку задачі, яку видали на планнінгу. задача скрам-мастера вирахувати велосіті продукт-овнеру. розрив між оцінкою і виконанням потрібно скорочувати за рахунок обговорення на ретроспективах — іноді потрібно виторговувати окремий спринт на технічний борг, іноді домовлятись краще проводити грумінги, іноді просити СМ і ПО вирішити орг. проблеми — обмежити вплив на команду замовника, змін від інших команд, задач від інших команд і навіть спілкування з ПО.

окремо про тдд моє особисте: я лінива, тому мені простіше написати тест, ніж тестувати руками (при чому не тільки тоді, коли пишеш функціонал, а і коли щось переписуєш — запускаєш тести і спокійно йдеш додому після серйозної переписки важливого коду). реально мені так швидше, не розумію тих, хто все тестує кожен раз руками.

мені особисто весь цей скрам місцями дуже нагадує реаліті-шоу )))), кожен приходить на мітинги, щось зі себе видавлює, хтось з кимось свариться, хтось не витримує такої розтрати часу і виходить... але в результаті всі починають про щось говорити і рано чи пізно реально піднімаються важливі питання і з’являються нові ідеї реорганізації процесу.

але це все можливо тільки коли скрам-мастер толковий і дає процесу котитись самому, щоб люди ті чи інші процеси почали самі вимагати, тому що дійсно їх потребують. на приклад, в нас не було грумінга довгий час, багато хто з цього приводу тільки радів — чим менше мітингів — тим краще. потім пару раз набігались до ПО за поясненнями по сторі і прийшлось переписувати задачі через неправильне розуміння і ПО і програмістами задач — самі попросили проводити грумінги. те саме з тдд: хоч СМ в нас ярий фанат автотестів, ні разу їх не продавлював. ми самі між собою сварились, він давав всім висловлюватись. пару раз прийшлось переписати ключовий функціонал і наловити багів — прихильників автотестів стало більше.

в процесі весь час виникає відчуття, що можна було б все робити і значно швидше і краще, і продумувати наперед ефективніше і т.п. — але суть скрама в тому, що хоч і повільніше, але надійно колектив людей збивається в команду, в якій люди співпрацюють між собою (що часто на багато важливіше за їх тех.рівень) і видають прогнозований результат при постійній зміні задач.

Полностью согласен с автором в плане Agile, очень реально написано, видно что человек сталкивался, а не слышал где-то.

Это Вы не совсем про SCRUM или Agile. Это типа «У нас Agile, вы должны быть гибче, поэтому слегка прогнитесь, вдавите глаза обратно в глазницы, и возьмите эти десять багов в спрынт», а scrum-митинг, это когда один менеджер пинает ногами команду мол «щательнее нада», другой обещает в три короба, а команда заученными фразами «тудай айм воркд он нью фанктионалити, но блокерс, но обстиклс».

Пример про дейли стэндапы: где-то года полтора назад, каждый день, плюс минус в одно время мы собирались и пытались отвечать сакральные вопросы. Вообще помогает понять кто над чем и куда, и в случае чего перегрупироваться. Через какое-то время формальные стэндапы закончились: просто нафиг не нужны, и так все знают все что нужно, можно комфортно обсудить и в течении дня, без единства времени, места и персонажей.

Тоже не поняла, на каком этапе возникаем проблема.
Как раз «фишка» эджайла в опреденной гибкости, а как раз наличие постоянных скрамов дисциплинирует. Этакий нежесткий вариант кнута и пряника.
Проблемы в подготовке к скраму нет, включаются все сразу, учитывая что все проекты на английсвком

«Не понимаю в чём проблема Agile» — от завхоза? Гибкость и дисциплинированность в одном предложении.

А не бывает что это в одном предложении?)

Граммар наци вылез, я молчу) Может быть я не понял мысль. Тоесть выходит как только появился Agile, все расслабились после водопада, и тут же скрам всех вдруг дисциплинировал?

А этот вывод основываясь на чем в моем сообщении был сделан?

Скрам-митинг должен быть быстрым и честным. «Что сделал», «что собираюсь сделать», «что мне мешает». Всё остальное неуместно.

Если программист вчера весь день тупил на DOU и лайкал котиков в фейсбуке — значит, на скрам-митинге так и надо говорить. Всякое бывает и это не повод для огрвыводов. Опытный тим-лид знает, что равномерная производительность труда редко встречается и что оценивать производительность труда программиста надо за какой-то заметный период (хотя бы за пару недель).

Отдельный нюанс в том, что надо говорить «что сделал», а не «что делал». Не надо рассказывать «весь день писал большой модуль, почти дописал». Если за день не удалось сделать ни одного цельного результата, значит, задача недостаточно хорошо разбита на подзадачи (и у неё наверняка кривой estimate).

Менеджерам вход на скрам-митинг запрещён. Менеджер захочет услышать о том что всё хорошо. Не надо менеджерам видеть внутреннюю кухню.

Дима, привет!
Рад слышать от тебя такие слова ;)

хреновый это менеджер, если он только хорошие новости хочет слышать :) з.ы. а упомянутый "

Опытный тим-лид
" это ниразу не менеджер? :)

Могу добавить что многое зависит от Scrum Master — если он организовывать не умеет, то и хорошего ничего не будет.
По поводу менеджера (Engineering Manager) — у нас он не присутствует, но заказчик(Program Manager) на стендапах есть. Единственный прикол — по телеконференции и без права голоса.

Я вообще не понимаю, какое отношение SCRUM имеет к Agile, кроме маркетингового. Ритуальных танцев в нем поболе чем в ином водопаде.
Причем не вполне ясно, зачем большинство из них нужно. У меня дома валяется большая книжка по SCRUM’у, и там больше место посвящено тому как выжить или технично заткнуть его скептиков при внедрении, что тоже показательно.

На одной из прошлых работ, где я проработал полгода, тоже играли в эти игры. Из десятидневной (двухнедельной) итерации начисто вылетали два дня (планирования и демо). Каждое утро начиналось с пятиминутки, на которую с учетом подготовки уходило полчаса. За эту пятиминутку приходилось платить фактически фиксацией рабочего графика и ездой в переполненном автобусе в час пик. После “пятиминутки” шла очередь лидов общаться друг с другом, а потом был доклад к овнеру, когда тот просыпался в своем часовом поясе. Т. о. у лидом вылетало еще по полдня. Моего лида, уволившегося передо мной, сожгли до такой степени, что наследующую работу он решил пойти простым программистом, хотя предлагали и тимлидом.

По-моему, все эти игрушки хороши для простой горизонтально и вертикально масштабируемой работы в стиле “делаем стопицотый в жизни интернет-магазин”, где работа в принципе легко эстимируется и все члены команды занимаются примерно одним и тем же или по крайней мере хорошо понимают, чем занимаются другие.
Если же большинство задач — ресерч и делаются впервые, толку с пятиминуток и фиксированных итераций — ноль.

Нравятся комментарии в стиле

Не хочу образити, але ваш пост нагадав анекдот: “Фігня цей ваш Бітлз, мені Петрович по телефону насвистів”.
Очень напоминает оправдание религий типа “ислам на самом деле мирный” или “христианство на самом деле прогрессивное” и пофигу на первый всегда распространялся войнами и принуждением, а второе всегда приводило к сжиганию ведьм, пока в него по настоящему верили.То все были неправильные имплементации. Социализм-коммунизм тоже так оправдывают. Хорошая штука, но почему-то все его неправильно готовят.

Весь фокус в том, что в том же SCRUM _ни один_ элемент не является обязательным. SCRUM — это набор рекомендаций в стиле «Можно делать вот так-то, таким образом достигается то-то и то-то». А можно не делать. Или делать иначе, так, как подходит конкретной команде, среде и проекту. Только очень во многих компаниях эти наборы рекомендаций почему-то воспринимаются как Священные Скрижали, которым нужно следовать от и до, что и приводит к невероятному бардаку.

Всё ровно наоборот. Правил в Скраме не так много. Почти все они обязательны, природны и потому просты для запоминания. Вы можете модифицировать Скрам, убрав какие-то пункты или добавив в него новые, но, ради Бога, не называйте это Скрамом (вы либо играете в шахматы, либо не в шахматы — не бывает «слегка изменённых шахмат»). А как следствие, не жалуйтесь потом на «бардак», обвиняя в своих косяках процесс.

ну я зараз працюю по нормальному скраму, а описана тут ситуація — дійсно «петрович бітлз по телефону наспівав».

реально нормально працює скрам. якщо ви в ньому бачите якісь ритуали — значить це не аджайл, а «а давайте ми все як завжди під лінійку, тільки назвем це аджайл».

і під ресерч можна пристосувати і, при бажанні, під рефакторинг. в скрамі головне — добитись взаємодії людей в команді, пристосуватись до змін і дати можливість якось рахувати швидкість виконання задачі, не прив’язуючись до оцінок конкретних задач програмістів. все.

ми викидали і грумінг і тдд і участь в дейлі стендапах, і все це було в рамках скраму норм. потім, правда, щось з цього самі просили повернути — вже не як ритуал, а тому що реально це нам було потрібно.

ваше порівняння з релігіями-ідеологіями не корректне, бо вони кажуть, як має бути в ідеалі, але взагалі не враховують практики (хоча насправді вони по-своєму працюють — на курсері зараз хороший курс про історію х’юмен кайнда: людям завжди потрібні історії, які їм дозволяють взаємодіяти з незнайомими людьми, і які заставляють змиритись з поділом. але це офтоп).

скрам — методологія, яка враховує, що на практиці працівники не кожного дня продуктивні, [умовні] замовники міняють постановку задачі, точну оцінку видати неможливо, люди в команді разом не завжди будуть ладити. і дає примітивні інструменти, як це все якось усереднити і все-таки спрогнозувати результат.

Поддержу высказавшихся про неправильное планирование и и кривой менеджмент.
То, что вы описали — это скорее попытка карго-культ-реализации Agile, особенно:

Мы так поверили в Agile и SCRUM, что пару человек из нашей команды даже заказали себе домой по SCRUM-доске из пробки.

И да, ответы:
1. Да
2. Полезны
3. Ту, которую сочтет приемлемым команда разработчиков — возможно, самописный набор процессов, включая элементы Agile.

То, что вы описали, больше похоже на неправильное планирование.
1. Да
2. Норм
3. Agile не исключён

Важно чтобы каждый член команды ответил на вопрос «кто в действительности мне платит зарплату?». Для аутсорсинг бизнеса это конечный заказчик — а все посредники просто перекладывают деньги с одного кармана в другой, оставляя себе за посредничество :) . В продуктовой разработке это инвестор. И для инвестора/конечного заказчика не важно какая методология выбрана, а важно чтобы его деньги эффективно конвертировались в фичи продукта, которые он хочет, а не те которые считают интересным сделать разработчики. Так как нередко происходит наоборот (важные для заказчика фичи делаются неполностью, некачественно, с опозданием, одновременно с тем разрабочики по своей инициативе отвлекаются на интересные им улучшения идеи и т.д.) то заказчик стремится контролировать эффективность конвертации денег в нужные ЕМУ фичи продукта, и SCRUM неплохо в этом помогает. А вот не «пить соки» будет только тот заказчик который не считает денег потраченных на продукт — такие «санта клаусы» еще встречаются, но немного и нечасто, и зачастую такая благотворительность заканчиваются неожиданно с приходом нового менеджера на стороне заказчика, которому топы сказали «пора контролировать расходы в эту бездонную бочку» и начитается «питье соков...» из разработчиков :)

Для смягчения этого самого «кровопития» есть менеджеры (скрам-мастера). Их задача сводится к тому, чтобы оградить команду разработки от летящего в них говна. Мне посчастливилось работать с несколькими такими менеджерами. Поэтому могу сказать — даже самого упёртого кастомера можно склонить на свою сторону при правильном подходе. Либо же просто по-человечески договориться внутри команды об овертаймах и т. д. Но, как показывает жизнь, менеджеру проще «лизнуть» кастомеру или вышестоящему директору и просто перейти на их сторону, присоединившись таким образом к метанию говна в разрабтчиков.

К слову говоря, я ещё не встречал ни в одной IT-компании разработчиков-лодырей, которые хотели бы кого-то обмануть или откосить от работы. Изначально разработчик старается помочь кастомеру в его бизнесе, где-то даже переживает. Но это продолжается ровно до тех пор, пока из него не начинают вить верёвки.

PS. Зарплатные вопросы (угрозы и т. п. наезды, связанные с зарплатой) — удел менеджеров-недоумков, у которых просто нет лидерских качеств. У настоящего менеджера всегда найдётся что сказать своей команде, как заставить её работать эффективнее, или уговорить в случае чего. Обычно, после того как менеджер касается вопроса зарплаты (если разработчик откажется овертаймить, к примеру), разработчик первым делом проверяет свежие вакансии.

Могу только представить как тяжело живется разработчику который считает что в него «кидает говно» тот который даем ему средства к существованию. Я бы на месте такого разработчика это не терпел — уволился и пошел искать другую работу где в него не кидают говно.

Так часто и происходит.

тот который даем ему средства к существованию
не совсем понял. хоть продуктовая контора, хоть аутсорс. деньги платит компания, а контактируешь с конкретным человеком. которому, например, может быть пофиг на развитие продукта и не пофиг на собственный карьерный рост. или же вовсе — на аутсорс отдали кусок, который должен был достаться его команде вместе с бонусами за менеджерство и человек вовсю пытается доказать, что вокруг все лодыри и рукожопы.

Я вас полностью поддерживаю! В описанных ситуациях я бы уволился бы и не мучился, а при поиске новой работы тем кто это испытал на предыдущей работе я советую говорить рекрутеру (чтоб не наступать на грабли): хочу работать в проекте, в котором заказчик не

кидается говном
, не пытается доказать что
что вокруг все лодыри и рукожопы
и заказчику
пофиг на собственный карьерный рост и не пофиг развитие продукта
.

Рекрутер, скорее всего, не будет знать ответы на эти вопросы :)

Лайфхак насчет упёртых кастомеров и овертаймов. Спросить: «А если не через полгода, а через неделю, но только одна фича из 10-ти?». Работает like magic.

Дальше дело техники — построить процесс, который позволяет часто релизиться!

Не всегда. Часто бывает так, что маркетинг заказчика понаобещал все 10 фич своим клиентам и, что хуже, уже наобещал сроки, когда эти фичи будут готовы.

У мене для вас є новина.
Те, про що ви розказали — не Аджайл. Що завгодно, але не Аджайл.

1. Скрам-мітинги проводяться в середині команди. Якщо у вас там з’явились замовники, то не вже не скрам-мітинги.
2. XP не є частиною Аджайлу. Це інженерна практика, а не управлінська. Мені, правда, здалось, що ви мали на увазі CI — continuous integration, але не зрозуміло, чому у вас білди збирали люди, а не Дженкінс.
3. TDD — розробка через тестування. Написання юніт-тестів після функціоналу не є TDD.
4. Аджайл — це якраз проти вигорання. Команда має працювати в зручному, рівномірному режимі. Інакше ви не зможете метриками користуватись.
5. Скрам-мітинги — необхідність. Нагадаю, що їх основою є три питання: «Що зробив?», «Що зроблю?», «Які є проблеми?». Два перші не просто так сформульовані у доконанному часі. Программіст цілком може сказати: «Нічого не зробив». Скрам — це не звіт про те чим займався. Це саме оновлення статусу і прогнозоване оновлення статусу. Неспівпадання їх допоможе виявити проблеми навіть тоді, коли розробник каже, що проблем немає.

Ну і відповіді на питання:
1. Так подобається. Ефективний.
2. Проводимо регулярно.
3. Звісно, що Аджайл.

Не хочу образити, але ваш пост нагадав анекдот: «Фігня цей ваш Бітлз, мені Петрович по телефону насвистів».

1. По-вашему, скрам-митинг проводится только внутри команды. А как же быть, если заказчики являются по-совместительству ещё и программистами, с которыми происходит работа в паре? Демонстративно не звать заказчиков на митинг? Но ведь они тоже берут на себя таски и пишут код.
2. XP — это тип Agile’а (en.wikipedia.org/...eme_programming)
3. >>

Написання юніт-тестів після функціоналу не є TDD
Поэтому я и сказал, что оно у нас было чисто номинальным.
4. Может быть Agile и против выгорания, но у нас не получалось не выгорать.
5. Зачем нужен ежедневный скрам-митинг, если можно высылать каждый вечер отчёт на всю команду? Тем более, что научно доказано — переписка по e-mail — один из самых честных видов коммуникации.

Спасибо за ответы)

Общение фейс-ту-фейс намного эффективнее любых переписок и звонков. Кастомера можно звать на дейли-митинги, но в режиме пассивного слушателя (это придаёт процессу допольнительную прозрачность). Если кастомер по совместительству программист, являющийся частью той же команды — он также может принимать участие в митинге, но в рамках адженды дейли-митинга и только как девелопер, а не кастомер.

Может быть Agile и против выгорания, но у нас не получалось не выгорать.
Увольте продакт овнера и возьмите другого.

швидше скрам-мастера, хоча в мене таке відчуття, що в них і ту і ту роль неправильно виконували.

умовно кажучи, ПО має захищати команду від бізнесу, СМ — команду від ПО.

Заказчик является частью команды и пишет код? Сразу вешаться. Так работать нельзя.

Ага, и заниматься бизнесом вместе с друзьями тоже круто. До какого-то момента. Почему-то во многих случаях такие истории заканчиваются плохо и для бизнеса, и для дружбы.

Про бизнес соглашусь. Что же касается заказчиков, которые умеют кодить и находятся почти ежедневно с командой — в этом вижу достаточно много плюсов. Исчезает звено в виде ПМа, или же его роль становится незначительной — это позволяет избежать эффекта «испорченного телефона». При этом заказчики не требуют чудес, так как понимают специфику работы. Да и опыт можно перенять. Хотя, может вы и правы.

У меня был обратный опыт. Кастомер, он же СТО компании-заказчика, работал с нами в одной комнате. Ничего положительного это ровным счётом не дало, за исключением перманентного ощущения «ока Саурона» на спине. Все рабочие вопросы решались как обычно, через ПМа. Сам кастомер крайне редко принимал участие в процессах команды.

И что в этом такого ужасного? На текущей работе (правда, это продукт, а не аутсорс) код пишут все, вплоть до VP, «чистых манагеров» в разработке нет ни одного и это реально очень круто.

тут напевно замовник — айті компанія, яка частину роботи виконує сама, частину аутсорсить. нічого смертельного, часто навіть навпаки краще, ніж робити щось для не-ІТ замовника.

просто складніше працювати, якщо команди час від часу не зводять разом і замовник не вміє працювати з аутсорсерами — не все додатково комунікує і пояснює. ще тяжко, коли різні часові пояси.

1. Якщо є програмісти на стороні замовника, то можна з ними проводити.
Аврал? Скажи, що ти його вирішив.
Нічого не зробив? Так і кажи. Скрам — це не звіт.
Знову ж таки, на Скрамі не пояснюють: «Я нічого не зробив, в мене є проблема ххх». Все.
Є в мене здогад, що у вас ще й менеджер проекту десь там був. Бо перед ким ще виправдовуватись? Так от в Аджайлі немає такої ролі.

2. Вікіпедія помиляється. Екстремальне програмування як набір техніз з’явилося в 90-их. Аджайл — в 2001. І ще раз, Аджайл — управлінські техніки. ХР — інженерні.

3. Ні. У вас його було. Звідси і купа інших проблему. «Робив я якось качку в яблуках, але качки й яблук не було, то взяв курку й апельсини. Не сподобалось».

4. Тому що у вас не було Аджайлу. «Individuals and interactions over processes and tools» — не потогонка, не спрінти — люди. Якщо ви не слідуєте принципам аджайлу, то це вже щось інше.

5. Не зустрічав таких досліджень. І знову, скрам-мітинг, це не звіт. Це не те місце де треба розказувати чим займався і чим буду займатись. Можна навіть поточний статус висилати поштою, але тоді ніхто не буде це читати. Якщо людям в команді важко спілкуватися між собою, то проблема не в скрамі, а в людях і в тому, хто їх підбирав.

Нічого не зробив? Так і кажи. Скрам — це не звіт.
— здесь я полностью соглашусь. Нет ничего лучше честности.
2. Вікіпедія помиляється. Екстремальне програмування як набір техніз з’явилося в 90-их. Аджайл — в 2001. І ще раз, Аджайл — управлінські техніки. ХР — інженерні.

А его создатели вот с вами не согласны:
«Extreme Programming is one of several popular Agile Processes. »
www.extremeprogramming.org

Ну, значить, і вони помиляються.

The first Extreme Programming project was started March 6, 1996.
Манифест Аджайлу — 2001-ий.

Можна бути гнучкими і без TDD.
На мою думку TDD це обов’язкова інженерна практика.
Як і рев’ю, СІ тощо, автотести.

З TDD все простіше, але відповідати за інженерні практики можуть геть інші люди.
Особливо у великих компаніях.

тоді це не замовники, а рівноцінні члени команди. і перед ними не треба випендрюватись чи відчитуватись.

Аджайл — це якраз проти вигорання. Команда має працювати в зручному, рівномірному режимі. Інакше ви не зможете метриками користуватись.

Плюсую. Одним из пунктов расширенного Agile Manifesto, если не ошибаюсь, был как раз sustainable pace.

1.на скрам-митинг(daily) можете спокойно позвать ПО, по скраму(Agile) ПО есть член команды.

Не член команды, а участник Скрам-процесса. И тем не менее, присутствовать могут все. Просто говорят только «свиньи».

www.scrumalliance.org/...um-values-roles
Scrum roles
A Scrum team /*команда!??*/ has three roles:
Product Owner — holds the vision for the product
ScrumMaster — helps the team best use Scrum to build the product
Development team — builds the product

P.S Ken Schwaber/*en.wikipedia.org/.../Ken_Schwaber создатель скрама был основателем www.scrumalliance.org, ну и многого еще чего...

Под «командой» чаще всего поразумевают Development team, а не Scrum team. (это если в контексте ответа на предыдущий коммент). И таки участвовать могут не только лишь все, не каждый может это делать. Дев тим онли ;)

Присутствуют все, но говорят только «свиньи».

Программіст цілком може сказати: “Нічого не зробив”
То есть так надо говорить все те несколько дней, которые программист решал одну проблему?

Так.
Якщо є якісь проблеми, то він має їх озвучити.
Але як показує досвід, то майже будь-яку задачу можна розбити на підзадачі, що цілком вміщаються в день роботи. Більш того — ці підзадачі можна тестувати доки основна задача не завершена.

Как правило, в проекте задачи с годами не становятся интереснее. Всё начинает сводиться к методичному баг-фиксингу, оптимизации и перепиливанию одного говнокода на другой говнокод (потому что надо быстро и вчера, и вообще «там же нечего делать, уже ведь всё готово»). Выгорание наступает никак не из-за Аджайла. Вернее, состояние фрустрации и ностальгии по лучшим временам усугубляется, например, когда реквайрмент менеджер (продакт овнер, или кто там у вас) не справляется со своей работой, то есть не предоставляет реквайрменты и не продумывает если не все кейсы, то хотя бы базовое флоу (а по моему опыту могу сказать — это случается постоянно). Опять же, отсутствие дизайнерских мокапов добавляет в эту бочку ещё одну ложку дёгтя. Ну и, конечно же, полное игнорирование пожеланий разработчиков по процессам (опять же, по моему опыту — разработчики никогда не просят чего-то радикального или сверхъестественного). Всё это вместе взятое приводит к выгоранию разработчиков и к их уходу. А теперь вопрос: виноват ли Аджайл, если не выполняется элементарный SMART?

Отвечаю на вопросы:
1. Да, Аджайл лучшая методика из всех мне известных. В сфере разработки ПО только она, пожалуй, и эффективна. ИМХО.
2. Положительно, только если они не превращаются в репортинг менеджеру или кастомеру. В противном случае — будет только хуже.
3. Использовал бы Скрам.

А теперь вопрос: виноват ли Аджайл, если не выполняется элементарный SMART?
о, да
ППКС
Да, Аджайл лучшая методика из всех мне известных. В сфере разработки ПО только она, пожалуй, и эффективна. ИМХО.
Ой Дим, не согласен. Только для краткосрочных проектов, и думаю только для внешнего заказчика.

Возможно. Потому и написал — ИМХО. Когда проект плавно перетекает в стадию саппорта, часто начинают применять Канбан вместо Скрама.

Канбан хорош, но если посмотреть, то использовался любым саппортом задолго до названия своего )

то использовался любым саппортом задолго до названия своего
та какая разница? паттерны были и до описания GoF. просто удобно, когда все на одной волне и достаточно одного слова вместо 10 предложений.

Сейчас еще набирает популярность такое движение, как disciplined Agile — по сути, это RUP, каким он должен был быть. И SAFe еще для проектов большого масштаба.

С внутренним заказчиком видел только одну явную проблему: поначалу тяжело сдерживать бизнес от глобального изменения приоритетов по ходу итерации. Со временем привыкают и начинают ценить предсказуемость и повторяемость.

А что не так с долгосрочными проектами? Насколько долгосрочные?

agilemanifesto.org/iso/uk
А вы... вы просто искали того, кто подержит верблюдицу.

Подписаться на комментарии