3 вопроса, которые улучшат ваши эстимейты
<test> Подойдите к своему программисту с задачей: нужно выровнять грунт на площадке 10 на 10 метров. Нужно убрать верхний слой – опустить на 1 м. И уточните у него, за сколько часов он сможет выполнить эту задачу.
Среднестатистический ответ, который слышал я – 2-3 дня 
.
Правильный ответ: отталкиваясь от нормы профессиональных землекопов 100 кубических метров земли можно убрать за 85-130 часов, что равно 2-3 рабочих человеко-недели. Программист без навыков делал бы это очень долго. </test>
Если разобраться в причинах, то видим:
- Явная недооценка задачи, потому что она новая.
- Недооценка задачи, так как она крупная и из-за масштаба кажется, что вначале будет сложнее, а потом я «разгонюсь».
- Предположение, что уже все готово и можно приступать к работе.
Давайте теперь разбирать, как это применять и главное как этого ИЗБЕЖАТЬ в наших проектах…
Новизна задачи
ИТ – отрасль настолько динамична, что в ней постоянно решаются новые задачи. Типовые задачи решены уже с помощью библиотек и шаблонов. И когда приходит заказчик, то, вероятнее всего, ему надо сделать то, чего еще нет. А это значит, что всегда есть что-то новое. Среднестатистический программист считает, что для того, чтобы разобраться в новом ему нужно «почитать форумы и книжки», опытный программист считает, что необходимо почитать и попробовать что-то сделать.
Вывод: перед тем, как выдать эстимейт убедитесь, что в вашей команде есть кто-то, кто понимает, о чем идет речь. Задайте вопрос: «Сейчас ты можешь объяснить команде джуниоров, что им следует делать? Какие классы/методы/стили писать?». Если получаем ответ «Ну надо посмотреть спеку…», «пусть они прочитают об этом…» и похожие по невнятности фразы, то есть симптом недопонимания, который в оценке исправляется следующим: добавляйте больше времени на реализацию и «битвы с граблями» или разносите этап эстимирования на 2 фазы: обучение/прототипирование и реализация.
Проблема Масштаба (с большой буквы, так как масштаб большой :))
200 деталей "до" и 80 000 "после"
Большая задача всегда кажется проще, чем набор деталей. Примером может послужить автомобиль, снаружи все просто и понятно, многим известен принцип и ясны все детали взаимодействия узлов: двигатель, коробка передач, тормоза, рулевое управление и т.д. Так вот в среднестатистическом седане их 14 000 – 20 000, а в болиде формулы 1 их 80 000. Каждая требует проверки, подгонки и главное, чтобы вместе они работали!
Вывод: всегда необходимо «разбить» задачу на более мелкие части (кстати, в SCRUM методологии это одно из важных условий). Все время, которое есть у вас на оценку, должно быть потрачено на «измельчение». Каждый уровень измельчения сначала породит кучу вопросов, потом даст дополнительную информацию, а потом, как результат, получится более детальный эстимейт. Хороший вопрос «Можешь ли ты ответить, какой класс будет использоваться для «отправки сообщения в другую систему с рабочего места кассира» (подставить свое) и как это пройдет через всю систему?» Обязательно при этом связать вопрос с конкретными действиями, которые пользователи ожидают от системы (подчеркиваю поль-зо-ва-те-ли!, а не программист)
Предположение готовности
Как часто программисты ошибаются только потому, что считают, что все готово к работе. Клиент – сидит и ждет его вопроса, окружение – уже настроено и все возможные утилиты и их комбинации уже готовы, требования уже написаны, а поэтому будем писать «по-правильному» и т.д. В реальности все происходит намного «реальнее» (хотел сказать «хуже», да рука дрогнула :)). Нет ни окружения, ни ответов от клиента, ни требований, ни даже устройства (которое позарез нужно для старта разработки).
Вывод: При составлении эстимейта уточните у программиста/тестировщика о том, что же нужно для того, чтобы начать работу немедленно. Вопрос: «Можешь ли ты приступить к написанию кода прямо сейчас?» обычно породит массу неуверенных ответов a-la «Ну сейчас скачаю билд», «Надо посмотреть где лежат требования», «А я не могу подключиться к клиентскому серверу». Задавая такой простой вопрос, менеджер сможет узнать невероятное количество мелочей, которые влияют на график (даже не на трудозатраты) проекта.
Если же у вас есть идеи вопросов, которые могут еще улучшить качество эстимейтов, то комментарии работают 
Было бы еще полезно упомянуть Planning Poker, как очень хороший помощник эстимейтам. Он помогает убрать погрешность, поскольку вероятность того, что ошибутся все сразу, да еще и в одинаковую сторону, все таки не большая.
Как показывает практика, и это абсолютно нормально, даже опытные люди при игре в Planning Poker выдают иногда эстимейты (числа), не вписывающиеся в понимание других. При втором раунде они исправляются. Но суть в том, что любой может ошибаться, и это нормально
(это к вопросу о том, что даже супер-специалист может облажаться в эстимейтах. И этого нет в этих 3 вопросах)
И, кстати, Planning Poker при грамотном использовании позволяет избежать проблемы Масштаба (иногда детализировать все не целесообразно, либо просто на это нет времени). Нужно только подключить математику, теорию вероятности и статистику. И тогда даже при наличии 2-3 человек могут получиться вполне жизнеспособные эстимейты.
to Дмитрий Марков
Кто бы спорил о том, что Planning Poker это классная штука. Эту методику нужно использовать, так как она даст возможность нескольким людям независимо оценить задачу.
Но “покер” не исключает тех вопросов, о которых я писал:
Но что-то мне подсказывает, что во время пленнинг покера тоже часто забывают о том, что нужна подготовка (вопрос “Готов ли ты начать прямо сейчас?”). Да и я плохо помню, когда во время пленинг-покера кто-то спрашивал “а как эта фича будет выполнять функцию Х для бухгалтера?”
И еще, теория вероятности и статистика – далеко выходит за пределы этих простых вопросов
За мат.статистикой надо иди к Максу Дорофееву
Мы при выставлении оценок обычно применяем такую “формулу”:
Время = (Работа * Сложность * Неопределенность) * FF
Работа – это время, которое, по оценке разрабочиков, нужно для того, чтобы все сделать, когда четко понятно, чего и как делать.
Если модуль, в котором это надо приделать, сам по себе довольно сложный, либо функционал сложный – оценка немного увеличивается (коэф. “Сложность”), поскольку ввиду повышенной сложности могут возникать непредвиденные неучтенные моменты.
Если требования размыты либо команде нужно вносить изменения в модуль, в котором никто не шарит – срабатывает коэффициент “Неопределенность”, т.е. оценка снова повышается.
FF – Фокус-Фактор – коэффициент, который принимается для всех задач текущей итерации, устанавливается на основе статистики прошлых итераций, и покрывает:
– степень оптимистичности команды
– время, которое нужно на проверку выполнения задачи, ревизию кода, и т.д. (обычно разработчики забывают учесть в переменной Работа)
– время на исправление замечаний от TestTeam
– и т.д.
to Андрей
Спасибо за отличный пример из вашего опыта!
Приведенная формула просто классная. Она дает много степеней свободы при составлении эстимейта и при пересмотре хотя бы одного параметра, дает сразу же новую цифру. Фокус-фактор – это абсолютно правильный «поправочный коэффициент». На моем текущем проекте QA Lead обладает «7 чувством» (это даже не шестое) по определению фокус-фактора для группы. Спорить при этом почти бессмысленно (статистика 100% в его пользу
).
С другой стороны есть у меня пара замечаний, когда формула не будет столь эффективной. Во-первых, такая методика хороша для более-менее больших задач. Для «мелочи» определение коэффициентов займет больше времени, чем сам эстимейт. И второй, но более мощный аргумент – это то, что статистическое (историческое) значение каждого из коэффициентов, в особенности FF, сильно зависит от стабильности команды. Если команда нестабильна, то и значение фокус-фактора может варьироваться в РАЗЫ. Т.е. мы опять угадываем
Да, и еще одна «the dark side». Обычно Клиенты очень настороженно относятся к эстимейтам с «магическими коэффициентами». Если у вас недостаточно доверительные отношения с клиентом (см. OaaS страничку), то очень сложно объяснить им, что коэффициент отражает суть разработки, а не желание «напарить» его на довольно крупную сумму. IMHO, Клиенты больше склонны к концепции использования буфера, чем «множителей».
Ради интереса, прежде чем читать дальше, подсчитал свой эстимейт для землекопной задачи. Получилось от 56 до 278 часов. Вывод: может я бы в эстимейт и уложился, но гда-то ближе к максимальному сроку
Поздравляю. Доля оптимизма у вас есть, но и опыт в оценке собственных сил тоже чувствуется. 56 часов как минимальная оценка выглядит очень хорошо!