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

скачать книгу бесплатно


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

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

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

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

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

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

Далее. В бережливом производстве считается, что разработка продукта должна вестись быстро. Принцип скрама – передача готового продукта производится в среднем раз в 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 часов работы.

Диаграмма сгорания очень важна – ведь дата окончания спринта устанавливается раз и навсегда. Наряду с ежедневными скрам-митингами бэклог спринта и диаграмма сгорания наглядно показывают команде, когда она сбивается с ритма, и позволяют предметно обсудить, что можно предпринять для исправления ситуации. Диаграмма сгорания спринта «сжигает» часы работы по дням спринта, тогда как диаграмма сгорания релиза отражает выполнение единиц работы (часто оцениваемых в неких условных единицах) или количество спринтов, оставшихся до релиза. В главе 3 и 5 подробно рассказывается про бэклоги и диаграммы сгорания.

Сбой или настоящая проблема?

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

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

Так что же нам, скрам-мастерам, делать со всеми этими трудностями? Нужно спросить себя: «Трудность, с которой мы столкнулись, настоящая проблема нашей организации или просто досадный сбой?» Рассмотрим пример настоящей проблемы – документ, который необходимо представить для утверждения в Управление по санитарному надзору за качеством пищевых продуктов и медикаментов США (FDA). Скажем, в ходе ретроспективы команда указала, что эта проблема приводит к непроизводительным потерям, – но ведь ни один продукт не попадет на американский рынок без разрешения от FDA. Так что это и есть настоящая проблема, с которой придется тщательно работать.

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

Готова ли ваша команда к скраму?

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

? В вашей команде все члены выделены для проекта на 100 %? Члены команды представляют собой кросс-функциональный набор навыков и способностей, которых в совокупности достаточно для поставки ценности конечному заказчику?

? Есть ли у вас владелец продукта? Если нет, можете ли вы подобрать кого-то на эту роль, чтобы команда как можно скорее начала работать над самыми важными элементами бэклога?

? Есть ли у владельца продукта свое видение, ведет ли он бэклог? (Подробнее см. главу 5.)

? Можете ли вы организовать не более чем 30-дневный (а еще лучше – более короткий) спринт?

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

? Хватит ли вам смелости обсуждать проблемы по мере их появления?

? Можете ли вы помочь команде создать и вести бэклог спринта? (Подробнее см. главу 2.)

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

Заключение

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

Глава 2

Планирование релиза – настройка процесса разработки продукта

В традиционных проектах содержание[6 - Здесь и далее терминология проектного менеджмента приводится по русскоязычному изданию «Руководства PMBOK

» – «Руководство к своду знаний по управлению проектами» (М.: Олимп-Бизнес, 2018). – Прим. пер.] (объем) определяется и контролируется по ходу проекта. Аджайл-команды подходят к этому вопросу по-другому: сначала определяют достаточный для начала проекта объем, а затем примиряются с необходимостью изменений и начинают работать, следуя по вновь открывающимся путям. Аджайл-команды стремятся прежде всего отвечать на запросы рынка или пользователей по мере возникновения этих потребностей. Однако время от времени нужды бизнеса требуют и от них планирования на перспективу. Члены аджайл-команд понимают, что предсказать итоги работы по проекту невозможно, поэтому действуют прагматически – подстраивают усилия по разработке продукта к последним и самым важным требованиям. Это похоже на прогноз погоды в вечерних новостях: предсказания метеорологов на следующий день, как правило, сбываются, а вот через неделю – никогда! К сожалению, не существует команд (и метеорологов), способных предсказывать будущее. Именно поэтому я всегда держу в машине запасной зонтик.

Традиционные проектные метрики – скажем, запланированный объем, стоимость и сроки – не годятся в случае сложных технических проектов. Вот вам простой пример (на самом деле таких примеров тысячи): если команда проекта меняет его направление потому, что клиент на полпути меняет требования, это провал? Члены аджайл-команд уверенно ответят, что нет, пояснив, что умение реагировать на меняющиеся требования свидетельствует как раз об успехе работы. Но я слышала и противоположные утверждения: если бы члены команды уделяли больше внимания обсуждению требований заказчика, то они смогли бы предугадать все его нужды с самого начала, чтобы не сталкиваться по ходу работы с неожиданными осложнениями (как будто возможно забросить невод и вытащить, как рыбу, все возможные требования к проекту!). Согласно традиционной логике управления проектами, если мы не достигли цели по объему, срокам и стоимости, значит, проект провалился. К сожалению, до сих пор многие руководители следуют этому глубоко укоренившемуся принципу. Это может свести на нет любые попытки аджайл-планирования.

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

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

Впрочем, вы живете в реальном мире и вряд ли решитесь на бунт, поэтому у меня есть для вас совет, который несколько полезнее лозунга «Ура, долой правила!». Во-первых, не бойтесь иметь альтернативную точку зрения по вопросам планирования. Помните, почему в современных условиях вас просят планировать проекты: потому что этого требует бизнес. Ограничения – стоимость проекта, его сроки и ресурсы (человеческие и не только) – это данность, с которой скрам-мастеру придется иметь дело в ходе проекта. Или не совсем данность? Аджайл-методы позволяют сделать паузу и задуматься, что все эти параметры могут изменяться – если организации для итогового успеха необходимы перемены. Знайте, что в настоящее время среди организаций набирает силу тренд на отход от традиционного мышления по вопросам управления проектами. И я целиком и полностью списываю это на аджайл. Аджайл смещает фокус – с «магического кристалла» на «постоянную адаптацию». Мэри Поппендик, автор книги «Бережливая разработка программного обеспечения: Аджайл-инструменты» (Lean Software Development: An Agile Toolkit), утверждает, что успешные компании не составляют планы и не следуют им, а создают возможности и реагируют на перемены в реальном мире. Скрам-фреймворк предоставляет два инструмента для осознания потенциала и планирования: долгосрочное планирование релиза продукта и краткосрочное планирование спринтов. Основа обоих инструментов – бэклог. Эта глава научит вас, как планировать релизы и вместе с тем видеть в скраме возможность тихого бунта, как применять философию и инструменты скрама, чтобы изменить взгляд организации на проекты и ценности.

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

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

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

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