Майк Кон - Agile - оценка и планирование проектов

На рис. 18.2 поддерживающий буфер вставлен между завершением API командой 1 и началом работы команды 2 с использованием API над пользовательской историей, связанной с данными по индивидуальным результатам. Поддерживающий буфер защищает дату начала работы над историей, связанной с данными по индивидуальным результатам, от задержек в реализации API.

Чтобы включить поддерживающий буфер в план релиза, нужно всего лишь временно планировать работу с расчетом на более низкую скорость команды, которая поставляет определенную возможность другой команде. В случае, представленном на рис. 18.2, усилия команды 1 равномерно делятся между завершением API и поддерживающим буфером так, чтобы гарантировать команде 2 возможность приступить к работе над индивидуальными результатами с самого начала третьей итерации. Это не означает, что команда 1 получает возможность не торопиться в процессе второй итерации. В действительности от нее ожидают, что она выполнит связанную с API работу в 10 пунктов, использует только часть буфера и начнет работать над пользовательской историей, связанной с национальными рекордами, уже во второй итерации.

В ситуации, показанной на рис. 18.2, добавление поддерживающего буфера не увеличивает длину проекта в целом, поскольку третья итерация команды 1 была заполнена лишь частично. Во многих случаях, однако, добавление поддерживающего буфера увеличивает ожидаемую длину проекта. Правда, обычно это делают аккуратно, чтобы остаться в рамках реалистичных ожиданий в отношении вероятного календарного графика и не создать впечатление «раздувания графика в стремлении не особенно напрягаться». Из-за того что поддерживающие буферы могут удлинять сроки, их следует добавлять только при необходимости.

Чтобы определить, где необходимы поддерживающие буферы, сначала распределите пользовательские истории между командами и итерациями. Затем идентифицируйте критические взаимозависимости между итерациями и командами. Наконец, создайте поддерживающий буфер между этими критическими взаимозависимостями. Иначе говоря, добавляйте поддерживающий буфер только тогда, когда команда не может выполнить запланированную высокоприоритетную работу без получения результатов работы другой команды. Если же команда может легко переключиться на другую работу с высокой ценностью, то поддерживающий буфер не нужен. Аналогичным образом не добавляйте поддерживающий буфер, если вторая команда может успешно продвигаться вперед, опираясь лишь на часть результатов работы первой команды. Когда ваша команда может начать работу, получив от моей команды всего половину запланированной функциональности, поддерживающий буфер не нужен.

При определении размера поддерживающего буфера можно руководствоваться правилами, изложенными в главе 17 «Буферизация планов для компенсации неопределенности». Впрочем, к счастью, большинство межкомандных взаимозависимостей обычно связано не более чем с несколькими историями или функциями. Как результат, чаще всего у вас не хватает историй для эффективного использования метода «квадратный корень из суммы квадратов», описанного в этой главе. В таких случаях размер поддерживающего буфера принимается равным некоторому проценту от размера историй, в которых проявляется взаимозависимость. По умолчанию размер буфера устанавливается на уровне 50 %, однако эту величину необходимо скорректировать с учетом оценки команды.

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