×Закрыть

To Be Agile Or Not To Be Agile?

Сказка. А может, и быль. В одной большой компании было несколько офисов, в частности, офис в городе A (в дальнейшем — просто Team А) и офис в городе B (в дальнейшем — просто Team B). В этих офисах практически в одно и то же время начинались два проекта для двух разных клиентов.


© nigelmaine

Команды были одинакового уровня технической экспертизы; использовали одинаковый набор технологий; оба проекта были примерно на одном уровне сложности бизнес-фукнциональности, а заказчики одинаково четко понимали, что им необходимо (PDF-документ в 10 листов). Оба проекта были оценены в четыре месяца разработки.

Начало

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

Team B решила писать документацию по ходу выполнения. Они пригласили Product Owner к себе и, собрав экспертную группу, закрылись с ним в одной комнате. Через две недели были готовы (довольно поверхностные) диаграммы модулей и их взаимодействия, определены технологии и используемые фреймворки, составлен продукт-беклог, уточнено и оценено задач на два спринта вперед, выбран спринт-беклог. Началась имплементация.

Коротко ли, долго ли — но прошел месяц.

Первые результаты

Team A дописала и дооформила очень детальную design specification, составила и утвердила (подписала у клиента) план проекта и была готова приступить к реализации.

Team B — как раз закончила первый спринт и демонстрировала клиенту первый релиз.

Быстро сказка сказывается, да не быстро код пишется и тестится.

Минул еще месяц

Team A с удивлением обнаружила, что после их первого релиза клиент поменял свои требования, и теперь они не совпадают с тем, что было зафиксированно и подписано. Клиент, скрепя сердце, соглашается с изменениями (подписано ведь) и платит за них. Архитектура проекта все больше и больше отклоняется от изначальной.

Что же происходит в Team B? Клиент тоже меняет требования, добавляет истории и детализацию в беклог. Количество feature points, в которые оценивается беклог, уже вдвое превысила тот «very basic», с которого начинали. Клиент волнуется что новый, раздутый скоп не будет выполнен к оговоренному времени. Однако он не платит за изменения и (после детального многочасового разъяснения ситуации), очень ответственно подходит к приоритезации задач.

Прошли оговоренные четыре месяца

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

Team B, успешно сдав клиенту «basic, but functional» версию, трудится над второй фазой (advanced). В неё перешло большинство «дополнительных» задач которые клиент увидел и добавил в ходе первого этапа. Клиент счастлив и поговаривает о фазе номер три.

Мораль

Здесь, как в известной песне: «Думайте сами, решайте сами — иметь или не иметь».

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

Конечно, все это становится возможным при определенных обстоятельствах:

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

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

Ещё немного морали

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

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

Хотя, конечно, за четыре месяца Team А заработала больше денег за счет change request-ов. :-)

👍НравитсяПонравилось0
В избранноеВ избранном0
Подписаться на автора
LinkedIn

Похожие статьи



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

Вот что лично мне представляется странным в Agile.

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

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

3. Отсутствием яркого лидерства. Все сколько-нибудь значимые проекты (и программные тоже) в истории — никогда не есть произведение коллектива авторов. Покажите мне коллективную поэму. Или язык программирования, который разработал коллектив. Прекрасную скрипку коллектива итальянских мастеров XVII века (вы не поверите, Страдивари тоже делал их для клиентов!). В связи с тем, что бывает очень огромная разница в опыте, способностях, творческой энергии и т.п. в коллективе программистов наличие лидеров — неизбежно. Зачем строить методику на отрицании лидерства как такового, что мы выигрываем?

4. Код становится выше всех остальных рабочих артефактов. Это прямое отрицание накопленного опыта. RUP подытоживает опыт десятилетий и говорит: программный продукт — это набор артефактов как-то: документация, спецификации, архитектура, код, описание дефектов, .... (может быть бесконечный список). Если у нас есть хороший проработанный проект, то закодировать его можно. Аргументация Agile — на это нет времени, главное код. Хороший аргумент. Мои возражения:
4.1 На составление проекта физически тратиться меньше времени, чем на кодирование. Для этого и придумали эскизы, чтобы каждый раз не строить пробный образец. А работу можно распараллелить. Тот же RUP тоже не поощряет водопад.
4.2 При анализе на бумаге можно быстрее исправить ошибки.
4.3 При выполнении повторного проекта другой группой уже есть много элемента для повторного использования.
4.4 QA работать трудно (практически невозможно), имея только код. Требования тоже должны тестироваться. Нет особого смысла тестировать программу до тестирования требований на непротивроечивость. Достижимость некоторых требований, например, производительности или надёжности, должна проверяться на ранних этапах — это определяет архитектуру.

Ну и так далее. Это классика, нет необходимости повторять учебники. (Из собственного опыта: да, по книжкам строить рабочий процесс нельзя. Во всём нужен опыт. Но из этого не следует Agile. )

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

5. Из разговора с серьёзными разработчиками я делаю вывод, что я не один не люблю Agile.

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

Я не готов покупать всю методологию целиком как бренд и говорить «я работаю по Agile». Это глупость. Если кто умеет, допустим, кататься на лыжах, тому не надо читать новый учебник, как это делать. У того уже много наработок на рефлекторном уровне.

7. Групповая ответственность это хорошо, но это — утопия. Хороший руководитель, как мне кажется, всегда распределит на каждого столько ответственности, сколько тот способен потянуть, всё остальное возьмёт на себя. Бывает на практике, когда умение брать ответственность — то, что спасает проект. Иногда, наоборот, её пытаются взять те, кто не потянет. Опыт руководителя УЖЕ подразумевает то, что в критической ситуацию ОН должен брать ответственность за ход проекта. А это подразумевает то, что он пользуется авторитетом. Авторитет и подавление команды — не одно и то же, как многие Junior-ы привыкли думать.

8. Не понятно, как работать с Fixed price проектами. Боюсь писать, потому что знаю реакцию Agile тренеров. У них есть рецепты! Они заключаются в следующем
8.1 Вам посочувствуют (хотя я люблю fixed price и на нём специализируюсь, вообще-то)

8.2 Вам скажут как можно «максимально подтянуть» ваш процесс под Agile (только не понятно зачем).

Ну и так далее, уже много текста. Много чего ещё можно придумать, да времени на это нет. За сим заканчиваю.

395 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.
Проект на 4 месяца... Agile vs waterfall... Знаете, мне кажется, что при обсуждении применимости методик стоит говорить о том, для каких проектов это используется.
Например, ну не вяжется у меня Agile с проработанной архитектурой. Тут бенефит только в том, что мы измначально всем говорим что мы непонятно че хотим, поэтому будем меня на ходу, перерабатывая и архитектуру и UI и вообще все в зависимости от изменяющегося видения продукта. И если это аутсорс — то без проблем, почему бы и нет. В конце концов, клиент платит за время, мы говорим что это примерно 4 месяца и он понимает, что ему надо заплатить, скажем 100 штук. И за них он получит то, что мы успеем за 4 месяца. Но это не значит, что он получит законченный продукт. А все потому что он его и не заказывал, он заказывал РАЗРАБОТКУ, а не ПРОДУКТ.
Альтернативный подход в какой-то мере больше похож на waterfall, но это скорее внешняя схожесть. Смотрите, нас не истересуют формальный спецификации, нас так же не интересует тестирование после реализации и другие атрибуты waterfall. Нас интересует четкое видение продукта, его аудитории, задач и т.п. до начала разработки. То есть корректный product management.
Я веду к тому, что охватить продукт, который надо кодить 4 месяца (а если он продуман, то и меньше) можно примерно за месяц работы двух человек — Product manager и UX-дизайнер. В случае назнакомой предметной области — еще и бизнес-аналитик. Они прорабатывают продукт и показывают результаты клиенту. На этом этапе технических спецов надо подключать только на пару дней на консультирование что можно/нельзя делать. Ну и потом работаем уже командой с итерациями, приоритизированным беклогом и другими плюшками.
Клиент (который платит) ничего в беклоге не меняет. С какой радости ему менять, если он:
— не умеет проектировать продукт лучше PM
— не умеет дизайнить лучше UX-спеца
— не знает требования юзеров лучше бизнес-аналитика

Единственное где он знает что-то лучше нас — это его бизнес-модель. Соответственно и менять что-то надо только в случае ее изменений. А это далеко не так часто как «ой, действительно, тут же надо редактировать инфу, а места уже нету, надо перепроектировать UI и, заодно, архитектуру»

Если речь просто о продаже услуг девелопмента без ответственности за конечный продукт, то SCRUM/Kanban вполне себе уместен, потому что тут Product management дается на откуп клиенту, который обычно это делать не умеет. Отсюда и имеем «хороший» и «плохой» SCRUM.

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

Ошибка Команды А в том, что они неправильно проработали продукт, а команды Б — что они этого вообще не сделали. Тут должна работать умная команда С, которая вообще отправляет девов в отпуск на месяц и делает классный продукт за оставшиеся 3 :)

Сейчас Вас, Константин, местные Аджайло коачи порвут на части -)))))

Аджайло коачи сейчас не в моде. Сейчас в моде ангельские инвесторы, т.е. люди, которые могут инвестировать свои кровные 300 долларов на начально стадии проекта :) Вот эти особо суровы, а аджайл евангилисты не... не то...)))

Я не переживаю, главное чтобы поддержали люди с опытом создания продуктов, а не продажи «человекочасов»

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

Почему аджайл хорошо работает в ИТ? Да потому что заказчик часто заранее не знает что он хочет: «яблоки» или «арбузы». Поэтому если начинали делать яблоки, потом заказчик захотел «со вкусом арбузов», а в результате получились дыни то он все равно останется доволен («мед даже лучше»).

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

Вот поэтому методику и надо выбирать под проект. Так же не обязательно брать что то одно (только Скрам или Руп) — вполне можно «компилировать».

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

Посадил пшеницу — а по ходу вдруг начала расти кукуруза или того хуже — помидоры. Ой, что делать!? Или вот — с самого начала «я вся такая изменчивая бизнесмена — я не знаю, чем мне лучше заняться: огурцами или арбузами» (к)

«Если начинали, а потом заказчик захотел, а в результате получилось совсем другое, то он все равно остался доволен» — это означает только одно: у заказчика не «бизнес», а такая себе... :) подставить по вкусу. А задача подрядчика в данном случае — не решить проблему заказчика (проблема которого на самом деле — вавка в голове), а последовательно впарить ему свои услуги, растянув сроки по максимуму и по максимуму ограничив свою ответственность за результат. Ведь в результате «получилось то, что хотел заказчик», правильно? Значит к подрядчику претензий нет.

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

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

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

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

Есть сферы, где нужно, чтобы было стабильно и качественно в первую очередь,

Собственно, эти «есть сферы» — и есть бизнес.

... а поэтому медленно и дорого...

Интересно, откуда такой тезис? Я оцениваю скорее наоборот: если не знаешь, куда идти — гораздо труднее дойти туда прямой и ровной дорогой, тем более что опыт прохождения этого пути и инструменты для этого — уже отработаны и могут просто комбинироваться в зависимости от цели. Строим мы большой самолет или маленький, строим дом или промышленный комплекс — процесс отработан и идет максимально прямым и коротким путем. Где здесь «медленно и дорого»? Мне действительно интересно, на чем основывается этот вывод в сравнении «альтернативных» и «классических» методологий?

Вот именно, что «альтернативы» — хороши для

а какой-нибудь плагин для вордпресса

Мне в этом отношении больше нравится термин «социальные сети для собак».

Денис, Вам ведь нравится, когда поезд ходит по расписанию, лифт останавливается на нужном этаже, микроволновка и стиралка работают точно по заданной программе? :) Мне кажется, или

Agile — не панацея, но она позволяет сделать работающий продукт

Относится к продуктам класса «ну не сделали — и ладно»?

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

... а поэтому медленно и дорого...

Интересно, откуда такой тезис?

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

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

Это тоже все так, только чью работу таким образом можно сделать легче? Нашу. Кому больше пользы? Так действительно легче для разработчика. Написали, утвердили, получите. Эджайл, же как мне кажется, задумывался, чтобы помочь в первую очередь клиенту. Довольный клиент — одно из главных условий. Довольный клиент вернется и приведет с собой кого-то, потому что он знает, что можно, например, внести правку на самой последней стадии, ту правку, которая даст ему преимущество перед конкурентами, которые свои спеки утвердили в начале разработки их продукта и ждут. Ждут надежного продукта, который может быть уже никому и не нужен. Дождутся, но пенять могут только на себя. Все по спеку. Никаких претензий к разработчику.

Денис, Вам ведь нравится, когда поезд ходит по расписанию, лифт останавливается на нужном этаже, микроволновка и стиралка работают точно по заданной программе? :)

Да, мне нравится порядок. Но к сожалению, нельзя убить всех убийц... :) С преступностью нужно бороться так-то по-другому. :)

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

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

Или тогда мы потеряем и клиента, и может даже саму «методологию»? :)

Насчет:

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

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

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

Полностью с Вами согласен. Бизнес — это когда деньги зарабатывают. Если клиент возвращается — он приносит еще немного денег. Хочет он иметь возможность вносить кардинальные правки для этого в конце процесса разработки — пожалуйста.

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

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

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

Не верно, что команда А заработала бы больше. Сомнительна гипотеза, что заказчик не думая мог набрасывать change request в бэклог вотрефоллу. Скорее наоборот.

А вот команда B, применив Канбан, вообще без сколь-либо сложных переговоров может примнимать change request-ы, на протяжении многих лет. Больше скажу — сотрудники предприятия заказчика, которые будут непосредственными пользователями и/или получателями жалоб/предложений, без ложной скромности будут видеть в изменениях прогресс для компании, и понимать что команда B производит рост бизнесу, приносит денежку.

С командой А — всё плачевно. Продукт встанет на этапе после сдачи. При современной сложности софта, возникнут серьёзные проблемы уже после сдачи, и не смогут быть исправлены. На стороне заказчика найдутся люди, которые ГРОМКО и АВТОРИТЕТНО заявят, что сделайте всё как раньше — надо работать!

В общем, To Be, но не так тупо, как вот в этом примере — software-testing.ru/...age__pid__99637

«Дод» ему подавай...

Набрёл на каноническую фразу на приведённой странице

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

Возможно тогда вы сможете прочесть, что аджайл манифест не противоречит ни водопаду, ни ГОСТ 34.х + ГОСТ 9126 + ГОСТ 28195, ни всякому разному прочему.
Все что там сказано, это то, что человекоориентированность ценится больше процессоориентированности. Все.

Уважаю человека, это написавшего (минимум за способность читать манифест пол года). Но.

Господа, не кажется ли вам что в нём вообще ничего конкретного (в манифесте) не сказано. То есть, взяв манифест мы не можем каким-то однозначным способом прийти к методике (чем, собственно, и кормятся тренеры).

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

Пример.

Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.

Who is the «customer». Если заказчик — промежуточная прокладка со своим маркетинговым отделом, то где наш customer? Кого мы собственно, как специалисты, должны-таки удовлетворять?

Ну это один вопрос. Если кто работал с требованиями — там вопросов возникает куча.

Я работал с требованиями в Agile на очень грамотно поставленном проекте. Заказ там представляло несколько человек сразу :) Был не ОДИН «владелец продукта», а был главный манагер, который отслеживал ход всех дел и лично отвечал за ВЕСЬ проект; и было аж два аналитика (настоящие аналитики, а не то, что обычно подразумевается в наших краях), которые сами когда-то были трейдерами, и которые теперь работали непосредственно с трейдерами. Аналитики получали от работников биржи сообщения о том, что хорошо/плохо & надо/не надо, и оформляли эти идеи в виде юз-кейсов — пошагово, с мокап-картинками. Там и кейсы расписывать не было необходимости, было достаточно только идеи генерировать по примерам использования, да записать в виде чек-листа.

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

Сравнить?

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

взяв манифест мы не можем каким-то однозначным способом прийти к методике

У вас неверные ожидания от манифеста :)

Манифест — это как соглашение об определенных принципах, а не о конкретных действиях.

Например: «Джентльмены не убивают военнопленных согласно женевской конвенции.» Конкретной методики обращения с военнопленными нет. Например, их явно нельзя убивать, но джентльмены могут неявно перестать их кормить :)

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

Культ карго во всей красе.

