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

• Осталась ли прежней область деятельности?

• Осталась ли прежней команда?

• Остался ли прежним владелец продукта?

• Остались ли прежними инструменты?

• Осталась ли прежней рабочая среда?

• Были ли эти оценки сделаны теми же людьми?

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

Если же ответ на любой из перечисленных выше вопросов отрицателен, то следует дважды подумать, прежде чем использовать исторические скорости. Как вариант, на них можно опереться, но при этом увеличить диапазон для отражения неопределенности, присущей такой оценке. С этой целью начните с расчета средней скорости команды в течение работы над предыдущим релизом. Если команда выполнила работу объемом 150 пунктов за 10 итераций, то ее средняя (среднеарифметическая) скорость равна 15 пунктам.

Прежде чем читать о том, как преобразовать этот показатель в диапазон, посмотрите на рис. 16.1. На нем показан конус неопределенности, о котором мы говорили в главе 1 «Цель планирования». Из конуса неопределенности следует, что фактический срок проекта лежит в диапазоне между 60 % и 160 % от того, чему он равен в соответствии с нашими представлениями. Поэтому, чтобы преобразовать нашу среднюю скорость в диапазон, я умножаю ее на 60 % и на 160 %[6]. Таким образом, если наша историческая скорость равна 15, то я говорю, что скорость лежит в диапазоне от 9 до 24.

Этот диапазон может показаться большим, однако с учетом неопределенности в данной точке он приемлем. Создание диапазона подобным образом помогает проектной команде следовать совету, данному в эпиграфе к этой главе, т. е. быть примерно правой и не оказаться точно неправой. Широкий диапазон значений ожидаемой скорости облегчает попадание в него.

Выполнение итерации

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

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

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

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

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

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