Следующий уровень — планирование итерации, осуществляемое в начале каждой из них. Опираясь на результаты только что завершенной итерации, владелец продукта идентифицирует высокоприоритетную работу, которой команда должна заниматься в новой итерации. Поскольку на этом уровне мы имеем более близкий горизонт, чем при планировании релиза, компоненты плана итерации могут быть более мелкими. В процессе планирования итерации мы говорим о задачах, реализация которых необходима для превращения запроса на функцию в работающую и протестированную программу.
Наконец, существует еще дневное планирование. Большинство agile-команд ежедневно проводят своего рода летучки для координирования работы и синхронизации действий. Хотя с формальной точки зрения такое планирование может показаться излишним, на этих летучках команды действительно составляют, оценивают и пересматривают свои планы. Во время ежедневных совещаний команды ограничивают горизонт планирования следующим днем, когда они вновь соберутся для обсуждения дел, поэтому они фокусируются на планировании задач и на координировании отдельных видов деятельности, необходимых для выполнения этих задач.
Осуществляя планирование на трех временны́х горизонтах — релиз, итерация и день, — agile-команды концентрируют внимание на видимых и важных для создаваемого плана аспектах.
Планирование на уровне продукта и портфеля, а также стратегическое планирование находятся вне сферы интереса большинства agile-команд (и настоящей книги). Планирование на уровне продукта требует от владельца продукта прогнозирования ситуации на более далеком горизонте, чем выпуск ближайшего релиза, и планирования эволюции выпущенного продукта или системы. Планирование на уровне портфеля предполагает выбор продуктов, которые наилучшим образом соответствуют видению, сформированному в процессе стратегического планирования организации.
Состояние удовлетворенности
Любой проект начинается с набора целей. Ваш текущий проект может быть нацелен на создание лучшего в мире текстового процессора. Однако цели проекта, как правило, этим не исчерпываются. Наверняка существуют дополнительные цели, связанные с календарным графиком, бюджетом и качеством. Эти цели можно считать условиями удовлетворенности клиента или владельца продукта — иначе говоря, критериями, которые используются для оценки успешности проекта.
Когда-то, во времена моей учебы в средней школе, получив задание написать реферат по какой-нибудь книге, скажем «Моби Дик», я всегда спрашивал учительницу, какого объема должен быть этот реферат. Учительница говорила, например, «пять страниц», и я получал информацию о ее первом условии удовлетворенности. Конечно, существовал еще ряд дополнительных, неписаных условий удовлетворенности. Например, подразумевалось, что реферат должен быть написан аккуратно, что он написан мною лично, на английском языке и т. д.
В начале планирования релиза команда и владелец продукта совместно обговаривают условия удовлетворенности владельца продукта. Они включают в себя обычные аспекты — объем, календарный график, бюджет и качество, — хотя agile-команды обычно предпочитают рассматривать качество как безусловный показатель. Команда и владелец продукта определяют пути выполнения всех условий удовлетворенности. Владельца продукта может, например, в равной мере удовлетворять выпуск через пять месяцев релиза, включающего определенный набор пользовательских историй, и выпуск на месяц позже релиза, включающего дополнительные пользовательские истории.
Случается, однако, что все условия удовлетворенности владельца продукта выполнить невозможно. Команда может создать лучший в мире текстовый процессор, но у нее нет возможностей сделать это к следующему месяцу. Если приемлемое решение найти не удается, условия удовлетворенности необходимо менять. По этой причине планирование релиза и выяснение условий удовлетворенности владельца продукта являются итеративными процессами, как показано на рис. 3.2.
После составления плана релиза, охватывающего примерно следующие три — шесть месяцев, его используют как основу для планирования первой итерации. Аналогично планированию релиза планирование итерации начинается с рассмотрения условий удовлетворенности владельца продукта. Для итерации эти условия обычно включают в себя функции, которые он хотел бы получить, а также высокоуровневое тестирование этих функций.
В качестве примера рассмотрим туристический сайт, который включает такую пользовательскую историю: «Как пользователь я хочу иметь возможность аннулирования заказа». При обсуждении этой истории с владельцем продукта разработчики узнают, что его условия удовлетворенности включают в себя следующее:
• Пользователь, который аннулирует заказ более чем за 24 часа, получает полное возмещение своих средств.
• Пользователь, который аннулирует заказ менее чем за 24 часа, получает возмещение своих средств за вычетом комиссии в размере $25.
• Условия аннулирования заказа размещаются на сайте и высылаются пользователю по электронной почте.
Как и планирование релиза, планирование итерации является итеративным процессом. Владелец продукта и команда обсуждают различные пути достижения условий удовлетворенности для итерации.
На рис. 3.2 показана петля обратной связи от новой модификации продукта к этапу определения условий удовлетворенности в начале обоих процессов планирования релиза и итерации. В результате опыта, полученного при создании модификации продукта в процессе итерации, команда может приобрести знания, влияющие на планирование на одном или нескольких уровнях. Аналогичным образом, представляя модификацию продукта существующим или потенциальным пользователям, можно получать новые знания, заставляющие вносить изменения в планы. Agile-команда встраивает эти изменения в планы в той мере, в какой это позволяет создавать более ценный продукт.
Резюме
Agile-команды работают как единое целое, однако в них существует целый ряд конкретных ролей. Во-первых, владелец продукта, который отвечает за формирование общего видения проекта и за определение очередности разработки функций. Во-вторых, клиент, который принимает решение о финансировании проекта или о покупке программы после ее разработки. Помимо этих ролей в agile-проекте есть еще пользователи, разработчики и менеджеры.
Работа agile-команды разбивается на короткие, ограниченные по времени итерации, и каждая из них завершается поставкой работоспособного продукта. Функции, разрабатываемые в процессе выполнения итераций, выбираются на основе их приоритетности для бизнеса. Это позволяет гарантировать первоочередную разработку наиболее важных функций. Пользовательские истории — наиболее распространенный подход, применяемый agile-командами для представления потребностей пользователей. Agile-команды исходят из того, что планы быстро устаревают. Как результат, они корректируют свои планы по мере необходимости.