Манифест — это как соглашение об определенных принципах, а не о конкретных действиях.

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

Хорошо. Но откуда такое желание у некоторых групп разработчиков работать по Agile, даже когда это не возможно (в силу, например, редких связей с клиентом). Чем же он реально оказывается привлекательным, Agile?

Fun? Quality? Мода?

Ведь работало как-то до этого всё и без Agile.

Agile отлично расширяет сознание и возможности с технической точки зрения. Он рулит, если сознание уже не узкое и возможности уже какие-то наработаны.

Он рулит в уже сильных и умелых руках.

А если сознание empty, и руки еще слабые, то — религия не позволяет сомневаться в религии :) Или же: «Да у вас просто неправильный agile, вот и всё! Поменяйте планету, и дела у вас наладятся...»

Вообще, уже сложно понять, почему agile — это что-то отдельное, однозначное, четко формулируемое и процессно повторяемое.

Быть гибким в waterfall-процессе — это ли не вершина agile?

Культ карго во всей красе.

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

Согласен, с этим потом спорили. Но ведь в Agile достичь некоторого измеримого качества (хотя бы так: не хуже, чем в предыдущем проекте) намного более проблематично. Можно сдать, вероятно, всё, если в момент времени t это понравилось клиенту.

Более подробно о качестве писал здесь

Но ведь в Agile достичь некоторого измеримого качества (хотя бы так: не хуже, чем в предыдущем проекте) намного более проблематично.

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

Для менеджера в Agile другой фокус работы — нужно работать не столько над планом проекта (задачи, сроки и т.п.), сколько над командой (полноценный people management, который у нас очень мало кто умеет).

То есть можно сказать следующее.

Позиция 1. Качественный продукт следствие качественного процесса.

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

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

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

Интересно, какой пункт Agile манифеста не дает Вам это сделать?

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

А манифест чтоб брать — должно быть понимание, зачем оно нужно.

Мне кажется, что если сложно формально оценить процесс, то вполне можно формально оценить результат.

На каком-то этапе — да.

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

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

Либо простая теория вероятности. Если команда сделала 10 успешных релизов, то вероятность того, что имея того же PM-ма с головой, она выпустит 11-ую такой же успешной, велика.

Культ личности?

Кстати, а вроде PM-а в скраме нет.

Культ личности?

Доверие и делегирование полномочий. Без этого получается культ чьей-нибудь другой личности...

Стоп, мы о процессе разработки или о quality assurance говорим?

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

Да так же, как и до эпохи исторического материализма Agile. И вообще, причем тут quality control? Он как раз в правильном Agile (т.е., с инженерной т.з. использующем XP на всю катушку) полностью автоматизирован (включая и нагрузочное тестирование). Или я не понял вопрос?

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

Он как раз в правильном Agile (т.е., с инженерной т.з. использующем XP на всю катушку) полностью автоматизирован (включая и нагрузочное тестирование).

... и в каком пункте манифеста об этом говориться?

А вот про нагрузочное тестирование не соглашусь. Прежде чем проводить нагрузочное тестирование надо сформулировать требования по нагрузке, что ещё та работа. А иначе это уже не тестирование а эксперимент типа получилось-не получилось, post factum. Ну, если клиент ждёт пока вы переделываете — хорошо конечно, повезло вам. Но методика для предсказуемого результата а не для везения сделана.

В принципе, есть соль в том, что Agile «несколько» усложняет quality control. Живой тестировщик может и не выжить... только автоматы останутся, поэтому может и правильно растворить тестирование в комманде, не забывая про его. Но как я понимаю, Agile и был написан как способ угнаться за вечно меняющейся коньюнктурой. Там, где нужна стабильность на годы, возможно, нужно ограничиться манифестом...

Часто ошибочно полагают (не в последнюю очередь, благодаря «религиозным фанатикам»), что аджайл в принципе запрещает любое предварительное планирование. Это не так — аджайл говорит всего лишь о том, чтобы не пытаться сразу запланировать все до мелочей. В том же пресловутом Скраме есть понятие планирования релизов, в процессе которого «крупными мазками» выясняются требования на ближайшие 3-6 месяцев работы.

Полностью же адаптивный процесс имеет довольно узкие рамки применимости и очень высокую планку человеческого фактора. Но именно его почему-то считают панацеей и чуть ли не «единственно верным» воплощением манифеста.

Ну осталось только поднять темы IPhone/Android или Windows/Linux(Mac, вставить нужное)

А зачем писать столько букв и вставлять картинки, если можно всю эту статью выразить 1 предложением : «Скрам рулит, а все остальные методологии — нет»

Ruslan K

подопытный в Smile Ukraine вчера

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

Навіть більше — зрозуміло, що архітектурно система повинна мати достатню гнучкість (знов таки наскільки достатню ? — питання до досвіду, знань, загального розуміння і інтуїції ПМ\Архітектора ) проте архітектура системи є відображенням самого рішення поставленої задачі — певної вибудованої моделі, причому модель не є статична, а є певним набором з означеними можливостями подальшої деталізації/еволюції.

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

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

Якщо попередні пункти зроблені правильно то в більшості випадків не виникає жодних великих складностей зі зміною вимог і подальшим розвитком системи.

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

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

До того как выполнить задачи 1 и 2, надо спроектировать продукт с точки зрения юзера. Можно полностью (с персонажами, UX, требованиями и т.п.), можно хотя бы просто в интерфейсе (детально), тогда решение обеих задач сильно упрощается.

Sergei Lodyagin
Founder в Kogorta вчера

Да нет, Дима, разница в том, что в команда A думала сама, а команда B оутсорсила функцию мозга обратно заказчику, и тот остался доволен как слон, что его развели за его собственные деньги.

+100500
Одне з чому і не подобається це мені.
Доречі, а як в випадку з продуктом який треба буде продати сотні кастомерів ? Причому на етапі імплементації в кожного з них виникають якісь свої нюанси, відмінності і тд ?
Більше того з свого досвіду:
Є проблема(вимога) запущені люди котрі думають, що можна зробити і як причому передбачається найкращий варіант вирішення проте ризики, що вийде високі, і кілька резервних варіантів (також ризикованих але менше) тих, що гірше, але тим не менше вирішують поставлену задачу. Терміни всі визначені, бюджет також ?
Тільки не треба говорити про аналіз, узгодження, комунікейшини і тд — все це в даному випадку має цінність 0, бо сказано що якщо до 25 квітня це вирішено не буде то даний продукт тим кастомером куплений не буде також (куплять інший) ? Ось де тут спрінти, овнери і тд ?

А в ПМ задача до 25 зробити і він відповідальний за рішення, розприділення людей, він вислуховує декількох сеньойорів які обіцяють, що зроблять, деякі кажуть не вийде і йому приймати рішення як і що робити, ось в цій ситуації можна повісити відповідальність на команду ?

Команда — это единый организм, поэтому виновата всегда вся команда, а не конкретный ПМ. разработчик, тестер и т.д.

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

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

Стремиться брать ответственность — это похвально, но, как я и писал, опасность в том, что при «групповом поведении» её могут брать в качестве эдаких «медалей» те, кто ещё не знает, что это такое на самом-то деле.

(Потому как умный-то в гору не пойдёт.)

Потому ответственность должна распределяться правильно.

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

Аджаилефилы скажут (знаю я их) — так это и есть Agile!

Я скажу — а при чём тут Agile?

Аджаилефилы скажут (знаю я их) — так это и есть Agile!

Я скажу — а при чём тут Agile?

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

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

Ну да, все та же проблема леса и деревьев.

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

Тогда у меня вопрос: а что же делать незрелым командам?

«Зрелые» команды не берутся ниоткуда. Как-то они должны созреть, but it seems, Agile им в этом не помощник.

Зреть, наверное

Ну естественно, «23-летним синьорам» стоит сначала поработать по RUP, научиться себя организовывать. Никто и не говорит, что любая команда может по скраму работать.

Ну естественно, «23-летним синьорам» стоит сначала поработать по RUP, научиться себя организовывать.

Да, согласен. Но этот этап пропускается в угоду моде.

Никто и не говорит, что любая команда может по скраму работать.

Да вот в том-то и беда, что не просто говорят, а вталкивают всех в это прокрустово ложе. Разумеется, это не лично к Вам претензии, это констатация фактов, которые, как видим, тупо аффектят всю атмосферу вокруг Agile.

Грамотный (ключевое слово) скрам мастер/коуч им в этом очень даже помощник. При этом, под грамотностью я понимаю в первую очередь не получение бумажки с сертификатом, а

  1. Глубокое понимание того, как и почему работает Agile-подход, какие принципы заложены в его основе и как они взаимодействуют между собой
  2. Умение работать с людьми, быть именно хорошим тренером в спортивном смысле этого слова

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

И второй, даже более интересный.

То есть если на проекте насаждается Agile, то это недвусмысленно означает, что все участники — зрелая команда, значит зарплата у всех должна быть минимум на уровне сеньора, я правильно понимаю?

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

Вы мне хоть этого сеньора определите. Что это за зверь? 23-летний перец с зеркалкой, зарплатой и ЧСВ?

А Вы хоть определите «зрелую команду». Которой уже таки будут доступны сияющие вершины чистого Agile.

Сакрализация, как и было сказано.

Это оставьте для бодишопа

С бодишопом угадали, коллега, не вижу причин этого стыдиться. Но где же работаете Вы?

А Вы хоть определите «зрелую команду».

Ну, хотя бы для затравки: Команда, в которой каждый участник обладает сильной внутренней мотивацией, зрелостью и умеет брать как личную, так и , что не менее важно, коллективную ответственность за результат.

Ну, хотя бы для затравки:

Мгм. И сколько же их таких есть в масштабах Вселенной? Не, есть канешна, но не так чтобы уж в промышленных количествах, не так ли?

Ну то есть да, ниша для Аджайла вырисовывается. Но она не выглядит широкой. Поэтому всеобщие страсти по Аджайл мне всё так же непонятны, как и до прочтения этой ветки.

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

да! повысьте мне зп вдвое, и я согласен на любой аджайл!

Ну кстати да, у нас в том проекте, что я описывал тут в комментах, все и были сеньоры с соотв. з/п.

С другой стороны, когда команда уже сработалась, то туда можно и нужно потихоньку добавлять менее опытных товарищей (с целью дорастить их до общего уровня).

Очень удобно.

То есть, реально получается следующее.

Agile выжимает из разработчиков — раз, выжимает из заказчиков — два,
НО
все довольны и ещё активнейшим образом демонстрируют лозунг «а у вас ещё не Agile?»

А учёные нашли уже этот вирус?

В целом, если опустить войны между аджайл-фанами и неаджайл-фанами, есть следующее:
1. Agile удобен, если компания предоставляет заказчику услуги аутстаффинга. Т.е. большую часть ответственности берет на себя кастомер. Как уже писали ранее, компания заставляет кастомера сорсить свои мозги и, возможно, менеджмент.
2. Если компания предлагает услугу разработать проект фиксед прайс (без привязки, по скраму или нет, т.е. на выходе выдать чисто готовый продукт), то кастомеру фиолетово по аджайлу, и называется ли аджайл аджайлом вообще, ему главное чтобы сделали вовремя :)

Разница между пунктом 1 и пунктом 2 в том, что в случае пункта 2 заказчик заплатит больше за тот же объем работ + компенсирует дополнительно все изменения. В случае первого пункта, с точки зрения команды, в которой много умников и «тупых манагеров» не нужно — это cool и fun, но денег будет поменьше для компании... Такая вот правда жизни.

Разница между пунктом 1 и пунктом 2 в том, что в случае пункта 2 заказчик заплатит больше за тот же объем работ + компенсирует дополнительно все изменения.

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

Интересная (и главное неожиданная) мысль в выводе.

По поводу разницы услуг. Это очевидно. Интересно просто было, насколько долго разговор c оппонентами продержится в «универсальной плоскости» like this: (for any type of software development) if you used Agile and you didn’t like it it was not True Agile.

Sergei Lodyagin и AL

Отвечу Вам обоим в одном посте. Если у кастомера есть бюджет на разработку N денег, то больше чем это N он на разработку все равно, увы, не потратит :)

А что тогда может означать фраза «пересмотрели финансирование» в обсуждаемой статье.

То есть, если у какого-то перца есть клиент, который аккуратно платит по его bill, то это неправильный клиент, который не достоин Agile?

Это неправильные пчелы, и у них неправильный мед

Доречі, а як в випадку з продуктом який треба буде продати сотні кастомерів ? Причому на етапі імплементації в кожного з них виникають якісь свої нюанси, відмінності і тд ?

Тоді робимо для команди Project Manager = Product Owner, і зводимо задачу до попередньої. До речі, у вас там один продукт для сотні кастомерів чи таки сто продуктів для сотні кастомерів?

Коллеги,
Мне кажется спор перешел в религиозную плоскость, где каждый опирается на аргументы, которые, мягко говоря, сомнительны... «а еще в одной фирме, как я слышал...», «настоящий Agile не должен...»

Есть одно НО, которое упустил автор. Многими (к сожалению) Agile разработка воспринимается как ОТКАЗ от всех правил в пользу fun-а. Поэтому можно НЕ писать документацию, не делать рефакторинга и т.д. Отказ от всех правил означает анархию и хаос. Структуру (систему) из хаоса построить очень сложно.

Как команда могла неправильно сделать бизнес-функции, если она делала демо каждые 2 недели? Как они могли писать документацию, если клиент говорил о том, что она не нужна? Как оно могло не работать если должен быть хороший тест-кавередж и углубленный код ревью? и т.д.

У менедера «agile» проекта не хватило квалификации-опыта довести проект до нормального взрослого состояния, когда все это есть. Точно так же в команде «не-аджайловой» поставьте джуниор ПМа и все будет точно так же.

Мне кажется спор перешел в религиозную плоскость,

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

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

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

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

Да, вечная любовь, подлинное счастье, настоящая аджайлость ...

Гибкая архитектура. Вот это уже интересно. Где бы пообсуждать. Так, чтобы на пальцах объяснили, как же её строить, гибкую эту ...

Нет, на мой взгляд, никакой такой «архитектуры, которая изначально предполагает». Можно изучать примеры очень удачных классических архитектурных подходов. Например, Unix. Но, тоже есть свои достаточно ощутимые границы.

http? Да, но вот само TCP тоже уже на современном оборудовании не отвечает всем желаемым требованиям...

Но к теме.

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

Так что я за термин «настоящее искусство», коллега.

http? Да, но вот само TCP тоже уже на современном оборудовании не отвечает всем желаемым требованиям...
Казалось бы, зачем люди придумывали STCP и SCTP. Последнему уже 10 лет.
Хоть убейте не вижу никакой разницы в действиях Team A и Team B.
И там и там была начальная фаза детальной спецификации + проектирования.
И там и там и там было управление изменениями.
В то, что у Team A не было промежуточных релизов, как-то с трудом вериться (бо откуда тогда брались запросы на изменения?)
Едиственное отличие — это наборе терминов, использованных автором для названия ОДНИХ И ТЕХ ЖЕ бест практисес.
Вобщем: Приведенный вывод никак не вытекает из перечисленных фактов.

Если бы бюджет закончился в проекте Team B, то история была бы пересказана каким-нибудь адептом Анти-Аджаил :)

Да нет, Дима, разница в том, что в команда A думала сама, а команда B оутсорсила функцию мозга обратно заказчику, и тот остался доволен как слон, что его развели за его собственные деньги.

Нет, на уровне продаж всё классно.

Ну у команды А тоже ж были изначальные требования и запросы на изменения :)

«закрылись с ним в одной комнате» — ключевой момент?

ахахаха

на что ты намекаешь? ))))))

Вот что лично мне представляется странным в Agile.

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

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

3. Отсутствием яркого лидерства. Все сколько-нибудь значимые проекты (и программные тоже) в истории — никогда не есть произведение коллектива авторов. Покажите мне коллективную поэму. Или язык программирования, который разработал коллектив. Прекрасную скрипку коллектива итальянских мастеров XVII века (вы не поверите, Страдивари тоже делал их для клиентов!). В связи с тем, что бывает очень огромная разница в опыте, способностях, творческой энергии и т.п. в коллективе программистов наличие лидеров — неизбежно. Зачем строить методику на отрицании лидерства как такового, что мы выигрываем?

