4
ПЛАНИРОВАНИЕ РЕЛИЗА
«Планирование… — это поиск ценности», — пишет Майк Кон (Cohn, 2005; 5), а планирование релиза поддерживает разработку и запуск успешного продукта. Оно облегчает диалог между scrum-командой и заинтересованными лицами и отвечает на вопрос, какая функциональность будет включена в ближайший релиз продукта. Планирование релизов происходит в течение всего проекта, поскольку команда прислушивается к отзывам клиентов и пользователей и реагирует на них. Переход от основанного на документах и отчетах планирования к диалогу и беседам позволяет scrum-команде использовать простые методы планирования, отчего планы становятся проще и прозрачнее. Несмотря на то что планирование релиза — это совместный труд, ответственный за принятие всех необходимых решений — владелец продукта.
В этой главе рассказывается об основных идеях и методах планирования релиза. Более подробно они описаны в книге Agile Estimating and Planning (Cohn, 2005).
ВРЕМЯ, ЗАТРАТЫ И ФУНКЦИОНАЛЬНОСТЬ
Планирование релиза начинается с принятия решения о том, какая из составляющих проекта — время, затраты или функциональность — должна остаться неизменной для запуска успешного продукта. Необходим ли запуск именно в указанную дату? Жестко ли задан бюджет на разработку? Нужно ли реализовать все требования, отраженные в бэклоге продукта? Одновременная фиксация времени, бюджета и функциональности невозможна. По крайней мере одна из составляющих должна играть роль высвобождающего клапана. Самое удачное решение — ограничить время и делать гибкой функциональность.
Фиксирование функциональности — плохой вариант. Даже при наличии видения продукта его точные свойства, функциональность и особенности не известны сразу. Они открываются постепенно, на основе отзывов клиентов и пользователей. Появляются новые требования, бэклог продукта развивается по мере того, как scrum-команда больше узнает о потребностях клиентов и возможностях их удовлетворения. Попытка фиксировать функциональность вредит способностям команды адаптировать продукт к отзывам пользователей. В результате получится не тот продукт, который могут полюбить покупатели.
Определить дату запуска легче, если есть видение продукта. Оно позволяет установить возможное окно — временной интервал, когда продукт должен быть запущен для получения желаемых выгод. Фиксация этого окна защищает время как самый важный и труднодоступный ресурс. Если пропустить нужную дату, то возможность будет упущена и запуск продукта окажется бессмысленным. Выбор даты запуска на основании работы, записанной в бэклоге продукта, — не лучшая идея, поскольку это заставляет команду заморозить требования и часто приводит к плохой оценке. На деле реальный срок работы, основанный на требованиях, может составлять 60–160% от примерного. Так, проект, рассчитанный на 20 недель, может занять от 12 до 32 недель (Cohn, 2005; 4). Это хорошо известное соотношение называется «воронка неопределенности». Определение возможного окна вместо попыток оценить вероятную дату запуска позволяет избежать этих проблем.
Фиксация даты позволяет создать постоянный ритм для инноваций. Это достигается выбором единого временного ограничения для всех релизов. Звучит невероятно? Но именно так поступили в Salesforce.com — ведущем поставщике услуг по управлению связями с заказчиками по запросу. И преуспели. В 2006 году после нескольких лет быстрого роста Salesforce.com оказалась в неприятной ситуации. Способность компании выпускать новые продукты сократилась до одного в год, резко упала и производительность. Чтобы вернуть упущенное, команда внедрила методологию Scrum. Крис Фрай, вице-президент по разработке платформ Salesforce.com, поясняет:
Решение перейти к agile-методам в Salesforce.com выросло из желания быстрее выпускать более предсказуемые релизы. Мы уже год не выпускали ни одного крупного релиза и хотели перейти к более предсказуемому расписанию выхода продуктов, которые будут приносить ценность покупателям на постоянной основе.
После внедрения Scrum Salesforce.com стала следовать строгому ритму инноваций. «Вся организация перешла от двенадцатимесячного цикла к четырехмесячному, выпуская по три крупных релиза в год в соответствии с расписанием, включая разработку программного продукта, технические операции и внутренние IT-системы», — заявляет Стив Грин, вице-президент по управлению программами и гибкой разработке в Salesforce.com. Результаты оказались поразительными. Salesforce.com стала вырабатывать на 97% больше функций благодаря кратким устойчивым циклам релизов. В то же время компании удалось сократить время на разработку новой функциональности на 61%. Оценка и планирование стали точнее и эффективнее. Клиенты Salesforce.com могли твердо рассчитывать на следующий релиз. В то же время вырос и моральный дух разработчиков (Greene and Fry, 2008).
Фиксация даты и работа со стабильными scrum-командами существенно упрощают выработку бюджета, если считать оплату труда основным фактором издержек. Когда проект приходится масштабировать, точное предсказание бюджета оказывается сложным делом, особенно при разработке новых программных продуктов. Если бюджет подвергается опасности или превышен, владельцу продукта придется сделать выбор — представить продукт с меньшей функциональностью или повысить его стоимость, подключив к проекту дополнительных сотрудников (если эти новые члены смогут за оставшееся время повысить производительность). Apple, например, решила увеличить затраты и добавила сотрудников к своему первому проекту iPhone, чтобы успеть к дате релиза. При этом не стоит забывать о законе Брукса: «Увеличение числа участников при подготовке опаздывающей программы только замедляет процесс» (Brooks, 1995; 25).
КАК НАСЧЕТ КОНТРАКТОВ С ФИКСИРОВАННОЙ СТОИМОСТЬЮ?
Если есть выбор, избегайте проектов с фиксированным объемом работ и фиксированной стоимостью. Если это невозможно, то попробуйте следующее: разделите контракт с фиксированной ценой на две части и делайте два последовательных проекта. В ходе первого проекта вырабатывается и частично внедряется за два-три спринта видение продукта. В конце проекта бэклог продукта подвергается изменениям в соответствии с отзывами клиентов. Это позволяет разработать реалистичный план релиза и примерный бюджет на второй проект, где продолжается разработка продукта. Помните, что Scrum — это процесс прорывных инноваций. Как и в случае с другими прорывными инновациями, клиенты и покупатели, возможно, не захотят иметь дело с этим процессом, поскольку считают, что у них уже есть работающее решение.
СТАБИЛЬНОСТЬ КАЧЕСТВА
Как мы убедились, функциональность продукта развивается. Его точность тоже может возрастать в ходе проекта: улучшаются внешний вид, ощущения и опыт использования. Но качество продукта в Scrum стабильно. Критерии качества зафиксированы в критериях готовности. Такое определение обычно подразумевает, что результат каждого спринта должен быть (потенциально) готов к постановке инкремента продукта: это будет исполняемая программа, проверенная, задокументированная и готовая к релизу. Обеспечение качества и меры контроля образуют неотъемлемую часть любого спринта. Они не проводятся в конце проекта задним числом.
Необходимо убедиться, что в ходе спринтов действительно создаются обновления нужного качества. Владелец продукта не должен поощрять компромиссы в качестве программ: не следует принимать результаты работы, не соответствующие заданным критериям. Ненадлежащее качество ведет к дефектным обновлениям продукта, поэтому не получается четко отслеживать прогресс и выпускать частые и быстрые релизы. Более того, компромиссный подход к качеству имеет долгосрочный отрицательный эффект. Вырабатывается технический долг — программы, которые трудно улучшать и поддерживать (Cunningham, 1992). Это может повредить репутации бренда и оставить потребителей неудовлетворенными. Недостаточное качество программ — результат уступок в долговременном росте в пользу краткосрочных выгод. Вы сами себя лишаете успешного, яркого будущего.
БЫСТРЫЕ И ЧАСТЫЕ РЕЛИЗЫ
«Наш приоритет — удовлетворить покупателя, часто и постоянно выпуская ценные программы», — утверждается в agile-манифесте, а далее приводится рекомендация: «Почаще выпускайте рабочие программы — с интервалом от пары недель до пары месяцев, но предпочтительны более короткие интервалы» (Beck et al., 2001). Быстрый и частый выпуск инкремента продукта для целевых потребителей вместо разового выхода законченного продукта порождает ценные отзывы.
Это дает продукту возможность изменяться на основе отзывов пользователей и экономит scrum-команде время, предотвращая внедрение лишних функций и выпуск продукта с избыточной или недостаточной функциональностью. Создается именно то, что нужно.
Частые релизы эффективны, поскольку клиенты и пользователи могут применить продукт на практике, а не просто посмотреть демоверсию на обзорном совещании по спринту. Более того, быстрые и частые релизы позволяют команде Scrum охватить больше людей, снижая риск неправильного выбора целевых потребителей. Ранний выход программ имеет и другое преимущество: в этом случае сразу обнаруживается ошибочность видения, так что появляется возможность либо пересмотреть его, либо отказаться от продукта на ранней стадии.
Команда, разрабатывавшая браузер Chrome, сначала планировала не использовать панель закладок. Но отзывы пользователей показали, что некоторые любят переходить именно по этой панели. Поэтому команда выступила с новым решением: если пользователь изначально подбирал закладки в Internet Explorer или Firefox, Chrome импортирует их. В ином случае у пользователей не будет панели закладок, пока они не добавят ее. Не выпустив первых версий браузера, команда не осознала бы важности панели закладок, так что продукт в итоге получился бы не оптимальным.
Частые релизы образуют строительные кирпичики для инновационных возможностей Google, отмечает Бернар Жирар, автор книги The Google Way: «Быстро выводя на рынок даже не до конца готовые продукты, Google извлекает максимум из своих усилий и сводит на нет потенциальную конкуренцию… Стратегия Google, состоящая в быстрых и частых релизах, — это блестящая и изобретательная маркетинговая стратегия: она устраняет потенциальных конкурентов, повышает стоимость выхода на рынок и удерживает пользователей в сфере влияния Google» (Girard, 2009; 86).
Но, как известно, бесплатный сыр бывает только в мышеловке. Частые релизы имеют свою цену: программы должны быть высокого качества и нужно иметь возможность легко получить и установить продукт. Совершенно нормально, когда в ранних релизах лишь частично внедряются некоторые функции. Приемлемо также предлагать функциональность, обеспечивающую клиенту или пользователю лишь ограниченные преимущества. Однако качество программ, которое обозначено в критериях готовности, должно быть высоким для всех инкрементов продукта. Это позволяет команде быстро улучшать продукт во время будущих спринтов и препятствует возникновению ошибок, которые могут навредить репутации продукта. Такие методы, как разработка через тестирование и автоматизация тестов, рефакторинг и непрерывная интеграция, облегчают создание работающих обновлений продукта. Командам понадобится время, чтобы освоить эти техники, а их применение может потребовать изменения инфраструктуры и среды.
Если получить и установить новые версии продукта будет нелегко, то потребители откажутся от обновлений или проигнорируют их. Хотя достичь этого непросто, «любой большой проект можно разбить на серию более мелких и с более ранними сроками поставки. Не сдавайтесь, даже если для этого потребуются новые технические решения. Вас должны интересовать результаты, а не технологии» (Gilb, 1988; 336).
КВАРТАЛЬНЫЕ ЦИКЛЫ
В Scrum не существует правил, которые предписывали бы конкретную длительность проекта. Однако agile-проекты обычно длятся от трех до шести месяцев. Если для вывода продукта на рынок требуется более трех-четырех месяцев, используйте квартальные циклы, выпуская ежеквартально как минимум одну версию работающей, протестированной и задокументированной программы (Beck and Andres, 2005; 47–48). Google пользовалась этой методикой в течение тех двух лет, которые ушли на разработку первой версии браузера Chrome. Дэрин Фишер так описывает процесс: «Мы ориентировались на квартальные циклы, так что живой документ [бэклог продукта] пересматривался каждый квартал. Например, в этом квартале мы работаем с таким набором функций, в следующем — с другим и т. д. Это было полезным средством продвижения вперед, к тому же продукт мог применяться кем угодно в Google на самых ранних стадиях, так что мы непрерывно получали отзывы». Еще одна компания, систематически пользующаяся квартальными циклами, — это PatientKeeper, выпускающая продукты для сферы здравоохранения. Новая версия продукта выходит у них каждые три месяца (Sutherland, 2005). Если учесть, что продукты PatientKeeper имеют особые требования по безопасности, нуждаются в одобрении регулятора и применяются в больницах в самых разных условиях, то это огромное достижение, дающее компании значительные конкурентные преимущества. Неудивительно, что PatientKeeper утвердилась в качестве лидера среди производителей мобильных приложений в сфере здравоохранения, опережая гораздо более мощных конкурентов.
СКОРОСТЬ
Скорость — индикатор того, какой объем работы может выполнить команда в течение одного спринта. Она позволяет отследить и предсказать ход проекта. Точнее говоря, скорость — это сумма усилий, затраченных на достижение результата, принятого владельцем продукта в течение одного спринта. Рассмотрим пример. На совещании по планированию спринта команда решает завершить работу над шестью историями общей суммой в 12 очков историй. В конце спринта владелец продукта тщательно проверяет обновление и обнаруживает, что все требования выполнены в соответствии с приемочными критериями, кроме одного: не окончена небольшая часть документирования истории Г. Поскольку Г не закончена, очки за нее не попадают в сумму командной скорости, как указано в таблице 4.1. Сумма очков за принятые элементы бэклога продукта равна 10. Таким образом, скорость команды в этом спринте равна 10.
Таблица 4.1. Определение скорости
| Элемент бэклога продукта | Очки за пользовательскую историю | Результат приемки |
| А | 1 | Принято |
| Б | 3 | Принято |
| В | 1 | Принято |
| Г | 2 | Отказано |
| Д | 2 | Принято |
| Е | 3 | Принято |
Как показывает этот пример, скорость лучше всего определять по способности команды превращать элементы бэклога продукта в инкремент продукта. «Работающие программы — это основная мера прогресса», — сообщает по этому поводу agile-манифест (Beck et al., 2001). Скорость может колебаться в зависимости от многих факторов — например, динамики командной работы, затруднений и доступности средств. Если несколько членов команды уходят в отпуск, то скорость, вероятнее всего, упадет. В случае новых команд или проектов разработки новых продуктов может потребоваться два-три спринта, прежде чем скорость стабилизируется (Cohn, 2005; 179).
Скорость специфична для каждой команды, ее не стоит сравнивать у разных команд, если только они не договорились об использовании очков за пользовательскую историю с одинаковым значением. Когда команда, разрабатывающая продукт А, имеет скорость 40, а создающая продукт Б — скорость 20, это не значит, что первая команда продуктивнее. Исходные данные могут быть разными, оценки первой команды иногда просто ниже.
ДИАГРАММА СГОРАНИЯ РАБОТ ДЛЯ РЕЛИЗА
Диаграмма сгорания работ — это неотъемлемый инструмент отслеживания и прогнозирования хода проекта в Scrum. Она может выглядеть как график или как столбиковая диаграмма. Сначала рассмотрим график.
ГРАФИК СГОРАНИЯ РАБОТ ДЛЯ РЕЛИЗА
График сгорания работ позволяет отслеживать и прогнозировать ход проекта (Schwaber and Beedle, 2002; 83–88). Он основан на скорости предыдущих спринтов и способен предсказывать будущее, так что scrum-команда может на основании этих прогнозов видоизменять продукт и проект нужным ей образом. Он базируется на двух факторах: времени и оставшемся объеме работ из бэклога продукта. График лучше всего составлять и обновлять на обзорном совещании по спринту, когда результаты спринта уже известны.
Составление графика — процесс несложный. Сначала мы чертим систему координат и на оси х указываем количество спринтов. На оси у мы пишем очки за пользовательскую историю (или другую, более привычную вам единицу измерения усилий). Первая точка на графике — это примерный объем работ на весь бэклог продукта еще до разработки. Для следующей точки нужно определить оставшийся объем работ из бэклога продукта в конце первого спринта. После этого мы проводим линию между этими точками. Она называется сгоранием и показывает скорость, с которой разрабатывается функционал из бэклога продукта. Если мы продлим линию выполнения до оси х, то сможем предсказать, когда примерно проект будет закончен (при условии, что скорость работы и усилия останутся стабильными). Рассмотрим образец графика сгорания работ, показанный на рисунке 4.1.
На этом графике видны две линии. Сплошная линия — это действительное сгорание. Она соответствует реальному прогрессу и оставшемуся объему работ. Видно, что начало проекта получилось довольно медленным. Это могло быть вызвано задержками, материализацией рисков, проблемами при построении команды или технологическими сложностями. В третьем спринте количество оставшихся усилий даже увеличилось. Это может быть связано с переоценкой командой элементов бэклога продукта или выявлением новых требований, необходимых для реализации видения. Четвертому спринту соответствует пологий спуск: проект быстро прогрессирует. Если сейчас рассмотреть предыдущие спринты, то можно отметить тенденцию сгорания, которой и соответствует прерывистая линия на рисунке 4.1. Тенденция сгорания предсказывает прогресс в ходе следующих спринтов. Оказывается, что если работа по бэклогу продукта и темпы сгорания задач останутся прежними, то проект не будет закончен за десять спринтов, то есть команда сбилась с пути. Поняв проблемы, scrum-команда может выяснить, в чем причины задержки — медленном прогрессе или чрезмерном количестве работы. Когда команда приходит к определенному выводу, она может принять верное решение. Если дата фиксирована, то можно либо снизить количество функций, либо попросить добавить в состав команды еще одного специалиста.
Рисунок 4.1. График хода сгорания работ
График хода сгорания работ можно использовать «на автопилоте», по выражению одного из моих коллег, Штефана Рука. Это простое средство, стимулирующее диалог и облегчающее исследования. Тщательно выберите временное окно и решите, принимать во внимание все спринты или только их часть. Выясните, не проявляют ли какие-то спринты аномалий, которые могут исказить прогноз. Например, это могут быть болезни членов команды, падение сервера в процессе разработки или слишком высокий темп работы. Затем внесите соответствующие изменения в тенденцию.
Кстати, один из методов составления, обновления и хранения графика сгорания работ — это рисовать на перекидных листах флипчартов. Это облегчает диалог и сотрудничество и дает возможность избежать иллюзии точности, которую могут создавать электронные файлы. В любом случае полезно вывесить график в рабочем помещении и приносить его на каждую ретроспективу спринта.
СТОЛБИКОВАЯ ДИАГРАММА СГОРАНИЯ РАБОТ
Более сложная версия диаграммы сгорания работ — это столбиковый вариант (Cohn, 2005; 221–224). Столбиковая диаграмма сгорания работ обладает всеми свойствами соответствующего графика, но проводит границу между переоценкой элементов и выполнением работы, с одной стороны, и добавлением и исключением элементов бэклога продукта — с другой. Если команда добивается прогресса или снижает оценки усилий, то верхушка столбика движется вниз. А когда увеличивает оценки — верхушка столбика движется вверх. Если в бэклог добавляются новые элементы, то нижняя часть движется вниз. Когда элементы удаляют из бэклога или их заменяют на требующие меньших усилий, нижняя часть движется вверх. На рисунке 4.2 показан образец столбиковой диаграммы сгорания работ.
Рисунок 4.2. Столбиковая диаграмма сгорания работ
Диаграмма на рисунке 4.2 — это те же самые данные, что и в примере графика на рисунке 4.1. Разница в том, что теперь мы лучше понимаем, что случилось во время третьего и четвертого спринтов. Верхушка столбиков пошла вниз, значит, команда добилась прогресса в ходе обоих спринтов. То, что нижняя часть столбика пошла вниз на третьем спринте, свидетельствует о появлении в бэклоге продукта новых элементов. В ходе четвертого спринта нижняя часть двинулась вверх, показывая, что элементы были устранены. Самый первый столбик демонстрирует количество работы до первого спринта.
На рисунке 4.2 видны две пунктирные линии, обозначающие тенденции, — верхняя и нижняя. Верхняя представляет тенденцию сгорания работ и наносится точно так же, как и в случае с графиком. Нижняя отражает текущую нулевую линию.
ПЛАН РЕЛИЗА
«Планы — ничто, планирование — все», — заметил как-то Дуайт Эйзенхауэр. Эта идея особенно подходит для плана релиза. Хотя в Scrum от команд в обязательном порядке не требуется план релиза, планировать его все-таки необходимо. Многим командам Scrum достаточно использовать диаграмму сгорания работ и группировать элементы бэклога продукта по категориям, чтобы понимать, какие функции и в каком релизе внедрять. Однако большие scrum-проекты и те, которые требуют координации с другими проектами, партнерами или поставщиками, все же должны разрабатывать формальный план релиза.
План релиза — это своего рода карта, обозначающая нам направление. Он показывает, насколько мы приблизились к выпуску продукта и когда он состоится. Можно сказать, что план релиза — это расширенная версия диаграммы сгорания работ. Он не только содержит больше информации, но и более комплексный. План релиза основывается на четырех факторах: элементах бэклога продукта, оставшегося объема работ, скорости команды и времени. План релиза не является фиксированным. Он меняется вместе с развитием бэклога продукта, а также нашего понимания оставшегося объема работ и скорости. Как и диаграмму сгорания работ, план релиза лучше всего составлять и обновлять совместными усилиями команды во время демонстрации результатов спринта.
Чтобы выжать из плана максимум, полезно представлять функциональность, которая внедряется в ходе каждого релиза, в виде тем или эпиков. Включение в план релиза пользовательских историй обычно ведет к излишней детализации и усложнению (исключение из этого правила — крупные проекты, их обсудим в этой же главе ниже). Полезно также включить в план релиза любую информацию, необходимую для координации усилий с другими проектами, партнерами, поставщиками, а также зафиксировать все известные изменения, влияющие на скорость, — например, изменения в составе команды или организации проекта. Таблица 4.2 иллюстрирует образец плана релиза.
Таблица 4.2. Образец плана релиза
В примере, представленном в таблице 4.2, проект находится на стадии четвертого спринта, а выход версии 1.0 должен состояться еще через четыре спринта.
Продолжительность каждого спринта — две недели. Альфа-версия, включающая в себя две темы, поставляется выбранным заказчикам после четвертого спринта. Бета-версия с еще двумя темами выходит после шестого спринта. Хотя эти релизы имеют приставки альфа и бета, это обновления продукта, удовлетворяющие критериям готовности. Версия 1.0 выходит на рынок после восьми спринтов (четыре месяца). После третьего спринта ожидается поставка продукта на сервер. План релиза фиксирует актуальную скорость работы команды и предоставляет прогноз на оставшиеся спринты.
ПРОГНОЗИРОВАНИЕ СКОРОСТИ
Чтобы спрогнозировать скорость работы команды, мы предпринимаем следующие шаги: если разрабатывается новый продукт, команда никогда не работала вместе или ее состав существенно изменился, нам нужно понаблюдать скорость работы команды по крайней мере по итогам первого спринта, а лучше — после двух или трех. Как уже упоминалось, чтобы скорость стабилизировалась, может потребоваться несколько спринтов. После этого мы можем использовать полученные данные по скорости работы команды для прогнозирования в будущих спринтах. В плане релиза из таблицы 4.2 для четвертого спринта ожидается скорость работы команды от 20 до 28 очков со средним значением 24 очка.
Кроме того, чтобы спрогнозировать будущую скорость работы команды, можно использовать и таблицу 4.3 (Cohn, 2005; 180). Так и поступила scrum-команда в плане релиза из таблицы 4.2.
Таблица 4.3. Множители скорости на основе завершенных спринтов
| Завершенные спринты | Наименьший множитель | Наибольший множитель |
| 1 | 0,6 | 1,60 |
| 2 | 0,8 | 1,25 |
| 3 | 0,85 | 1,15 |
| 4 или более | 0,9 | 1,10 |
Используя среднюю скорость трех первых спринтов из таблицы 4.2, мы умножаем 24 на соответствующие наименьший и наибольший множитель из таблицы 4.3. Получается диапазон значений скорости работы команды от 21 до 28 очков.
После того как команда проделала пять и более спринтов, можно составить точный прогноз (Cohn, 2009; 297–300). Допустим, мы завершили восьмой спринт из таблицы 4.2 и хотим предсказать скорость команды в следующем релизе. Скорости завершенных спринтов имеют следующие значения: 20, 25, 28, 26, 16, 20, 26, 26. Теперь исключаем из рассмотрения данные по тем спринтам, в которых произошли аномалии — например, половина команды заболела или сервер на несколько дней стал недоступен. Затем сортируем список оставшихся значений в порядке возрастания. Получается следующее: 16, 20, 20, 25, 26, 26, 26, 28. Теперь, пользуясь таблицей 4.4, мы с 90%-ной уверенностью можем определить будущую скорость работы команды.
Таблица 4.4. Использование n-ного наименьшего и n-ного наибольшего наблюдения в отсортированном списке значений скорости для нахождения 90%-ного интервала достоверности
| Количество наблюдений скорости | n-ное наблюдение скорости |
| 5 | 1 |
| 8 | 2 |
| 11 | 3 |
| 13 | 4 |
| 16 | 5 |
| 18 | 6 |
| 21 | 7 |
| 23 | 8 |
| 26 | 9 |
Поскольку мы прошли восемь спринтов, берем второе наблюдение скорости с начала и с конца последовательности. Это дает диапазон значений скорости от 20 до 26 со средней скоростью 23. Можно быть на 90% уверенными, что реальное значение скорости работы команды будет внутри этого диапазона.
СОСТАВЛЕНИЕ ПЛАНА РЕЛИЗА
Предсказав скорость, делим оставшийся объем работ из бэклога продукта на среднюю скорость работы команды или на диапазон скоростей, что дает примерное количество спринтов, необходимых для реализации продукта. Теперь фиксируем выявленное число спринтов в календаре и изучаем факты, которые могут повлиять на скорость, но при этом не учтены в прогнозе. Это могут быть выходные, отпуск, дни для обучения и развития персонала, а также статистика заболеваемости и запланированные изменения в организации проекта — например, изменение состава команды. В соответствии с этими данными корректируем прогноз скорости разработки для каждого будущего спринта в плане релиза.
Вернемся к плану релиза из таблицы 4.2. Из него следует, что реальная скорость работы команды по итогам первых трех спринтов составила 20, 25 и 28. Средняя скорость спринта, таким образом, равняется 24 очкам. Scrum-команда спрогнозировала скорость в диапазоне от 21 до 28 очков для четвертого, седьмого и восьмого спринтов, воспользовавшись множителями из таблицы 4.3.
План релиза также прогнозирует падение скорости для пятого и шестого спринтов, поскольку в это время несколько членов команды берут отпуск, после чего возвращаются на работу.
Если работа в бэклоге продукта не будет завершена в допустимые сроки (например, в случае фиксированной даты запуска), можно либо сократить функциональность, либо увеличить бюджет, добавив людей в команду (например, одного специалиста).
Отличное средство представления плана релиза — это белая маркерная доска, расположенная в рабочем помещении. Некоторые из них снабжены колесиками, которые позволяют вывезти доску в другую комнату. Конечно, план релиза может храниться в электронном виде — например, как электронная таблица. Однако при использовании любого инструмента план релиза должен быть ясным, прозрачным и способствовать диалогу между scrum-командой и заинтересованными лицами.
ПЛАНИРОВАНИЕ РЕЛИЗОВ В БОЛЬШИХ ПРОЕКТАХ
Для планирования релизов в больших проектах требуются дополнительные методы работы. К ним относятся установление общих ориентиров для оценок, перспективное планирование и, при необходимости, организация конвейерной работы.
ОБЩИЕ ОРИЕНТИРЫ ДЛЯ ОЦЕНОК
Если несколько команд оценивают элементы в одном бэклоге продукта, им необходимо выработать общие ориентиры для своих оценок, диапазон очков за пользовательскую историю и смысл каждого числового значения. Иначе трудно понять, какой объем работы зафиксирован. Если проект растет постепенно и команды появляются одна за другой, то общие оценки обычно возникают сами собой. Первая команда назначает исходные цифры, которыми руководствуются команды, вступающие в проект на более поздних стадиях. Если же проект сразу предполагает работу нескольких команд, то представители каждой из них должны провести сессию совместной оценки, чтобы согласовать общий диапазон с общим смыслом числовых значений.
ПЕРСПЕКТИВНОЕ ПЛАНИРОВАНИЕ
Чтобы помочь каждой команде в процессе оптимизации хода всего проекта, нужно приложить дополнительные усилия. Прежде всего следует заглянуть на два-три спринта вперед. Это даст возможность понять, над какими элементами бэклога продукта, вероятнее всего, будет проводиться работа (Cohn, 2005; 206. Pichler, 2008; 146). Это требует более ранней декомпозиции и оценки элементов бэклога продукта. Теперь в его верхней части будет больше детализированных элементов.
Следующий шаг — выявление взаимозависимости между командами. Следует спросить себя, должны ли команды совместно работать над какой-то функцией или компонентом? Будет ли какая-либо команда выступать поставщиком для другой команды? Если да, то возможно ли за один спринт реализовать какую-то функцию или компонент и сразу же его использовать? Чтобы ликвидировать проблемные зависимости, можно прибегнуть к пересмотру приоритетов в бэклоге продукта. Например, вместо того чтобы поручить двум командам во время следующего спринта работать над одной и той же подсистемой, можно отложить внедрение некоторых требований на следующий спринт и выдвинуть на передний план другие элементы, поменяв приоритеты в бэклоге продукта.
После того как все проблемы взаимозависимости решены, оцениваем объем работы для каждой команды. Не будет ли команда перегружена во время следующего спринта? А может быть, ее, напротив, используют недостаточно? В любом случае есть возможность вернуться и изменить расстановку приоритетов в бэклоге продукта.
Можно пройти указанные этапы несколько раз, прежде чем будет достигнут оптимальный баланс между потребностями индивидуальных команд и общими нуждами проекта. Когда это сделано, добавляем в план релиза истории для следующих двух-трех спринтов. Прохождение всех этих этапов никак не влияет на права и обязанности команды. Предсказание скорости команды и объема работ не означает, что команды обязательно все это выполнят. Результат всего этого — еще больше работы. Но, к сожалению, альтернативы нет. Не смотреть вперед — это все равно что бежать по ночному лесу без фонаря. Наверняка в этом случае мы будем постоянно натыкаться на деревья и получать травмы.
КОНВЕЙЕРНАЯ РАБОТА
Конвейер — это последний шанс. К данной методике стоит обращаться, только если все остальные возможности исчерпаны. Конвейерная работа разделяет то, что должно быть единым целым. Она распределяет работу над одним элементом бэклога продукта по нескольким спринтам (Larman, 2004; 251–253). Вот как это работает: допустим, у нас есть две команды — А и Б. Команда А должна поставить компонент для команды Б, а команда Б будет с ним работать. В процессе перспективного планирования мы обнаруживаем, что обе части процесса нельзя выполнить в ходе одного спринта. Сложно также сократить объем работы посредством последующей декомпозиции требований. Последний шанс — перейти на конвейерный метод. Мы просим команду А внедрить нужный компонент в ходе ближайшего спринта, а команду Б — использовать его в ходе следующего.
Звучит замечательно, но сразу возникает проблема: что будет сделано, когда команда А завершит работу? И как убедиться в том, что компонент будет работать нужным образом, когда команда Б начнет его использовать? Поскольку за частично сделанную работу не начисляется очков, то деятельность команды А не будет отражена в диаграмме сгорания работ, что затруднит отслеживание прогресса. Более того, может потребоваться резерв времени, чтобы убедиться в том, что команда А действительно сможет поставить нужный компонент (Cohn, 2005; 208). Буфер нужен в том случае, если команда A столкнется с необходимостью приложить больше усилий к работе над проектом, чем ожидалось. Потребности в конвейерной работе можно снизить, если задействовать функциональные, а не компонентные команды.
РАСПРОСТРАНЕННЫЕ ОШИБКИ
При планировании релиза в scrum-проекте избегайте следующих ошибок: отсутствие диаграммы сгорания работ или плана релиза; пассивный владелец продукта, не принимающий участия в процессе планирования релиза; взрывные релизы, предлагающие слишком много функциональности сразу; работа в ущерб качеству.
ОТСУТСТВИЕ ДИАГРАММЫ СГОРАНИЯ РАБОТ ИЛИ ПЛАНА РЕЛИЗА
Мне встречались организации, которые, привыкнув к предварительному составлению детального плана проекта, бросались в другую крайность и вообще отказывались от планирования релиза. Жить от спринта к спринту опасно, а попасться в эту ловушку довольно легко. Из-за этого трудно оценить прогресс проекта и внести нужные изменения в продукт и проект. Необходимо всегда иметь диаграмму сгорания работ или план релиза. Они должны быть размещены в рабочем помещении и на вики-портале проекта и быть легко доступными для всех участников.
ВЛАДЕЛЕЦ ПРОДУКТА В КРЕСЛЕ ПАССАЖИРА
Владелец продукта должен принимать активное участие в деятельности по планированию релиза, не перекладывая ее полностью на команду или scrum-мастера. Как человек, который прежде всего отвечает за успех продукта, он должен руководить им с самого начала.
ВЗРЫВНОЙ РЕЛИЗ
Если выбрать главный совет этой главы, то вот он: делайте все возможное для быстрых и частых релизов ПО. Избегайте взрывного релиза, то есть поставки продукта только после внедрения всей возможной функциональности. В этом случае очень трудно, если вообще возможно, вовремя отреагировать на отзывы клиентов и пользователей, так что вероятность создания продукта, который полюбят клиенты, стремится к нулю. Есть и еще один недостаток. Взрывной релиз означает, что команда впервые сдает программу при выходе ее на рынок. Это часто влечет за собой дополнительный стресс членов команды и может привести к опозданию и срыву даты запуска.
РАБОТА В УЩЕРБ КАЧЕСТВУ
У владельца продукта может возникнуть искушение выпустить побольше функций в ущерб качеству. В конце концов, почему бы и нет, ведь это часто приводило к ускорению хода работы. Срезать немного углов тут и там, чуть меньше тестирования, небольшая отсрочка в документации… Проблема, однако, в том, что, жертвуя качеством, команды остаются с продуктом, который будет все сложнее и дороже поддерживать и расширять. Да, краткосрочная выгода очевидна. Но через несколько месяцев начнутся проблемы. Кроме того, жертвуя качеством, сотрудники вряд ли будут гордиться своей работой, так как подрывают мастерство команды и применение правильных инженерных методов. У команд должны быть критерии готовности — это требования, которым должен удовлетворять продукт. Эти критерии владелец продукта должен использовать при каждой демонстрации результата спринта. Не следует принимать частично выполненную или выполненную с ошибками работу. Упрощайте планирование релиза, назначая временные рамки для проектов, и установите равномерную частоту выпуска обновлений.
ВОПРОСЫ ДЛЯ САМОКОНТРОЛЯ
Зачем ждать официального запуска продукта, чтобы узнать реакцию рынка? Выпускайте релизы быстро и часто, но ПО должно быть качественным. Учитесь на первичных отзывах заказчиков и пользователей, включайте их замечания в следующие улучшения программы.
Выпустите обновления, а затем снова улучшайте проект.
- Каковы будут последствия, если зафиксировать время, качество или гибкость функциональности?
- Каковы выгоды от частых и быстрых релизов? И как на них перейти? Что нужно сделать, чтобы организовать выпуск проекта квартальными циклами? Какова скорость работы вашей команды?
- Что вы используете: диаграмму сгорания работ или план? Кто составляет и обновляет их?
