Управление Релизами

Иногда задают вопрос, как при итеративной модели можно осуществлять долгосрочное релизное планирование. Следует рассмотреть два случая: (1) планирование первого релиза нового продукта, и (2) планирование очередного релиза существующего продукта.

В случае нового продукта или существующего продукта, который только что перешёл на Скрам, необходимо выполнить первоначальное Уточнение Бэклога Продукта перед первым Спринтом, когда Владелец Продукта и Команда формируют надлежащий Бэклог Продукта по принципам Скрама. Это может занять от нескольких дней до недели и включает в себя сессию совместной работы (иногда называемую Первоначальным Уточнением Бэклога Продукта или Планированием Релиза), подробный анализ требований и оценку всех элементов, определённых для первого релиза.

Удивительно, но в Скраме в случае существующего продукта, уже имеющего Бэклог Продукта, не должно быть необходимости в каком-либо специальном или дополнительном планировании следующего релиза. Почему? Потому что Владелец Продукта и Команда должны проводить Уточнение Бэклога Продукта каждый Спринт (пять или десять процентов усилий в каждом Спринте), непрерывно готовясь к будущему. Этот режим непрерывной разработки продукта устраняет необходимость в драматически прерывистых этапах подготовки-выполнения-завершения, которые можно увидеть в жизненном цикле традиционной последовательной разработки.

Во время первоначального Уточнения Бэклога Продукта и во время непрерывных Уточнений Бэклога Продукта в каждом Спринте, Команда и Владелец Продукта будут планировать релиз, уточняя оценки, приоритеты и содержание по мере того, как они учатся.

Некоторые релизы ориентированы на дату; например: “Мы выпустим версию 2.0 нашего проекта к началу выставки 10 ноября”. В этой ситуации Команда завершит столько Спринтов (и создать как можно больше функциональности), сколько сможет за отведенное время. Другие продукты требуют создания определённой функциональности, прежде чем их можно будет назвать завершёнными, и продукт не будет запущен, пока эти требования не будут удовлетворены, сколько бы времени это не заняло. Поскольку Скрам делает упор на создание потенциально готового к поставке кода в каждом спринте, Владелец Продукта может решить начать делать промежуточные релизы, чтобы позволить клиентам как можно раньше воспользоваться преимуществами готовой работы.

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

Пункт назначения важнее самого путешествия.

Большинство Владельцев Продуктов выбирает один из релизных подходов. Например, они определят дату выпуска и будут работать с Командой над оценкой элементов Бэклога Продукта, которые могут быть выполнены к этой дате. Элементы, которые, как ожидается, будут в текущем релизе, иногда называются релизными элементами. В ситуациях, когда зафиксированы обязательства “фиксированная цена / фиксированная дата / фиксированный результат” - например, при заказной контрактной разработке - один или несколько из этих параметров должны иметь встроенный буфер, чтобы учесть неопределенность и изменчивость; в этом отношении Скрам ничем не отличается от других подходов.

Перевод статьи осуществлён Кротовым Артёмом и Романом Лапаевым.