4. Код становится выше всех остальных рабочих артефактов. Это прямое отрицание накопленного опыта. RUP подытоживает опыт десятилетий и говорит: программный продукт — это набор артефактов как-то: документация, спецификации, архитектура, код, описание дефектов, .... (может быть бесконечный список). Если у нас есть хороший проработанный проект, то закодировать его можно. Аргументация Agile — на это нет времени, главное код. Хороший аргумент. Мои возражения:
4.1 На составление проекта физически тратиться меньше времени, чем на кодирование. Для этого и придумали эскизы, чтобы каждый раз не строить пробный образец. А работу можно распараллелить. Тот же RUP тоже не поощряет водопад.
4.2 При анализе на бумаге можно быстрее исправить ошибки.
4.3 При выполнении повторного проекта другой группой уже есть много элемента для повторного использования.
4.4 QA работать трудно (практически невозможно), имея только код. Требования тоже должны тестироваться. Нет особого смысла тестировать программу до тестирования требований на непротивроечивость. Достижимость некоторых требований, например, производительности или надёжности, должна проверяться на ранних этапах — это определяет архитектуру.

Ну и так далее. Это классика, нет необходимости повторять учебники. (Из собственного опыта: да, по книжкам строить рабочий процесс нельзя. Во всём нужен опыт. Но из этого не следует Agile. )

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

5. Из разговора с серьёзными разработчиками я делаю вывод, что я не один не люблю Agile.

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

Я не готов покупать всю методологию целиком как бренд и говорить «я работаю по Agile». Это глупость. Если кто умеет, допустим, кататься на лыжах, тому не надо читать новый учебник, как это делать. У того уже много наработок на рефлекторном уровне.

7. Групповая ответственность это хорошо, но это — утопия. Хороший руководитель, как мне кажется, всегда распределит на каждого столько ответственности, сколько тот способен потянуть, всё остальное возьмёт на себя. Бывает на практике, когда умение брать ответственность — то, что спасает проект. Иногда, наоборот, её пытаются взять те, кто не потянет. Опыт руководителя УЖЕ подразумевает то, что в критической ситуацию ОН должен брать ответственность за ход проекта. А это подразумевает то, что он пользуется авторитетом. Авторитет и подавление команды — не одно и то же, как многие Junior-ы привыкли думать.

8. Не понятно, как работать с Fixed price проектами. Боюсь писать, потому что знаю реакцию Agile тренеров. У них есть рецепты! Они заключаются в следующем
8.1 Вам посочувствуют (хотя я люблю fixed price и на нём специализируюсь, вообще-то)

8.2 Вам скажут как можно «максимально подтянуть» ваш процесс под Agile (только не понятно зачем).

Ну и так далее, уже много текста. Много чего ещё можно придумать, да времени на это нет. За сим заканчиваю.

1. «Не надо долго думать, не надо проектировать, оно само всё получиться — лишь бы клиент всегда был доволен».

Соломенное чучело это, а не аргумент. Ясен пень, что проектировать нужно. Только вот глупость это — изначально считать себя умнее клиента в его предметной области, запереться в башню слоновой кости и потом выдать ему НЕЧТО, что ему потом снится в кошмарных снах.

Deliverables всегда должны обсуждаться с клиентом. И методика, как проверить соответствие (из этого acceptance tests и лепятся). Разница между подходами agile/не-agile в том, что последний предполагает разбивку этих самых deliverables на такие куски, чтобы их можно было доставлять за итерацию, и сортировку оставшихся deliverables по приоритетам, с пересмотром в конце каждой итерации.

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

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

Там, где я имел счастье поработать, применялся Scrum. Но вместо того, чтобы это был Scrum и ничего кроме, применялись практики обычного XP (все небось уже позабывали, что это и зачем). Тот же TDD, хотя принять его было ой как трудно. Постоянная интеграция. Сам же scrum лично мне помог как-то более реалистично оценивать свои силы и сроки выполнения работ. Чем плохо?

Мне ничего не остается ответить, как только набившим оскомину «у вас опыт с каким-то не таким аджайлом».

Опыт? Хуже.

Просто несостыковка на уровне теории и я многословен.

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

Сейчас об этом помнят только разработчики какого-то критического software.

Вопрос — непрерывную поддержку продавать легче, чем качество?
Ответ — да. Это менее рисковано.
Вопрос — а при чём тут интересы абстрактного клиента в вакууме?

Результат каждой итерации рассматривался как законченная вещь.

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

Скажем так, новый эджайл мне нравится далеко не во всем. Мне не нравятся agile-новояз, разъездной цирк-шапито с тренингами (человек, который начинает зарабатывать в основном тренингами, вскоре теряет связь с реальностью) и обещания серебряной пули каждому. Вот в самой разработке мне как-то XP старой школы больше по душе.

Вопрос — а при чём тут интересы абстрактного клиента в вакууме?

Дык, все для него, родимого, делаем! :)

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

Да, я заметил ровно то же самое. Цитата из аннотации к книге «Хенрик Книберг. Scrum и XP: зметки с передовой»:

Основная ценность книги Хенрика состоит в том, что если вы будете следовать его советам, то у вас будет и product backlog, и оценки для product backlog’а, и burndown-диаграмма.

Это писано в аннотации от переводчиков к книге, в которой методика описана для «начинающих».

Идиoтизм, достойный религиозных фанатиков. Они тоже не способны большинство своих догматов человеческим языком и понятиями объяснить.

Да не совсем же идиотизм.

Морские термины тоже никто объяснять не будет. Штурвал будут называть штурвалом, а не «реечным устройством, посредством которого можно выполнять маневр по изменению курса плавучего средства»... Тем более, что оно и не реечное вовсе :) «Вращение штурвала вызывает поворот пера руля на соответствующий угол, чем достигается поворот судна».

Также проще, быстрее и правильнее сказать «на рей ставили шкентели брасов, заводя огоном на нок рея. Этот блок в торговом флоте, а иногда и в военном стропили к ноку рея без шкентеля (по Д. Леверу), вероятно, не намного раньше 1800 г.» — поди докапывайся, если не в теме...

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

Например, в индустрии давно используется и всем понятен термин «итерация». Спрашивается, на кой ляд и в чем была нужда вводить для абсолютно того же самого понятия иной термин «спринт»? Чтобы видеть тех, кто крестится двумя пальцами и говорят «итерация»?

Секта, натуральная секта!

— Вступайте в нашу секту — наша секта ближе к Богу!

— Лучше вступайте в нашу секту — наша секта ближе к метро! :)

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

В то время как итерация — ru.wikipedia.org/....BD.D0.B8.D0.B8 (дальше прямая цитата) — это организация обработки данных, при которой действия повторяются многократно, не приводя при этом к вызовам самих себя — не путать с рекурсией. Когда какое-то действие необходимо повторить большое количество раз, в программировании используются циклы. Например, нужно вывести 200 раз на экран текст «Hello, World!». Вместо 200-кратного повторения одной и той же команды вывода текста часто создается цикл, который прокручивается 200 раз, и 200 раз выполняет то, что написано в теле цикла. Один шаг цикла и называется итерацией.

Вы подразумеваете то же самое?

Эээээ, Алексей, у Вас произошла типичная подмена понятий. Разговор-то об итерации как понятии процесса разработки, а не об итерации в программировании. Смотрите в начале общее определение, оно ближе к теме.

В процессе разработки (например, XP) итерация абсолютно то же самое, что в Скраме спринт. Ну нету разницы, какие обоснования в «необходимости» нового термина ни придумывай.

Да, случился прогон, сорри.

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

// Божежмой, я выражаюсь как американский сенатор в ответ на вопрос: «Давно ли вы воруете деньги налогоплательщиков?»

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

Важно другое. Уже существует термин, которым пользовались все для обозначения определенного понятия (даже не один, еще есть «этап»). Он всем понятен. Зачем новый, смысл?

Инновации в виде подмены терминов — пыль в глаза.

Был еще более ранний термин для нового слова «спринт», введен во времена И. В. Сталина в масштабах огромной страны: ПЯТИЛЕТКА :).

Чтобы удачно пошутить по теме, надо на достаточном уровне ей владеть ;-)

Пятилетка — перспективное планирование.

Спринт, как и итерация, относится к оперативному/текущему (недельному, месячному) планированию.

Книберг, вообще-то, не «скрам для начинающих» писал, а методичку по внедрению. Т.е., предполагается, что у читателя «Scrum from trenches» есть какой-то бэкграунд (хотя бы на уровне среднего CSM курса).

Ну, сама книга более чем понятная и доступная. Я не о Книберге. Я о переводчиках, которые в том же вступлении говорят, что они фанаты Скрама...

Я когда читал, не поленился, остановился и сделал у себя такую заметку.

UPD: и тут злые админы среагировали на кляузу и цитату потерли :-)

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

Апологет по определению не гибок, поэтому лично я строю процесс разработки в зависимости от конкретного проекта — где-то это будет XP, где-то Скрам (может быть), где-то даже RUP; итерационный (как правило), а, может быть, и водопад; как полностью формализованный, так и без каких-либо формальных ограничений. Повторяю, все зависит от конкретного проекта: его сложности, сроков, заказчика, технологий и пр. и пр. И ни в коем случае «только Скрам», «только XP», «му-му», «баржа, а на барже ж»...

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

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

Я когда пишу, всегда думаю о той аудитории, для которой предназначен текст. Вы хоть раз задумались?; Уверен, что нет. Адекватный писатель во введении никогда не напишет «Основная ценность книги Хенрика состоит в том, что если вы будете следовать его советам, то у вас будет и product backlog, и оценки для product backlog’а, и burndown-диаграмма.» — это бред для любого читателя кроме апологета скрама, а апологету скрама эта книга уже не нужна.

Вам действительно так трудно было изложить введение на понятном любому читателю языке? Вы не можете излагать свои мысли по-русски? Не уважаете родной язык? Почему же тогда беретесь за перевод?

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

Василий, если бы вы с этого начали, мне проще было бы смирить праведный гнев, и не замечать переход на личности вроде ущербных по определению апологетов, слабоватой работы и т.п.

По существу: мне понятно ваше желание как автора Википедии, чтобы все писали понятно даже для учеников третьего класса. Мы это желание вполне разделяли, поэтому достаточно времени уделили поиску перевода для терминов. При этом мы отталкивались от следующего: а) что имел в виду автор (поэтому sprint не переводится однозначно как итерация), б) насколько перевод будет понятен профессиональному сообществу (журнал продукта? пользовательские истории?), и в) насколько перевод термина благозвучен. Примером «как не надо делать» для нас служили книги по RUP и MSF, которые невозможно читать именно из-за плохо переведенной терминологии.

После долгих дискуссий мы сознательно решили не переводить следующие термины. Буду рад обсудить термины на родном языке, которые Вы могли бы для них предложить. Пожалуйста, примите во внимание, что в тексте эти термины могут встречаться по 50 раз в главе, и по 3-4 раза в соседнем предложении, поэтому переводы должны быть в том числе и лаконичными:
Code review
Planning Poker
Sprint Backlog
Scrum

Story Point

Насчет автора Википедии Вы, конечно, загнули :-)

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

Претензия к переводу связана с введением. Независимо от последующего содержания введение должно содержать информацию полностью понятную неподготовленному читателю. Здесь неподготовленный не третьеклассник, а человек, на момент начала прочтения незнакомый с предметом. Т.е. это может быть подготовленный отраслевой специалист, который с этой ее частью (в данном случае — Скрамом) еще не сталкивался. Если во введении используются специфические термины их следует тут же объяснять. Нет возможности объяснить во введении — переписать и не использовать, по тексту книги оно и так есть.

Когда это действительно необходимо, не вижу проблем использования терминов на исходном языке, но оставлять тот же «Code review» из-за его якобы лаконичности по-моему уже перебор. Наиболее известные/подходящие варианты: «ревизия кода», «рецензия кода», «пересмотр кода».

Planning Poker — придуман еще до Скрама. Уже существует русскоязычный термин «покер планирования». По сути то же самое, что «игра в планирование». По-моему подходят оба варианта.

Sprint Backlog — здесь ну прямо напрашивается «план итерации» (мы же знаем, что план может иметь совершенно разные внешние представления). Если более буквально: «план спринта», «журнал спринта».

Scrum — оставим эту хрень без перевода :)

Story Point — а здесь есть большая идеологическая сложность.

Дело в том, что «Story Point», как условная единица измерения объема и скорости работ, призваны решить проблему часов, которые для одной и той же задачи у разных разработчиков разные. Вводится как инновация, тренеры тренируют, манагеры писяют кипятком, переходят на планирование в «сторипоинтах». Это не плохо, плохо другое: все это давно изобретено десятки лет назад и прекрасно работало. Этого сейчас никто не знает и «сторипоинты» становятся почему-то неким открытием, серебрянной пулей...

В правильном, еще советском планировании проектов, в отличие от Проджектов и пр., в которых есть «план» и «факт», время учитывалось тремя показателями: план, факт и табель.

Так вот, при трех показателях план и факт учитывались не в часах, а в условных «нормочасах», что фактически и есть полный аналог «сторипоинтов». В «табель» вписывались реальные рабочие часы, затраченные на работу.

Простейший пример: если на стандартную модальну форму с тремя полями ввода по нормам положено 16 нормочасов, значит в план вписывается 16 н/ч. Если эта задача не менялась (форма та же, что первоначально задумано, число полей то же), значит независимо от реально затраченного времени вписываем факт 16 н/ч, а в табель 2 ч, если управились за два рабочих часа или 40 ч, если управились за неделю. Сравнение факта и табеля дает нам понимание производительности отдельных разработчиков и команды в целом.

Но это так, слишком поверхностно, если будет желание, то по этой теме я могу много и подробно :)

Кое-что, опять же поверхностно, я отразил здесь: armor.kiev.ua/...дство_проектами

Спасибо за комментарий.

Насчет автора википедии — информация отсюда: www.wikireality.ru/...Чобиток_Василий

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

По поводу собственно терминологии: спасибо за варианты. Возможно, в следующем переводе мы их примем во внимание.

О «первородстве». Мне как менеджеру, глубоко неинтересно, до Скрама был придумал Planning Poker или после. Аналогично с учетом нормочасов. Если у меня это применимо, я это применю.

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

А, Вы в смысле «редактор ВП». Уже очень давно нет :)

Мне тоже фиолетово когда придуман термин, я имел ввиду, что как давно придуманный он уже имеет вариант перевода «покер планирования».

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

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

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

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

На этом можно остановиться и у нас полная аналогия.

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

Скрам — великое гониво и обман. Это я Вам говорю, как ярый противник производства тех артефактов, которые не ведут к выпуску готового продукта (что Вы, кстати, так же декларируете).

В скраме задачи оцениваются сторипоинтами, та же самая оценка в нормочасах ничем организационно не отличается, просто другие единицы измерения
Василий, это неправда. В Скраме не оценивают сторипойнтами. Вы читали Скрам Гайд? Скрам не говорит каким образом вы должны оценивать. Оценивайте часами или елочками — это ваше дело.

Можно поинтересоваться — каким образом Скрам не ведет к выпуску готового продукта, если Скрам ОБЯЗЫВАЕТ вас иметь готовый к выпуску продукт в конце каждого Спринта. Василий, вы читали Скрам Гайд?

Илья, Вы судя по всему читали «Скрам Гайд» (по-русски не умеете?), но не поняли, как не понимаете написанное другими.

Почему Вы решили спросить меня «каким образом Скрам не ведет к выпуску готового продукта...?» Вы решили, что я где-то утверждал обратное? Попробуйте внимательнее почитать здесь ветки обсуждения, прежде чем бессмысленно выдергивать фразы из контекста и выдумывать мысли за оппонента.

Успешные люди делаться на две категории:
1. Преуспели в делах — результатах

2. Преуспели в имидже

Предлагаю посмотреть на малые результаты Василия — armor.kiev.ua ну в ВП вклад участника и сравнить результатами «поборников морали» на ВП.

+ У Василия есть еще много реализованных проектов.

ПС: Выше приведенное есть набор фактов.

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

У меня есть претензии по терминологии к Скраму в целом — в нем многие термины подменяют существующие, как пример тот же спринт, который на самом деле итерация.
Василий, тут все просто — итерацию назвали Спринтом специально. Дело в том, что многие путают итерационную разработку с итерациями. Хотя ничего общего между ними нет. Спринт — лишь акцент на том, что итерация — лишь временной промежуток. Информация достоверная, потому что я это услышал лично в беседе с Кеном Швабером

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

