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

Я использую следующие две шкалы оценки:

• 1, 2, 3, 5 и 8;

• 1, 2, 4 и 8.

В основе каждой из этих последовательностей лежит своя логика. Первая — последовательность Фибоначчи[4]. Я считаю эту последовательность очень полезной, потому что шаг в ней повышается соответствующим образом с ростом величины чисел. Шаг в один пункт между числами 1 и 2, а также между числами 2 и 3 выглядит подходящим, как и шаги между 3 и 5 и между 5 и 8. Во второй последовательности каждое число определяется путем умножения предыдущего числа на два. Эти нелинейные последовательности работают хорошо, поскольку отражают повышение неопределенности, связанной с оценками более крупных элементов работы. В принципе, данные последовательности равноценны, но лично я предпочитаю первую.

Каждое из этих чисел следует рассматривать как емкость, в которую «выливают» объекты соответствующего размера. Работу лучше представлять как текущий песок, а не воду, льющуюся в емкость. Если вы используете ряд 1, 2, 3, 5 и 8, а оцениваемая история чуть больше, чем другие оцененные в пять пунктов истории, то ее можно поместить в 5-пунктовую емкость. Понятное дело, что история, которую вы оцениваете на семь, для 5-пунктовой емкости не подходит.

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

Если команда решит не включать ноль в шкалу оценки, то все участники проекта (особенно владелец продукта) должны ясно понимать, что 13 × 0 ≠ 0. У меня никогда не было проблем с объяснением этого владельцам продукта, которые понимали, что 0-пунктовая история — эквивалент бесплатного сыра. Однако они также понимали, что в одной итерации количество ломтиков бесплатного сыра не может быть безграничным. Альтернативой использованию нуля является группирование очень маленьких историй и их оценка как отдельный элемент работы.

Некоторые команды предпочитают работать с большими числами, такими как 10, 20, 30, 50 и 100. Это нормально, поскольку они представляют диапазон одного порядка. Вместе с тем, если вы имеете дело с большими числами в диапазоне от 10 до 100, я настоятельно рекомендую заранее определить используемые числа в этом диапазоне. Не допускайте, например, оценки одной истории в 66 пунктов или идеальных дней, а другой — в 67. Это ложный уровень точности, так как невозможно уловить 1,5 %-ную разницу в размере. Разница в один пункт приемлема для таких величин, как 1, 2 и 3. В процентном выражении она значительно больше разницы между 66 и 67.

Пользовательские истории, эпопеи и сюжеты

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

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

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

Пользовательские истории, подлежащие реализации в ближайшем будущем (в следующих нескольких итерациях), должны иметь не очень большой размер, чтобы работу над ними можно было завершить за одну итерацию. Такие объекты следует оценивать в пределах одного порядка. Я использую для этого последовательность 1, 2, 3, 5 и 8.

Пользовательские истории или другие объекты, работа с которыми, скорее всего, не будет осуществляться в ближайших итерациях, можно представить в виде эпопей или тем. Такие объекты можно оценивать в единицах за пределами рекомендуемого мною диапазона от 1 до 8. Чтобы оценивать крупные объекты, я добавляю 13, 20, 40 и 100 к своей любимой последовательности 1, 2, 3, 5 и 8.

Получение оценки

Наибольшее распространение получили следующие три метода оценки:

• экспертная оценка;

• оценка по аналогии;

• разбивка на более мелкие части.

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

Экспертная оценка

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

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

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

Оценка по аналогии

Альтернативой экспертной оценке является оценка по аналогии. Именно к ней мы прибегаем, когда говорим: «Эта история немного больше, чем та история». При оценке по аналогии оценщик сравнивает оцениваемую историю с одной или несколькими другими историями. Если данная история превышает другие по размеру в два раза, то говорят, что она в два раза больше. Существуют явные свидетельства того, что мы оцениваем относительные размеры лучше, чем абсолютные (Lederer and Prasad, 1998; Vicinanza et al., 1991).