Эстимирование – один из наиболее болезненных процессов. Каждый хоть раз в своей жизни ошибался с эстимейтом. И хорошо, если только раз.
Существует огромное количество рекомендаций, как надо осуществлять эстимирование проекта, задач. Рассмотрим наиболее часто используемые подходы.
1. Экспертная оценка. Для эстимирования необходимо привлекать экспертов в данной области, имеющих опыт в выполнении оценок. Если привлекается несколько экспертов, то для вычисления конечного результата можно использовать один из ниже приведенных способов получения единого результата.
2. Оценка по аналогам (сверху вниз, Top-Down estimation). Основывается на использовании исторических данных. В качестве основы берутся те значения, которые были получены ранее при эстимирвании аналогичных проектов и вносятся коррективы с учетом специфики эстимируемого проекта или задачи.
3. Параметрическая оценка. Базируется на использовании разработанных алгоритмов и математических моделей для вычисления стоимости проекта и сроков его выполнения. В качестве исходных данных используются статические, исторические данные, различные метрики. Использование модели позволяет проанализировать влияние того или иного параметра на стоимость, бюджет и длительность.
4. Оценка по трем точкам. В качестве исходных данных для получения финального (Ф) эстимейта используются оптимистичные (О), пессимистичные (П) и наиболее вероятные (В) эстимейты. Далее на выбор можно взять одну из двух формул: Ф=(O+В+П)/3 или же Ф=(O+4*В+П)/6. Данный метод целесообразно использовать тогда, когда информация об исторических данных отсутствует полностью.
5. Оценка «Снизу вверх» (Bottom-Up estimation). Если проект или задача достаточно объемны, то для получения более точного эстимейта выполняется декомпозиция задач (декомпозицию желательно производить до тех пор, пока продолжительность одной задачи не будет превышать 8 часов или не будет понятна для эстимирования исполнителям).
6. Planning Poker. Самый популярный на данный момент способ эстимирования задач. При планировании спринта каждый из членов команды выбирает карту с наиболее подходящей оценкой. Участники, выставившие наивысший и наинизший бал, приводят свои аргументы после первого тура. Далее происходит повторное голосование. Цель – прийти к общему мнению. В среднем, за час удается проэстимировать 4-10 задач.
Более подробно процесс рассмотрим в дальнейших статьях, а также детально поговорим о Story Points (единица измерения, позволяющая выразить оценку общих усилий, которые потребуются для реализации того или иного функционала).
7. Bucket System. Используются емкости (ведра), на которых написаны цифры (ряд Фибоначчи). Все таски, которые надо обсудить, выписываются на отдельные карточки. Команда выбирает 3-5 карточек рандомно и обсуждает их. Это позволяет задать ориентиры для дальнейшего движения. После открытого обсуждения и оценки карточки помещаются в соответствующие ведра.
Далее все оставшиеся карточки делятся между всеми участниками поровну и каждый уже свою карточку кладет в то ведро, которое считает нужным. Если решение кто-то самостоятельно принять не может, то передает свою карточку другому участнику (техлиду, например). Данный метод позволяет за час обработать около 50 карточек (при численности команды в 7 человек).
8. Middle-developer estimation. Достаточно часто в эстимировании ориентируются на те часы, которые выставляет Middle-developer. Поскольку рэйты и продуктивность джуна, мидла и синьера существенно отличаются, то фиксируют либо среднее между джуном и синьером или же просто берут часы мидла.
Мы рассмотрели наиболее часто используемые способы эстимирования. В интернете существуют сотни различных вариантов (Ordering Rule, T-Shirt Sizing, Dot-Voting и т.д.) эстимирования, которые в одной статье охватить просто невозможно.
После эстимирования менеджерам проектов обязательно стоит обратить внимание на ряд моментов, которые могут увеличить существенно эстимейт. Команда, как правило, выставляет эстимейт по девелопменту. Если задачи декомпозированы, то дизайн и верстка могут идти отдельными задачами, а вот про тестирование, менеджмент, code review, написание тестов, документацию, риски иногда забывают.
А это достаточно объемные, с точки зрения трудоемкости, процессы. Менеджмент, например, может занимать от 5% до 50%, тестирование – от 10% до 30%, риски могут закладываться от 10% до 20% и т.д. Об этом не стоит забывать. Да и команду стоит сразу предупреждать, чтоб эстимировали с учетом сode review, а так же с учетом написания тестов.
Более подробную информацию по данному вопросу вы сможете получить у нас, пройдя наши курсы (ShBP Academy).