Может Вам не повезло с интеллектуальным уровнем окружающих, поэтому тривиальные вещи вроде Скрама вызывают у Вас столь сильную притягательную реакцию?

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

Ууууу.... как все запущено.

Илья, Вы таки исто верующий ;-)

Попробуйте сопоставить эти Ваши высказывания:

По моим личным наблюдениям 95 процентов команд «делающих Скрам» даже не догадываются о том, что это в действительности ничего общего не имеет со Скрамом.
По исследованию Standish Group аджайльные (а Скрам занимаемт 70 проц. этого рынка) проекты ровно в 3 раза успешнее.

Здесь заложены глубочайшие противоречия. Кто-то из авторов этих двух высказываний нам врет. Не находите? ;-)

Никакого противоречия. Даже те команды, которые не делают настоящий Скрам, имеют преимущества перед командами, работающими по старинке. Поэтому они эффективнее. Но, к сожалению, полностью реализовать весь потенциал не могут, потому что у них СкрамНо или по просту ScrumBut. Обычно самое большое препятствие для команд — иметь возможность выходить в релиз каждый Спринт. (potentially shippable increment)

Относительно Вашей жалобы «с какой стати человек, которому не понравился перевод, говнoм мажет 10 человек и называет фигней их работу для сообщества?»

Перевод меня устраивает. Заметны отличия в стиле разделов и используемых терминов, видно, что не было редактора и рецензента но в целом на приемлемом уровне.

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

Василий, а вы не читайте Книберга. Это слабая книга, которая имеет мало общего с настоящим Скрамом. Прочитайте Скрам Гайд, пожалуйста! К сожалению, книги Книберга слабые, но очень раскрученные.

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

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

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

Замечательно сказано! Конечно, если набор ценностей и принципа Аджайла вам не подходит — не надо себя ломать. Работайте по старинке.

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

Илья, Вы слишком топорно съехали со Скрама на набор ценностей и принципов Аджайла. Извините, этот набор ценностей я разделял еще до появления Аджайла, а Скрам — туфта для мало образованных.

Когда Вы поймете, что в Вашем Скраме нет ничего нового, то поймете, что именно Вы работали по старинке, на уровне каменного века разработки.

Василий, я аплодирую вашему умению находить метафоры. И метафора с пулей и с фанатиками евангелистами, стучащими в вашу дверь, конечно же, очень интересны. Мне бы, все таки, хотелось услышать больше конкретики и меньше эмоциональных, но пустых фраз, которые лишь звучат в воздухе как громкий хлопок.
Буду предельно конкретен.
Классическая модель менеджмента или то, что я называю «работать по старинке» — построена на детерминистической модели (вспоминаем Тейлора с его «Научным менеджментом» начала 20 века). Очень неудачный подход в такой запутанной (вспоминаем теорию запутанности и Cynefin framework, диаграмму Стейси) отрасли как АйТи. Скрам же основан на эмпирическом подходе, единственно верном инструменте для АйТи. И, конечно же, вы правы, говоря, что в этом нет ничего нового. Скрам создан из соединения эмпирического подхода и идей, возникших из New New New Development Game (1986). Главное, что это работает — и работает очень эффективно. По исследованию Standish Group аджайльные (а Скрам занимаемт 70 проц. этого рынка) проекты ровно в 3 раза успешнее. И это по классическому определению успешности проекта (соответствие треугольнику менеджера). Задумайтесь над этим. Мне нужны факты — они у вас есть? Вы можете представить ссылку на исследования или факты, которые, доказывают обратное? Спасибо.

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

Я понимаю но не разделяю Ваше желание все порвать на барабаны за Скрам, но это, повторяю, только терминологическая шелуха, которая под видом новизны подсовывает нам то, что известно уже десятки лет и то, как уже я работал когда Вы, Илья, еще в памперсах ходили.

Простите, молодой человек, но Вы ошиблись дверью. С молитвенниками «Скрайм Гайдами» принимают по коридору налево. И спасибо за Ваше светлое желание просветить нас, темных.

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

Нет, Илья.

1) Вы пустили пузыри в лужу данными про 70% Скрам команд на рынке и после этого указали про 95% Скрам команд которые таковыми не являются. Т.е. на Скраме, по-вашим утверждениям работают 3.5%. Так стоит ли эта мелочь вообще того времени, которое мы тратим на ее обсуждение?

2) Вы требуете от меня неких данных. Я не понимаю: каких и зачем? Воздух сотрясаете Вы, т.к. пока я с Вами вообще ни о чем не спорил. Определитесь с предметом спора, и тогда мы вместе определимся должен ли я Вам что-то доказывать и приводить некие данные или нет.

И не подменяете понятийно 3.5%-ю туфту именуемую Скрам с Аджайлом.

Да, очень мало команд работают в настоящем Скраме, потому что это очень сложно. В предыдущей версии Скрам Гайда было написано «экстремально сложно делать». Поэтому 70 проц — это ScrumBUT, и лишь малый процент настоящего Скрама. Наша задача сделать все, чтобы этот BUT отпал )))

Скрам — это гибкий фреймворк, который имплементирует принципы и ценности Аджайл Манифеста. Не забывайте, что из 17 человек, подписавших его ТРОЕ были авторами Скрама — Джефф Сазерленд, Кен Швабер и Майк Бидл. Скрам соответствует Аджайл принципам — поэтому он Аджайл. Никакой подмены нет.

Не надо вводить в заблуждение, от этого можно впасть в ошибку. Если Скрам это Аджайл, то Аджайл это не Скрам.

Вы не находите, что это основы логики, которые не следует нарушать?

Да, совершенно верно. Аджайл это не Скрам ))) Кроме Скрама есть еще XP, FDD, группа Crystal и так далее. Скрам лишь один из способов имплементации ценностей манифеста. В конце концов, можно вообще работать в своем собственном «домашнем» процессе и тем ни менее быть гибким.

Сергей, респект за пост — все по делу. От себя добавлю:
1. Ни один нормальный проект в ИТ не протянет без ПМ. Менять все бесконечно долго тоже достанет любого кастомера и рано или поздно он наймет менеджера, который будет думать головой.
2. Чем больше скрам мастеров, рулящих проектами, тем дороже становятся услуги ПМ как более широконаправленного спеца.

3. Большинство проектов все еще фиксед прайсовые и продать их как услугу стаффинга со скрамом НЕВОЗМОЖНО.

Откуда эта ересь про скраммастера, заменяющего ПМ?

Я так понимаю у Вас аргументы закончились и Вы решили перевести беседу в такое русло? Не нужно...
По поводу скраммастера, заменяющего ПМа — Вы говорили ранее, что в ИТ проектах с использованием Agile и Scrum роли ПМа на проекте нет, т.к. она не нужна. Об этом говорят многие другие приверженцы гибких методологий.

В результате, как показывает практика продакт овнеры, поработав со скраммастерами все равно рано или поздно нанимают на проект ПМа, даже если на нем остается скрам.

Андрей, вы правы — мененджер не нужен Скрам команде. Для чего? Все его обязанности разделены между 3 ролями.
Что касается ремарки насчет практики — ок, принимается. вот только у меня другая практика и опыт ))) противоположный вашему. То, что вы описываете — не Скрам и скорее всего Скрамом никогда не было.

Андрей, Скрам Мастера не рулят проектами — у них нет такой власти, Скрам Мастер вообще ЛИШЕН ВСЯКОЙ власти над командой. И я согласен с тобой — ПМ нужен, но он трехликий — его распилили на 3 части: что-то взяла команда, что-то Владелец Продукта, что-то Скрам Мастер.

Сергей, расскажите пожалуйста мне, как аджайл-тренеру, за что вы любите fixed cost fixed scope проекты, и что вам помогает удовлетворять в них клиента и получать нормальную маржу.

Буду признателен.

Есть различные цвета белый, черный, ультрамарин, и еще много разных, включающие разные серые тона.

Черный и белый — это банально. Серость — это не про нас.

Держитесь ультрамарина, а еще лучше индиго — это свет прозрения!!!

ПС: Правильные вопрос не в том какой цвет нравиться, а в том какой цвет нужен для определенной цели.

правильный вопрос — как подобрать антидепрессант:

ibigdan.livejournal.com/11311369.html

Фу — це не дуже приємне видовище та і дуже сумнівний вихід для менеджера.

Я б Вам не радив.

сами же советовали держаться ультрамарина, а лучше индиго. Вас не поймешь.

Перепрошую, це була алегорія до "

как аджайл-тренеру, за что вы любите fixed cost fixed scope проекты

".

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

Прийшли до тебе з вимогою повантажити три вагони вантажиш три вагони і за це ціна1.

Прийшли до тебе з задачею організувати неперервний вантаж із швидкістю 30 вагонів/сек робиш дану задачу і за це ціна2.

Ціль задачі чітка і зрозуміла — ні в першій ні в другій задачі нічого надприроднього нема.

Захар, ну у Вас и аллегории.

Вопрос к Сергейю был не «Зачем вы имеете дело с ужасным fixed cost fixed scope», а как именно он в них легко удовлетворяет клиента и получает нормальную норму прибыли.

Исходя из Ваших ответов «чего думать, прыгать надо», могу предположить, что Вы уже на том уровне мастерства, что распиливаете любой проект, что фиксд кост, что т&м, что втф, не задумываясь о том, как Вы это делаете.

В это случае аджайл и правда Вас ограничивает. Не используйте его. Но Ваши ответы для меня, увы, не полезны.

Маленькое уточнение: думая и выбирая подходящий вариант подхода.

На счет ограничения — хромает логика. От того что можно применить на практике на один подход больше — это наоборот расширение возможностей.

Если насчет ограничения — хромает логика, то хромает она у вас:

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

Артеме, щоб Вам було зрозумілими основи логіки, наведу дитячий прикл:

Задача: Є пункт А та пункт Б. Відстань між ними по прямій 10км. Потрібно з пункту А дістатись до пункту Б за час в 1 день. Та є деякі обмеження: можна використати лише наявні у нас засоби: швидкісний мотоцикл, легковий спорт кар (у нас саме найкраще).

І маленьке уточнення від життя: між А та Б гірський кряж по різні боки та і дороги бодай грунтової нема.

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

Ось і виходить подекуди що полишивши мотоцикл та спорткар ідеш гнучко пішечки :-)

Легко. Мы говорим о разработке продукта? Тогда это делается в несколько этапов. Клиенту называется примерная цена, на нее просто ориентируются. Разработку требований оцениваем в X денег и Y времени. В течение этого времени берем заказчика в оборот, работаем с ним, проектируем наш продукт с точки зрения юзера. Дальше в зависимости от размеров и желаемых сроков выделяем команду, определяемся с клиентом по деньгам. Он знает, когда и что он получит. Да, это нифига не Agile, но это не значит «оторванный от действительности некачесвтенный продукт». Это значит «хорошо спроектированный с участием клиента продукт»
Чем это лучше для меня? Наверное тем что я знаю, когда и какая команда у меня начинает и заканчивает работать, тем что могу брать заказы «наперед», соблюдая сроки.
Просто это требует планирования, которое обычно всем делать лень. А, еще есть «непредсказуемость рынка» — надо поскорее выпустить и посмотреть что будет. Да хрень будет, разве что идея революционная, иначе хрень. «Если бы я давал моим клиентам то, что они просят, я бы должен был дать им более быструю лошадь. Генри Форд»

Константин, спасибо за ответ. А как вы боретесь вот с таким спецэффектом: construx.com/...e.aspx?cid=1648

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

Если Вы не против, поделюсь своим еще военным опытом. Тогда эту практику я воспринимал как дуристику, но уже потом понял ее глубинный положительный смысл.

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

Откуда брались трудоемкость и сроки для новых проектов? На эти проекты до их начала разрабатывались технические задания. Проект не мог быть включен в план части и отдела без ТЗ на него. Причем, разработка ТЗ считалась частью проекта и по трудоемкости включалась в него. Т.е. получалось, что ТЗ вписано в план на январь-февраль, а реально готово до начала проекта — к концу предыдущего года.

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

Только потом я понял такую простую вещь: когда ТЗ готово, проект можно спланировать достаточно точно даже на год вперед (и без двухнедельных спринтов). А поскольку в следующем году мы все равно будем делать ТЗ на другие проекты, то время, которое мы запланировали на уже готовое ТЗ, будет израсходовано уже на них. Т.е. в январе-феврале мы фактически не ТЗ пишем, а делаем следующую за ним по плану работу, с тем прицелом, что в этом году писать другие ТЗ, на которые формально времени нет, а фактически есть :)

Ну и отчитаться же за потраченное на ТЗ время надо все-равно, а включать его в план до начала проекта мы не можем.

Такая, на первый взгляд, дуристика позволяла резко сужать конус планирования :)

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

Конкретный пример в студию. Не спорю, такое возможно, но это скорее исключение, чем правило и под такие проекты надо действительно думать о другой методике. Для большиства (подавляющего!) это порочная практика — выпускать г**но и допиливать.

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

Прикладів можу навести, це не проблема: куча софта в державному секторі. Але скільки потім його доводиться подекуди допилювати.

Возможно я не понял... Я просил примеры софта в котором необходимость выйти на рынок ОЧЕНЬ быстро ценой качества продукта. Думаю госсектор — это наоброт. Но я с ними никогда не работал, не в курсе.

Тут є два моменти:
1. До проходження тендеру, коли потрібен робочий прототип (саме про цей момент іде мова).

2. Після проходження тендеру (а тут як вийде).

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

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

Саме так. Саме відсутність нормального проектування призводить до посередніх результатів.

Як правило, на тендер пропонується прототип який відповідає деяким формальним вимогам тендера. На підготовку прототипу фінансів зі сторони замовника не виділяєть, а відповідно як такі початкова та уточнювальні стадії відсутні, які є передумовами вдалого проекту.

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

Да, но конкретно в этой ветке мы говорим про «fixed cost fixed scope».

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

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

А если заказчик не повелся на их продукт? Максимум, что я теряю — месяц работы одного аналитика на ТЗ, максимум, что теряет такой конкурент — месяц и больше работы команды.

Согласитесь, такой конкурент рискует на порядок большей суммой затрат при значительно большей вероятности реализации риска :-)

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

Ключевое слово «наличие нормальных альтернатив»

Це вже стратегічне планування і суть можливо краще пояснити так:
1. Є відомий процент часу скільки потрібно для розробки ТЗ (згідно попередньому досвіду CMMI >=3).
2. Є стратегія розвитку (портфель проектів).

3. А далі в залежності від ресурсу плануєш (списуєш частину ТЗ-шного ресурсу на відповідне ТЗ).

Василий, спасибо, что поделились.

Я могу предположить, что в хорошо изученной и стабильной предметной области Big Design Upfront вполне уместен и уменьшает риски.

В стартапах, в которых я сейчас плаваю, к сожалению, а) домен в начале как правило не изучен, и б) big design upfront ведет к следующему спецеффекту. Если мы ошиблись на этапе дизайна (такое вполне возможно и очень вероятно), то BDUF будет нас заставлять настаивать на своих ошибках вопреки тестированию и отзывам пользователей.

Вы с такой проблемой не сталкивались?

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

Достаточно подробно один из таких случаев описывал в этой теме, сразу под Вашим постом от 1 марта ;-). Фундаментальные ошибки в проектировании (причем, как видно из описания, обнаруженные и озвученные вовремя) привели в итоге к краху очень крупного проекта. И, кстати говоря, там я не упомянул: до начала проекта я проводил занятие по ознакомлению команды разработки с существующими продуктами конкурентов и указывал на особенности принятой архитектуры, обратил особое внимание на один из продуктов — «так делать не надо» и объяснил почему. Спроектировали именно так, как я сказал не надо, только на другой «элементной базе».

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

Цена ошибки проектирования высока (выше только цена ошибок анализа) в любом типе проектов. Другое дело, что в «BDUF» такая ошибка лучше документирована, ее можно раньше выявить и понятнее, что с ней делать (когда, наконец, до принимающих решение дошло, что ошибка есть) :-)

