Перевод статьи, в которой описан взгляд на то, почему программисты ошибаются в своих оценках, с позиции руководителя проектов (РП), и советы разработчикам, как улучшить свои навыки в оценке времени на реализацию задач. (Ранее перевод был опубликован в блоге ГК "Компьютерный аудит").
Один опытный руководитель проектов, с которым я работал, пожаловался, что для того, чтобы получить достоверное значение трудозатрат по задаче, ему приходится оценку, сделанную программистом, умножать на число Пи, а затем переводить полученное число в величину следующего порядка. Таким вот образом 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 человеко-часов декомпозицию можно сделать и в уме, но даже опытным разработчикам необходимо разбивать большие задачи на меньшие подзадачи.
Также необходимо понимать, что опыт в программировании не то же самое, что и опыт в оценке трудозатрат. Разработчики, которые не включены в процесс оценки, так и не научатся давать хорошую оценку. Также если фактическое время никогда не измеряется и не сравнивается с заранее сделанной оценкой, никогда не будет получено обратной связи, которая научит вас лучше оценивать задачи.
Каждому программисту требуются навыки оценки трудозатрат. Чтобы подготовиться к этому, каждый раз, когда вам поручают выполнение задачи, сначала определитесь с тем, когда можно считать задачу завершенной и какие действия надо выполнить, чтобы довести ее до состояния завершенности. После этого прикиньте время, которое вам потребуется на выполнение этих действий. Выполнив задачу, посчитайте фактически потраченное время и сравните с вашей оценкой, а также сравните ваш план действий с тем, что вам пришлось делать по факту. Это улучшит как ваше понимание деталей, требующихся для выполнения задачи, равно как и навыки оценки задачи.
