Чем вымощена дорога в agile? часть i. ничто «не едет» без сильной команды

- kbrbank

Чем вымощена дорога в agile? часть i. ничто «не едет» без сильной команды

Мы начинаем публикацию саги о эластичных методиках разработки.

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

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

Цель этого материала — не отвратить от применения способов Agile, а обратить внимание на необходимость взвешенного принятия и подхода во внимание всех рисков.

Начнем с маленького дисклеймера.

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

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

Персональный опыт фактически любого менеджера недостаточен для статистики

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

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

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

•     Я не буду сравнивать Agile с другими способами, а буду оценивать его применимость к конкретным обстановкам и его ограничения. К слову, Agile довольно часто сопоставляют с разработкой водопада (waterfall), а по факту «совершенный водопад» весьма в далеком прошлом уже никто не использует. Разрешу себе аналог из области диеты: это как сравнивать последствия регулярного здорового питания с потреблением в пищу бургера три ежедневно.

На этом я покончил с дисклеймером и перейду к выводам. «А где же главное содержание?» — спросите вы. Я исхожу из того, что поклонники Agile не обожают пространных сложных построений и документов. Исходя из этого — сходу выводы, но к каждому выводу я попытаюсь привести кейсы либо доводы.

Agile весьма требователен к квалификации команды.

Первый проект на Agile я сделал в 2004 году, и это был кредитный конвейер. У нас был клиент, осознающий, чего он желает, экстремально сжатые для совсем нового проекта сроки и Excel как главный инструмент управления бэклогом и планирования спринтов. Современную прекрасную Jira тогда тяжело было кроме того представить. Проект был довольно успешным — мы не выдержали сроки, но клиент однако добился ощутимого бизнес-результата.

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

Что же пошло не так?

•     Догадка 1 от Agile: у вас имеется product owner, что в состоянии выразить либо консолидировать вывод всех стейкхолдеров.

Вы рискуете в каждой следующей итерации не наращивать, а переделывать ранее созданный функционал

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

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

Вы желаете хороших коммуникационных навыков, воли и дара предвидения, и хорошего понимания предметной области от product owner? В случае если у вас таковой имеется, вам крупно повезло. Догадка 1 время от времени срабатывает. Я же не утверждал, что этого не бывает.

Легко требования высоки — на рынке такие эксперты не валяются.

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

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

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

На практике взаимозаменяемость достигается лишь для довольно маленького подмножества задач

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

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

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

•     Догадка 5: команда легко переварит новых участников, а универсальность способа делает проект свободным от конкретных участников. — Как бы не так!

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

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

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

На этом разговор о сложностях Agile не заканчивается: интрига лишь начала закручиваться, продолжение направляться… 

Напоминаем: Вторая ежегодная клубная конференция «Эластичное управление проектами в банках» отправится в Москве в 26 октября. Организатор мероприятия — Bankir.Ru, модератор — Антон Арнаутов. Вся подробная информация — по ссылке.

15 февраля 2014: Team motivation in Agile

Интересные записи

Похожие статьи, которые вам, наверника будут интересны: