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

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

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

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

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

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

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

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

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

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

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

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

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

 

Почему недельная длина Спринта хуже, чем двухнедельная
Tagged on:             

3 thoughts on “Почему недельная длина Спринта хуже, чем двухнедельная

  • «Да-да, я имею в виду плановые встречи.» — я правильно понимаю, что имеется ввиду встреча по планированию спринта — planning meeting?

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

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

Comments are closed.