Как и Scrum, в наши дни стали чрезвычайно популярны сериалы. Создатели того или иного сериала сначала проверяют интерес к своей идее, выпуская пилотную серию и подготавливая несколько эпизодов первого сезона. И если сезон будет хорошо принят зрителями, за первым на экраны выйдет второй, и третий, и еще больше, пока сохраняется интерес публики.
Эта аналогия спринта с эпизодом сериала поразила меня, и по этой причине я буду использовать термин «сезон» для обозначения последовательности из нескольких спринтов.
Ранее, в предыдущих изданиях этой книги, я использовал термин релиз. Но это постоянно приводило к путанице между периодом времени и поставкой в головах моих читателей. Поэтому я хотел бы заменить этот термин и в дальнейшем использовать слово сезон, когда речь идет о временном периоде, состоящем из нескольких спринтов.
Я рекомендую фиксировать сезон по продолжительности, как и спринт. Другими словами, все сезоны одинаковы по времени. Мы вернемся к этому в главе 16.
Как и в спринте, команда сама определяет продолжительность сезона.
Рисунок 2.10 – Релиз заменен сезоном. Наблюдается сопротивление переменам.
Паттерн сезонного ритма состоит в ритмичном делении периода разработки на отрезки по 3 месяца, в которые проходят спринты.
Оказывается, в этом может помочь деление времени на триместры. Посчитаем: триместр длится около 13 недель.
✓ Команда проводит двухнедельные спринты, выходит 6 спринтов за сезон, плюс остается неделя, о которой мы скоро поговорим.
✓ Команда проводит трехнедельные спринты, у нее выходит 4 спринта за сезон.
Цикл спринтов может продолжаться в течение длительного времени, например, нескольких сезонов. Есть также предпремьерный сезон, конец сезона и пост-финальный сезон.
Рисунок 2.11 – Спринты и сезоны
Период до начала спринтов составляет прелюдию.
Название нулевой спринт вызывает сомнения и приводит к недоразумениям, мы не будем его использовать. Следует понимать, что это этап, отличающийся от последующих спринтов.
Прелюдии посвящена целая глава (см. главу 13), мы к ней вернемся, когда познакомимся со всеми элементами Scrum.
Так как сезонов будет несколько, интерлюдия тоже будет не одна.
До этого мы видели, что спринты следовали один за другим, без интервала. В конце сезона рекомендуется делать передышку, скажем, на неделю.
Зачем? Чтобы провести на другой скорости цикл инспекции/адаптации, который бы охватывал более устойчивые темы, чем те, что были в фокусе спринта.
Это также поможет команде поддерживать желаемый ритм, который иногда нарушается в связи с непрерывной цепочкой спринтов.
Вот несколько вариантов того, чем можно заняться во время интерлюдии:
✓ празднование успеха команды,
✓ ретроспектива, посвященная окончившемуся сезону (см. главы 12 и 22),
✓ небольшое увеличение команды (см. главу 3),
✓ чистка бэклога (см. главу 8),
✓ прогнозы на следующий сезон (см. главу 16),
✓ открытый форум по вопросам Agility (см. главу 22),
✓ любая другая деятельность, не связанная с продуктом, – чтобы расслабиться или просто отвлечься.
Существует ли последний сезон?
Если команда прекращает работу над продуктом, это значит, что продукт мертв или передан другой команде. Последний вариант объясняется двумя возможными причинами:
✓ Трансфер c целью техобслуживания. Обычно ввод в эксплуатацию выполняется после разработки и другой командой. В некоторых организациях разработкой и обслуживанием занимаются разные люди. В Agile-подходе такого разделения нет. Те, кто занимается разработкой продукта, знают лучше остальных, как оказывать поддержку, исправлять ошибки и дальше его развивать. Следует помнить: в отличие от концепции проекта, цикл спринтов не заканчивается на первой версии. Он продолжается на протяжении всей жизни продукта, который развивается по мере релизов. Можно также сказать, что обслуживание начинается после первого ввода в эксплуатацию. Тем не менее, в жизни продукта может наступить момент, когда поток входных данных уменьшается и больше не оправдывает команду такого размера. В таком случае команда может сама решить, как ей дальше работать. Это отличный момент для начала использования Kanban (см. главу 20).
✓ Трансфер с целью релиза. Это тот случай, когда вводом в эксплуатацию занимается не Scrum-команда [15].
15
Обидно, когда ввод в эксплуатацию занимает время, потому что в течение этого периода бизнес-ценность не более чем виртуальная. –