Марат-блог
Услуги по продвижению и разработке сайта
Отправить заявку
Заказать обратный звонок

Спасибо, Ваша заявка принята.

В ближайшее время менеджер свяжется с Вами.

Главная Новости Почему программисты плохо оценивают время
Почему программисты плохо оценивают время
189
07 декабря 2015

Почему программисты плохо оценивают время

Перевод статьи, в которой описан взгляд на то, почему программисты ошибаются в своих оценках, с позиции руководителя проектов (РП), и советы разработчикам, как улучшить свои навыки в оценке времени на реализацию задач. (Ранее перевод был опубликован в блоге ГК "Компьютерный аудит").

Один опытный руководитель проектов, с которым я работал, пожаловался, что для того, чтобы получить достоверное значение трудозатрат по задаче, ему приходится оценку, сделанную программистом, умножать на число Пи, а затем переводить полученное число в величину следующего порядка. Таким вот образом 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 человеко-часов декомпозицию можно сделать и в уме, но даже опытным разработчикам необходимо разбивать большие задачи на меньшие подзадачи.

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

Каждому программисту требуются навыки оценки трудозатрат. Чтобы подготовиться к этому, каждый раз, когда вам поручают выполнение задачи, сначала определитесь с тем, когда можно считать задачу завершенной и какие действия надо выполнить, чтобы довести ее до состояния завершенности. После этого прикиньте время, которое вам потребуется на выполнение этих действий. Выполнив задачу, посчитайте фактически потраченное время и сравните с вашей оценкой, а также сравните ваш план действий с тем, что вам пришлось делать по факту. Это улучшит как ваше понимание деталей, требующихся для выполнения задачи, равно как и навыки оценки задачи.