FogBugz и Evidence Based Scheduling
На так давно Joel Spolsky написал статью, в которой описывается довольно интересный метод вычисления оценки времени завершения проекта, реализованный в FogBugz 6.
Суть метода в следующем:
Идея замечательная, сразу захотелось реализовать это в TrackStudio, но есть серьезные проблемы:
Суть метода в следующем:
- Перед началом работы программисты разбивают задачи на небольшие задачки, не больше 16 часов каждая.
- На задачи назначаются ответственные программисты.
- Программисты оценивают время (в статье говорится, что только тот, кто будет делать задачу способен более-менее точно оценить ее).
- После завершения работы - смотрим сколько рабочего времени на самом деле заняла задача.
- Вычисляем для каждой задачи параметр velocity как "оценка / на самом деле". Joel пишет, что в большинстве случаев velocity (по сути, степень оптимизма разработчика) будет очень близкой для разных задач одного разработчика. Даже если разработчика отвлекает шеф разговорами о рыбалке, то беспокоиться по этому поводу не надо - в будущем он будет отвлекать точно так же и алгоритм все правильно посчитает.
- Берем оставшиеся задачи и делаем для них 100 прогонов следующего содержания:
- смотрим, какой у данной задачи разработчик
- выбираем его velocity случайным образом из тех, что уже были в его истории.
- на основании оценки и выбранного velocity считаем сколько времени займет решение этой задачи
Если сделать это для каждой задачи и просуммировать - получим общее время выполнения всех задач в данном случае.Делаем 100 прогонов алгоритма - получаем 100 вариантов общего времени выполнения задач. После этого можно построить график типа: "с вероятностью 5% мы сделаем за 100 часов, с вероятностью 50% - за 120, с вероятностью 95% - за 150 часов". Чем ближе оценки для 5% и 95% - тем точнее прогноз.
Идея замечательная, сразу захотелось реализовать это в TrackStudio, но есть серьезные проблемы:
