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

Сбор данных

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

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

Там же в экселе рассчитывается и среднее время выполнения одной задачи для всей команды (или нескольких команд, или всей компании). Например, в моей команде из семи человек, среднее время на решение одной задачи составляет 14 часов.

Тут есть небольшой вопрос: что считать сделанными за месяц задачами? Ведь есть задания, которые были начаты сотрудником в прошлом (или позапрошлом) месяце и закончены в этом. Немного подумав, я решил, что буду учитывать все задачи, назначенные на сотрудника, которые были переведены в статус Closed в этом месяце (Redmine, которым мы пользуемся для управления задачами, позволяет собрать такую статистику). Это логично, потому что в общей статистике по всем месяцам, которая собственно и нужна, конкретный месяц завершения неважен.

Применение

Для оценки времени, требуемого на разработку функциональности, она должна быть разбита на задачи. Задачи должны быть типичного для команды размера. И тогда всё просто:

T = N * A * k / D,
где:
T — оценка в часах;
N — количество задач;
А — среднее для команды время выполнения одной задачи в часах;
k — коэффициент неопределенности;
D — количество разработчиков в команде.

Для чего нужен k — коэффициент неопределенности? Несмотря на то, что A включает в себя типичные незначительные риски на проекте (болезни, отгулы, низкая работоспособность вследствие плохого самочувствия и пр.), оно не учитывает некоторые вещи, которые влияют на общее время выполнения списка задач. Например, отвлечение людей на задачи не связанные с рассматриваемой функциональностью (багфикс старой функциональности, срочные задачи). Или, например, добавление новых задач в функциональность: что-то недодумали или пришлось декомпозировать внезапно крупную задачу на несколько поменьше (по моим замерам, у нас на проекте добавляется 30% — 50% новых задач в ходе работы над функциональностью). Изначально я взял k = 1 + 0,4(новые задачи) + 0,2(переключения) = 1,6. Но по мере накопления данных уменьшил его до 1,5.

Как это работает в жизни? Недавно нам на проекте надо было сделать новую фичу. Моя команда была занята, поэтому директор предложил взять соседнюю со словами «эти тебе за пару недель всё напишут». Я был менее оптимистичен и считал, что потребуется не меньше месяца. После того как фича была разбита на задачи, я на всякий случай решил сделать оценку. Так как у меня не было параметров для новой команды, то я просто взял те, что использую для своей и получил, что ребята закончат за 2,5 месяца. Это уже не так радужно как две недели или даже месяц. В итоге всё было готово за 3 месяца. Кстати, исходя из позадачной оценки самих разработчиков, выходило, что им потребуется около 1,5 месяцев.

Итоги

В качестве итогов приведу достоинства и ограничения описанного метода.

Достоинства:

• Прост и быстр — легко собирать статистику, просто считать оценку. Можно даже приноровиться оценивать в уме.
• Учитывает типичные мелкие риски: болезни, отгулы, переключение на срочные задачи и т.п.
• Позволяет оценивать объемы работ ещё до того как разработчики приступили к оценке.
• Если есть статистика отдельно по каждому человеку, то можно рассчитывать оценку для любых команд, составленных из этих разработчиков.

Ограничения:

• Необходим сбор статистики, иначе ничего оценить не получится.
• Необходим подбор коэффициента неопределённости — k.
• Собираемые в статистику задачи и оцениваемые задачи должны формироваться одинаковым образом. Например, если один менеджер предпочитает создавать задачи не более чем на 8 часов (если больше, то разбивать на более мелкие), а для другого недельные задачи это норма, то их задачи нельзя объединять в оценке и статистике.
• Сложные и легкие задачи должны распределяться между разработчиками более менее равномерно. Если одному человеку постоянно достаются задачи длительностью 1 час, а второму — 8 часов, то возникают перекосы в их показателях. Кстати, этим можно пользоваться, выявляя людей, которых вы недогружаете или перегружаете сложными задачами.

Автор:

Источник