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


• У нас код - общий, программисты заранее не знают какие из этих задач они будут делать через месяц. Т.е. у каждого программиста есть 1-2 текущие задачи, а кто будет делать оставшиеся (и сколько это времени у них займет - разница может быть на порядок легко) - не известно.


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

У нас в TrackStudio созданием задач (а значит и их оценкой) занимаюсь я сам, критерий - 2-3 часа на задачу. Конечно, бывают и большие задачи на десятки часов, но они потом компенсируются большим количеством мелких доделок по 15-20 минут. Я посчитал среднее время решения задачи в TrackStudio 3.0, 3.1 и 3.5:
TrackStudio 3.0 - 2.37 часа на задачу
TrackStudio 3.1 - 2.25 часа на задачу
TrackStudio 3.5 - 2.39 часа на задачу.

Как видно, оценка в 2.3 часа на задачу очень точна, разброс минимальный, при том что я просто поделил одно число на другое и вообще ничего больше не учитывал. Значит ли это, если я теперь умножу оставшиеся по следующей версии TrackStudio 50 задач на 2.3 часа, то получу очень точный прогноз в 115 часов ?

Очевидно, нет - проблема именно в количестве задач:

• 50 задач - это то, что известно. Что там вылезет когда мы начнем это сами тестировать - не известно. Что найдут бета-тестеры и клиенты - тоже. Джоэль советует включать время на исправление багов в задачу, где была изначально реализована требуемая функциональность, но это все сильно усложняет и все равно не поможет - нам не нужно знать, что оценка такого-то работника 2 года назад была неверной, он с большой вероятностью с тех пор научился оценивать лучше или вообще уволился.


• В своей статье Джоэль пишет, что периодические отвлекания на разговоры с шефом или помощь с настройкой софта другому разработчику - не проблема. Я тут полностью согласен, но это только если эта нагрузка более-менее постоянная. Если у компании начался бурный рост, и мы наняли 50 человек - на обучение сотрудников придется потратить куда больше времени, чем планировалось. Если мы запустили хорошую рекламу, и поток клиентов/вопросов увеличился в 10 раз - это чертовски сложно предсказать. Могут быть ошибки и в обратную сторону - (реальный пример) мы собирались делать хитрый импорт в TrackStudio, а потом нашли JitterBit и поняли, что будет достаточно просто вырезать лишнее.


• Метод Джоэля можно использовать динамически, т.е. по мере появления новых задач мы периодически производим переоценку времени завершения проекта. Но того же результата можно добиться вообще без компьютера: просто умножьте количество оставшихся задач на среднее время решения одной задачи и получим аналогичный результат куда проще и быстрее. У нас разработчики постоянно пользуются этим методом, но он предсказывает время завершения известных оставшихся задач, а не о время релиза.