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

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

По тем же причинам, как и в случае директора по разработке, большинству руководителей проектов полезно воздерживаться от оценок на протяжении как минимум одной итерации. Если вы оказались в такой ситуации, воспользуйтесь возможностью выполнить итерацию и измерить скорость. Затем определите диапазон относительно ее значения с помощью конуса неопределенности. Так, если вы выполните итерацию и получите скорость 15, преобразуйте ее путем умножения на 0,6 и 1,6 в диапазон 9–24.

Если команда может выполнить три итерации или более, прежде чем оценивать скорость, то у нее появляется пара дополнительных возможностей определения диапазона. Во-первых, она может просто использовать диапазон наблюдаемых значений. Допустим, команда выполнила три итерации и получила скорости 12, 15 и 16. В этом случае скорость будет лежать в диапазоне от 12 до 16.

Во-вторых, она может применить конус неопределенности. Хотя у подхода, который я собираюсь описать, нет солидной эмпирической основы, он работает и дает результаты. Вот этот подход: рассчитайте среднюю скорость для выполненных итераций. Затем для каждой итерации сместитесь на один этап вправо на конусе неопределенности. Если команда выполнила одну итерацию, используйте диапазон для этапа «начальная концепция продукта». Если команда выполнила две итерации, используйте диапазон для этапа «утвержденная концепция продукта» (от 80 % до 120 %) и т. д. Для удобства значения нужных множителей приведены в табл. 16.1.

Предположим, что команда выполнила три итерации при средней скорости 20 за период. Для трех итераций диапазон составляет 85–115 %. Это означает, что фактическая скорость к концу проекта будет, скорее всего, лежать в диапазоне от 17 до 23.

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

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

Бывает, что исторические данные отсутствуют, а посвятить несколько итераций наблюдению за скоростью нет возможности. Допустим, оценка нужна для проекта, который начнется не раньше чем через 12 месяцев. Или, как вариант, проект может начаться скоро, но только после подписания клиентом договора на выполнение работы. Такие случаи характеризуются двумя ключевыми особенностями. Во-первых, с учетом желания минимизировать затраты на проект вы вряд ли будете проводить итерации по проекту, который начнется в отдаленном будущем или может не начаться вообще. Во-вторых, оценки скорости по таким проектам должны отражать высокую степень неопределенности.

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

1. Оценка количества часов, в течение которых каждый участник сможет ежедневно заниматься проектом.

2. Определение суммарного количества часов, которые будут затрачены на проект в процессе итерации.

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

4. Преобразование найденной на предыдущем этапе скорости в диапазон.

Посмотрим на примере, как работает такой подход.

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

По моим наблюдениям и по мнению моих коллег, большинство работников, полностью занятых в проекте, могут уделять проекту от четырех до шести часов в день. Это соответствует данным о том, что участники уделяют работе над проектом от 55 % (Ganssle, 2004) до 70 % (Boehm, 1981) своего времени. Самый высокий показатель, по данным Кеннеди (Kennedy, 2003), у инженеров компании Toyota, где высокоэффективный процесс бережливого производства позволяет посвящать работе над целевым проектом до 80 % времени.

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

Этот этап несложен: нужно просто умножить количество доступных часов в день на количество членов команды и на количество дней в итерации. Допустим, в состав команды SwimStats входит один аналитик, один программист, один администратор баз данных и один тестировщик. Четыре человека, каждый из которых работает по шесть часов в день, вместе будут отрабатывать 24 часа в день. За десятидневную итерацию они посвятят проекту примерно 240 часов.