Стейша Вискарди
Руководство профессионального скрам-мастера: Практические советы по внедрению аджайл-подходов
Роли в скраме
Этот раздел – краткий обзор трех ролей в скраме: скрам-команда, владелец продукта и скрам-мастер. Наша книга посвящена в основном роли скрам-мастера, но мы подробно разберем и остальные роли, исходя из их естественных взаимосвязей. Как вы, наверное, сами понимаете, людей обычно очень беспокоит, какова их роль в коллективе и где границы их зоны ответственности. Мы более предметно поговорим о ролях в скраме (и не только в скраме) в главе 9 «Формирование аджайл-организации».
Скрам-команда
Скрам-команда включает в себя владельца продукта, скрам-мастера и членов команды (оговоримся, что команда разработки состоит только из технического ядра команды). Вся команда принимает участие в работе над поставленной проблемой (элементом бэклога – упорядоченного списка требований, журнала пожеланий) и разрабатывает инновационные решения. Скрам-команда – это 5–9 участников, организованных в группу на период жизненного цикла проекта (и, возможно, на более длительный период). Команда должна обладать соответствующими полномочиями, быть кросс-функциональной[4], а также способной к самоорганизации. Они сами планируют, оценивают и берут на себя обязательства по своей работе, а не надеются на менеджера. Конечная цель работы команды состоит в создании инкремента продукта, который потенциально можно представить заказчику и который удовлетворяет критериям готовности. Обувных мастеров George Cleverly and Company мы можем рассматривать как ядро скрам-команды (команду разработки), тогда как клиент, дизайнеры обуви и так далее совместно с теми же обувными мастерами будут составлять общую скрам-команду. И все эти люди участвуют в производстве соответствующей модели обуви.
Владелец продукта
Владелец продукта несет ответственность за его конечный успех. Иными словами, если команда отвечает за поставку качественного решения, владелец продукта должен хорошо знать рынок и понимать нужды потребителей, чтобы правильно направлять команду на разработку потенциально продаваемого на рынке релиза – от спринта к спринту. В разных проектах владельцы продуктов, разумеется, разные, но – независимо от технической ситуации и желаемых результатов – у каждого продукта должен быть один (и единственный) владелец, который принимает окончательные решения о направлениях его разработки и порядке создания элементов функциональности. Бэклог, или список того, что должна сделать скрам-команда, составляется владельцем так, чтобы отражать наиболее ценные требования и пожелания к продукту (или их изменения по мере продвижения разработки). Владелец продукта, представляя себе все «что» и «зачем», связанные с разработкой, должен быть доступен для регулярного диалога с командой о требованиях, которые содержатся в бэклоге продукта. Кроме того, владелец продукта должен добиться, чтобы каждый участник команды отчетливо видел будущий продукт и чтобы бэклог заполнялся в соответствии с этим видением. У владельца продукта всегда должен быть готов очередной набор пожеланий по продукту – чтобы команда заблаговременно представляла себе объем работы для следующего спринта. Клиент компании по производству элитной обуви (см. пример выше) – это идеальный пример владельца продукта для скрам-команды: именно он и платит за продукт!
Скрам-мастер
Скрам-мастер «охраняет» процесс разработки. Он понимает причины, лежащие в основе эмпирического процесса, и изо всех сил пытается обеспечить как можно более ровный ход разработки продукта. Этот «слуга-лидер» (термин принадлежит Р. Гринлифу – см. его книгу «Слуга в роли лидера»[5] (Servant Leadership)) защищает членов команды от нежелательных вмешательств и отвлекающих моментов для того, чтобы дать им возможность сосредоточиться на выполнении своих обязательств по спринту, а также помогает владельцу продукта правильно работать с бэклогом. Кроме того, он фасилитирует все встречи, заложенные в структуру скрама, добиваясь, чтобы каждый член команды осознавал поставленные цели и разделял общую ответственность – словом, чтобы команда была настоящей командой, а не наспех собранной группой индивидуумов. Скрам-мастер устраняет препятствия на пути разработки функциональности, несущей максимальную ценность в продукте. Зачастую природа этих препятствий – организационная.
Представьте себе, что скрам-мастер – это такая Швейцария: сохранение нейтралитета, помощь всем стейкхолдерам, вмешательство в самые подходящие моменты – и все это для того, чтобы создавать в первую очередь наиболее важные и ценные элементы функциональности продукта.
Обзор структуры скрама
Структура скрама проста: это шесть событий, одно из которых опционально, три роли и три «официальных» артефакта.
Спринт – первое из шести событий – итерация с определенной датой начала и окончания. Спринт начинается с планирования и заканчивается обзором и ретроспективой. Команда ежедневно собирается на скрам-собрания (скрам-митинги), цель которых – сделать текущую работу каждого члена команды видимой для других и синхронизировать общие действия на основе того, что было усвоено в процессе работы над проектом.
Планирование спринта
Во время планирования спринта (второе событие) владелец продукта и команда обсуждают важнейшие задачи, внесенные в бэклог продукта, и осуществляют «мозговой штурм» плана по их реализации. Совокупность пожеланий и требований, выбранных для спринта, и задачи, поставленные перед командой в связи с этим, называются бэклогом спринта.
Планирование обычно занимает 8 часов для 30-дневного спринта. Это время пропорционально сокращается для более коротких спринтов (например, планирование двухнедельного спринта длится не более 4 часов). Совещание состоит из двух частей. В первой части главная роль отводится владельцу продукта, который представляет наиболее важные элементы бэклога (при этом он может пользоваться иллюстрациями, моделями, схемами и т. д.) и дает разработчикам пояснения по любым вопросам – что он хочет видеть в продукте и почему он хочет это видеть. Во второй части совещания на авансцену выходит скрам-команда разработки, члены которой совместно вырабатывают подходы к процессу разработки и в итоге согласовывают план. Именно с этого этапа – второй части планирования – начинается собственно спринт.
Разумеется, команды всегда ищут способы сделать планирование более быстрым и эффективным. Если команда действует последовательно, то можно заметить, что от спринта к спринту время, затрачиваемое на их планирование, сокращается.
Результат планирования спринта – бэклог спринта, который включает в себя конкретные требования по продукту для конкретного спринта, а также соответствующие задачи, поставленные командой во второй части планирования. Мы детально рассмотрим, как обеспечить эффективность планирования спринтов, в главе 3.
Ежедневные скрам-митинги
В ходе ежедневных скрам-совещаний (третьего события скрама) члены команды стараются сделать свой прогресс в работе видимым, чтобы проинспектировать его и адаптировать к своим целям. Это чем-то похоже на ежедневный мини-цикл Деминга («Планируй – пробуй – проверяй – корректируй»)! Совещание обычно проводится в одно и то же время и в одном и том же месте, о чем команда договаривается заранее. Даже если команда приложила все усилия для правильного планирования спринта, ситуация может измениться в мгновение ока. Том завершает свою работу с небольшим опозданием, Бет, наоборот, раньше, а Ашиш вообще застрял на половине. Во время 15-минутной встречи члены команды обсуждают, что им удалось сделать со времени предыдущего митинга, что они планируют сделать к завтрашнему, а также беседуют про препятствия, которые стоят перед ними. Роль скрам-мастера на таких совещаниях – содействовать обсуждению, не давать участникам «закопаться» в поиск решений для каждой проблемы и фиксировать все препятствия, с которыми, как полагают члены команды, они не могут справиться сами. Скрам-мастер должен попытаться устранить эти препятствия после совещания. Ежедневное скрам-собрание представляет собой текущую оценку и адаптацию сделанного. В совещании участвуют члены команды, владелец продукта и скрам-мастер. Присутствовать могут все желающие – но только в качестве наблюдателей.
Обзор спринта
Обзор спринта, четвертое событие скрам-метода, дает возможность всем стейкхолдерам высказать в обстановке сотрудничества свои соображения по поводу разрабатываемого продукта. Команда, владелец продукта, скрам-мастер и остальные желающие встречаются, чтобы обсудить элементы функциональности, прогресс работы и текущее состояние продукта, а также обменяться мнениями о том, какие элементы продукта необходимо изменить, и, возможно, сформулировать ряд новых идей, которые можно было бы включить в бэклог. Обычно на таких совещаниях скрам-мастер резюмирует ход спринта, упоминает о важнейших трудностях и проблемах, с которыми столкнулась команда, перечисляет решения, принятые «на ходу» при помощи владельца продукта, и т. д. И, разумеется, на итоговых совещаниях команда должна продемонстрировать, чего ей удалось добиться к окончанию спринта. Такое совещание должно продолжаться не более 4 часов (для 30-дневного спринта).
Ретроспектива спринта
В ходе ретроспективы – финальной встречи в рамках спринта – члены команды обсуждают события спринта, отмечают, что помогло им в работе, а что – нет, и решают, что нужно поменять в ходе следующих спринтов. Скрам-мастер фиксирует вопросы, которые команда, по ее мнению, не может решить самостоятельно и которые, возможно, должны решаться в масштабе всей организации. В дальнейшем скрам-мастер должен будет сообщить команде о действиях, предпринятых по поводу возникших вопросов. Ретроспектива должна занимать не более 3 часов. Мы подробнее рассмотрим обзор и ретроспективу спринта в главе 5 «Конец? Как шаг за шагом улучшать продукт и процесс его разработки».
Планирование релиза продукта (опционально)
Последнее (и необязательное, факультативное) событие скрама – это планирование релиза продукта, в ходе которого скрам-команда планирует долгосрочные инициативы на основании множественных достижений нескольких спринтов. Владелец продукта и команда обсуждают пункты бэклога, зависимости между задачами, риски, план-график, производительность команды и другие вопросы, и, кроме того, согласовывают прогноз на предстоящие работы. Так как бэклог может быть безразмерным, планирование релиза помогает команде и владельцу продукта понять, каковы шансы выпустить продукт в срок. Можно даже вести сокращенную версию бэклога – так называемый бэклог релиза, ценный результат планирования релиза. Такое совещание тоже должно иметь фиксированную продолжительность, однако она разнится и зависит от масштаба программы, количества команд, их распределения по заданиям и от качества самого бэклога. Планирование релиза часто проводятся в самом начале проекта, а по ходу работы команды встречаются с владельцем продукта, чтобы вносить в план соответствующие коррективы в зависимости от полученного опыта. В то же время команды нередко откладывают планирование релиза до тех пор, пока не выполнят хотя бы несколько спринтов: накопленные знания и опыт придают уверенность и позволяют строить более долгосрочные планы релизов (подробно об этом см. главу 2 «Планирование релиза – настройка процесса разработки продукта»). Организация может выбрать любой вариант – в зависимости от ее потребностей.
Кен Швабер как-то сказал мне: «Я не понимаю, почему люди превращают планирование релиза в такое долгое и нудное мероприятие. На деле в нем нет ничего сложного». И после этого мы провели планирование релиза за 15 минут.
Артефакты скрама
Набор артефактов скрама невелик: бэклог продукта, бэклог спринта и инкремент продукта после каждого спринта. Ниже мы рассмотрим и детально проанализируем эти артефакты.
Бэклог продукта
Бэклог – это журнал пожеланий владельца продукта. Все, что владельцы (и другие стейкхолдеры) хотят увидеть в окончательном варианте продукта, заносится в этот список. Бэклог, как уже говорилось, может быть бесконечным: постоянно возникают новые идеи, как улучшить функциональность. Ведет бэклог владелец продукта, хотя доступ к нему должен быть и у членов команды, и у других стейкхолдеров, чтобы они могли предлагать новые элементы в список (задачи или требования).
Владелец продукта формулирует приоритеты, начиная с самых важных или самых полезных позиций. Имеется в виду, что верхняя часть списка представляет собой не просто 10 важнейших позиций, а скорее 10 наиболее приоритетных и срочных позиций. Именно так они и фигурируют в бэклоге продукта – одна за другой. Именно эти позиции – первые в очереди для реализации. Как только команды выбирает задачи, которые должны быть выполнены в рамках очередного спринта (или итерации), эти позиции и их очередности фиксируются. Впрочем, любые приоритеты и детали любого элемента бэклога, если он еще не взят в работу (в спринт), могут быть изменены. При помощи такого механизма команды могут сосредоточиться на задачах конкретного спринта, а владелец продукта сохраняет максимальную свободу действий, устанавливая объем работы на очередной спринт.
У владельцев продукта много способов для оценки и расстановки приоритетов по списку. Требования по продукту, содержащиеся в бэклоге, могут также сопровождаться дополнительными примечаниями: например, нужно увеличить узнаваемость бренда, поднять продажи, заинтересовать клиентов, готовых вложить не менее $10 000, и т. д. Такие дополнительные примечания уникальны для каждой компании и конкретного продукта – они помогают владельцу продукта поддерживать бэклог в порядке.
Бэклог спринта
Бэклогом спринта обычно занимается сама команда: он отражает те задачи, которые команды обязалась выполнить в ходе планирования спринта, а также задачи, отложенные на будущее, и перспективные идеи. Члены команды ежедневно обновляют бэклог спринта, чтобы определить, сколько часов осталось у конкретного работника на выполнение стоящей перед ним задачи. Кроме того, члены команды могут снимать, добавлять и изменять задачи по ходу спринта.
Инкремент продукта
Инкремент (приращение) продукта – ощутимый результат работы каждого спринта. Он представляет собой набор бизнес-функциональности, отдельных пользовательских историй и других результатов, которых команде удалось добиться в ходе спринта. Инкремент продукта должен быть потенциально готовым к поставке, то есть достаточно высококачественным для того, чтобы его можно было передать пользователям. Владелец продукта отвечает за принятие инкремента продукта после каждого спринта – в соответствии с согласованными критериями готовности и критериями приемки по каждому результату работы в спринте (функциональности, пользовательской истории, обособленной задачи). Без инкремента продукта его владелец и другие стейкхолдеры не в состоянии ни проинспектировать, ни адаптировать продукт.
Видимый прогресс
Команда должна добиться, чтобы ее прогресс был всегда видимым. Для этого она может пользоваться различными инструментами. К этим инструментам относятся, например, диаграммы сгорания – то есть графики сделанной и оставшейся по релизу и спринту работы.
Бэклог и диаграмма сгорания релиза
Разновидность бэклога продукта, который составляется под релиз конкретного продукта, так и называется – бэклог релиза. Хотя бэклог релиза можно составить и заранее, в ходе проекта владелец продукта имеет право убирать или менять требования, а также договариваться с командой о глубине охвата конкретных элементов в соответствии со своими взглядами на объем работы, время и затраты. Таким образом, в процессе реализации проекта бэклог релиза должен постоянно обновляться. В главе 2 будет рассказано подробнее о бэклогах продукта, а также о бэклогах релиза и диаграммах сгорания.
Диаграмма сгорания показывает, сколько работы остается в бэклоге релиза после окончания каждого спринта. Это дает владельцу продукта важную информацию для принятия обоснованных решений по объемам работы, времени и затратам. Из нижеприведенной диаграммы понятно, что объем работы, остающейся в конце каждого спринта, больше, чем планировалось.
Диаграмма сгорания спринта
Если в процессе конкретного спринта каждый член команды будет обновлять бэклог спринта, ежедневно указывая количество оставшихся часов работы по каждому заданию, то команда увидит, удастся ли ей «сжечь» эти часы до конца спринта. Следующая таблица показывает, что команда не справилась со всеми задачами, определенными в плане спринта: остается еще примерно 50 часов работы.
Диаграмма сгорания очень важна – ведь дата окончания спринта устанавливается раз и навсегда. Наряду с ежедневными скрам-митингами бэклог спринта и диаграмма сгорания наглядно показывают команде, когда она сбивается с ритма, и позволяют предметно обсудить, что можно предпринять для исправления ситуации. Диаграмма сгорания спринта «сжигает» часы работы по дням спринта, тогда как диаграмма сгорания релиза отражает выполнение единиц работы (часто оцениваемых в неких условных единицах) или количество спринтов, оставшихся до релиза. В главе 3 и 5 подробно рассказывается про бэклоги и диаграммы сгорания.
Сбой или настоящая проблема?
Скрам основан на «бережливой» концепции превращения идеи в функциональность продукта c максимально возможной эффективностью. Скрам-модель подразумевает выявление препятствий на пути к результатам. Законы скрама защищают команду от хаоса – так, чтобы к концу спринта она смогла выполнить свои обязательства перед клиентом.
Цикл жизни проекта, как правило, краток, а препятствия, которые необходимо выявлять, возникают постоянно, поэтому список проблем, требующих вмешательства скрам-мастера, может быть бесконечным. В ходе работы команда ежедневно, ежечасно сталкивается с самыми разными препятствиями и отвлекающими моментами. Владелец продукта и стейкхолдеры, подводя итоги спринта, внимательно исследуют продукт. Это часто приводит к изменениям в бэклоге продукта и, таким образом, в самом продукте. Ретроспектива спринта дает команде возможность сосредоточиться на совершенствовании процесса, чтобы в дальнейшем он протекал более гладко. Следует отметить, что скрам-модель содержит три встроенных механизма для выявления проблем. Как говорят в Техасе, если вы ищете приключений на свой зад, то обязательно их найдете. А скрам может выявить немало проблем.
Так что же нам, скрам-мастерам, делать со всеми этими трудностями? Нужно спросить себя: «Трудность, с которой мы столкнулись, настоящая проблема нашей организации или просто досадный сбой?» Рассмотрим пример настоящей проблемы – документ, который необходимо представить для утверждения в Управление по санитарному надзору за качеством пищевых продуктов и медикаментов США (FDA). Скажем, в ходе ретроспективы команда указала, что эта проблема приводит к непроизводительным потерям, – но ведь ни один продукт не попадет на американский рынок без разрешения от FDA. Так что это и есть настоящая проблема, с которой придется тщательно работать.
Или, например, давайте представим себе, что на ретроспективе спринта сотрудник жалуется, что его часто отрывали от командной работы, заставляя переключаться на другой проект с другим менеджером. Это серьезная проблема? Вполне возможно. Но, возможно, и просто сбой. Почему? Скрам гласит: члены команды должны быть преданы общему делу и сосредоточены на выполнении обязательств перед командой. Когда разработчик вынужден отвлечься на другой проект, у него голова идет кругом от перегрузок, поскольку объем работы увеличивается. Вполне вероятно, что он не выполнит свои обязательства ни перед командой, ни по другому проекту. Пока элементы функциональности не готовы, невозможно провести их инспекцию и адаптацию, что сводит на нет все плюсы эмпирического контроля. Словом, это неприемлемый вариант, членов команды нельзя отрывать от текущей работы. В таких случаях скрам-мастер должен предупредить владельца продукта, что выполнение разработчиком своих обязательств находится под угрозой. Возможно, о проблеме придется довести до сведения руководства, чтобы такие просьбы больше не повторялись, – да и сами члены команды должны научиться отказывать. Впрочем, маловероятно, что описанная ситуация возникнет в самом начале работы.
Готова ли ваша команда к скраму?
Начиная (или даже продолжая) работать со скрамом, вы, скорее всего, едва ли получите в свое распоряжение идеальную команду, функционирующую в идеальных рабочих условиях. Поэтому я подготовила короткий список: что необходимо уяснить в первую очередь для успешного начала работы.
● В вашей команде все члены выделены для проекта на 100 %? Члены команды представляют собой кросс-функциональный набор навыков и способностей, которых в совокупности достаточно для поставки ценности конечному заказчику?
● Есть ли у вас владелец продукта? Если нет, можете ли вы подобрать кого-то на эту роль, чтобы команда как можно скорее начала работать над самыми важными элементами бэклога?
● Есть ли у владельца продукта свое видение, ведет ли он бэклог? (Подробнее см. главу 5.)
● Можете ли вы организовать не более чем 30-дневный (а еще лучше – более короткий) спринт?
● Можете ли вы привлечь к участию в обзоре спринта бизнес-стейкхолдеров? (Это отнюдь не обязательное требование, однако в этом случае повышается оперативность и прозрачность работы вашей команды.)
● Хватит ли вам смелости обсуждать проблемы по мере их появления?
● Можете ли вы помочь команде создать и вести бэклог спринта? (Подробнее см. главу 2.)
● Можете ли вы взять на себя обязательства по защите команды от вмешательств, независимо от того, кто будет их инициатором?