Максим Крамаренко (maximkr) wrote,
Максим Крамаренко
maximkr

Categories:

FogBugz и Evidence Based Scheduling

На так давно Joel Spolsky написал статью, в которой описывается довольно интересный метод вычисления оценки времени завершения проекта, реализованный в FogBugz 6.

Суть метода в следующем:

  1. Перед началом работы программисты разбивают задачи на небольшие задачки, не больше 16 часов каждая.

  2. На задачи назначаются ответственные программисты.

  3. Программисты оценивают время (в статье говорится, что только тот, кто будет делать задачу способен более-менее точно оценить ее).

  4. После завершения работы - смотрим сколько рабочего времени на самом деле заняла задача.

  5. Вычисляем для каждой задачи параметр velocity как "оценка / на самом деле". Joel пишет, что в большинстве случаев velocity (по сути, степень оптимизма разработчика) будет очень близкой для разных задач одного разработчика. Даже если разработчика отвлекает шеф разговорами о рыбалке, то беспокоиться по этому поводу не надо - в будущем он будет отвлекать точно так же и алгоритм все правильно посчитает.

  6. Берем оставшиеся задачи и делаем для них 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 и поняли, что будет достаточно просто вырезать лишнее.

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


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

Вывод: проблема не в оценке тех задач, о которых мы знаем, проблема в задачах о которых мы не знаем. Для точной оценки нам нужны не методы предсказания оптимизма разработчиков по уже известным задачам, а методы предсказания количества неизвестных задач. К сожалению, оценить это на основе исторической/хронологической информации нельзя, т.к. весь опыт разработчиков уже учтен в созданных задачах.
Subscribe

  • Post a new comment

    Error

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.
  • 14 comments