Готовим фичи к PI-планированию — нет водопадному мышлению

Часть 1. Опасность водопадного мышления: минимально необходимое и точно в срок — это еще не все

На непрерывное уточнение Бэклога Продукта уходит много сил. Как на уровне Бэклога Фичей, так и на уровне Бэклога Историй. Кажется, в SAFe® (Scaled Agile Framework®) слишком много времени уходит на подготовку Фичей к PI-планированию.

Что такое PI-планирование

PI-планирование — ключевое событие SAFe, поощряющее Agile-поведение.

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

Это сердцебиение Agile Release Train и любой имплементации SAFe.

На PI-планировании команды работают совместно друг с другом и Владельцами Продуктов над Фичами и Историями прорабатывают, декомпозируют и оценивают их. В итоге команды берут на себя ответственность за результат.

Непрерывное уточнение Фичей из Бэклога Программы один из самых сложных вызовов для команд, работающих по SAFe. Приоритеты постоянно меняются, регулярно появляются новые клиенты, новые Фичи, а текущие Фичи трансформируются или устаревают.

К Фичам, также как к Историям, а может даже и в больше степени, применимы классические техники, такие как INVEST (прим. пер. — Independent — независимая, Negotiable — обсуждаемая, Valuable — ценная, Estimable — оцениваемая, Small — небольшая, Testable — тестируемая) и 3C (прим. пер. — Card — карточка, Conversation — обсуждение, Confirmation — подтверждение).

Так как Инкремент Программы ограничен по времени, большие по размеру Фичи должны быть декомпозированы таким образом, чтобы:

1. Могли быть завершены в рамках одного PI.
2. Будут равномерно реализовываться в рамках PI-итераций и не будут отложены на последний момент. Сами Фичи должны быть понятными, выполнимыми и проверяемыми.

Учитывая вышесказанное, один из наших Менеджеров Продукта начал свою первую сессию PI-планирования с набора карточек, каждая из которых кратко описывала одну из ожидаемых Фичей, используя шаблон, показанный ниже (прим. пер — другую версию шаблона фичей от Марка Ричардса скачайте в статье Эффективный шаблон описания Фичей в SAFe®).

Рисунок 1: Пример карточки Фичи

Он поощрял совместное с командами обсуждение объема каждой Фичи, ее Историй и критериев приемки.

Таким образом получилось добиться высокого уровня сотрудничества и вдохновить команды на взятие на себя полной ответственности за реализацию выбранных ими Фичей, сформировать надежный план и, в конечном итоге, выпуск первого для команды жизнеспособного релиза. В итоге, команды добились невероятной для первого Инкремента Программы результата метрики предсказуемости поставки более 80%.

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

Рисунок 2: Регрессионная спираль водопадного мышления

Водопадная реализация Фичей может привести к постоянным проблемам команды, таким как:

• Давление плана: команда сразу же чувствует, что их работа состоит в том, чтобы просто реализовать все Истории как есть, даже если они думают, что они ошибочны, не нужны или просто глупы. Еще, если сложность Историй оценена не командой, то она чувствует себя под еще большим давлением. От команды требуют выполнения именно того, что заранее определено, и точно, когда это было запланировано. Это давление ставит под угрозу любой план, который был создан, и мешает команде по-настоящему следовать плану, поскольку он кажется им чужим.
• Отсутствие ответственности: когда командам предоставляется то, что кажется окончательным набором Историй для Фичи, команды не берут на себя никаких обязательств. Они чувствуют, что их работа состоит в том, чтобы просто делать то, что им говорят и реализовывать все Истории, независимо от того, приближают ли они на самом деле к реализации Фичи или нет.
• Отсутствие вовлеченности членов команды: когда команды берут на себя полную ответственность за Фичу и брейнштормят Истории с Владельцем Продукта, все заряжаются энергией и вовлекаются. Когда Истории спускаются сверху и подаются как свершившийся факт, это приводит к тому, что команда не вовлекается, а механически выполняет работу. PI-планирование становится достаточно скучным административным событием, который команды стараются избегать. Сигналом такого планирования является то, что команда на ретроспективе поднимает вопрос о целесообразности посещения PI-планирования всей командой.
• Отсутствие обратной связи в процессе работы: Продуктовый Менеджмент приходит к команде со списком связанных Историй, которые они передают командам для реализации. Команды работают изолированно, пока все Истории не будут закончены, а завершенная Фича не будет передана на приемку. Такой процесс влияет как на само PI-планирование, так и на спринты: Фичи рассматриваются по принципу «все или ничего», каждая История должна быть завершена, прежде чем Фича будет продемонстрирована, а уж тем более принята.
• Прогнозное, а не адаптивное планирование: одно из следствий заранее определенной работы это прискорбная тенденция к тому, чтобы вернуться к прогнозному планированию, когда командам назначается работа, которая должна быть завершена в определенное время. В свою очередь адаптивное планирование предполагает, что команды “вытягивают” (pull)работу и планируют “минимально необходимо” (just enough), чтобы быть уверенными в выполнении своих обязательств.
• Зависимость, а не сотрудничество: одна из целей PI-планирования состоит в том, чтобы подтолкнуть команды сотрудничать для улучшения потока программы и их собственной эффективности. Там, где Истории определены заранее, команды, как правило, сотрудничают гораздо меньше, часто принимая на веру полученные зависимости, вместо того, чтобы продумывать их самостоятельно.

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

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

Это может показаться нелогичным, но один из секретов SAFe заключается в том, что чем лучше вы в SAFe и в PI-планировании, тем больше вы можете доверять командам и тем меньше вам нужно готовиться.

В этой первой статье описано, как и почему вы должны противостоять искушению чрезмерно централизовать подробный анализ или искушению завершить детальную подготовку Историй до PI-планирования. В следующей статье мы сосредоточимся на “семи смертных грехах” связанных с подготовкой новых Фичей.

SAFe and Scaled Agile Framework are registered trademarks of Scaled Agile, Inc.