Идея в том, чтобы начать разработку где-то в районе Detailed design complete и не делать оценок пока у нас нет проработатнного продукта. Именно для этого в начале мы не говорим «мы хотим todo-list», а мы строим полную концепцию продукта:
— кто будет его юзать
— как на этом зарабатываются деньги
— в идеале общаемся с юзерами
— проектируем UI
— прорабатываем требования
Все это время никто не кодит, работает 1,5-3 человека (Product manager, UX designer, business analyst). В зависимости от продукта, UX’ов может быть и 2 без аналитиков. Или, наоборот, больше аналитиков. Тут ключевой момент в том, что заказчик — это максимум аналитик, а лучше вообще просто заинтересованный нетипичный юзер :) А продукт прорабатывают специалисты.

Я думаю, никто не будет спорить, что если прорисованы все скрины приложения, подумано как работают сложные контролы и описана ключевая логика backend, то cone of uncertainty становится весьма узок, в пределах 30% на технические риски. И в данном случае все прикольно, потому что в 30% входят ТОЛЬКО ТЕХНИЧЕСКИЕ риски, которые с опытной командой хорошо считаются и управляются.

В моем варианте засада в том, чтобы выбрать правильное время на первую фазу проработки продукта. Тут разве что «на глазок» или T&M. Но поскольку это около 20-30% всего времени, то промах намного меньше, да и стоимость его существенно ниже.

Спасибо за ответ. Здраво.

Приятно видеть, что и аджайл-тренеру не чужд последовательный руповский подход.

Вне зависимости от подхода, в начале должна быть разумность, и это правильно.

Однако! Главная фишка рупа, которая так и не далась многим, — «кастомизация».

При «кастомизации» из рупа можно получить и XP, и Scrum, и какой еще захочешь Agile :-) :-) :-) :-)

Вот это точно здраво!

Сергей, у меня есть несколько замечаний, которые я выскажу

1. Аджайл не «одна из методологий» как вы выразились. Аджайл очень мало общего имеет с методологиями в принципе. Аджайл — это группа ценностей и принципов разработки программного обеспечения.
2. Отсутствие лидерства — неправда. Аджайл не подразумевает отсутствие лидерства абсолютно. Меняется лишь его стиль — с командно контрольного на servant leadership, Вы можете найти в Аджайл Манифесте место, где написано о том, что лидеры не нужны? Нет, потому что там такого не написано. Аджайл — это соответствие тому, что написано в Аджайл Манифесте.

3. Вы ссылаетесь на РУП — ок, если он такой классный и успешный, можете найти хотябы одну конференцию в мире по нему? Можете не искать, потому что РУП — мертв.

4.

Из разговора с серьёзными разработчиками я делаю вывод, что я не один не люблю Agile
А я утверждаю обратное! Тот разработчик, который поработал в нормальном Скраме уже НИКОГДА не сможет работать в мрачной атмосфере классического менеджмента на правах раба, которому говорят, что ему можно делать, а что нет. Аджайл — это человеческое достоинство, свобода от произвола менеджмента, возможность почувствовать себя человеком.

5.

Но
Я не готов покупать всю методологию целиком как бренд и говорить «я работаю по Agile».
Аджайл не методология.

6.

Групповая ответственность это хорошо, но это — утопия
 А я так уверен в обратном.

7.

Не понятно, как работать с Fixed price проектами
Мне как Скрам тренеру все понятно ))) пишите, и вам тоже объясню.

8.

Вам скажут как можно «максимально подтянуть» ваш процесс под Agile (только не понятно зачем).
Не обобщайте. Кто это говорит? У любой аджайл (скрам) трансформации если определенные цели и они достигаются.

9.

Если вы начали набирать свой опыт когда никакого Agile не было, на собственных ошибках по крупице сформировали свои представления, что-то начало получаться и т.п. Вы росли как менеджер и тут — здрасьте — Agile. Всё на свалку
Вот в этом вы правы, Сергей! Именно в этом и кроется проблема внедрения Аджайла в компании — оголтелое сопротивление со стороны менеджмента. Им есть что терять.

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

Возможно вы просто неправильно до этого понимали эти «гибкие методы». ))))

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

Хотя одну мысль позволю себе высказать, не свою, а Дональда Кнута, но я с ней, как оказалось, вполне солидарен (не услышал бы — не узнал). Чтобы не перепосчивать сюда (весь текст — оффтопик), приведу ссылку и сошлюсь на 2 и 3 предложение. Для неумеющих бегло читать по-английски по ссылке есть полный перевод

Дональд Кнут — Мой совет молодым людям

And I think one of the
things that I would, that would sort of come first to me is this idea
of, don’t just believe that because something is trendy, that it’s
good. I’d probably go the other extreme where if something, if I find
too many people adopting a certain idea I’d probably think it’s wrong
or if, you know, if my work had become too popular I’d probably think
I’d have to change.

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

p.s. добавлю, проект, над которым работаю сейчас, делается как раз по паттерну команды Б. делается уже 3 года. да, он очень объемный, но все же.. в итоге никто уже не понимает, что он делает.. зачем он это делает. и что в итоге должно получиться. немного расставил на свои места подход, которым действовала команда А, но в полной мере осуществить не получается из-за времени (так и не понимают, что лучше потратить больше времени на проектирование, чем на латание дыр... не учатся на своих ошибках люди)

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

Реальный мир с вами не согласен. Выжимка из отговорок, которые я вот этими ушами слышал:

— Но это же такое маленькое изменение! (Да, оно маленькое, но конкретно меняет бизнес-логику и пользовательский интерфейс — сразу думаешь, как бы тебе данные на продакшене мигрировать, и тут-то собака порылась)
— А вы разве сами не видели, что это идиотизм? (Я не понял, кто из нас в предметной области более специалист?)
— Да не может быть, чтобы я ВОТ ЭТО имел в виду, я же не дурак! (Рукописи не горят, но как раз по ним и спор.)
— Вы никогда не можете понять, что я имею в виду.

— Да, все сделано, как я просил, но надо переделать, ПОТОМУ ЧТО МНЕ НЕ НРАВИТСЯ.

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

в случае, если он их утверждает, то все изменения вносятся за его счет

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

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

Зато на практике бывает несколько другая ситуация — представитель заказчика, который думает, что знает, что надо, подписывает дизайн спеки, а потом пытается забесплатно протолкнуть изменения требований с нежеланием платить денег, аргументируя это тем, что «продукт-де не выполняет свою задачу»

Собственно, Ярослав Федевич ниже все это еще более красочно расписал, сразу виден опыт работы на fixed price fixed scope проектах :)

Да, все истории про Agile заканчиваются почему-то Happy End на том месте, когда «клиент остаётся доволен и продукт выходит на рынок». Госода Agile-филы а скажите пожалуйста, к вам приходили когда-то эти клиенты лет через 5 с раздутым в N раз продуктом и полным отчаянием, потому что «попытка что-то где-то поправить приводит к 2 месяцам восстановительных работ» а конкуренты тем временем догоняют и обгоняют? Вы пробовали когда-либо составить документацию на «работающий» %#$%код, который проще переписать, но надо возиться, потому что, якобы «работает и все довольны», или (более реалистично) на переписывание никто не закладывал денег, потому что «те парни из команды B показали, как быстро можно делать классные продукты». А QA просто надо весь уволить и набрать новый, потому что «эти идиоты не знают, как можно тестировать без спецификаций».

Нет. Клиент всегда прав — это правильно, но, команда тоже должна иметь свою стратегию выживания. А потому, считаю, картина показана не полностью. Это счастливое начало, а не печальный конец. А в IT, как и в шахматах — есть фигуры и процессы лёгкие, есть и тяжёлые. Когда команда B со сцены уйдёт в этой конторе всё будет тянуть команда A, вот посмотрите. Хотя, мне кажется, недоработка на метауровне. Вера в процесс — это не серьёзно. Берите опытных менеджеров и контролируйте всё происходящее лично.

Нет

Да.

Мой последний проект длился более 5 лет (и продолжается сейчас — в саппортной фазе), все тестирование автоматизировано (JUnit, easyB, proprietary functional testing framework, Selenium), исполняемые сценарии функциональных тестов являются основой документации (более того — 100% релевантной), все technical trade-offs заносятся в отдельный бэклог, на который тратится от 10% до 20% времени команд каждый спринт (так что г-нокода нет), изменения вносятся легко и быстро, а выделенных QA вообще нет.

100+ человек в 6 локациях, восьмизначный бюджет и distributed Scrum со 100% self-organized teams.

Шестой год — полет нормальный (вообще-то, отличный).

100+ человек в 6 локациях
Было бы интересно послушать и их мнение, хотя бы статистику «да/нет» по озвученным тезисам.

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

О, отлично. У меня есть содержательный вопрос.

из 7 членов команды 6 CSM

Чем в реале повседневно занимаются CSM? Чем отличаются роли в команде CSM и не-CSM? Сколько их нужно на команду? 6 из 7 — это чуть менее, чем все, это мало или много? Спасибо.

Так получилось :) Скраммастер в команде был один, но его роль сводилась, по сути к формальной, т.к. у всех членов одинаковый бэкграунд в процессе.

Я вообще считаю, что сама по себе корочка Certified ScrumMaster ни о чем не говорит (особенно в отрыве от личности тренера). Главное, чтобы в каждой команде был хотя бы один человек с хорошим практическим опытом внедрения Agile-процессов, способный подсказать команде хорошие практики и эксперименты.

И на тренинги жмотиться не нужно, они окупаются. У нас обе стороны (заказчик и вендор) независимо выделяли хорошие бюджеты на привлечение опытных тренеров (Craig Larman, Gojko Adzic, Alistair Cockburn, John Smart и т.д.)

Я вообще считаю, что сама по себе корочка Certified ScrumMaster ни о чем не говорит

Тогда зачем они?
И Вы, извините, написАли многобукв, но я не увидел в них ответа на первых два вопроса

Чем в реале повседневно занимаются CSM? Чем отличаются роли в команде CSM и не-CSM?

Имелась в виду Ваша конкретная практика. Если это НДА, так и скажите, если Вы просто не хотите отвечать — Ваше право, но сэр, каков смысл ответа в стиле К.О.?

Тем не менее, спасибо за потраченное время.

Тогда зачем они?

Затем же, зачем и другие сертификаты.

У нас CSM были обычными членами команды. Точно так же, как OCJP — обычными девелоперами.

И, как сказала молоденькая Керо королю Вриданку в их первую брачную ночь, «недурная штучка, но есть ли у нее какое-то практическое применение?». © Анджей Сапковский, «Владычица Озера»

Как и у любого сертификата, практическое применение — украшать рабочее место (ну, или стену сортира — по вкусу).

из 7 членов команды — 6 CSM

Почему так мало? Надо хотя бы 7 CSM, все обязательно должны понимать почему именно выбран Scrum и свято верить в то, что это сделано правильно :)

Отвечаю:
4 — члены Luxoft Agile Practice, тренинг нужен был для повышения навыков зомбирования коллег :)
1 — уже когда-то проходил тренинг (задолго до Люксофта)

1 — Скраммастер, решили, что будет не комильфо, если он чуть ли не единственный без сертификата ;)

Но в целом — мы сами над этим прикалывались неоднократно.

Сергей, Вам пора открывать свою контору с тренингами (как минимум продавать Вы их сможете) :)

Но помните, на кроме Agile есть еще и другие формы жизни на проектах :))

Надо хотя бы 7 CSM, все обязательно должны понимать почему именно выбран Scrum и свято верить в то, что это сделано правильно :)

И участвовать в ритуальных сожжениях спецификаций каждый месяц. :)

Да чего там — в ритуальном сожжении самого не-аджального члена команды :)

из 7 членов команды — 6 CSM

То есть уже 6 человек в команде :)

Ну, согласен, суп и из топора можно сварить. Паче, если есть хотя бы один опытный менеджер и надстроечная поддержка a-la (не много ни мало) Luxoft. А вот возьмите 2-3 парней из команды и пойдите в рукопашную ... Хотя о чём это я?

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

4 фремворка для тестирования за 5 лет — одно это вызывает огромный личный неприкрытый интерес.

А вот возьмите 2-3 парней из команды и пойдите в рукопашную

Легко. На небольшом проекте построить Scrum гораздо проще, он, собственно, для этого и был впервые применен. Корпоративные монстрики типа distributed Scrum появились сильно позже и, по-моему, только в последние лет 5 их научились нормально повторять и масштабировать.

Никакой пропаганды Скрама я не устраиваю, но могу сказать, что предыдущие две попытки реализовать тот же проект успешно завалились именно из-за неприспособленности вотерфолла к постоянным change requests. А тут меньше, чем за год выкатили первую продакшен-версию (юзерам, естественно, регулярно показывали и до продакшена) и потом ее допиливали с релизами раз в месяц.

Я уже как-то давал ссылку на презентацию на QCon London 2011: www.infoq.com/...Kiev-Experiment

День открытых дверей, к сожалению, устроить не можем. Хотя в пределах Люксофта народ регулярно приходит посмотреть и расспросить (даже из других офисов приезжают).

4 фремворка для тестирования за 5 лет — одно это вызывает огромный личный неприкрытый интерес.

Они все одновременно используются. Просто разные уровни — unit tests, behavioural tests, acceptance tests, GUI tests. Все тест паки крутятся в CI (TeamCity) и сваленные тесты вместе с виновником торжества тут же видны на плазмах возле каждой команды. Красные тесты — stop & fix, никаких коммитов до исправления.

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

Зачем противопоставлять Scrum Waterfall. Это не серьёзно. Не серьёзно считать, что все противники скрам отстаивают именно Waterfall. Есть масса других процессов, которые пропогандировались и до Agile, и до XP (например, RUP), но те, кто всё это опробовал, вероятнее всего, пришли к следующему выводу : «теперь я буду верить только себе».

5 лет проекту — прекрасно. Но, согласитесь, не тот уровень, когда можно переходить к анализу методик. За 5 лет даже давать лаконичные имена переменным многие не успевают ещё научиться. Методики возникали в больших компаниях на длинных проектах. Зачем их продвигать, если она приносит доход и есть Know How — не понятно. Скорей всего имиджевая игра крупных компаний. А Agile — игра на уничтожение прочих методик.

А хорошая методика разработки — не объект продажи и рекламы, господа!

Вообще-то, Agile Manifesto как раз и был создан консультантами из крупных компаний с опытом руководства проектами больше возраста большинства здешних спорщиков. И идея была в том, чтобы развивать рынок и брать best practices из опыта каждого, а не зажимать «ноу хау».

Скорей всего имиджевая игра крупных компаний. А Agile — игра на уничтожение прочих методик.

Ну и какие же это компании прямо так агрессивно впаривают аджайл? В Люксофте я, как раз наоборот, вижу инициативу со стороны клиентов, в первую очередь (что и понятно).

Вообще-то, Agile Manifesto как раз и был создан консультантами из крупных компаний с опытом руководства проектами больше возраста большинства здешних спорщиков.

Каждый возраст хорош по-своему.

И идея была в том, чтобы развивать рынок и брать best practices из опыта каждого, а не зажимать «ноу хау».

Если все идут за Agile, значит это кому-нибудь нужно.

Ну и какие же это компании прямо так агрессивно впаривают аджайл? В Люксофте я, как раз наоборот, вижу инициативу со стороны клиентов, в первую очередь (что и понятно).

Как-нибудь напишу статейку под названием «Agile Team: хотим, но не можем». Пока просто не соглашусь. Не хочет клиент, как правило, играться в умные игры с разработчиками, не хочет. Это Luxoft где-то таких специальных клиентов нашла.

с опытом руководства проектами больше возраста большинства здешних спорщиков

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

Не я первый начал:

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

Вы что, хотите найти в моих словах скрытый смысл — «все методики писали маразматики»? Их там нет! Слово sales manager-а!

> Они все одновременно используются. Просто разные уровни — unit tests, behavioural > tests, acceptance tests, GUI tests

Нет, вы не поняли, это не вопрос с подвохом. Мы просто разрабатываем продукт для автотестирования. Зря только, что в Scrum, по видимому, есть «рекомендованный и апрувленный набор продуктов». То есть, мне, чтобы продвинуть хороший продукт и хорошую поддержку надо (как минимум) залезть куда-то почти в Agile Manifest и что-то там подкрутить. А то прихожу — говорю — пацаны, продукт не нужен? — А мне — «у нас Scrum и Selenium» :)

Ну почему же? Я лично знаю проекты, использующие (кроме вышеперечисленного): FitNesse, JBehave, WebDriver. Я думаю, Scrum + Selenium — это какое-то туннельное видение.

