3 вопроса, которые улучшат ваши эстимейты

Estimates enhancement<test> Подойдите к своему программисту с задачей: нужно выровнять грунт на площадке 10 на 10 метров. Нужно убрать верхний слой – опустить на 1 м. И уточните у него, за сколько часов он сможет выполнить эту задачу.

Среднестатистический ответ, который слышал я – 2-3 дня :roll: .

Правильный ответ: отталкиваясь от нормы профессиональных землекопов 100 кубических метров земли можно убрать за 85-130 часов, что равно 2-3 рабочих человеко-недели. Программист без навыков делал бы это очень долго. </test>

Если разобраться в причинах, то видим:

  1. Явная недооценка задачи, потому что она новая.
  2. Недооценка задачи, так как она крупная и из-за масштаба кажется, что вначале будет сложнее, а потом я «разгонюсь».
  3. Предположение, что уже все готово и можно приступать к работе.

Давайте теперь разбирать, как это применять и главное как этого ИЗБЕЖАТЬ в наших проектах…

Новизна задачи

ИТ – отрасль настолько динамична, что в ней постоянно решаются новые задачи. Типовые задачи решены уже с помощью библиотек и шаблонов. И когда приходит заказчик, то, вероятнее всего, ему надо сделать то, чего еще нет. А это значит, что всегда есть что-то новое. Среднестатистический программист считает, что для того, чтобы разобраться в новом ему нужно «почитать форумы и книжки», опытный программист считает, что необходимо почитать и попробовать что-то сделать.

Вывод: перед тем, как выдать эстимейт убедитесь, что в вашей команде есть кто-то, кто понимает, о чем идет речь. Задайте вопрос: «Сейчас ты можешь объяснить команде джуниоров, что им следует делать? Какие классы/методы/стили писать?». Если получаем ответ «Ну надо посмотреть спеку…», «пусть они прочитают об этом…» и похожие по невнятности фразы, то есть симптом недопонимания, который в оценке исправляется следующим:  добавляйте больше времени на реализацию и «битвы с граблями» или разносите этап эстимирования на 2 фазы: обучение/прототипирование и реализация.

Проблема Масштаба (с большой буквы, так как масштаб большой :))

200 деталей "до" и 80 000 "после"

200 деталей "до" и 80 000 "после"

Большая задача всегда кажется проще, чем набор деталей. Примером может послужить автомобиль, снаружи все просто и понятно, многим известен принцип и ясны все детали взаимодействия узлов: двигатель, коробка передач, тормоза, рулевое управление и т.д. Так вот в среднестатистическом седане их 14 000 – 20 000, а в болиде формулы 1 их 80 000. Каждая требует проверки, подгонки и главное, чтобы вместе они работали!

Вывод: всегда необходимо «разбить» задачу на более мелкие части (кстати, в SCRUM методологии это одно из важных условий). Все время, которое есть у вас на оценку, должно быть потрачено на «измельчение». Каждый уровень измельчения сначала породит кучу вопросов, потом даст дополнительную информацию, а потом, как результат, получится более детальный эстимейт. Хороший вопрос «Можешь ли ты ответить, какой класс будет использоваться для «отправки сообщения в другую систему с рабочего места кассира» (подставить свое) и как это пройдет через всю систему?» Обязательно при этом связать вопрос с конкретными действиями, которые пользователи ожидают от системы (подчеркиваю поль-зо-ва-те-ли!, а не программист)

Предположение готовности

Как часто программисты ошибаются только потому, что считают, что все готово к работе. Клиент – сидит и ждет его вопроса, окружение – уже настроено и все возможные утилиты и их комбинации уже готовы, требования уже написаны, а поэтому будем писать «по-правильному» и т.д. В реальности все происходит намного «реальнее» (хотел сказать «хуже», да рука дрогнула :)). Нет ни окружения, ни ответов от клиента, ни требований, ни даже устройства (которое позарез нужно для старта разработки).

Вывод: При составлении эстимейта уточните у программиста/тестировщика о том, что же нужно для того, чтобы начать работу немедленно. Вопрос: «Можешь ли ты приступить к написанию кода прямо сейчас?» обычно породит массу неуверенных ответов a-la «Ну сейчас скачаю билд», «Надо посмотреть где лежат требования», «А я не могу подключиться к клиентскому серверу». Задавая такой простой вопрос, менеджер сможет узнать невероятное количество мелочей, которые влияют на график (даже не на трудозатраты) проекта.

Если же у вас есть идеи вопросов, которые могут еще улучшить качество эстимейтов, то комментарии работают :)

