Рассуждения о нулевой итерации в Scrum

Приветствую, хабровчане!

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

Я нередко встречаю команды, которые практикуют использование «Спринта Зеро» для того чтобы провести подготовительные работы: привести к нормальному состоянию свой Product Backlog и инфраструктуру (development environment, сервера continuous integration), чтобы подготовить команду к началу нового этапа работы и т д. Почему они решили что это является частью Скрам? Насколько это вообще полезно?
Я посчитал, что по данному вопросу лучше всего будет обратиться к высказываниям известных Agile-личностей.

Jeff McKenna говорит:

Это термин, часто используется у новых команд, или у тех, кто новичок в Скрам. Упорядочивание первоначального беклога, приведение к рабочему виду рабочих мест и машин для билда и автотестинга, подготовка всех инструментов, возможно, чуть-чуть тренингов, и еще чуть-чуть работы, чтобы убедиться что это все работает.… Это не «официальный» Скрам, Но это общий случай, который довольно часто встречается. Мы ожидаем, что команды будут полностью готовы (после нулевой итерации) для атаки реальной работы!

Dan Rawsthorne так охарактеризовал нулевую итерацию:

Идея проста: берем начальный спринт (его и называют его инициализацией, Спринтом 0 или нулевой итерацией), и задаем ему простые цели:

• Получить в результате некоторое число quality items в беклоге продукта
• Предоставить минимальный environment, который предоставляет возможность писать качественный код,
• Написать минимальный работающий код, причем не имеет значения, насколько маленький

Mark Woyna считает, что спринт 0 лучше использовать как спайк:

Команда должна сделать 3 результата к концу этой итерации

• Список всех проэстимированых и приоритизированых фичей/стори»
• Релиз-план, в котором все фичи/стори присвоены итерации/спринту
• Должна быть создана архитектура приложения, хотя бы на высоком уровне, т. е. должно быть понятно как эти фичи будут имплементированы.

Peter Stevens, аджайл-коуч из Швейцарии, использует Спринт 0 для того чтобы оценить не все, а самые важные фичи, сойтись в едином мнении о definition of done, восстановить/повысить доверие заказчика. Как и многие, он советует сделать длину этого спринта короче других, нормальных по длине для команды спринтов.
Так является ли это Скрамом? Мы получаем итерацию совсем другой длины, чем обычная длина спринта для команды, и результат спринта – совсем не potentially shippable product. Или, может, это полезно настолько, что можно закрыть глаза на такие нестыковки?

Во многих командах существует множество вещей, который необходимо сделать перед тем, как стартовать проект/релиз.
George Dinwiddie считает, что даже если команды пытаются сделать всю предварительную работу, всегда остается много незаконченного, что предстоит доделать в предстоящих спринтах. И мы тоже добавить: “Welcome changes!”. А значит, решения по инфраструктуре, выбор технологий, и список фич, определенных в «итерации зеро», станут управлять процессом, а не наоборот. А ведь каждая итерация должны получать на выходе работающий продукт.

Спросите себя, что нужно, чтобы начать деливери? Возьмите это, и нарежьте его мелкими ломтиками. Придумайте примеры, которые будут хорошо показывать, что эти ломтики рабочие. Некоторые кусочки будут иметь вопросы без ответов. В данный момент отставьте такие кусочки в сторону. Выберите один центральный кусок, который проходит через весь концепт от начала до конца, или близок к этому. Проэстимируйте его как одну итерацию для команды. Оценки не должны быть «правильными», они просто должны быть! Начните разработку этого продукта!

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

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

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

Alistair Cockburn по этому вопросу более жесткий:

Меня терзают смутные сомнения, что кто-то давит на ваше использование скрам в команде, когда вы делаете в самом начале что-то, что не дает очевидного бизнес-значения. А этот «кто-то» изобрел «О. это же спринт ноль!», чтобы крестьяне с кирками ушли от его порога… А затем, и другие, думая, что это отличный ответ, повторяли его вновь и вновь. А потом это стало частью культуры.

Стоит ли приравнивать спринт ноль к предварительному планированию (upfront planning)? Некоторым действительно трудно представить нулевой спринт без предварительного планирования. Представляя, что это часть чартеринга проекта. Но многие команды, тем не менее, не обсуждают цели и видение проекта во время нулевой итерации. Они чаще тратят время на создание беклога и инфраструктуры.

Кен Щвабер по этому вопросу говорит:

Фраза «Спринт 0» была создана для того, чтобы описать планирование, которое происходит до начала первого спринта. А так как планирование создает артефакты, которые потом часто меняются, оно должно быть сведено к минимуму на данном этапе, а затем должно происходить каждый спринт во время sprint review/sprint planning

Выходит, общее мнение светил аджайла по вопросу нулевого спринта скорее сходится во мнении, что это не совсем родная для скрам вещь, и ее лучше вообще избегать по возможности. А ключевым моментом является добавление бизнес-значимости прямо с самого начала. Видит ли ваша команда существенный плюс в проведении нулевой итерации вместо того чтобы сразу начать производить business value, постепенно по пути наращивая инфраструктуру и принимая решения о технологический стеке?
Если видит, то нужно ответить на вопрос для себя — не попахивает ли это все ситуацией, когда «подготовительные работы» не окончатся ни после нулевой итерации, ни после первой, и это будет мешать команде двигаться вперед полным ходом, и не попахивает ли это некоторой дисфункцией команды? Если ответ отрицательный, может быть, это ваш способ.

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