Это все круто. Но кто сказал, что бюджет нельзя сократить, число программистов уменьшить а проект сдать 3 года назад и забыть?

ИМХО оч. субъективно.

Да, восьмизначный бюджет, что и говорить, бодрит разработчика.

А почему, собственно, выделенный QA не сделали? Не достойны тестеры оказались освоению бюджета?

А зачем делать тестирование вручную, если можно автоматизировать?

Пехота тоже нужна, танки не везде успеют. Да и бюджет на танки больше.

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

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

Бюджет больше только в момент внедрения фреймворка для автоматизации (если не с начала проекта используется). А в перспективе экономия на регрессионном тестировании огромная (особенно если релизы раз в месяц, а regression pack — штук 500 сценариев, каждый из которых руками проверить — минимум час).

Действительно, а кто пишет/правит сценарии для автоматизированного тестирования?

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

Хм.

А поддерживать 500 сценариев от релиза к релизу — сколько программистов съедает на полный день? Или требования не меняются?

Вот поэтому и бюджеты 8 значные :)

С ручным тестированием были бы 9-значные. Не говоря уже о цене ошибки (в инвестбанке на 8-значную сумму влететь за день можно), поэтому все же лучше «перебдеть».

А кто план тестирования и тест кейсы пишет?

Мне кажется, что никакая технология не заменит разум. Можно и телевизором гвозди забивать и возмущаться, что не удобно, а стоит дороже молотка... Можно пилить электропилой не включая ее в розетку. Вообще даже самую великолепную идею можно довести до абсурда. Есть такой термин как Итальянская забастовка — ru.wikipedia.org/...ская_забастовка -
Итальянская забастовка — также наз. обструкция — форма протеста наряду с забастовкой и саботажем, заключающаяся в предельно строгом исполнении сотрудниками предприятия своих должностных обязанностей и правил, ни на шаг не отступая от них и ни на шаг не выходя за их пределы. Иногда итальянскую забастовку называют работой по правилам (англ. Work-to-rule).
Такой метод забастовочной борьбы весьма эффективен, так как работать строго по инструкциям практически невозможно и вкупе с бюрократическим характером должностных инструкций и невозможностью учесть в них все нюансы производственной деятельности, такая форма протеста приводит к существенному спаду производительности и, соответственно, к крупным убыткам для предприятия. При этом с итальянской забастовкой трудно бороться с помощью антизабастовочных законов, а привлечь к ответственности инициаторов практически невозможно, так как формально они действуют в строгом соответствии с Трудовым Кодексом.

Нет. Клиент всегда прав — это правильно, но, команда тоже должна иметь свою стратегию выживания.

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

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

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

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

В соответсвтвии с некоторым статистическим исследованием среди софтверных компаний, которое презентовала небезысвестная SmartBear на одном из своих вебинаров (они проводили опрос в Штатах), наиболее употребительная из всех методик на прошлый год была методика под названием «своя методика». На втором месте был Agile (с хорошим отрывом), на 3-м Waterfall, с очень большим отрывом шли другие.

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

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

Если, допустим, я — компания, то я и только я отвечаю за то, с кем я работаю. Клиентов надо тоже ведь выбирать. У меня должны быть конкуррентные преимущества перед другими компаниями — а значит своя стратегия. Стратегия — это то, как я буду развиваться.

То есть, я понимаю, что заказчик должен оставаться доволен, но собственная стратегия у команды — она важнее. Если я не собираюсь делать продукты-однодневки, то не буду искать и таких клиентов. Сохранить своё лицо — это важнее.

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

Коллега, чаще всего под гордым названием «своя методология» скрывается методология «итить-колотить», также известная как «тяп-ляп».

Ну из этого же не следует, что первым шагом по преодолению тяп-ляп должен быть _именно_ Agile «как самый правильный способ делать софт» (если расшифровать все высказывания сторонников Agile).

Хотя ваша мысль мне понравилась.

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

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

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

1.

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

+100500

2.

если у заказчика восемь пятниц на неделю и он сам не знает, чего хочет, но готов за это платить

+ еще раз 100500, главное чтобы у него при этом бюджет был порезиновее, а то могут потом начаться истерики типа «Ребята я это хотел когда-то, а Вы не сделали, а для меня это очень важно» (ну не все понимают разницу между Agile, Waterfall и т.д. и всегда нужно быть готовым к тому, что надо ткнуть человека носом во все логи итераций, которые соответственно надо бережно хранить).

+ еще раз 100500, главное чтобы у него при этом бюджет был порезиновее, а то могут потом начаться истерики типа «Ребята я это хотел когда-то, а Вы не сделали, а для меня это очень важно».

«Чувак, ты же сам такие приоритеты расставил, вот мы по ним и сделали, и ты получил и расписался.» Универсальный ответ, для любой методологии.

Важно понимать, что каждый спринт — это все же маленький водопадик (планирование уже было, есть написание кода и тестирование с отладкой). Когда команда расписала план спринта, то изменять его нельзя, а если что, то надо было думать перед, а не во время. Надо поменять? Ну какие проблемы, после спринта разберемся. А покажем демку, кто ж тебя знает, может, ничего и менять не надо будет.

«Чувак, ты же сам такие приоритеты расставил, вот мы по ним и сделали, и ты получил и расписался.»

Главное не нарваться на истерика, не понимающего что он делает)))
Был у меня один проект года 2 назад, который был выполнен по спецификации 1 в 1. В результате перед официальным анонсированным ланчем, появляется список того, что было «mentioned before», но нигде не обсуждалось и не записывалось. Sign off проекта он не сделал, истерил почти неделю, в результате договорились за доп бюджет, т.к. и ему, и нам репутация важна.
Потом узнали что было на самом деле. Проект был для правительственной организации и этот заказчик был посредником. Он контракт с нами и спецификацию подписал (фиксед прайс), а спецификацию его заказчик не подписывал и надавал кучу изменений (уже обсуждали о waterfall для крупных организаций), о которых нас никто не оповестил. В результате у нас была головомойка около недели с приходом домой в 11 вечера каждый день (само собой за хороший бонус), но все во время успели.

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

Андрей, опять вы боретесь с ветряными мельницами :) Вы же месяц назад писали статью про «недокоммуникацию», все ваши советы из нее практически повторяют Agile Manifesto и 12 его принципов.

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

Т.е., Scrum — он действительно антагонист strict-методологий, тут можно спорить, в каких случаях что больше подходит (на самом деле, все давно придумано до нас). А Agile — это не методология, а mindset, с которым можно работать по любому процессу (хоть RUP, хоть XP).

По поводу доков — я как раз в «недокоммуникации» писал зачем они нужны. Док — это качественный пруф, прикрывающий зад команды в критических ситуациях.

P.S. Кстати я на одном из проектов (команда 4 человека + я парт-тайм) использую микс Prince2 (бюрократичный и ненавистный тем, кто не любит писать документацию) + Kanban, доки мне пишет PO и это required! Т.е. фактически PO сам нас подстраховывает, команда же пишет технический доки, касаемые проекта и я пишу общий док в конце итерации, описывающий то, что было сделано. Очень зачетненько работает.

А Agile Manifesto и не говорит, что не нужны.

Working software over comprehensive documentation

That is, while there is value in the items on the right, we value the items on the left more.

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

Софт без доки почти всегда несет какую-то ценность, а вот дока без софта — никогда.

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

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

Софт без доки почти всегда несет какую-то ценность, а вот дока без софта — никогда.

Смотря на каком этапе. Код нужен тогда, когда он нужен, а дока — всегда, от первого дня работы над проектом. Внутренняя дока. Ну, пусть та же wiki по проекту.

Вот как вы распараллелите работу группы QA и девелоперов? Или полностью на автоматизацию сразу всё садите? Не долго ли потом тесты править каждый раз?

Какую ценность для заказчика несет для себя дока без работающего софта?! Например, бабло у заказчика ВНЕЗАПНО закончилось, мы говорим: «извините, пока ничего не работает, зато у нас есть полная супер-пупер спека на все требования на 5 релизов вперед». Это нормально?

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

Как мы сами определяем критерии успеха, так и будет.

Возьмём другую гипотетическую ситуацию.

В процессе работы надо проектом команда была расформирована и на её место взяли другую команду...

Или лучше.

Фирму заказчика купила другая контора и попыталась оценить стоимость проекта ...

Или проект содержал определённую исследовательскую работу (допустим, лингвистическую), ключевой исполнитель, который всё знал — свалил, у нас остался замечательный код, но не понятно, как оно всё работает.

Да мало ли. Я о том, что критерий успеха — «у нас есть код» — сомнительный. А поддержку мы той же группой будем делать, держать её вечно, что-ли?

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

нашли какого-то стороннего тестера, а он и спрашивает а что с чем сравнивать. ну акчуал я увижу, а экспектед бехейвор откуда брать?

Ну, поделюсь и я примером из жизни.

Солидная фирма, собственный отдел разработки. Наши специалисты строят им процесс. Проблема в том, что за последний год фирма увеличилась в N раз (их услуга оказалась на редкость востребованной, открылись перспективы). Потому вместо одного тестера и продакт специалиста в одном лице группа из 13 QA сотрудников с разной специализацией. Спецификаций, понятно, нет. Источник знаний — тот самый тестер, он же и специалист продукта, он же и гениальный изобретатель услуги. Наш QA всё документируют задним числом, чтобы знать, с чем сравнивать.

Спрашиваем — как должна, вообще, работать эта фича?
— Посмотрите как работает. Так и должна.
— Так она не правильно работает.
— Ну, спросите программиста. Не помню я.

Спрашиваем. Он тоже не помнит.

Ну, там какие-то формулы расчёта каких-то денег, реинженирить не реально.

Это один только момент к картине маслом.

Интересная деталь — сейчас там в QA опять один человек, документации по прежнему нет.

Мораль: хотите быстро расшириться в N раз — думайте о документации с первого дня работы. А то шанс мирового бизнес-господства пролетит мимо вас.

Госода Agile-филы а скажите пожалуйста, к вам приходили когда-то эти клиенты лет через 5 с раздутым в N раз продуктом и полным отчаянием, потому что «попытка что-то где-то поправить приводит к 2 месяцам восстановительных работ» а конкуренты тем временем догоняют и обгоняют?

Ну если клиенты решили, что потом продукт могут развивать какие-нибудь левые индусы или студэнты, после чего через пять лет они решают всю вину свалить на первоначальную команду, то это клиника. У меня сразу возникнет вопрос: «чуваки, а где support contract и проплаты по нему за все это время?»

Короткие спринты без видения целостности решения задачи => г*внокод.

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

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

И где они?

Team B решила писать документацию по ходу выполнения.
С этого момента (т. е. с самого начала) начинается г*внокод: толком не разобрались, но уже в бой!!!

Хотя, для «Hallo world!» такой подход потянет.

Конечно, я не спорю, для задач аутсерсинга г-код — это хорошо. Г-код — это море суппорта, а море суппорта — море бабла от заказчика.

согласен, когда приоритетом есть «but functional» и на завтра, начинают гaвнокодить даже адепты clear code

Еще раз повторю: проблема в менеджменте, расставляющем такие приоритеты.

rbazinet.files.wordpress.com/...66700071126.gif

И где они?

— Product vision workshops
— Product backlog refinement workshops
— Architectural community of practice
— BA community of practice
— Design workshops (эти — да, как правило, к планированию итерации привязаны)

— регулярные командировки между локациями для обмена знаниями и наращивания бизнес-экспертизы

Да море их, если видите проблему в своем процессе — предложите решение. Другое дело, что менеджмент должен всячески саппортить такие инициативы и выделять бюджет на их внедрение, а не требовать «писать код, блеать!» 40 часов в неделю.

Набор тривиальных шаблонов с громкими именами (кстати, у них есть и русские названия).

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

Первичны все-таки иные вещи, которым в книжках/тренингах по Agile и скрум не научат.

Так в кривых руках любой процесс «не взлетит». Насчет опыта совершенно согласен — для Скрама первична самоорганизованная команда, а это уже подразумевает очень высокий уровень как ее членов, так и менеджмента (т.к. рулить бойцами опытнее себя не очень получается).

P.S. Насчет русских названий не в курсе совершенно — я никогда не работал с отечественными заказчиками.

Только в примере выше о них почему-то забыли. Или это основа Agile — говорить одно, делать другое?

ВОт она — фраза моей мечты: "

Наказать заказчика через change request

" , написал АНдрей Богданов в одном из комментов.

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

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

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

В оффлайн бизнесе Change Request-ы оплачиваются без вопросов и это не вызывает ни у кого недоумения: если вы НЕ оплатили занос мебели на 12 этаж то водитель и грузчики мебельной фирмы, которые доставили ее к вашему подьезду не будут таскать мебель на 12 этаж чтобы сохранить вашу лояльность. ;-)

Стоимость просто несравнимая. Там вы платите 5 баксов, их никто не замечает. А тут вы требуете пару штук.

Я думаю, тут вопрос более общий. Потребность какая-то наказать любого, чье поведение не устраивает. Может какое-то видоизменение извечной проблемы: чтобы задать вопрос «что делать,» нужно непременно получить ответ на «кто виноват?»

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

Думаю, что Аджайл Манифесто более применим для продуктовых кампаний. Так как цель — сделать успешный продукт для рынка. Вот и думаешь, что действительно:

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

обеспечения.

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

конкурентного преимущества.

Работающий продукт следует выпускать как можно чаще, с периодичностью

от пары недель до пары месяцев.

На протяжении всего проекта разработчики и представители бизнеса должны

ежедневно работать вместе.

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

доверьтесь им.

Непосредственное общение является наиболее практичным и эффективным

способом обмена информацией как с самой командой, так и внутри команды.

Работающий продукт — основной показатель прогресса.

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

устойчивый процесс разработки.

Постоянное внимание к техническому совершенству и качеству

проектирования повышает гибкость проекта.

Простота — искусство минимизации лишней работы — крайне необходима.

Самые лучшие требования, архитектурные и технические решения рождаются

у самоорганизующихся команд.

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

стиль своей работы..

agilemanifesto.org/...principles.html

Как по-другому сделать собственный продукт наиболее конкурентоспособным? Надеяться на сверхъестественные способности директоров?

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

контракта.

Главная цель, как ни крути, — единовременный доход от выполнения
контракта.
Это в краткосрочной перспективе. А уже в среднесрочной — получаем конкуренцию с условным випро вместо условного айбиэм.
Как по-другому сделать собственный продукт наиболее конкурентоспособным? Надеяться на сверхъестественные способности директоров?
Проектировать пробовали? Я имею в виду продукт, а не код. Поговорить с юзерами, посмотреть похожие продукты, спроектировать персонажей, выработать концепцию дизайна под это. Это не «сверхъестественные способности», это видение продукта плюс дофига работы по детализации этого видения, устранению конфликтов и т.п.

Если честно, я не пробовал проектировать код...

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

Мной выведен очень простой, но эффективный закон: чем меньше времени на разработку, тем большую его часть надо выделить на «подумать».

Чтобы не писать заново, позволю себе ещё раз обратиться к собственным заметкам:

Аналитик, сразу наваявший по заданию руководства ТЗ на 60 страниц, формально задачу выполнил вовремя. Но фактически он впустую потерял неделю, так как не разобрался в предметной области. Более того, руководство со своими сжатыми сроками получило совершенно непригодный к использованию документ, пойдет с ним к заказчику и начнётся многомесячный геморрой по внесению правок, взаимным упрёкам в некомпетентности и глупости, обидам и т. п. В результате реальные потери времени составят человеко-месяцы!

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

Есть интересная статья blogs.telerik.com/...sing-today.aspx . В ней есть первый пункт о злоупотреблении термина Agile . Так и начинается “1.Don’t call it ‘Agile’ — The term Agile seems to have become fatigued or simply over/misused.”

Тема аджайлів вже встигла набити оскому...
Ось мені цікаво колектив, котрий розробляє новий танк — він також працює по аджайлу ?
Чи в процесі розробки і випробовування (буває і 15 років) вимоги(технології, стан науки) не змінюються ?

Як на мене справа просто в тому, що на державу достатньо 10 чоловік тих котрі можуть бути «генеральними конструкторами», наприклад танка і на ці посади можна підібрати відповідних людей, в той час коли в розробці ПЗ проектів тисячі і підібрати відповідних керівників дійсно проблема.

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

