Один опытный руководитель проектов, с которым я работал, пожаловался, что для того, чтобы получить достоверное значение трудозатрат по задаче, ему приходится оценку, сделанную программистом, умножать на число Пи, а затем переводить полученное число в величину следующего порядка. Таким вот образом 1 человеко-день превращается в 3,14 человеко-недели. Горький опыт научил его, что программисты - не самые лучшие оценщики.
Чтобы получить более точное значение оценки трудозатрат и уменьшить ее погрешность, я создал таблицу соответствия оценок программистов и соответствующих правдоподобных оценок.
|
Оценка |
Как думает программист |
Что программист забывает |
Реальное время |
| 30 секунд | Надо изменить пару строк. Я точно знаю, что надо написать и где. На то, чтобы написать эти пару строк, надо секунд 30. | Время для запуска компьютера, рабочего окружения вцелом, время на нахождение нужного участка кода. А также время на сборку, тестирование, помещение изменений в репозитарий и на документирование этих изменений. | 1 час |
| 5 минут | Это простая задача, мне надо всего лишь погуглить, чтобы уточнить синтаксис - и готово! | Довольно редко удается найти необходимую информацию с первой попытки. И даже если она найдена, может потребоваться ее подкорректировать под себя. Плюс, время для сборки, тестирования и т.п. | 2 часа |
| 1 час | Я знаю, как это сделать, но надо написать немного кода, поэтому решение займет времени побольше. | Одного часа слишком мало, чтобы застраховаться от непредвиденных проблем. Что-то всегда идет не так. | 4 часа |
| 4 часа | Надо будет написать некоторое количество кода, и я примерно знаю, что именно и как. Я знаю, что модуль Wizzabanga нашего стандартного фреймворка имеет необходимую функцию, но мне надо пошерстить документацию, чтобы уточнить, как ее вызывать. | Пожалуй, это единственный случай реалистичной оценки. Она достаточно большая, чтобы иметь некоторый запас на случай неожиданных проблем, а задача все еще достаточно мала, чтобы ее можно было прикинуть в уме все ее детали. | 4 часа |
| 8 часов | Сначала я должен зарефакторить класс Balunga, сделав из него два, а затем добавить вызов кода модуля Wizzabanga и, наконец, добавить новые поля в пользовательском интерфейсе. | В разных частях системы есть множество зависимостей от класса Balunga. И поправить придется примерно 40 различных файлов. Новые поля в интерфейсе надо также добавить и в базу данных. 8- часовая задача слишком большая, чтобы полностью прикинуть все ее детали в уме. Потребуется гораздо больше действий, чем думал программист, когда давал оценку. | 12 - 16 часов |
| 2 дня | Это действительно много кода. Мне придется добавить несколько новых таблиц в базу данных, реализовать для них пользовательский интерфейс, потом еще и логику для чтения и записи данных в эти таблицы. | 2 дня работы - слишком большой объем для обзора для большинства разработчиков. Гарантированно найдутся вещи, которые он пропустит. Не просто какие-то небольшие вещи, а весьма значимые куски необходимой функциональности будут упущены в процессе выполнения оценки. | 5 дней |
|
1 неделя |
Упс, это ОГРОМНАЯ задача. И понятия не имею, как ее делать, но и сказать, что я не знаю, я не могу. Ну недели-то точно будет достаточно, я надеюсь... Очень надеюсь. Но и больше времени спросить я не могу, потому что тогда они подумают, что я недостаточно компетентен... |
Такие задачи слишком велики для понимания большинством программистов. Подобные задачи должны быть переданы обратно архитектору, который должен помочь разбить их на меньшие и указать направление, как они должны быть решены. Архитектор может найти простой способ, как выполнить задачу, или же он поймет, что задача потребует больше работы, чем ожидалось. |
2 - 20 дней |
Оценивать задачи сложно. Каждый программист в определенном интервале дает реалистичные оценки. Задачи до левой границы этого интервала недооцениваются - программист забывает про накладные расходы (сборка, тестирование, помещение изменений в репозитарий и подобные задачи). Задачи за правой границей интервала слишком большие, чтобы их можно было прикинуть в уме.
Для начинающих разработчиков этот интервал и вообще может не существовать. Они упускают из виду накладные расходы, а любая нетривиальная задача - слишком большая для них для обзора. Я бы сказал, что опытные разработчики точны в диапазоне задач с трудоемкостью от 0,5 до 24 человеко-часов. Задачи со сложностью, большей 24 человеко-часов требуют декомпозиции. Для задач трудоемкостью до 60 человеко-часов декомпозицию можно сделать и в уме, но даже опытным разработчикам необходимо разбивать большие задачи на меньшие подзадачи.
Также необходимо понимать, что опыт в программировании не то же самое, что и опыт в оценке трудозатрат. Разработчики, которые не включены в процесс оценки, так и не научатся давать хорошую оценку. Также если фактическое время никогда не измеряется и не сравнивается с заранее сделанной оценкой, никогда не будет получено обратной связи, которая научит вас лучше оценивать задачи.
Оригинал статьи можно найти по ссылке: Anders Abel, Programmer Time Translation Cheatsheet -or- Why Programmers Are Bad at Estimating Times (ссылка ведет на Веб-архив, т.к. на оригилальном сайте DZone после его редизайна статья была потеряна)
