При таком подходе каждый спринт превращается в маленький двух- или четырехнедельный проект, с четко очерченным кругом задач, ясным началом и фиксированной конечной датой (у большинства спринтов период фиксирован). Однако этот подход не так прост, как кажется.

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

Недавно я делал обзор типичного скрам-проекта, создававшего продукт за 15 четырехнедельных спринтов. К концу 12-го спринта я взял интервью у трех команд. Они было плохо мотивированы и жаловались на большую загрузку. Некоторое количество народа к тому времени уже покинуло проект из-за таких же жалоб. Поскольку большинство скрам-команд мониторит свою работу при помощи диаграмм сгорания, первое, о чем я попросил, - показать мне эти диаграммы.

Большая часть из этих 12 диаграмм показывала один и тот же шаблон. В начале каждого спринта команда оценивала объем работы, который сможет закончить, как было видно по стартовым всплескам на диаграмме. Затем «сгорание» шло все медленнее, медленнее, покуда время не заканчивалось. Однако ни одна из изученных мной 12 диаграмм не показывала, что работы были выполнены в срок. Везде что-нибудь оставалось на потом, как показывает пример ниже. Еще более интересно, что на многих диаграммах было показано, что работа прибавлялась почти сразу же, как оценивались первые истории - поскольку команды понимали, что изначальная оценка была далека от реальности и что придется за тот же спринт выполнить больше работы.

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

«Красные спринты»

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

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

С большим оптимизмом он высчитал число пунктов, которые надо закрывать команде в спринт, назвав его «ожидаемым средним числом», хотя в реальности о таком числе можно было только молиться. Основываясь на этих расчетах, менеджер продукта давил на команды, чтобы они работали усерднее, производили меньше багов и работали сверхурочно. Миссия невыполнима, я бы сказал. Как можете представить, мотивация у команд упала до нуля. По мне, схема «красного спринта» - это антишаблон, и это, скорее, не диаграмма сгорания, а диаграмма выгорания.

Без устойчивого темпа

Возникает интересный вопрос: откуда же берется подобный антишаблон? А самое главное - что делать, чтобы избежать «красных спринтов»? У их появления множество причин:

• Возвращение «золотого треугольника». Во-первых, все начинается с отношения к спринтам как к маленьким проектам с фиксированной областью, фиксированной командой и фиксированным дедлайном. Цементирование всех трех конечных точек приводит ровно к тем же проблемам, что и в традиционных, линейных проектах, только в малом масштабе и с повторами. Вместо одного дедлайна на весь этап, как в традиционных проектах, команды имеют дело с серией самоустановленных дедлайнов, в каждый из которых трудно уложиться. И хотя я понимаю, что такой подход к спринтам создает некоторое желательное давление на команды, эти «много маленьких дедлайнов», похоже, ведут к чрезмерному стрессу у членов команд.
• Оценивать по-прежнему трудно. В начале каждого спринта команды тратят некое время на то, чтобы разделить нужные пользовательские истории на задачи, и пытаются точно оценить время, необходимое на каждую из них. В этих оценках им нужно быть дотошными и точными, поскольку по ним определяется согласованный объем работы. Неправильная оценка означает, что будет трудно предсказать, сможет команда выполнить эту работу или нет.
• В оценке в часах заложена угроза. Большинство команд, и традиционных, и гибких, оценивают задачи на самом низком уровне детализации, а именно в часах, необходимых на выполнение задачи. На мой взгляд, оценка в часах опасна, потому что всегда несет угрозу тем, кто ее производит. Откуда вы знаете, что на создание вон той веб-страницы требуется 8 часов? А если задачу во время спринта возьмет некто более опытный или, наоборот, менее опытный? А если вы не сможете уложиться в 8, а вам надо 12? Что скажет об этом руководитель проекта? Ведь в конечном счете в своей оценке нужно быть уверенным. А на практике это тот еще крепкий орешек.
• Бесконечное «вычесывание». Из-за перечисленного, как и в традиционных проектах, команда тратит кучу времени на разбиение на задачи, уточнение, переуточнение и прочее «вычесывание» пользовательских историй, чтобы оценка была всё точнее и точнее - просто уверенности ради. Кроме того, сам процесс деления элементов бэклога на задачи - штука временами сложная, особенно по тем историям, где нет стандартизованного подхода к их дроблению. Пользовательские истории - это всё же довольно неструктурированный способ описания, и дробление на задачи у каждой истории разное. Я видел команды, которые целый день тратили на «уточнение бэклога», «рассмотрение историй», «совещание по пересмотру бэклога» при двух недельном спринте - а это 10% общего рабочего времени.
• Неожиданности. С этим всё хуже. Что будет, если случится нечто неожиданное? Подумайте о меняющихся требованиях, технических проблемах или простых вещах вроде недоступного сервера или гриппа у разработчика. Эффект будет, как и на каскадных проектах, только размах поменьше. Задачи придется задержать или даже отложить - и вот он, еще один «красный спринт».
• Закон Паркисона. Даже если команда в состоянии оценивать точно, будет ли время, необходимое на решение отдельных задач, в сумме равно доступным человеко-часам в спринте? В большинстве случае - не будет, и причина тому - провисания. Обычно некоторый запас времени - это хорошо, но всегда помните, что непременно вмешается закон Паркинсона: работа заполняет всё отпущенное ей время. Так произойдет и в спринтах, если объем времени, необходимый для выполнения выбранных элементов бэклога лишь немного меньше, чем доступное время. В спринтах это ведет к темпу ниже оценочного (или «ожидаемого среднего» по выражению менеджера из примера выше), потому что на задачи по спринту тратится времени больше ожидаемого. Если такой шаблон имеет место, то обычно он проявляется, когда разработчики тратят время на полировку кода.
• Снижение качества. И последний по номеру, но не по значению пункт: что происходит, когда команда попадает в тиски цейтнота? Команде нужно довести до конца некие задачи, но на них недостаточно времени. Обычно это ведет к снижению качества, поскольку команды часто решают пожертвовать какой-то частью необходимой работы - к примеру, написанием юнит-тестов.

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

Оригинал: http://www.infoq.com/articles/beat-red-sprint-anti-agile-pattern

Об авторе: Сандер Хоогендоорн - автор бестселлера «Это Agile», ценимый отец, программист, системный архитектор, оратор и писатель. В качестве служителя основам технологии и лидера в глобальном осмыслении Agile

Перевод: Александра Родсет

Сертифицированные курсы

Андрей Плетенев. Онлайн курс Agile. SCRUM. Курс включает более 20 уроков с практическими заданиями, которые индивидуально проверяются и комментируются тренером.

Еще интересные статьи на эту тему:

• Масштабируем Scrum (но не так, как вы подумали)
• Анти-паттерн "красного спринта": от спринтов к итерациям
• Анти-паттерн "красного спринта": уход от каскадной модели
• Кен Швабер: истоки и будущее Скрама
• Персональный Скрам