Вихід не поганий, і працюючий (але на жаль не завжди)

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

Вище наведені якості є продуктом генів, дійсно ВО («якого не треба бо не читають с#») і конкретного практичного досвіду.

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

Самолеты уже пытались строить по agile, в результате сказали, что agile г***но. Но опять таки не стоит забывать, что есть проекты, на котором он применятеся «на ура», а есть такие, на которых о нем не стоит даже думать.

Интересно а кто пробовал ? В индустриях связанных Life рисками , как то авиа, медицина , космос .. agile практики менее применимы или не применимы. Сам подписант (один из) аджайл манифесто Alistair Cockburn повторял это на докладе в КИеве — слайд № 11 в презентахе (есть и на видео, сами найдете какая минута ) agileee.org/...re-engineering

Саша, он это не для AgileEE придумал ;)

Коберн, вообще-то, по адаптивным методологиям защитил докторскую, есличо. И семейству Crystal, о котором он в том докладе упоминал, уже второй десяток лет пошел :)

ТАк я и не утверждаю что для Agileee ) Написал ж : он это повторял это на докладе в КИеве..

Самолеты уже пытались строить по agile
Кто? Можете дать ссылку на источник?

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

Нет, и это как раз и является одной из причин, почему процентов 80 всех военных разработок (даже в Империи Добра) фэйлится. Т.е., разрабатывает КБ лет 5 опытный образец, потом передает на конкурсные испытания военным (вместе с пятью другими КБ), а те фэйлят все образцы, кроме одного (или вообще все фэйлят, например, как с программой ACR в США). Соответственно, R&D бюджет неудачников идет в чистый убыток.

А, еще бывает эпик фейл второго порядка — когда Минобороны образец принимает на вооружение, выпускает ограниченную партию, отдает в rapid fielding initiative в условный афгановьетнам, а там быстро оказывается, что это не пулемет/танк, а гуано. Тогда в убыток идет еще и бюджет на выпуск опытной партии.

Ну и вообще, такую попильно-откатную отрасль, как оборонка, еще поискать нужно.

Глупо сравнивать сложность проектов и стоимость изменений в оборонке с софтвером.

Вы не правы. Это я как имевший некоторое отношение к разработке танков...

С удовольствием послушаю опровержение от очевидца.

Да шоб Вы знали, все эти якобы новые принципы гибкой методологии разработки украдены у нас, танкистов, и применялись они еще с довоенных времен :-)

* Наш наивысший приоритет — удовлетворить заказчика ранней и непрерывной поставкой полезных результатов разработки (эскизный проект, технический проект, макет, макет в натуральную величину, прототип, предсерийные образцы, установочная партия, первая серия, постоянная модернизация).
* Приветствуются изменения требований, даже на поздних стадиях разработки танка. Враг не спит и мы вовремя реагируем на его новинки, это дает конкурентные преимущества.
* Регулярный выпуск БТВТ, каждый час новый танк покидает конвейер (тут я утрирую, чтобы явно не повторять п.1).
* Конструкторы и военные должны ежедневно, на протяжении всего проекта работать вместе.
* Строить проект на мотивированных личностях. Создать им условия, предоставить необходимую поддержку и довериться им в достижении результата. И ведь какие были личности! Не то, что нынешняя в основном серость в ПМ.
* Самый продуктивный и эффективный метод передачи информации к и от команды разработки — личное общение. Представители КБ постоянно сопровождают внедрение новой техники в войсках, КБ постоянно посещают представители войск. По рекламациям представители завода едут на место.
* Рабочий новый танк — основной показатель успешности работы.
* Гибкость способствует устойчивой разработке. Применение новых технологий, конструкционных материалов, инноваций.
* Постоянное внимание техническому совершенству и хорошему проектированию повышает гибкость. Хорошо спроектированный танк может прослужить десятки лет и быть неоднократно модернизирован.
* Необходима простота — искусство минимизации объемов выполненной работы. Технологичность и еще раз технологичность. Чем проще конструкция, тем надежнее и дешевле в производстве.
* Вот тут не катит, это отсебятина Agile: Лучшие архитектуру, требования и дизайн рождают самоорганизующиеся команды.

* Команда регулярно размышляет над тем, как работать ещё эффективнее, и соответствующим образом корректирует свою последующую работу.

Как же можно, без спринтов и бэклогов.

Ну, танки не религиозные фанатики делали. У них гибкость была не декларируемая, а реальная :)

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

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

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

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

Однако! Процесс разработки итерационный, с ранними стадиями прототипирования.

Кстати, мой первый программный проект (отчетность по драгметаллам для МО) как раз делался по СТП, в соответствии с которыми разрабатывалась конструкторская документация на бронетанковую технику. До сих пор самый рискованный (новые технологии, обучение на проекте, новый процесс, исполнитель новичок) и самый успешный проект — сдан за месяц до срока (продолжительность 6 мес.), проработал не менее 10 лет без поддержки со стороны разработчика.

Ось мені цікаво колектив, котрий розробляє новий танк — він також працює по аджайлу ?
Руслан, если вы внимательно читали Аджайл Манифест, то наверное заметили, что там говорится об АйТи. Agile Manifesto for Software Development. Я так подозреваю, что танк — немного не то, а вы как считаете?

человеческий фактор есть и в каскадной, и в гибкой методологии

Владимир, что такое «гибкая методология»? аджайл — не методология.

«Однажды группа программистов запорола проект. Казалось бы, при чём здесь Agile?» ©
Уважаемые коллеги!

Есть гербалайф, да святится имя его, эйвон, мэрикей, веллнесс про, over 9000 евангелистских церквей — есть куда приложить талант. Зачем это здесь?

Очень просто — аджайл здесь, потому что модель классического менеджмента показала свою несостоятельность за последние десятилетия. Она не подходит АйТи. Почитайте про теорию запутанности и все поймете.

www.youtube.com/...h?v=QEnfukLZfUc
таки да. сказка. а точнее — небылица.
особенно если пересказать ее в соответствующей манере: жили были два иван-царевича, первый был василисой прекрасной, а второй — соловьем разбойником...
по теме
если изначально обе команды одинаковых скилов, то
— почему команде А на дизайн спецификацию понадобился месяц, а команде B — две недели?
— почему команда А, выясняя требования, обошлась без продукт овнера, а В понадобилось 2 недели — пытать персонально, чтобы посвятить в детали реализации, которые овнеру и нафик не сдались?
— почему для команды А детальный дизайн спек является обязательным до начала каких либо телодвижений по кодингу (то есть вся команда, за исключением ответственных лиц тупо пинала куи целый месяц)?
— почему команда А за следующий месяц работы, но имплементируя расписанный до мелочей дизайн не сделала бОльше, чем команда В за 1.5 месяца, работавшая по абстрактному дизайну, регулярно переделывавшая и модифицировавшая написанный ранее код?
— почему изменения требований для команды А похерили первоначальную архитектуру, а для команды В — расширили?
— почему менеджер команды В считает необходимым «детальные многочасовые разъяснения ситуации» для того, чтобы с заказчиком был найден компромис, и последний относился к проекту ответственно, а менеджер команды Б всегда лишь посылает заказчика в пеший поход за деньгами за переработку (овертаймы)?
— почему команде А запрещено отчитыватываться перед заказчиком о прогрессе в выполнении проекта и периодически (по мере готовности) показывать результат заказчику?

— и наконец, почему заказчик команды А не остался счастлив, что вовремя остановился и не потратил еще больше денег на реализацию того, чего он и сам толком не представляет, а заказчик команды Б остался доволен тем, что сроки (а значит и бюджет) увеличились втрое, и при этом вполне вероятно, что по истечении еще 8 месяцев он увидит не финальный релиз, а очередной «but functional»?

резюмируя. будь я заказчиком, я предпочел бы работать с командой А. она честнее.

Ну если это поможет могу поклясться на крови. Или привести свидетелей что так оно и было :-). Хотя вера — это конечно — штука тонкая :-)

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

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

А при чем здесь «Аgile»? Что мешало и на первом проекте сдавать

«basic, but functional» версию

и договариватся про вторую фазу?

Текст статьи труден для понимания. Дочитал и не понял сути. Это о проблемах fixed price & Agile или о не умении договариватся/планировать?

И, да, господа протестующие — вы вообще с чем спорите, с Agile Manifesto (если да, то хотелось бы услышать детальный разбор по пунктам, что именно считаете неверным), или с конкретной реализацией одного из процессов, считающихся отвечающими критериям Agile (тогда так и говорите, мол, «описание Scrum от Scrum Alliance я считаю неправильным и вредным»)?

Agile сам по себе — это простые правила типа «не пить воду из-под крана», «мыть руки перед едой» и т.п. (более того, даже оригинальное описание Scrum без этой ереси от Альянса тоже очень простое и на полноценную методологию не претендует). Очевидно, что:
а) из любого правила есть исключения (например, вода в кране грязнее, чем руки)

б) они не всеобъемлющи (например, от вируса гриппа вряд ли спасут)

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

Ну так при грамотном применении правил Вы и с Waterfall покорите мир :)

Я тут, кстати, писал только что минут 10 комментарий и случайно его грохнул (нажал Ctrl-R вместо Ctrl-T). По-моему, это неплохая иллюстрация статьи :)

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

У вас есть выбор в каждый конкретный момент времени жизни проекта, а иногда даже до :)

Есть команды, которые не могут работать по Agile, просто по набору психологических факторов и есть менеджеры, которые хорошо работают в Agile ( я даже о них рассказывал...переворачивая код Адизеса ).

Много разных причин популярности Agile, но ни одна из них не стоит того, чтобы полностью выкинуть Waterfall!

Agile это для тупых и ленивых менеджеров которые дальше своего носа не видят будущее продукта, а видят как уже наломали дров. Денег больше нет, но нужно все переделать. Вообщем agile хороший способ покрывать тупость менеджеров под видом изменяющихся требований.

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

Если ставить перед собой задачу наказать клиента, то конечно правильно :).

Так их этих клиентов тупых, ату...

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

Ну сам, ну наказал. А кому от этого легче ? Ну или хотя бы хорошо :)

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

Мне кажется мы о разных вещах — суть не в том кто дурак, а в том как минимизировать риски и потерю клиента.

Чьи риски минимизировать? Клиент обиделся что ему проект вышел дороже чем он планировал по своей же тупости и ушел.

Это как ремонт в квартире — когда вы все купили, рассчитали, сделали предварительные работы , а потом выснилось, что на такую стяжку паркет класть нельзя. И вы ошарашенно смотрите на мастера — а он вам, сам виноват, надо было рассчитывать и контролировать. А вы ему — а зачем я вас нанимал ?

И рабочие , покуривая в сторонке — а что, все правильно, сам себя наказал, будет в следующий раз знать....

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

пральна, воще эти заказчики задолбали, мешают понимаетели заниматься своими делами на работе... фичу им видителе сделать надо, щас все брошу и начну делать

Правильнее сказать после работы будешь делать — забесплатно, потому что текущие задачи никто не отменял. ;-)

Ну да, конечно. В вашей реальности изменение требований происходит только по вине «тупых и ленивых менеджеров», не желающих составить и описать 100% полный детальный скоуп до начала девелопмента?

Класс, мне бы так. «Бросить бы все, и уехать в этот Урюпинск» ©

Не семь же пятниц на неделе или сколько там длится тот спринт. Отложите все новые требования к концу всех спринтов за дополнительные деньги, только вот проблема не дальновидные менеджеры упустили важные вещи которые делают Break Changes текущей архитектуре, а дважды платить очень неохота — вот и бесятся как же все поменять в текущем спринте без дополнительных затрат да еще и успеть сделать тот функционал что планировали изначально. Затем у разработчиков возникает дилемма: как успеть поменять архитектуру да еще успеть нагнать текущие задачи в срок. Есть только 3 выхода: 1. Запросить дополнительные деньги; (для fixed price не работает) 2. Овертаймить за свой счет; (Убыток себе но лояльность клиента) 3. снизить качество разрабатываемого продукта; (не всегда возможно и не всегда приемлемое решение);

Про «поменять в текущем спринте» никто и не говорит. Речь как раз о «четвертом выходе» — объяснить клиенту, что ресурсы ограничены, а посему нужно реприоритизировать запросы таким образом, чтобы успеть сделать самое важное до момента окончания бюджета.

только вот проблема не дальновидные менеджеры упустили важные вещи которые делают Break Changes текущей архитектуре

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

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

Желаю удачи с таким подходом к клиентам, ради которых вы работаете.

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

У меня тоже, и что?

О каком таком подходе вы тогда хотели сказать?

О подохде, когда вы считаете клиента «тупым» и вместо того, чтобы решить проблему с которой он пришёл «наказываете его рублём».

Изменчивость требований это природный процесс, я сам не могу заранее предусмотреть как будет лучше, а значит и чего я хочу на самом деле. Как опытный профессионал вы обязаны построить процесс так, чтобы я мог менять требования без боли и конечно не бесплатно, но я был доволен этим и понимал, за что я плачу. А не «наказывать меня рублём».

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

Естественно клиенту никто не пишет в стиле что вы все тупые и начинайте готовиться к тому что я буду наказывать вас рублем. ;-)

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

Мне непонятно, как наличие особых случаев с плохими клиентами, позволяют судить о ситуации в общем виде?

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

Относимся ко всем изначально хорошо, но не все клиенты умеют уважать чужой труд.

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

Я очень рад, что так оно и происходит, но вернёмся вначало, ваше заявление и его стиль заставляют больше думать об обратном. Это то, почему я пожелал удачи, т.к. не верю, что без неё что-то возможно с таким подходом. Не все клиенты умеют уважать чужой труд — это факт. Наличие этих клиентов не делает agile методики плохими, а менеджеров тупыми.

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

Вот это интересная мысль, важно подавать информацию не так категорично =)

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

Команду разработчиков намного легче контролировать: Daily Reports, CodeReview, QA. Они от своей ответственности никуда не уйдут.

Не знаю проще или нет, но какое это отношение имеет к тому, что я написал?

Суть в том, чтобы каждый член команды знал, что всё это лично его ответственность, а не _менеджера_ или _не менеджера_.

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

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

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

Если все продумано, то «забаганки» юзера идут как приятное дополнение к продукту, а не как Break Changes всему что есть.

«всё продумано» это нереальный сценарий. Если стоит вопрос минимизации рисков при внесении изменений — это работа всей команды, не только менеджера.

Менеджеру который разбирается в предметной области не составит труда разложить все по полочкам без Break Changes. Взять хотя бы .NET почему то MS не взяла кого либо в менеджеры — а вот тебе Agile и команда, а мы будем подваливать тебе каждый месяц новые требования которыми должен обладать .NET и что в итоге получилось бы? Или сроки разработки 100+ лет или УГ.

Уверен что при разработке .NET новые требования не являлись сюрпризом и имели вполне закономерное продолжение.

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

Чтобы что-то выпустить в срок нужно замораживать требования, это и делает скрам на время спринта, а что вы хотели этим сказать?

Архитектура очень даже связана с предметной областью;

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

Вы что-то запутались — в скраме (вы его подразумеваете под Agile?) Product Owner как раз и является экспертом в предметной области (или же способен предоставить доступ к таким экспертам для тех требований, где он не 100% компетентен).

Так что «майкрософтовский менеджер» как раз и является отличным примером Scrum PO.

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

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

Вы что нибудь сложнее hello world реализовывали ?

И во вторых, то что вы не можете молотком выкрутить шуруп, не означает что молоток порожден безответственными людьми, которые вовремя не сообразили , что шуруп молотком не выкрутить и теперь пытаются вас обмануть ;)

Причем здесь молотки и шурупы? Вы явно не в теме. ;-)

Разруха в головах а не в сортире.

Ни Agile, ни Waterfall ничего не породждали. Просто есть профессионалы, умело использующие преимущество той или иной методологиии в зависимости от контекста, а есть орлы, которые рассказывают, что зеркало кривое. И их рассказы ну никак не влияют на качество методологии.

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

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

OMG, где это сказано? В какой «этой методологии»? Можете привести ссылку, чтобы хотя бы было понятно, что мы обсуждаем?

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

Ага, судя по слову «спринт», имеется в виду Скрам.

