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