Agile: оценка и планирование проектов - [81]

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

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

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

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

Вопросы для обсуждения

1. Как вы устанавливаете общую базу для оценок в проектах с участием нескольких команд?

2. Насколько значительна взаимозависимость команд в вашем текущем проекте? Какие приемы из описанных в этой главе являются самыми действенными?

Часть V Отслеживание прогресса и информирование

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

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

Глава 19 Мониторинг плана релиза

Звезды могут лгать, а цифры — никогда.

Мэри Чапин Карпентер, песня «I Feel Lucky»

Перед древними моряками стояли две задачи. Во-первых, им нужно было знать, на какой широте они находятся, т. е. их положение на карте в направлении север — юг. Во-вторых, им нужно было знать долготу, т. е. положение в направлении восток — запад. Определение широты на основе наблюдений за Полярной звездой было сравнительно простым делом и практиковалось уже за 300 лет до Рождества Христова. С долготой было сложнее, поскольку для ее определения требовались относительно точные часы, или хронометр. К сожалению, достаточно точные хронометры (в частности, такие, которые годились бы для использования на борту корабля) появились лишь в начале XVIII в.

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

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

Отслеживание процесса разработки релиза

Перед началом работы над релизом мы составляем план, в котором говорится что-то вроде: «В течение следующих четырех месяцев и восьми двухнедельных итераций мы выполним работу объемом примерно 240 пунктов (или идеальных дней)». По мере того как мы узнаем больше об истинных потребностях пользователей и о размере проекта, эта оценка может меняться. Вместе с тем мы должны в любой точке иметь возможность оценить наше положение относительно цели — выполнения определенного объема работы за определенное время.

При такой оценке необходимо учитывать множество действующих факторов. Первое, и в идеале самое главное, — прогресс, которого добивается команда. Второе — изменение объема проекта. Владелец продукта может добавлять или удалять требования. Если он добавляет 40 пунктов, а команда реализует 30, то у нее остается больше работы, чем в начале предыдущей итерации. Цель сдвигается, и полезно знать, как далеко команда находится от достижения новой цели. Или разработчики могут получить во время итерации такие знания, которые заставят их пересмотреть оценки в пунктах, присвоенные последующим работам в плане релиза.