Как мы планируем релизы и составляем контракты с фиксированной стоимостью

Как мы планируем релизы и составляем контракты с фиксированной стоимостью

Иногда нужно планировать дальше, чем на один спринт вперед. Это типичная ситуация для контрактов с фиксированной стоимостью, когда нам приходится планировать наперед, или же есть риск подписаться под нереальной датой поставки.

Как правило, планирование релиза для нас - это попытка ответить на вопрос: «когда, в самом худшем случае, мы сможем поставить версию 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’а, раскрашенного в соответствии с вышеописанными правилами:

Красные = обязательно должны быть добавлены в версию 1.0 (банан - груша)

Жёлтые = желательно включить в версию 1.0 (изюм - лук)

Зелёные = могут быть добавлены позже (грейпфрут - персик)

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

Поделитесь на страничке

Следующая глава >

Похожие главы из других книг:

Типы данных фиксированной точности

Из книги автора

Типы данных фиксированной точности Обозначения типов данных фиксированной точности получаются из обычных обозначений типов данных Win32, таких как DWORD или LONG, добавлением суффикса размера, как показано в табл. 16.1.Таблица 16.1. Типы данных фиксированной точности Тип


Типы данных с фиксированной точкой

Из книги автора

Типы данных с фиксированной точкой К этим типам данных относятся NUMERIC и DECIMAL. Часто звучит вопрос, чем NUMERIC отличается от DECIMAL. Оба этих типа имеют одинаковую разрядность - от 1 до 18 знаков, одинаковую точность - от нуля до разрядности.Напомним, что разрядность - это общее


11.21. Реализация чисел с фиксированной точкой

Из книги автора

11.21. Реализация чисел с фиксированной точкой ПроблемаТребуется обеспечить выполнение вычислений с вещественными числами, используя тип с фиксированной, а не с плавающей точкой.РешениеВ примере 11.40 представлена реализация вещественного числа с фиксированной точкой,


Масштабируемые типы с фиксированной точкой

Из книги автора

Масштабируемые типы с фиксированной точкой Типы с фиксированной точкой позволяют управлять числами, которые должны вычисляться с дробной частью, задающейся количеством цифр после десятичной точки, или масштабом. Обычно масштабируемые типы нужны для финансовых


Поведение типов с фиксированной точкой в операциях

Из книги автора

Поведение типов с фиксированной точкой в операциях ДелениеПри выполнении деления типов с фиксированной точкой диалекты 1 и 3 ведут себя по-разному.В диалекте 3, когда оба операнда являются типами с фиксированной точкой, Firebird суммирует масштабы обоих операндов для


Символьные данные фиксированной длины

Из книги автора

Символьные данные фиксированной длины Строковые типы данных фиксированной длины в Firebird используются для хранения строк, длина которых является одной и той же или очень близкой, либо там, где фор- мат или относительная позиция символов может передавать семантическое


Красная буковка и чёрная чёрточка стоимостью в $3,5 млн, или Искусство вышибать деньгу в ИТ Сергей Голубицкий

Из книги автора

Красная буковка и чёрная чёрточка стоимостью в $3,5 млн, или Искусство вышибать деньгу в ИТ Сергей Голубицкий Опубликовано 14 марта 2014 Когда я прочитал про достижения Spritz Technology Inc., то сначала глазам не поверил (ну, это дело в последнее время обычное), а


Контракты и надежность ПО

Из книги автора

Контракты и надежность ПО Предусловие и постусловие программы определяют контракт со всеми ее


Инварианты и контракты

Из книги автора

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


Проект Human Brain: попытка смоделировать работу мозга на суперкомпьютере стоимостью в миллиард евро Андрей Васильков

Из книги автора

Проект Human Brain: попытка смоделировать работу мозга на суперкомпьютере стоимостью в миллиард евро Андрей Васильков Опубликовано 11 февраля 2013Европейская комиссия выбрала проект моделирования работы головного мозга человека на суперкомпьютере как один из наиболее