Приветствую, хабровчане!
Сегодня я решился написать свою первую статью на Хабр (так что уж не судите строго).
В этой, как и в большинстве последующих статей от меня, я буду говорить об Agile. Scrum и некоторых моментах из этой серии, на мой взгляд, являющихся интересными тем, кто увлекается данным направлением.
В этой статье я решил поговорить о нулевой итерации в Скрам, ее использовании в массах, и также попробовать определить является ли нулевая итерация частью true-Scrum или чертой темных Скрам-батов, которая приобрела свое название в угоду Скрам-брендингу.
Я нередко встречаю команды, которые практикуют использование «Нулевого Спринта» для того чтобы провести подготовительные работы: привести к нормальному состоянию свой Беклог Продукта и инфраструктуру (development environment, сервера continuous integration), чтобы подготовить команду к началу нового этапа работы и т д. Почему они решили что это является частью Скрам? Насколько это вообще полезно?
Я посчитал, что по данному вопросу лучше всего будет обратиться к высказываниям известных в кругах Agile личностей.
Джефф МакКенна говорит:
Ден Раусорн так охарактеризовал нулевую итерацию:
Марк Воуна считает, что нулевой спринт лучше использовать как спайк:
Питер Стивенс, аджайл-коуч из Швейцарии, использует нулевой спринт для того чтобы оценить самые важные фичи (не все), сойтись в едином мнении в определении «что значит сделать», восстановить/повысить доверие заказчика. Как и многие другие, он советует сделать длину этого спринта короче других, нормальных по длине для команды спринтов.
Так является ли это Скрамом? Мы получаем итерацию совсем другой длины, чем обычная длина спринта для команды, и результат спринта – совсем не потенциально готовый к продажам продукт. Или, может, это полезно настолько, что можно закрыть глаза на такие нестыковки?
Во многих командах существует множество вещей, который необходимо сделать перед тем, как стартовать проект/релиз.
Джордж Динвидди считает, что даже если команды пытаются сделать всю предварительную работу — всегда остается много незаконченного, что предстоит доделать в предстоящих спринтах. И мы тоже можем добавить: “Мы приветствуем изменения!”. А значит, решения по инфраструктуре, выбор технологий, и список фич, определенных в нулевой итерации, станут управлять процессом, а не наоборот. А ведь каждая итерация должны получать на выходе работающий продукт.
Согласно Джорджу, это самый лучший способ начать. Команда должны обучиться необходимым навыкам в технологиях, а затем, медленно начать строить инфраструктуру разработки, пока заканчивают реальную работу.
Я тоже не рекомендовал бы проводить итерации, которые ничего не демонстрируют. Хотя, большая часть нулевой итерации может пройти в предварительных мероприятиях, однако, все равно хотелось бы иметь возможность провалидировать «ядро» системы от начала до конца уже на этом этапе, каким бы сильно маленьким оно не было.
Алистар Коуберн по этому вопросу более жесткий:
Стоит ли приравнивать спринт ноль к предварительному планированию (upfront planning)? Некоторым действительно трудно представить нулевой спринт без предварительного планирования. Представляя, что это часть чартеринга проекта. Но многие команды, тем не менее, не обсуждают цели и видение проекта во время нулевой итерации. Они чаще тратят время на создание беклога и инфраструктуры.
Кен Щвабер по этому вопросу говорит:
Выходит, общее мнение светил аджайла по вопросу нулевого спринта скорее сходится во мнении, что это не совсем родная для скрам вещь, и ее лучше вообще избегать по возможности. А ключевым моментом является добавление бизнес-значимости прямо с самого начала. Видит ли ваша команда существенный плюс в проведении нулевой итерации вместо того чтобы сразу начать производить business value, постепенно по пути наращивая инфраструктуру и принимая решения о технологический стеке?
Если видит, то нужно ответить на вопрос для себя — не попахивает ли это все ситуацией, когда «подготовительные работы» не окончатся ни после нулевой итерации, ни после первой, и это будет мешать команде двигаться вперед полным ходом, и не попахивает ли это некоторой дисфункцией команды? Если ответ отрицательный, может быть, это ваш способ.
Хотя в некоторых случаях я могу ошибаться. Например, я забыл упомянуть о легкости, с которой некоторые команды могу начать производить значимый инкремент продукта после проведения некоторых предварительных действий, но все же у меня уже есть список действий, который мы можем попробовать применить для того чтобы избежать проведения Нулевого Спринта.
О чем я, естественно, напишу в следующей статье.
Сегодня я решился написать свою первую статью на Хабр (так что уж не судите строго).
В этой, как и в большинстве последующих статей от меня, я буду говорить об Agile. Scrum и некоторых моментах из этой серии, на мой взгляд, являющихся интересными тем, кто увлекается данным направлением.
В этой статье я решил поговорить о нулевой итерации в Скрам, ее использовании в массах, и также попробовать определить является ли нулевая итерация частью true-Scrum или чертой темных Скрам-батов, которая приобрела свое название в угоду Скрам-брендингу.
Я нередко встречаю команды, которые практикуют использование «Нулевого Спринта» для того чтобы провести подготовительные работы: привести к нормальному состоянию свой Беклог Продукта и инфраструктуру (development environment, сервера continuous integration), чтобы подготовить команду к началу нового этапа работы и т д. Почему они решили что это является частью Скрам? Насколько это вообще полезно?
Я посчитал, что по данному вопросу лучше всего будет обратиться к высказываниям известных в кругах Agile личностей.
Джефф МакКенна говорит:
Это термин часто используется у недавно образовавшихся команд, или у тех, кто новичок в Скрам. Упорядочивание начального беклога, приведение к рабочему виду рабочих мест и машин для билда и автотестинга, подготовка всех инструментов, возможно, чуть-чуть тренингов, и еще чуть-чуть работы, чтобы убедиться что это все работает.… Это не «официальный» Скрам, Но это общий случай, который довольно часто встречается. Мы ожидаем, что команды будут полностью готовы (после нулевой итерации) для атаки реальной работы!
Ден Раусорн так охарактеризовал нулевую итерацию:
Идея проста: берем начальный спринт (его и называют его инициализацией, нулевым спринтом или нулевой итерацией), и задаем ему простые цели:
- Получить в результате некоторое число качественных элементов в беклоге продукта
- Предоставить минимальную среду разработки, которая предоставляет возможность писать качественный код,
- Написать минимальный работающий код, причем не имеет значения, насколько маленький
Марк Воуна считает, что нулевой спринт лучше использовать как спайк:
Команда должна сделать 3 результата к концу этой итерации
- Список всех оцененных и приоритизированых фичей/стори»
- Релиз-план, в котором все фичи/стори помещены в необходимую итерациб/спринт
- Должна быть создана архитектура приложения, хотя бы на высоком уровне, т. е. должно быть понятно как эти фичи будут реализованы.
Питер Стивенс, аджайл-коуч из Швейцарии, использует нулевой спринт для того чтобы оценить самые важные фичи (не все), сойтись в едином мнении в определении «что значит сделать», восстановить/повысить доверие заказчика. Как и многие другие, он советует сделать длину этого спринта короче других, нормальных по длине для команды спринтов.
Так является ли это Скрамом? Мы получаем итерацию совсем другой длины, чем обычная длина спринта для команды, и результат спринта – совсем не потенциально готовый к продажам продукт. Или, может, это полезно настолько, что можно закрыть глаза на такие нестыковки?
Во многих командах существует множество вещей, который необходимо сделать перед тем, как стартовать проект/релиз.
Джордж Динвидди считает, что даже если команды пытаются сделать всю предварительную работу — всегда остается много незаконченного, что предстоит доделать в предстоящих спринтах. И мы тоже можем добавить: “Мы приветствуем изменения!”. А значит, решения по инфраструктуре, выбор технологий, и список фич, определенных в нулевой итерации, станут управлять процессом, а не наоборот. А ведь каждая итерация должны получать на выходе работающий продукт.
Спросите себя, что нужно, чтобы начать поставки продукта? Возьмите это, и нарежьте его мелкими ломтиками. Придумайте примеры, которые будут хорошо показывать, что эти ломтики рабочие. Некоторые кусочки будут иметь вопросы без ответов. В данный момент отставьте такие кусочки в сторону. Выберите один центральный кусок, который проходит через весь концепт от начала до конца, или близок к этому. Оцените его как одну итерацию для команды. Оценки не должны быть «правильными», они просто должны быть! Начните разработку этого продукта!
Согласно Джорджу, это самый лучший способ начать. Команда должны обучиться необходимым навыкам в технологиях, а затем, медленно начать строить инфраструктуру разработки, пока заканчивают реальную работу.
Да, инфраструктура разработки все еще должны будет доделываться. Не должно быть особой спешки, чтобы доделать это. Всего лишь продолжайте усовершенствовать ее таким образом, чтобы увеличивать количество сделанной работы. Да, технические навыки по-прежнему нужно усовершенствовать. Так всегда должно быть. Всего лишь продолжайте экспериментировать и расширять свои границы. Да, все еще будут фичи, которые необходимо будет добавить в беклог, приотизировать, разделить на стори и снова приоритизировать. Это должно продолжаться всегда.
Я тоже не рекомендовал бы проводить итерации, которые ничего не демонстрируют. Хотя, большая часть нулевой итерации может пройти в предварительных мероприятиях, однако, все равно хотелось бы иметь возможность провалидировать «ядро» системы от начала до конца уже на этом этапе, каким бы сильно маленьким оно не было.
Алистар Коуберн по этому вопросу более жесткий:
Меня терзают смутные сомнения, что кто-то давит на ваше использование скрам в команде, когда вы делаете в самом начале что-то, что не дает очевидного бизнес-значения. А этот «кто-то» изобрел «О. это же спринт ноль!», чтобы крестьяне с кирками ушли от его порога… А затем, и другие, думая, что это отличный ответ, повторяли его вновь и вновь. А потом это стало частью культуры.
Стоит ли приравнивать спринт ноль к предварительному планированию (upfront planning)? Некоторым действительно трудно представить нулевой спринт без предварительного планирования. Представляя, что это часть чартеринга проекта. Но многие команды, тем не менее, не обсуждают цели и видение проекта во время нулевой итерации. Они чаще тратят время на создание беклога и инфраструктуры.
Кен Щвабер по этому вопросу говорит:
Фраза «Спринт Ноль» была создана для того, чтобы описать планирование, которое происходит до начала первого спринта. А так как планирование создает артефакты, которые потом часто меняются, оно должно быть сведено к минимуму на данном этапе, а затем должно происходить каждый спринт во время sprint review/sprint planning
Выходит, общее мнение светил аджайла по вопросу нулевого спринта скорее сходится во мнении, что это не совсем родная для скрам вещь, и ее лучше вообще избегать по возможности. А ключевым моментом является добавление бизнес-значимости прямо с самого начала. Видит ли ваша команда существенный плюс в проведении нулевой итерации вместо того чтобы сразу начать производить business value, постепенно по пути наращивая инфраструктуру и принимая решения о технологический стеке?
Если видит, то нужно ответить на вопрос для себя — не попахивает ли это все ситуацией, когда «подготовительные работы» не окончатся ни после нулевой итерации, ни после первой, и это будет мешать команде двигаться вперед полным ходом, и не попахивает ли это некоторой дисфункцией команды? Если ответ отрицательный, может быть, это ваш способ.
Хотя в некоторых случаях я могу ошибаться. Например, я забыл упомянуть о легкости, с которой некоторые команды могу начать производить значимый инкремент продукта после проведения некоторых предварительных действий, но все же у меня уже есть список действий, который мы можем попробовать применить для того чтобы избежать проведения Нулевого Спринта.
О чем я, естественно, напишу в следующей статье.
