56 / 94
Scrum и XP: заметки с передовой
56
Как мы планируем релизы и составляем контракты с фиксированной стоимостью
Иногда нужно планировать дальше, чем на один спринт вперед. Это типичная ситуация для контрактов с
фиксированной стоимостью, когда нам
приходится
планировать наперед, или же есть риск подписаться под
нереальной датой поставки.
Как правило, планирование релиза для нас – это попытка ответить на вопрос: "
когда, в самом худшем
случае
, мы сможем поставить версию 1.0".
Если вы
действительно
хотите разобраться, как планировать релиз, советую пропустить эту главу и
купить книгу Майка Кона "Agile Estimating and Planning". Эх, прочитать бы мне эту книгу раньше... (она
попалась мне уже
после
того, как мы на собственном опыте поняли, что к чему...). Мой способ планирования
простой, как угол дома, но может послужить вам хорошей отправной точкой.
Определяем свою приёмочную шкалу
В ополнении к обычн му product backlog'у, product owner определяет
приёмочную шкалу
, которая
представляет собой ни что иное, как простое разбиение всех историй product backlog'а на группы в
зависимости от их уровня важности в контексте контрактных обязательств.
Вот пример диапазонов из нашей приёмочной шкалы:
•
Все элементы с важностью >= 100
обязаны
быть включены в версию 1.0, иначе нас оштрафуют по
полной программе.
•
Все элементы с важность 50-99
должны
быть включены в версию 1.0, но в случае чего мы
можем
выкатить эту функциональность в следующем дополнительном релизе.
•
Элементы с важностью 25-49 необходимы, но могут быть сделаны в последующем релизе версии
1.1.
•
Важность элементов < 25 весьма спорна, так как возможно, что они вообще никогда не
пригодятся.
Вот пример product backlog'а, раскрашенного в соответствии с вышеописанными правилами:
Важность
Название
130
Банан
120
Яблоко
115
Апельсин
110
Гуава
100
Груша
95
Изюм
80
Арахис
70
Пончик
60
Лук
40
Грейпфрут
35
Папайя
10
Черника
10
Персик