Вернемся к начальному вопросу: как можно избежать данного антишаблона? Позвольте перефразировать вопрос: есть ли у команд альтернатива, если стандартная процедура не срабатывает?
Я, поработав со многими командами, отошедшими от описанной выше традиционной модели спринта, твердо уверен, что есть. Поскольку сложно планировать точный объем работы даже на короткий (2 или 4 недели) период и уложиться с его выполнением в заданный срок, почему не перейти с подхода, ориентированного на элементы бэклога, к подходу, ориентированному на задачи?
При таком подходе реализация отдельных элементов бэклога становится важнее, чем успешное окончание одного мини-проекта за другим. «Зеленые» и «красные» спринты становятся менее применимы, потому что выполнение определенных элементов бэклога именно в рамках заданного спринта становится менее важным. Незаконченная работа над элементом бэклога просто продолжается в следующем спринте, а если команда сомневается, можно ли его реализовать в принципе, то элемент вообще возвращается в бэклог.
Почему это работает лучше? Выделю несколько моментов:
- Нет дробления. Если вам менее важно знать, поместится та или иная кучка элементов бэклога в ваш спринт или не поместится, то уменьшается и необходимость деления элементов на задачи - иногда она отпадает вообще. Вы просто работаете над реализацией элементов бэклога.
- Следование жизненному циклу. А это еще лучше. По моему опыту, схожие и равные по детализации элементы бэклога могут следовать при реализации одинаковому жизненному циклу. Для разработки ПО в этом нет ничего нового - мы так или иначе проделываем похожую работу для большинства элементов бэклога. Подумайте об обычных действиях, таких, как анализ, дизайн, дизайн теста, сборка, девелоперское тестирование, обычное тестирование, приемка - как минимум, в моих проектах в этом есть простой здравый смысл.
- Визуализация жизненного цикла. Отслеживать жизненный цикл элементов бэклога намного проще, чем создавать пачку отдельных задач, вроде «Собрать Х», «Написать юнит-тесты для Х» или «Протестировать Х». Это и экономит массу работы, и, более того, позволяет вам визуализировать прогресс более четко, нежели вы можете добиться при помощи традиционной скрам-доски, на которой всего три категории: «Сделать», «В работе» и «Сделано». На большинстве таких досок я видел пачки стикеров в колонке «В работе», но при этом никто в проекте не мог точно сказать, что означает это «в работе» для каждой из задач. Как только вы определили жизненный цикл для элементов бэклога, вы можете также отслеживать и прогресс прохождения активностей жизненного цикла - типичная процедура для Канбан. Теперь на один элемент бэклога приходится всего один стикер, который переезжает от шага к шагу слева направо.
- Оптимизация жизненного цикла. А тут еще лучше. Как только жизненный цикл визуализирован, вы сможете быстро определить узкие места - это те самые колонки, где скапливается больше всего стикеров. Теперь вы можете так настроить и отладить жизненный цикл, чтобы устранить эти узкие места. Вот самый простой пример подобной оптимизации: во время одного из моих проектов команда взяла отличный темп, но стикеры начали скапливаться на тестировании. Причина была проста: у тестировщика только что родила жена, и несколько дней его не было на месте. Когда он вернулся, его ожидал неприятный сюрприз в виде завала стикеров. Конечно, разработчики тут же прекратили производить еще больше кода, а вместо того потратили время на помощь с тестированием. Помните, что цепь настолько крепка, насколько крепко ее самое слабое звено. Активности жизненного цикла, требующие наибольшего количества усилий, как раз и задают темп разработки элементов бэклога.
- Часы не имеют значения. Когда вы перестаете разбивать элементы бэклога на задачи, отпадает и необходимость оценивать задачи в часах. На первый план выходит оценка в единицах, которая выражает размер или сложность элементов. Знания среднего количества единиц, которое команда может реализовать в течение одного спринта, вполне достаточно, чтобы запланировать следующий спринт. Вы просто подбираете элементы, чтобы выйти на это среднее число, и всё - можно спланировать следующий спринт за час вместо половины дня.
- Нет мини-дедлайнов. Думаю, вот этот пункт - самый главный. Если вы сможете воплотить все перечисленные принципы, то уйдете от постоянного давления и необходимости бежать стометровку каждый спринт. Хотя спринты задают вам хороший ритм и позволяют регулярно пересматривать вашу работу, больше не нужно паниковать, если вы выполнили «всего лишь» 10 из 12 элементов, которые рассчитывали сделать.
За последние 10 лет я видел так много проектов, сражающихся с моделью навязанных мини-проектов в спринтах, что тяжело представить, как эта модель вообще держится. Я рекомендую уйти от традиционной модели спринта, потому что тяжело оценить, сколько именно работы вы сделаете, даже на 2 или 4 недели вперед. А усилия по дроблению на еще меньшие элементы вообще того не стоят. Я много раз успешно реализовывал куда менее строгую модель итераций без разбивки элементов бэклога, просто придерживаясь оценочной шкалы в единицах и отдавая себе отчет, что иногда работа может не уложиться в итерацию. Слишком их много, этих проектов с «красными спринтами», а ведь даже Усейн Болт не может пробежать стометровку 12 раз подряд в одном темпе.
Оригинал: http://www.infoq.com/articles/beat-red-sprint-anti-agile-pattern
Об авторе: Сандер Хоогендоорн - автор бестселлера «Это Agile», ценимый отец, программист, системный архитектор, оратор и писатель. В качестве служителя основам технологии и лидера в глобальном осмыслении Agile
Перевод: Александра Родсет |
