Сбор данных
В конце каждого месяца я делаю простую операцию для каждого разработчика: сохраняю в экселе количество рабочих часов в месяце (производственный календарь в помощь) и число сделанных человеком за месяц задач.
В эксель файле сразу рассчитывается среднее количество рабочих часов за которое сотрудник делает одну задачу. Среднее рассчитывается как за весь период наблюдений, так и за конкретный месяц, чтобы можно было смотреть на динамику.
Там же в экселе рассчитывается и среднее время выполнения одной задачи для всей команды (или нескольких команд, или всей компании). Например, в моей команде из семи человек, среднее время на решение одной задачи составляет 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 часов, то возникают перекосы в их показателях. Кстати, этим можно пользоваться, выявляя людей, которых вы недогружаете или перегружаете сложными задачами.
Комментарии (8)
EndUser
30.11.2015 15:00А почему у вас девять женщин выносят ребёнка на 1 месяц?
Ещё Перельман в Занимательной физике писал, что 7 лошадей в упряжке — это максимальная доступная мощность конной тяги. Добавление 8-й добавляет мизер, 9-й практически не влияет на силу буксировки. Потому, что накапливается рассогласованность усилий.
У людей по Паркинсону максимально эффективная численность группы ? 3.14, далее опять резко растут потери на согласование.
curiouspm
30.11.2015 15:33Ну так и я пишу, что у меня 7
лошадей в упряжкеразработчиков в команде :) На самом деле, не обязательно вся команда проекта работает над одной фичей. Команда проекта может разбиваться на более мелкие команды для работы над разными функциональностями.
Но возможна ситуация, когда все пилят одну фичу, тогда команда разбивается на группы, выполняющие какие-то относительно независимые части одной фичи. Например, фронтэнд, бэкэнд и какие-нибудь полезные сервисы. И тогда необходимо организовать взаимодействие не всех со всеми, а только между группами и внутри групп.
velvetcat
30.11.2015 16:32> T = N * A * k / D
> если один менеджер предпочитает создавать задачи не более чем на 8 часов
> Если одному человеку постоянно достаются задачи длительностью 1 час, а второму — 8 часов
Вы обещали рассказать, как оценивать задачи. Рассказали же, как на основе готовых достаточно надежных оценок посчитать итоговые трудозатраты. Это же простая арифметика * фактор риска, специфичный для команды/человека/окружения, о чем тут вообще можно рассуждать?curiouspm
30.11.2015 19:37> на основе готовых достаточно надежных оценок
Я нигде ничего не говорил про оценки. Требуется просто более менее одинаково подходить к разбиению фичи на задачи. Например, если этим занимается только один человек, то этого достаточно (и не важно как он это делает). У меня, скажем, итоговое время выполнения задач варьируется от 0,5 часов до 20 часов.
> Это же простая арифметика
Я действительно рад, если для Вас всё это очевидно. Мне же потребовалось некоторое время, чтобы осознать и сформулировать описанный подход. Поэтому я и решил написать статью — может кому-то поможет.
> о чем тут вообще можно рассуждать?
Долгое время я склонялся к тому, что адекватно задачи может оценивать только разработчик, который будет их делать. Однако оказалось, что с не меньшей точностью и гораздо быстрее я могу давать оценку сам на основе накопленной статистики. На всякий случай: разработчики у меня по-прежнему оценивают задачи.
Arbalet
01.12.2015 17:45Как по мне то «оценивать задачи без помощи разработчиков» у вас не получилось, зато получилось примерно посчитать время выполнения определённого количества уже оценённых задач.
curiouspm
01.12.2015 22:121. Я оцениваю время на выполнение набора задач без привлечения к этому процессу разработчиков (то есть, по сути, оцениваю задачи без помощи разработчиков). Сколько при этом будет занимать каждая отдельная задача мне мало интересно.
2. Подскажите, где в тексте Вы нашли уже оценённые задачи? Мне правда интересно.velvetcat
03.12.2015 16:00где в тексте Вы нашли уже оценённые задачи
Везде, где Вы говорите про то, что задачи должны быть одного размера и тому подобное.
Неужели Вы не видите, что оперируете готовыми оценками, а статья повествует о том, как правильно суммировать трудозатраты? Это, безусловно, дело нужное и важное. Просто заголовок обещает совсем другое.
Akuji_bwn
В Scrum для этих целей обычно применяется список ранее оцененных и завершенных user stories, который используют сами разработчики в качестве «референсного» для быстрой оценки новых историй. Если взять наиболее примечательные, уже закрытые, истории, разбить их по категориям или по оценке; регулярно поддерживать актуальность списка, пополняя его более «свежими» исторями, можно с достаточной точностью оценивать новые задачи без участия разработчиков.