Скрам

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

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

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

Глава 7 Отчетность по проекту – поддержание прозрачности

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

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

Давайте посмотрим, какую информацию о статусе проектов по скраму использовали разные компании. В MegaEnergy мы увидим переход от традиционного отслеживания исполнения работ к отчетности в духе скрама, хотя руководству были неудобны новые способы отслеживания прогресса. Руководителю MegaBank, финансирующему проект, не нравились периодические отчеты скрама. Он хотел получить обобщенное графическое представление о прогрессе проекта. Мы посмотрим, каким образом эта потребность была удовлетворена. В Service1st отчеты участников команды разработки во время ежедневного скрама были настолько общими и абстрактными, что это 15-минутное событие казалось практически бессмысленным. Мы рассмотрим, почему это произошло, и обсудим, как обеспечить достаточный объем информации и деталей в отчетах.

Новая отчетность в проекте MegaEnergy

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

Команда проекта в MegaEnergy создавала внутренние артефакты: технические задания, архитектуры, модели, код. Если проект не стопорился на разработке этих артефактов, то в самом конце они объединялись и превращались в рабочую систему. Только тогда заинтересованные лица могли увидеть то, что будут в дальнейшем использовать. Заинтересованные лица – это те, кто заинтересован в результатах проекта, включая тех, кто финансирует проект, и тех, кто будет пользоваться разрабатываемой системой.