Sep 26th, 2010
  1. Дмитрий Марков
    Sep 30th, 2010 at 19:46 | #1

    Было бы еще полезно упомянуть Planning Poker, как очень хороший помощник эстимейтам. Он помогает убрать погрешность, поскольку вероятность того, что ошибутся все сразу, да еще и в одинаковую сторону, все таки не большая.
    Как показывает практика, и это абсолютно нормально, даже опытные люди при игре в Planning Poker выдают иногда эстимейты (числа), не вписывающиеся в понимание других. При втором раунде они исправляются. Но суть в том, что любой может ошибаться, и это нормально :)
    (это к вопросу о том, что даже супер-специалист может облажаться в эстимейтах. И этого нет в этих 3 вопросах)

    И, кстати, Planning Poker при грамотном использовании позволяет избежать проблемы Масштаба (иногда детализировать все не целесообразно, либо просто на это нет времени). Нужно только подключить математику, теорию вероятности и статистику. И тогда даже при наличии 2-3 человек могут получиться вполне жизнеспособные эстимейты.

  2. Oct 1st, 2010 at 14:21 | #2

    to Дмитрий Марков

    Кто бы спорил о том, что Planning Poker это классная штука. Эту методику нужно использовать, так как она даст возможность нескольким людям независимо оценить задачу.

    Но “покер” не исключает тех вопросов, о которых я писал:

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

    И еще, теория вероятности и статистика – далеко выходит за пределы этих простых вопросов :) За мат.статистикой надо иди к Максу Дорофееву

  3. Андрей
    Oct 7th, 2010 at 11:15 | #3

    Мы при выставлении оценок обычно применяем такую “формулу”:

    Время = (Работа * Сложность * Неопределенность) * FF

    Работа – это время, которое, по оценке разрабочиков, нужно для того, чтобы все сделать, когда четко понятно, чего и как делать.

    Если модуль, в котором это надо приделать, сам по себе довольно сложный, либо функционал сложный – оценка немного увеличивается (коэф. “Сложность”), поскольку ввиду повышенной сложности могут возникать непредвиденные неучтенные моменты.

    Если требования размыты либо команде нужно вносить изменения в модуль, в котором никто не шарит – срабатывает коэффициент “Неопределенность”, т.е. оценка снова повышается.

    FF – Фокус-Фактор – коэффициент, который принимается для всех задач текущей итерации, устанавливается на основе статистики прошлых итераций, и покрывает:
    – степень оптимистичности команды
    – время, которое нужно на проверку выполнения задачи, ревизию кода, и т.д. (обычно разработчики забывают учесть в переменной Работа)
    – время на исправление замечаний от TestTeam
    – и т.д.

    • Oct 7th, 2010 at 22:25 | #4

      to Андрей
      Время = (Работа * Сложность * Неопределенность) * FF
      Спасибо за отличный пример из вашего опыта!

      Приведенная формула просто классная. Она дает много степеней свободы при составлении эстимейта и при пересмотре хотя бы одного параметра, дает сразу же новую цифру. Фокус-фактор – это абсолютно правильный «поправочный коэффициент». На моем текущем проекте QA Lead обладает «7 чувством» (это даже не шестое) по определению фокус-фактора для группы. Спорить при этом почти бессмысленно (статистика 100% в его пользу :) ).

      С другой стороны есть у меня пара замечаний, когда формула не будет столь эффективной. Во-первых, такая методика хороша для более-менее больших задач. Для «мелочи» определение коэффициентов займет больше времени, чем сам эстимейт. И второй, но более мощный аргумент – это то, что статистическое (историческое) значение каждого из коэффициентов, в особенности FF, сильно зависит от стабильности команды. Если команда нестабильна, то и значение фокус-фактора может варьироваться в РАЗЫ. Т.е. мы опять угадываем :)
      Да, и еще одна «the dark side». Обычно Клиенты очень настороженно относятся к эстимейтам с «магическими коэффициентами». Если у вас недостаточно доверительные отношения с клиентом (см. OaaS страничку), то очень сложно объяснить им, что коэффициент отражает суть разработки, а не желание «напарить» его на довольно крупную сумму. IMHO, Клиенты больше склонны к концепции использования буфера, чем «множителей».

  4. Ради интереса, прежде чем читать дальше, подсчитал свой эстимейт для землекопной задачи. Получилось от 56 до 278 часов. Вывод: может я бы в эстимейт и уложился, но гда-то ближе к максимальному сроку :)

  5. Oct 18th, 2010 at 14:20 | #6
    Владимир Железняк :

    Ради интереса, прежде чем читать дальше, подсчитал свой эстимейт для землекопной задачи. Получилось от 56 до 278 часов. Вывод: может я бы в эстимейт и уложился, но гда-то ближе к максимальному сроку :)

    Поздравляю. Доля оптимизма у вас есть, но и опыт в оценке собственных сил тоже чувствуется. 56 часов как минимальная оценка выглядит очень хорошо! :)

Leave a comment