Функциональный буфер

Прошлым вечером я отправился в продовольственный магазин со списком продуктов из 37 пунктов. В моем распоряжении было лишь полчаса, чтобы купить нужные продукты и вернуться домой, поскольку я хотел посмотреть баскетбольный матч, который начался в это время. Как обычно, я начал с одного конца магазина и стал продвигаться к другому. Я шел вдоль полок, а мое внимание было сконцентрировано примерно на 20 товарах, которые нам требовались больше всего. Я знал: если приду домой без молока, хлеба или нарезки из индейки, то в перерыве мне придется снова идти в магазин. Если же я забуду что-то менее важное, то моя жена смирится с этим, у моих дочек будет что поесть, а у меня — возможность спокойно посмотреть баскетбол.

Буферизация проекта с помощью функций точно такой же процесс. Клиентам говорят: «Мы реализуем все функции в этом пакете, а в идеале некоторые функции в том пакете». В agile-проекте функциональный буфер создается очень просто. Сначала клиент выбирает всю абсолютно обязательную работу. Оценки этой работы суммируются. Данная работа представляет собой минимум, который может войти в релиз. Затем клиент выбирает еще 25–40 % работ ближе к узкоспециализированному концу диапазона для проектов с более высокой неопределенностью или меньшей устойчивостью к риску невыполнения календарного графика. Оценки этих работ добавляют к первоначальной оценке и получают суммарную оценку проекта. После этого составляют план проекта как обычно, предусматривая поставку полного набора функций, однако при этом часть работы является опциональной и выполняется только в том случае, если позволяет время. Опциональная работа выполняется в последнюю очередь и всегда после завершения обязательной.

Для лучшего понимания того, как это работает, предположим, что владелец продукта идентифицировал работу объемом 100 пунктов как обязательную. Каждая из отобранных историй предполагает выпуск продукта, который будет хорошо принят рынком. Владелец продукта затем выбирает дополнительные 30 % работы, идентифицируя пользовательские истории, оцениваемые еще в 30 пунктов. Эти истории добавляются в проект как опциональная работа. Ожидаемый суммарный размер проекта теперь составляет 130 пунктов. Используя методы, описанные в главе 16 «Оценка скорости», команда определяет, что ее скорость составит 10 пунктов на однонедельную итерацию. В план проекта закладывают 13 итераций (130 / 10). Если все идет хорошо, то обязательная работа выполняется за первые 10 итераций, а оставшиеся три итерации посвящают опциональным функциям.

Процесс функциональной буферизации согласуется с agile-процессом, называемым «метод разработки динамических систем (dynamic systems development method — DSDM)». В DSDM-проектах требования разделяют на четыре категории: обязательные, желательные, опциональные, ненужные. К обязательным может быть отнесено не более 70 % запланированных функций в проекте. Таким образом, в DSDM-проектах создается функциональный буфер, эквивалентный 30 % срока проекта.