Все о SCRUM. Изучение, разработка, интеграция

‣ Гойко Аджич, «Impact Mapping. Как повысить эффективность программных продуктов и проектов по их разработке», Альпина Паблишер, 2017

‣ Джефф Паттон, «Пользовательские истории. Искусство гибкой разработки ПО», Питер, 2017

16 Планирование на среднесрочную перспективу

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

Однако в большинстве случаев, с которыми я имел дело, команды нуждались в плане предстоящей работы. Планирование помогало им принять те или иные решения.

В Peetic постоянно встают вопросы о будущем.

– Сможем ли мы использовать управление подписками для выставки собак в марте?

– Через сколько времени мы сможем анонсировать запуск приложения на планшет?

– Какой бюджет необходим для разработки версии 2 приложения?

– Когда нам понадобится компонент онлайн-платежей, который разрабатывается извне?

В этой главе мы увидим, что среднесрочное планирование может помочь при ответе на все эти вопросы.

16.1 Зачем планировать то, что будет после спринта?

16.1.1 Небольшое напоминание о том, что такое сроки

Для полного взаимопонимания давайте сперва разберемся в значении некоторых понятий.

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

✓ планирование на среднесрочную перспективу (сезон),

✓ поставка конечным пользователям (ввод в эксплуатацию),

✓ техническая реализация (развертывание).

Вот мои обновленные определения:

Сезон – это период времени, состоящий из последовательности спринтов.

В предыдущих изданиях я называл этот период релизом. Соответственно, план релиза стал планом сезона.

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

Рисунок 16.1 – Все сезоны имеют одинаковую продолжительность.

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

Развертывание – это процесс установки версии в среде для изучения чего-либо (ценность обучения).

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

Ввод в эксплуатацию – это предоставление пользователям версии продукта (бизнес-ценность).

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

Ввод в эксплуатацию содержит развертывание в среде производства и активацию доступа для пользователей [46].

Пример разграничения трех понятий внутри команды Peetic.

– Сезон длится 3 месяца и состоит из 6 спринтов по 2 недели каждый. В конце сезона команда проводит ретроспективу, открытое собрание и подготовку плана следующего сезона. И так четыре раза за год.

– Ввод в эксплуатацию происходит раз в месяц по завершении работы над функциональностью.

– Развертывание происходит раз в месяц по завершении работы над историей.

16.1.2 Чтобы подготовить ввод в экспуатацию продукта