Так вот, в скраме, вообще-то, Product Owner не имеет права вносить изменения в спринт без согласия команды. Если команда считает, что с изменившимся скоупом она спринт зафейлит, то либо скоуп пересматривается, либо спринт останавливается. Если кто-то говорит иначе, то это уже совсем никакой не скрам.

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

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

ScrumMaster — член команды, ему ничего разъяснять не нужно (он на дэйли стэндапах вместе со всеми все видит).

PM — я о его роли в Скраме как-то писал колонку, он тут вообще не при делах.

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

Больше никому ничего объяснять не нужно, т.к. остальных ролей в скраме нет.

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

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

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

Ну и причем тут Agile?

а потому что оправдывалась вся эта чехарда именно скрамом и этими вашими аджайлами. типа это неотъемлимая часть методологии. дословно «а чего ты хочешь? это аджайл!!!11адын»

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

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

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

резюмируя упомянутые бурления, не могу не отметить, что наиболее яростными адептами аджайл методологии есть левел менеджмента. и их можно понять — их работа значительно упрощается, а часть работы и ответственности перераспределяются как на рядовых девелоперов, так и на непосредственно заказчика. скажите, почему я не слышу с нижнего левела (разработчиков) возгласов типа «тащусь от аджайла! обожаю скрам митинги, и релизы каждые 2 недели!»???

Может именно потому, что это уровень менеджмента: репутация кампании, прибыль кампании, из-за которой, в общем, должна расти и зарплата девелоперов — это профит...

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

Вот я и говорю, что в продуктовой кампании все гораздо нагляднее. Где все примерно знают как все продается и почему. Можно проще сделать выводы.

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

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

Одно из правил Agile:

Working software is the primary measure of progress.

Другое —

Continuous attention to technical excellence and good design enhances agility.

А Вы о чем?

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

я о том, что
technical excellence and good design enhances agility
!=
agility enhances technical excellence and makes design better
другими словами, в пропаганде причина и следствие переставлены местами.

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

Поддерживаю то что вы написали, но вот вам моё «тащусь от аджайла» =)

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

www.goripic.com/..._b3e0cc9878.jpg

Если мотивация для внедрения Agile именно такая — пиши пропало. Правильные мысли — «сейчас мы с помощью Agile покажем клиенту, что мы ставим его проблемы прежде всего, а потом он нам приведет новые проекты и кучу новых клиентов».

скажите, почему я не слышу с нижнего левела (разработчиков) возгласов типа «тащусь от аджайла! обожаю скрам митинги, и релизы каждые 2 недели!»???

А это смотря какая мотивация у разработчиков. Если проблемы заказчика ему пофигу, интересно только «писать код, блеать» и получать «з/п 23-летнего синьора», то, конечно же, Agile не нужен. Но если хочется получать не 30 баксов в час, а 100 (опять же, в перспективе), то для этого нужно все-таки не только знать джаву-спринг-хибернейт-паттерны, а еще иногда вникать, чего хочет заказчик, и как решить его проблему.

Вы на какой то идеальной планете живете! ;-)

Ну, вы первый же начали. Если уже хаять процесс, то его описание по методичке, а не чью-то кривое внедрение.

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

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

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

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

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

Лучшее наказание в данном случае — это наказать заказчика через change request. А дальше уже все просто: хочешь — делаем, не хочешь — не делаем.
===

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

Откуда такие динозавры ) ? Аgile допускает что нельзя продумать на год вперед, что понадобиться продукту и особенно , какие фичи актуальнее всего будут ему нужны через полгода. Это просто невозможно сделать даже супер мега головастому менеджеру)). Особенно если это web проект, в интернет индустии все очень быстро меняется.

Все попытки это сделать превращаются в создание гор фич, которые не используются или почти не используются)). Посмотрите на историю развития программного мира и мысли — сейчас более преимущественным подходом разработки является итеративно-инкрементальный , т.е. сделал набор фич — выпустил — ПОЛУЧИЛ ФИДБЕК от юзеров — понял, чего не хватает , добавил в список фич — сделал — выпустил — получил фидбек и так далее. ИМенно такой подход позволяет делать ВСЕГДА самое важное, самое востребованное и актуальное на ТЕКУЩИЙ МОМЕНТ ВРЕМЕНИ. Это один из фундаментальных прицнипов agile’ a

Я бы еще привел в пример Facebook, в котором вообще полный continuous delivery: сегодня придумали фичу, завтра заимплементили и выпустили в лимитед продакшен (на отдельных кластерах), послезавтра собрали статистику и решили, что с ней дальше делать (развивать дальше или прибить). А не ждать полгода релиза, чтобы потом выяснить, что 3/4 вылизанных фич нафиг никому не упали.

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

«Дура — не дура, а тридцатку в день имею» © анекдот

Чота вот ниасилил вабще:).

О чем статья? О том, что в одной команде выбрали неверный подход работы с ДАННЫМ заказчиком в ДАННОМ проекте? О том, что «ватерфол гауно» и только Agile спасет мир и сделает заказчика довольным? Что T&M лучше фиксед-прайс?

«ватерфол гауно»

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

Андрей, это я с иронией:). Проблемы-то в проектах «не в клозетах» ;)

Я думаю о том, что «Человек смертен, и это было бы еще полбеды. Плохо то, что он иногда внезапно смертен, вот в чем фокус»

Кстати, по поводу Agile... Сравните Agile, который пропогандирует популярный Scrum Alliance и Agile под эгидой PMI и увидите, как говорят в Одессе, 2 большие разницы. PMI-евский Agile больше защищает Agile команду и за основу берет многое из PMBOK, что, откровенно говоря, приятно удивило.

Посоветуйте, пожалуйста, что бы почитать про Agile под эгидой PMI, так чтобы читать мало, а знать много :) На pmi.org, конечно, много всего ...

Валерий, к сожалению вас ввели в заблуждение )) Нет такого PMI Agile и быть не может.
Это говорю вам я — человек, который получил все существующие в мире сертификации по Аджайл, включая PMI-ACP. Читайте Аджайл Манифест и умные книжки )) И забудьте про PMBOK — это зло, по крайней мере в ай ти сфере.

Если можно — мне бы тоже почитать специальную версию Agile manifesto for PMI. Думал что это — agilemanifesto.org единственная версия.

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

Что именно добавили? Пожете привести примеры того, что PMI добавил в Аджайл?

Скачни последний PMBoK — вся сермяга PMI в нем...

Что за глупость. Даже PMI настолько консервативный и тот столько уже позамиствовал из agile практик. И уже давно признал превосходство итеративно-инкрементального подхода.

угу, а еще переписали PMBOK под Agile manifesto :))))))))))))))))))))))))))))))))))))

Ну то что такая заскорузлая обросшая стандартами организация ввела сертификацию PMI-Agile Certified Practitioner , уже о многом говорит. То, что PMI за последние годы много берет из agile не мои слова , а слова PMP Юрия Кравченко , ведущего блон pmblog.com.ua

Ну, на Agile 2011 PMI наняли Алистера Коберна промоутить PMI-Agile Certified Practitioner на их стенде. Так что чуют, куда ветер дует.

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

Андрей, мне как человеку сдавшему PMI-ACP очень интересно увидеть

PMI-евский Agile больше защищает Agile команду и за основу берет многое из PMBOK
Где вы это нашли? Что такое
PMI-евский Agile
? Что конкретно берется из PMBOK? Я идеально знаю PMBOK, можете указать что именно взято?
Как fixed-price, так и agile-проекты имеют право на жизнь.
Качественно управляйте проектом, умейте доказать правоту ссылаясь на документацию, change requests и ситуаций

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

не возникнет.
В каждой методологии есть свои плюсы и минусы. Тот же agile не покрывает качественно управление бюджетами, тайм менеджмент или управление рисками. Те же «толстые методологии» не дают гибкости, удобной командам разработчиков без ПМ (вариант с наймом команд под заказчика).

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

а кто-то говорит, что agile покрывает управление бюджетами, рисками итд? Или, при agile, от этого всего можно легко отказаться?

Я говорю, что agile покрывает.
Agile это подход, а не методика. Agile скрамом вообще-то не исчерпывается.
Но управлене бюджетом есть даже в скраме. А насчет рисков — в MSF for Agile есть много про риски.

Могу подробнее, если интересно.

Тогда если можно, дайте формулы по которым Вы оцениваете риски для проекта/итерации/задачи? Не проще ли пользоваться готовыми решениями того же pmbok или prince2?

С удовольствием.
Для одного проекта, с не очень большими технологическими и коммуникационными рисками мы написали risk management plan по вот этому документу: www.microsoft.com/...ils.aspx?id=721

Никаких рисков для итераций и задач мы не оценивали.

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

Мы оценивали задачи с помощью ТТМ-матрицы (www.infoq.com/...mation-toolkit, где отдельными столбцами были technical risk и communication risk. Команда их оценивала в S/M/L, которые потом переводились в числа и добавлялись в общий эстимейт с коэффициентом «1».

Не проще ли пользоваться готовыми решениями того же pmbok или prince2

Проще, я лично так и делаю. И от этого наша разработка не становится менее гибкой ))

:)

дело ж не в гибкости, а в качестве. по поводу матриц я в курсе, поэтому и намекнул, что работа с рисками в аджайле слабовата.

Как fixed-price, так и agile-проекты

Справедливости ради нужно заметить, что существуют Agile Fixed Price контракты.

Насколько я понимаю, проект B был как раз fixed-price.

Что же происходит в Team B? Клиент тоже меняет требования, добавляет истории и детализацию в беклог. Количество feature points, в которые оценивается беклог, уже вдвое превысила тот «very basic», с которого начинали. Однако он не платит за изменения и (после детального многочасового разъяснения ситуации), очень ответственно подходит к приоритезации задач.

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

та все ж просто
цена фиксированная — а набор требований нет

ну то есть может быть уменьшен

например у нас есть $1000
на месяц разработки
хотим сделать фичи A,B,C и D
но через 2 недели оказалось что В заняла в 2 раза больше времени

тогда выбрасываем D, чтобы уложиться в бюджет

принцип «плати больше или бери меньше» :)

Чтоб закрыть тему — оба проекта начинались именно как fixed price. Разница только в подходе «фиксирования» скопа. Считались men-hours на рейт у обоих. Так что пусть меняет что хочет главное чтоб не вылезло за пределы договоренной суммы. А потом — у Team A пошел change request Managment а Team B просто сразу начали выстраивать приоритеты изначально и продолжали в том же духе.

но почему в одном случае реквесты меняли цену, а во втором нет?

потому что в первом случае — кроме цены была подписана спецификация (те scope) и изменения пошли как change request, а во втором случае scope остался не зафиксированным (что конечно с точки зрения классического управления проектами является преступлением :-)) фиксировалась только скорость качество команды.

простите за возможно глупый вопрос: а нефиксация скопа — это только для Agile характерна?

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

о! значит команда A — это была _ваша_ команда? )))))

upd нету команду в начале назвал

предлагаю оставить это под покровом тайны :-) хотя странно было бы для меня в таком случае писать эту статью :-)

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

это все потому что у заказчика А бабло закончилось

а у заказчика В — нет, вот и вся разница

предлагаю слоган для Agile:

«Мы освоим ваш бюджет играючи!» :)

Щоб закрити тему — реально fixed price відрізняється від time and material одним-єдиним принципом — у першому випадку оплачується плановий обсяг робіт, а в другому — фактичний. Відповідно, модель fixed price у випадку коротких ітерацій зводиться до оплати оцінної працемісткості задач. Це перше.
Друге. Обидві команди працювали ітераціями. Інше питання, наскільки ефективно було організовано управління вимогами, їх змінами та очікуваннями клієнта. Але це мало залежить від моделі ЖЦ проекту і навіть від довжини ітерацій. Менше з тим, короткі ітерації дозволяють підвищити стійкість проекту до змін вимог. Але зовсім не виключають ймовірності провалу проекту, особливо у випадку розробки великої системи з нуля, коли ризик архітектурної неузгодженості компонентів системи може врешті-решт призвести до повного провалу після кільканадцяти успішних поставок.

Ну я так и написал — оба проекта изначально подписывались как fixed price. Оба проекта соответственно оценивались, торговались на основе первой оценки и сроках (оба были 4 месяца) и тп. О Т&M речь не идет.

В такому випадку команда Б працювала без оплати зміненого обсягу робіт. А команда А — з оплатою. Відповідно, замовник у випадку команди Б заплатив менше за ту саму роботу. І, що недивно, залишився задоволеним. Слава роботодавцю команди Б, який дозволив їй працювати у збиток...

клиент заплатил ровно столько сколько договаривались не больше и не меньше и команда отработала ровно то кол-во часов которое было уговорено. Так что по факту никто в убытке не остался. Ж-) вот в чем хитрость то :-)

а что ж это тогда ? man-hours умножить на рейт = сумма денег которая не изменяется т/е fixed price. Кто сказал что fixed price должен быть еще и fixed scope (кроме команды А)? или даже fixed task list Ж-)

Ще раз.
Fixed price — оплачується плановий обсяг робіт, тобто замовнику нецікаво, скільки ми реально витратили часу.
Man-hours помножити на рейт — це чистої води time and material.

ну дык и я ж о том же!!! — фиксированная ЦЕНА за проект. Ему все равно какой там план. Он хочет феррари красненькое за милион и все. И ему все равно что для этого будет делаться. А мен аурс на рейт это как это считается. Ну конечно плюс коммерческая накрутка но это — по факту себестоимость которую объявляют клиенту. То есть именно этот милион за феррари. В T&M себестоимость проекта никто не объявляет так как ее никто не знает и продают просто man hours без ограничений по итоговой СУММЕ за проект.

Я знаю, що і під яким соусом продається :-)
Але є формальності, а є факт. Час (фактичний) на рейт — це T&M, а ніякий не FP.
Втім, я нерідко задумуюсь, чи знають професійні аутсорсери щось інше, ніж «фактичний час на рейт», і чи варто їм пояснювати, що проект — це перш за все результат, а вже потім витрачені на нього зусилля :-)
А якщо комусь як результат проекта потрібен лише ферарі за мільйон, можна взагалі не переживати за те, що зроблене не відповідає реальним потребам. І в такому разі це взагалі не проект, а розпилювання...
І до речі, я ніде не вживав слова «собівартість». Її в будь-якому випадку замовнику оголошувати не варто :-)

ОК Будь по Вашему :-) Это был T&M c фиксированной ценой. А как еще в аутсорсе посчитать стоимость проекта если не через затраты рабочего времени ? Ж-) Результат к сожалению не имеет унифицированной единицы измерения Ж-)

Ээээ. Мой мозг не смог обработать.

T&M с фиксированной ценой — это как это? Мне-то всегда казалось, что либо одно, либо другое. Либо мы еще Т или М прибиваем гвоздями, ибо.

Это тот случай, когда у заказчика есть бюджет Х, который он использует чтобы построить то, что ему хочется в T&M стиле. Все классно до тех пор, пока бюджет на разработку исчерпывается, а к тому моменту кастомер имеет еще целую кучу идей и пытается втулить их в стиле «it was mentioned before» :)

Если цена была фиксирована зараннее и не была превышена... Мне кажется, что это была фиксированная цена. Если использовался T&M для расчета этой фиксированной цены... То как это называется?

пардон, а разве

change request Managment

с отказом от меенее приоритетных требований из первичного списка в пользу более приоритетных запросов на изменения и

выстраивать приоритеты

для юзер стори в проджект бэклог — это разве НЕ ОДНО И ТО ЖЕ? ))))

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

В этом утверждении точно нет путаницы между Agile и итеративно-инкрементальной разработкой (возможно, с заимствованием каких-то отдельных техник или подходов из Agile)?

Вот именно это я и имел в виду выше. Вы точно имеете в виду Agile или все-таки какой-то конкретный процесс? Если что, ни в Agile Manifesto, ни в 12 principles of Agile software development вообще даже слова такого нет: «итерация».

Использовать agile manifesto в чистом виде в процессе — это все равно что пить чистый спирт :) Вы лично знаете тех, кто использует аджайл, но не имеет в процессе такой важной вещи как итерации?

Да, я знаю команды, которые работают вполне в духе Agile Manifesto, но в качестве процесса используют Kanban.

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

Идеальный процесс — это как сферический конь в вакууме. На практике любой процесс неидеален, вопрос только в том, насколько он удовлетворяет текущие цели.

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