Планирование релизов

Встреча планирования релизов используется для создания графика релизов, который определяет план разработки всего проекта. График релизов в дальнейшем используется для планирования каждого отдельного спринта.

Цель

Во время планирования релиза технические специалисты должны принять технические решения, а менеджеры и заказчики — сформулировать бизнес-требования. Важно, чтобы процесс позволял всем вовлечённым участникам принять решения и высказать своё мнение. Процесс определяет метод коммуникаций, в результате которых получается график, с которым все согласны.

Основная задача разработчиков в рамках планирования релизов — оценить каждую отдельную User Story в разрезе «идеальных» недель разработки: без внешних зависимостей, без параллельных задач, но с учётом написания тестов. После этого заказчик решает, какие истории наиболее ценные, и выставляет им приоритет.

Подход

Разработчики и заказчики совместно перебирают карточки User Stories одну за другой, определяя набор историй, которые будут реализованы в следующем (или в первом) релизе. Важно, чтобы процесс был удобным, учитывал тестирование и потребности бизнеса и пользователей с самых ранних этапов разработки проекта.

Планировать можно по времени или по объёму работ. Показатель Project Velocity (скорость разработки) используется для определения количества историй, которые могут быть реализованы до заданной даты (времени), либо сколько времени потребуется для реализации набора историй (объёма работ).

• При планировании по времени количество итераций умножается на Project Velocity, в результате определяется количество историй, которые можно завершить.
• При планировании по объёму работ общее количество недель, необходимых для реализации выбранных историй, делится на Project Velocity — таким образом определяется количество итераций, необходимых для готовности релиза.

Если сформулированный план релиза не устраивает менеджмент, может возникнуть соблазн уменьшить оценки трудозатрат — этого делать нельзя. Занижение оценок сейчас создаст проблемы позже. Оценки, сформулированные по процессу, считаются валидными и должны оставаться неизменными при планировании итераций.

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

Каждая отдельная итерация (спринт) планируется детально непосредственно перед её началом, а не заранее.

Четыре переменные планирования

Планирование релиза может быть разделено на четыре переменные: ресурсы, объём, качество и время.

• Ресурсы: сколько человек доступно.
• Объём: сколько работы может быть выполнено.
• Качество: насколько хорошим будет ПО и как хорошо оно будет протестировано.
• Время: дата, когда проект или релиз будет завершён.

Один отдельный человек не может контролировать все четыре переменные. Изменение одной из переменных приведёт к изменению другой.

Снижение показателя качества до уровня ниже «лучшего» может привести к непредвиденным последствиям для остальных трёх переменных. Эти последствия могут стать очевидными непосредственно перед финальным релизом, когда темп работы над проектом замедлится до минимума.

По сути, действительно стоит менять только три переменные: две из них установит менеджмент, а третью разработчики.

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