Руководство профессионального скрам-мастера: Практические советы по внедрению аджайл-подходов

Скрам и бережливость

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

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

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

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

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

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

Роли в скраме

Этот раздел – краткий обзор трех ролей в скраме: скрам-команда, владелец продукта и скрам-мастер. Наша книга посвящена в основном роли скрам-мастера, но мы подробно разберем и остальные роли, исходя из их естественных взаимосвязей. Как вы, наверное, сами понимаете, людей обычно очень беспокоит, какова их роль в коллективе и где границы их зоны ответственности. Мы более предметно поговорим о ролях в скраме (и не только в скраме) в главе 9 «Формирование аджайл-организации».

Скрам-команда

Скрам-команда включает в себя владельца продукта, скрам-мастера и членов команды (оговоримся, что команда разработки состоит только из технического ядра команды). Вся команда принимает участие в работе над поставленной проблемой (элементом бэклога – упорядоченного списка требований, журнала пожеланий) и разрабатывает инновационные решения. Скрам-команда – это 5–9 участников, организованных в группу на период жизненного цикла проекта (и, возможно, на более длительный период). Команда должна обладать соответствующими полномочиями, быть кросс-функциональной[4 - По скраму именно команда должна быть кросс-функциональной, т. е. содержать в своем составе все необходимые для регулярной поставки продукта компетенции. Важно понимать, что скрам ничего не говорит о том, что каждый член команды – универсал. – Прим. науч. ред.], а также способной к самоорганизации. Они сами планируют, оценивают и берут на себя обязательства по своей работе, а не надеются на менеджера. Конечная цель работы команды состоит в создании инкремента продукта, который потенциально можно представить заказчику и который удовлетворяет критериям готовности. Обувных мастеров George Cleverly and Company мы можем рассматривать как ядро скрам-команды (команду разработки), тогда как клиент, дизайнеры обуви и так далее совместно с теми же обувными мастерами будут составлять общую скрам-команду. И все эти люди участвуют в производстве соответствующей модели обуви.

Владелец продукта

Владелец продукта несет ответственность за его конечный успех. Иными словами, если команда отвечает за поставку качественного решения, владелец продукта должен хорошо знать рынок и понимать нужды потребителей, чтобы правильно направлять команду на разработку потенциально продаваемого на рынке релиза – от спринта к спринту. В разных проектах владельцы продуктов, разумеется, разные, но – независимо от технической ситуации и желаемых результатов – у каждого продукта должен быть один (и единственный) владелец, который принимает окончательные решения о направлениях его разработки и порядке создания элементов функциональности. Бэклог, или список того, что должна сделать скрам-команда, составляется владельцем так, чтобы отражать наиболее ценные требования и пожелания к продукту (или их изменения по мере продвижения разработки). Владелец продукта, представляя себе все «что» и «зачем», связанные с разработкой, должен быть доступен для регулярного диалога с командой о требованиях, которые содержатся в бэклоге продукта. Кроме того, владелец продукта должен добиться, чтобы каждый участник команды отчетливо видел будущий продукт и чтобы бэклог заполнялся в соответствии с этим видением. У владельца продукта всегда должен быть готов очередной набор пожеланий по продукту – чтобы команда заблаговременно представляла себе объем работы для следующего спринта. Клиент компании по производству элитной обуви (см. пример выше) – это идеальный пример владельца продукта для скрам-команды: именно он и платит за продукт!

Скрам-мастер

Скрам-мастер «охраняет» процесс разработки. Он понимает причины, лежащие в основе эмпирического процесса, и изо всех сил пытается обеспечить как можно более ровный ход разработки продукта. Этот «слуга-лидер» (термин принадлежит Р. Гринлифу – см. его книгу «Слуга в роли лидера»[5 - Гринлиф Р. Слуга в роли лидера. – М.: Рубиновый луч, 2003.] (Servant Leadership)) защищает членов команды от нежелательных вмешательств и отвлекающих моментов для того, чтобы дать им возможность сосредоточиться на выполнении своих обязательств по спринту, а также помогает владельцу продукта правильно работать с бэклогом. Кроме того, он фасилитирует все встречи, заложенные в структуру скрама, добиваясь, чтобы каждый член команды осознавал поставленные цели и разделял общую ответственность – словом, чтобы команда была настоящей командой, а не наспех собранной группой индивидуумов. Скрам-мастер устраняет препятствия на пути разработки функциональности, несущей максимальную ценность в продукте. Зачастую природа этих препятствий – организационная.

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

Обзор структуры скрама

Структура скрама проста: это шесть событий, одно из которых опционально, три роли и три «официальных» артефакта.

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

Планирование спринта

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

Планирование обычно занимает 8 часов для 30-дневного спринта. Это время пропорционально сокращается для более коротких спринтов (например, планирование двухнедельного спринта длится не более 4 часов). Совещание состоит из двух частей. В первой части главная роль отводится владельцу продукта, который представляет наиболее важные элементы бэклога (при этом он может пользоваться иллюстрациями, моделями, схемами и т. д.) и дает разработчикам пояснения по любым вопросам – что он хочет видеть в продукте и почему он хочет это видеть. Во второй части совещания на авансцену выходит скрам-команда разработки, члены которой совместно вырабатывают подходы к процессу разработки и в итоге согласовывают план. Именно с этого этапа – второй части планирования – начинается собственно спринт.

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

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

Ежедневные скрам-митинги

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

Обзор спринта

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

Ретроспектива спринта

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

Планирование релиза продукта (опционально)

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

Кен Швабер как-то сказал мне: «Я не понимаю, почему люди превращают планирование релиза в такое долгое и нудное мероприятие. На деле в нем нет ничего сложного». И после этого мы провели планирование релиза за 15 минут.

Артефакты скрама

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

Бэклог продукта

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

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

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

Бэклог спринта

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

Инкремент продукта

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

Видимый прогресс

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

Бэклог и диаграмма сгорания релиза

Разновидность бэклога продукта, который составляется под релиз конкретного продукта, так и называется – бэклог релиза. Хотя бэклог релиза можно составить и заранее, в ходе проекта владелец продукта имеет право убирать или менять требования, а также договариваться с командой о глубине охвата конкретных элементов в соответствии со своими взглядами на объем работы, время и затраты. Таким образом, в процессе реализации проекта бэклог релиза должен постоянно обновляться. В главе 2 будет рассказано подробнее о бэклогах продукта, а также о бэклогах релиза и диаграммах сгорания.

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

Диаграмма сгорания спринта

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