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

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

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

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

Осуществляя планирование на трех временны́х горизонтах — релиз, итерация и день, — agile-команды концентрируют внимание на видимых и важных для создаваемого плана аспектах.

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

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

Когда-то, во времена моей учебы в средней школе, получив задание написать реферат по какой-нибудь книге, скажем «Моби Дик», я всегда спрашивал учительницу, какого объема должен быть этот реферат. Учительница говорила, например, «пять страниц», и я получал информацию о ее первом условии удовлетворенности. Конечно, существовал еще ряд дополнительных, неписаных условий удовлетворенности. Например, подразумевалось, что реферат должен быть написан аккуратно, что он написан мною лично, на английском языке и т. д.

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

Случается, однако, что все условия удовлетворенности владельца продукта выполнить невозможно. Команда может создать лучший в мире текстовый процессор, но у нее нет возможностей сделать это к следующему месяцу. Если приемлемое решение найти не удается, условия удовлетворенности необходимо менять. По этой причине планирование релиза и выяснение условий удовлетворенности владельца продукта являются итеративными процессами, как показано на рис. 3.2.