В 90-х Джеф Сазерленд и Кен Швабер экспериментировали со своими командами и вырабатывали подходы, которые потом и назвали Scrum методологией. Они говорили о коротком цикле разработки длиной в один месяц. На фоне долгосрочных многолетних проектов – это была уже сама по себе революция, которая обеспечивала быструю обратную связь и гибкость всего проекта. Сегодня две недели стали уже де-факто стандартом длины итерации (спринта). Более того, некоторым компаниям две недели оказываются слишком долгими, и они требуют от своих команд коротких недельных итераций.

“Почему недельная  длина спринта хуже?”, – этот вопрос мне часто задают команды, с которыми я работаю, во время моих тренингов и просто в общении со знакомыми Скрам мастерами. Попробую обобщить свои мысли на эту тему.

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

Во-вторых, у вас не получится сделать большой список Критериев Готовности (“Definition of Done”). Если в вашем DoD чек-листе много нужных идей вроде “peer review когда”, или хотя бы минимального обновления документации, или полной автоматизации тестирования и т.п. – это будет требовать времени. Как и предыдущая причина, длинная цепочка действий не позволит с должным качеством сделать много за одну недельную итерацию.  Как следствие, если у вас минимальные Критерии Готовности, то результаты, которые команда показывает в конце недельной итерации, могут требовать дальнейшей доработки в следующих спринтах. Нужно понимать, что качество не бывает дешевым 😉

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

В-четвертых, если заболел или отсутствует один из членов команды – это сильно влияет на общую ситуацию, скорость и даже вообще возможность что-то сделать за неделю.

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

В-шестых, потери на организацию и поддержку самого Скрам процесса становятся существенными. Да-да, я имею в виду плановые встречи. Даже если у вас опытная команда и все встречи проходят максимально быстро, буквально по полчаса на каждую, то все равно получается где-то 3-4 часа. Это полдня, что составляет 10% из 5 дней итерации. В тоже время, если у вас итерация две недели, то это будет всего 5%, а времени на встречи нужно почти столько же, сколько и при одной неделе.

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

Стоит обсудить с Владельцем Продукта и командой, какова причина того, что требуется такой короткий цикл.

Возможно, вашему Владельцу Продукта нужно давать команде быструю обратную связь о том, что делается и поэтому возникла идея недельной итерации. Тогда это больше похоже на подход, который был в Extreme Programming (XP) – там предлагалось работать короткими недельными итерациями и делать Выпуск раз в месяц. В Scrum чаще всего говорят, что в конце итерации нужно показывать уже готовый продукт, максимально близкий к поставке. Можно обсудить этот момент и договориться о разных Критериях Готовности для итерации и Выпуска.

Возможно, наоборот, вам требуется частая поставка готовых функций пользователям, поэтому попытка сократить длину итерации была попыткой сделать частые поставки. Подумайте, можно ли включить “отгрузку” в список работ по каждой функции и делать обновления вне зависимости от цикла итерации. Кстати, может вам стоит перейти на Канбан? Хотя сейчас часто говорят про Scrum-ban, как допустимый микс регулярных и ритмичных циклов, которые дает Scrum, и свободного потока, который дает Kanban. Об этом я постараюсь написать подробнее в ближайшее время, следите за обновлениями.

Пожалуй, это все мысли, что были на эту тему. Если у вас есть еще что-то – не стесняйтесь поделиться 🙂