Теория от практики на практике отличается гораздо больше, чем в теории.
После всех теоретических рассуждений о разных способах оценки (смотри Оценка. Часть 1 и Оценка. Часть 2) давайте рассмотрим примеры оценки нескольких гипотетических проектов.
Проект «МегаХ»
Большая система, time & materials. Заказчик за Scrum, но просит изначально оценить примерные затраты и хочет иметь возможность видеть общий прогресс проекта. Хороший заказчик.
После обзорного анализа PM определяет состав команды. Так как участники проекта уже известны, то проводить оценку решено всей командой.
Для оценки всего проекта решено выбрать story points. Учитывая свой предыдущий опыт, PM рассказывает команде, почему именно story points и что они дадут (иначе команда будет считать в днях и просто называть их story point). Уф, команда за story points – тем более, что у некоторых уже есть опыт. Проводится небольшой тренинг по оценке.
Заказчик хочет Scrum, но не готов писать user stories, хотя согласен быстро отвечать на вопросы и объяснять непонятные моменты. Проблем особых нет – PM становится Proxy Product Owner и с помощью заказчика пишет истории.
Истории написаны и согласованы с заказчиком. Ок, можно приступать к оценке.
За несколько дней оценили все истории (использовали poker planning), прояснили оставшиеся неясные моменты, набросали начальную архитектуру. По согласованию с заказчиком добавили несколько новых историй.
Story points есть, как оценить примерные затраты? Выбрали 5 user stories, каждый индивидуально оценил в днях. Посчитали, сколько стоит средний story point. Сказали заказчику, предварительно объяснив, что это достаточно примерная оценка. Его устраивает. Команду тоже.
Как оценивать задачи в спринте? Решили использовать инженерные часы. В коэффициент ушли тесты, code review, исправление ошибок, стандартный оптимизм команды, перерывы. Для начала взяли коэффициент 2 (т.е. 4 инженерных часа = 8 реальных).
На основе velocity (которая в story points) выбираем историй немного больше, чем мы обычно успеваем сделать за спринт. Каждую историю сначала разбиваем на задачи. Когда все истории разбиты (и уже более-менее понятно, что и как делать), начинается непосредственно оценка. Как обычно, используется poker planning. Если оценки сильно отличаются, то те, кто положил самую маленькую и самую большую оценку, рассказывают, какие подводные камни или очень простые решения они видят. После этого проводится еще один раунд poker planning. Как правило, третьего раунда нет, так как уже на втором раунде оценки в целом одинаковы.
Все, для каждой задачи есть оценка. Считаем, сколько всего нужно инженерных часов для каждой истории. Считаем, сколько инженерных часов мы успеем сделать в этом спринте: количество «производительных» дней (количество дней в спринте – время на планирование – время на рефакторинг (если рефакторинг не в коэффициенте) – время на подготовку билда) * 8 / коэффициент. Добавляем истории (в порядке приоритета), пока суммарная оценка меньше, чем общее количество инженерных часов для этого спринта.
Истории выбраны, команда готова их сделать за этот спринт. Делаем.
После каждого спринта пересчитывается velocity в story points, и соответственно, общая продолжительность проекта (так как мы знаем, сколько еще story points нам надо сделать, зная скорость, можем узнать время). Через некоторое время заметили, что скорость увеличивается. Приятно. Заказчик доволен.
После нескольких попыток изменять базовый коэффициент для инженерных часов стало понятно, что особого смысла это не имеет – если не успели сделать запланированное в предыдущем спринте, то в следующем команда автоматически делала более пессимистические оценки. А если при этом еще и коэффициент становится более пессимистичным, то попадаем в другую крайность. Поэтому зафиксировали 2 как значение для коэффициента.
Закончили проект успешно, даже немного быстрее, чем изначально планировали. Команда довольна. Заказчик в восторге – уже работает над требованиями для нового проекта, который планирует отдать нам.
Проект «Fixed»
Небольшое приложение. Из особенностей – заказчик хочет и изменять требования, и иметь fixed price проект. Уже есть история успешной работы с этим заказчиком, так что обговариваются правила – небольшие изменения делаем сразу, большие – убираем какое-то другое равноценное по затратам на реализацию требование.
Заказчик не готов писать user stories (хотя уже имеет опыт работы со Scrum проектами). Ок, PM пишет user stories и согласовывает с заказчиком.
Состав команды уже ясен, так что в оценке принимает участие вся команда. Решено использовать для оценки реальные дни. Для каждой истории дается 3 оценки – в лучшем случае, скорее всего, в худшем случае. Оценили. PM какими-то магическими манипуляциями (что загадочное делал с рисками, какими-то коэффициентами для процесса и не мог это внятно объяснить) выдает итоговую оценку. После небольшого обдумывания команда соглашается, что она готова сделать проект за это время.
Согласования с заказчиком. Контракт подписан.
Для оценки спринта использовали инженерные часы и poker planning.
Как впоследствии оказалось, PM не зря шаманил с рисками. Но в итоге проект сделали вовремя и в соответствии с требованиями заказчика (требования менялись, но благодаря начальному соглашению о правилах изменения, общее время оставалось почти неизменным).
Проект «Конь и вакуум»
Государственный тендер. Сколько вам надо, чтобы решить нашу задачу, которую мы еще не знаем? Требования, чтобы оценить проект? Нет, ТЗ только после подписания контракта. Да, и мы еще хотим иметь возможность вносить изменения.
Приехали.
Анализируем. Вроде представляем область проекта. Есть люди. Но уж очень рискованные условия. Наводим справки. Ага, по отзывам, со стороны госорганизации соображающий человек, представляющий всю сложность ситуации. После беседы с ним выясняется, что они согласны изначально ограничить объем изменений какими-то рамками и правилами. Заодно выясняется немного больше о самом проекте.
Много думаем. Решили взяться.
User stories какие-то уж очень большие и расплывчатые (понятно, что их писать пришлось самим). Оценку решили делать в неделях, так как требования все еще не до конца понятны, Полную команду не собирали – только потенциальные PM и tech lead. Использовали подход 3 оценок. Оценили. Опять загадочные манипуляции PM’a с цифрами. В этот раз итоговая оценка больше отличается от простой суммы оценок. Начали подозревать, что за действиями PM’a что-то есть.
Выиграли тендер. Собрали команду.
Для спринта использовали стандартную схему (инженерные часы + poker planning).
В итоге проект сделали. Анализируя, поняли, что если бы изначально попытались все определить, то были бы большие проблемы – несмотря на то, что человек со стороны госорганизации был очень толковым, требования все-таки менялись. Но мы-то были готовы к изменениям.
Все довольны.
Inspect and adapt
Как видите, для разных типов проектов (и команд) подходят разные способы и единциы оценки. Поэтому не стоит зацикливаться на одном способе только потому, что он хорошо работал на двух предыдущих проектах. Анализируйте и выбирайте наиболее подходящий вариант для каждого конкретного случая.
