Суть метода в следующем:
- Перед началом работы программисты разбивают задачи на небольшие задачки, не больше 16 часов каждая.
- На задачи назначаются ответственные программисты.
- Программисты оценивают время (в статье говорится, что только тот, кто будет делать задачу способен более-менее точно оценить ее).
- После завершения работы - смотрим сколько рабочего времени на самом деле заняла задача.
- Вычисляем для каждой задачи параметр velocity как "оценка / на самом деле". Joel пишет, что в большинстве случаев velocity (по сути, степень оптимизма разработчика) будет очень близкой для разных задач одного разработчика. Даже если разработчика отвлекает шеф разговорами о рыбалке, то беспокоиться по этому поводу не надо - в будущем он будет отвлекать точно так же и алгоритм все правильно посчитает.
- Берем оставшиеся задачи и делаем для них 100 прогонов следующего содержания:
- смотрим, какой у данной задачи разработчик
- выбираем его velocity случайным образом из тех, что уже были в его истории.
- на основании оценки и выбранного velocity считаем сколько времени займет решение этой задачи
Если сделать это для каждой задачи и просуммировать - получим общее время выполнения всех задач в данном случае.Делаем 100 прогонов алгоритма - получаем 100 вариантов общего времени выполнения задач. После этого можно построить график типа: "с вероятностью 5% мы сделаем за 100 часов, с вероятностью 50% - за 120, с вероятностью 95% - за 150 часов". Чем ближе оценки для 5% и 95% - тем точнее прогноз.
Идея замечательная, сразу захотелось реализовать это в TrackStudio, но есть серьезные проблемы:
- Джоэль пишет, что оценивать затраты времени должен тот кто будет делать, т.е. программист. Если задачу будут делать несколько человек (программист, тестировщих, техписатель), то кто должен оценивать ? В реальности это означает, что такие задачи нужно делить на несколько (нужно реализовать вот это, нужно протестировать, нужно написать документацию) и как-то учитывать связи между задачами: техписатель не сможет ничего написать, пока ничего не сделано. Если связи не учитывать (а это наш случай), то метод будет показывать что у техписателя времени - вагон, а на самом деле он будет главным тормозом на критическом пути.
- У нас код - общий, программисты заранее не знают какие из этих задач они будут делать через месяц. Т.е. у каждого программиста есть 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 и поняли, что будет достаточно просто вырезать лишнее.
- Метод Джоэля можно использовать динамически, т.е. по мере появления новых задач мы периодически производим переоценку времени завершения проекта. Но того же результата можно добиться вообще без компьютера: просто умножьте количество оставшихся задач на среднее время решения одной задачи и получим аналогичный результат куда проще и быстрее. У нас разработчики постоянно пользуются этим методом, но он предсказывает время завершения известных оставшихся задач, а не о время релиза.
Проблема немного напоминает известную проблему с предсказанием курсов валют или акций. Дело в том, что нынешний курс на бирже - он уже включает в себя известную информацию, включая котировки в прошлом, прогнозы экспертов, слухи, вероятность крупных терактов и прочее. Изменения цен сложно предсказать именно потому, что они зависят от факторов, о которых сейчас никто не знает.
Вывод: проблема не в оценке тех задач, о которых мы знаем, проблема в задачах о которых мы не знаем. Для точной оценки нам нужны не методы предсказания оптимизма разработчиков по уже известным задачам, а методы предсказания количества неизвестных задач. К сожалению, оценить это на основе исторической/хронологической информации нельзя, т.к. весь опыт разработчиков уже учтен в созданных задачах.
