Читать книгу "Agile: Оценка и планирование проектов - Майк Кон"

Анализ итерации обычно занимает от 30 до 60 минут. В случаях крупных продуктов при участии нескольких команд бывает, что владелец продукта и другие ключевые заинтересованные лица, необходимые для обсуждения приоритетов, тратят на анализ итерации полдня. Добавьте к этому четыре часа на планирование итерации, и у вас может не остаться времени для обсуждения приоритетов в тот же день.

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

Определение целевой скорости

Следующий этап планирования итерации на основе скорости — определение целевой скорости команды. По умолчанию большинство команд принимают свою скорость в следующей итерации равной скорости в ближайшей прошлой итерации. Бек и Фаулер (Beck and Fowler, 2000) называют это вчерашней погодой, поскольку самый лучший прогноз сегодняшней погоды тот, который похож на вчерашнюю погоду. Есть и такие команды, которые предпочитают использовать скользящие средние, скажем, за последние три итерации.

Если команда не работала вместе прежде или не знакома с agile-процессом, то ей придется спрогнозировать скорость. Методы прогнозирования скорости описаны в главе 16 «Оценка скорости».

Идентификация цели итерации

С учетом приоритетов и целевой скорости команда идентифицирует цель, которой она должна достичь во время итерации. Цель — короткое описание того, что она хотела бы реализовать за этот период. Например, команда SwimStats может выбрать в качестве цели итерации «Завершение всех гендерно-возрастных функций». Другие цели итераций для SwimStats могут включать в себя следующее:

• Добиться прогресса по отчетам.

• Завершить реализацию всех отчетов по результатам в соревновании.

• Обеспечить работоспособность функции безопасности.

Цель итерации — это единое заявление о том, что должно быть реализовано в течение данной итерации. Она не должна быть очень конкретной. Например, «Добиться прогресса по отчетам» — хорошая цель итерации. Ее не нужно делать более конкретной, например «Завершить 15 отчетов» или «Выполнить отчеты по результатам соревнования». Если «Добиться прогресса по отчетам» наглядно описывает, над чем придется работать в предстоящей итерации, то это хорошее заявление об этой цели.

Выбор пользовательских историй

На следующем этапе владелец продукта и команда выбирают истории, которые в совокупности обеспечивают достижение цели итерации. Если команда SwimStats выбирает в качестве цели итерации «Завершение всех гендерно-возрастных функций», она должна работать над любыми еще не реализованными историями, которые имеют отношение к гендерно-возрастным функциям. Они могут включать в себя:

• Как пловец я могу корректировать свою гендерно-возрастную информацию.

• Как тренер я могу вводить гендерно-возрастную информацию по всем пловцам моей команды.

• Как тренер я могу импортировать файл со всеми гендерно-возрастными данными.

• Как тренер я могу экспортировать файл со всеми гендерно-возрастными данными.

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

Разбивка пользовательских историй на задачи

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

• Определение правил, которые влияют на то, кого можно поставить на какой заплыв.

• Написание тестовых сценариев, показывающих, как это должно работать.

• Разработка пользовательского интерфейса.

• Получение обратной связи по пользовательскому интерфейсу от тренеров.

• Кодирование пользовательского интерфейса.

• Кодирование среднего яруса.

• Добавление новых таблиц в базу данных.

• Автоматизация приемочных тестов.

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

Включайте только ту работу, которая создает стоимость для соответствующего проекта

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

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

Будьте конкретны, пусть это станет привычкой

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