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

Приветствую вас, хабровчане! Сегодня я решил написать свою первую статью на Хабре (поэтому не судите строго).

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

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

Я часто встречаю команды, которые практикуют использование «Sprint Zero» для проведения подготовительных работ: приведения своего Product Backlog и инфраструктуры (среды разработки, серверов непрерывной интеграции) в нормальное состояние, чтобы подготовить команду к старту нового этапа.

работы и т. д. Почему они решили, что это часть Scrum? Насколько это вообще полезно? Я подумал, что по этому вопросу лучше всего будет обратиться к высказываниям известных личностей в Agile-кругах.

Джефф МакКенна говорит:

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

Мы ожидаем, что команды будут полностью готовы (после нулевой итерации) к настоящей работе!

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

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

Марк Вон считает, что нулевой спринт лучше использовать в качестве скачка:
К концу этой итерации команда должна создать 3 результата.

  • Список всех оцененных и приоритетных функций/историй"
  • План выпуска, в котором все функции/истории помещены в необходимую итерацию/спринт.
  • Архитектура приложения должна быть создана хотя бы на высоком уровне, т.е.

    должно быть понятно, как эти возможности будут реализованы.

Питер Стивенс , agile-тренер из Швейцарии, использует нулевой спринт, чтобы оценить наиболее важные функции (не все), согласовать определение того, «что значит делать», и восстановить/увеличить доверие клиентов.

Как и многие другие, он советует делать этот спринт короче, чем другие обычные командные спринты.

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

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

А ещё можно добавить: «Мы приветствуем перемены!» Это означает, что инфраструктурные решения, выбор технологий и список функций, определенный на нулевой итерации, будут контролировать процесс, а не наоборот. Но каждая итерация должна давать на выходе работающий продукт.

Спросите себя, что нужно, чтобы начать поставлять продукт? Возьмите это и нарежьте небольшими ломтиками.

Придумайте примеры, которые ясно покажут, что эти фрагменты работают. В некоторых произведениях останутся вопросы без ответов.

А пока отложите эти детали в сторону.

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

Оцените это как одну итерацию для команды.

Оценки не обязательно должны быть «правильными», они просто должны быть таковыми! Начните разработку этого продукта!

По мнению Джорджа, это лучший способ начать.

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

Да, инфраструктуру развития еще нужно будет достроить.

Не следует слишком торопиться, чтобы это сделать.

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

Да, технические навыки еще нужно совершенствовать.

Так должно быть всегда.

Просто продолжайте экспериментировать и расширять свои границы.

Да, все равно будут фичи, которые нужно будет добавить в бэклог, расставить приоритеты, разделить на истории и снова расставить приоритеты.

Это должно продолжаться всегда.

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

Алистер Коуберн более строгий в этом вопросе:

У меня есть смутные сомнения, что кто-то оказывает на вас давление, чтобы вы использовали Scrum в команде, когда вы в самом начале делаете что-то, что не представляет очевидной ценности для бизнеса.

И этот «кто-то» придумал «О.

это нулевой спринт!» чтобы мужики с кирками ушли от его порога.

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

А потом это стало частью культуры.

Следует ли приравнивать Sprint Zero к предварительному планированию? Некоторым людям действительно трудно представить себе Sprint Zero без предварительного планирования.

Делая вид, что это часть уставного проекта.

Но многие команды, однако, не обсуждают цели и видение проекта во время нулевой итерации.

Они с большей вероятностью потратят время на создание резерва и инфраструктуры.

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

Фраза «Нулевой спринт» была создана для описания планирования, которое происходит перед началом первого спринта.

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

Получается, что общее мнение корифеев Agile по вопросу Sprint Zero скорее сходится в том, что это не совсем родная вещь для Scrum, и лучше по возможности избегать ее вообще.

И самое главное — повысить ценность бизнеса с самого начала.

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

Хотя в некоторых случаях я могу ошибаться.

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

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

Теги: #agile #scrum #нулевой спринт #нулевая итерация #agile

Вместе с данным постом часто просматривают:

Автор Статьи


Зарегистрирован: 2019-12-10 15:07:06
Баллов опыта: 0
Всего постов на сайте: 0
Всего комментарий на сайте: 0
Dima Manisha

Dima Manisha

Эксперт Wmlog. Профессиональный веб-мастер, SEO-специалист, дизайнер, маркетолог и интернет-предприниматель.