Планирование, учитывающее предыдущие результаты

Даже не знаю, как можно правильно перевести термин "Evidence Based Scheduling"... Джоэль Спольски разразился в своем блоге отличной статьей, посвященной объяснению вот этой вот самой штуки. Термин "Evidence Based Scheduling", похоже, придуман Джоэлем и его командой, а сам метод планирования внедрен и активно продвигается в их продукте FogBugz 6.0 (демо, которое заслуживает отдельных похвал, можно глянуть здесь, а запись выступления Джоэля - здесь). Итак, для тех, кто не любит читать "много букофф", вкратце, что же это такое и с чем его едят. Evidence Based Scheduling - это метод планирования проекта, основанный на 2-х основных принципах:

• учет предыдущих результатов для получения реальной оценки (estimate) времени, которое будет затрачено на разработку продукта
• прогнозирование вероятности релиза продукта в конкретный день (с использованием метода Монте-Карло)

По первому пункту, в принципе, все понятно. Есть люди, склонные переоценивать свои силы и недооценивать их, и это нужно учитывать при планировании проекта. Каждый грамотный team/dev/QA/project lead (нужное подчеркнуть) более-менее хорошо знает свою команду и может на основании эмпирических фактов проставить каждому девелоперу/QA коэффициент, на который нужно домножить его собственный estimate. Однако существует еще очень много факторов, которые могут повлиять на то, что проект затянется во времени и мы выпадем из графика или бюджета. Часть из них являются непроизводственными, например, прогулки по Интернету, общение в команде, кофе/чай, "а глянь какие фотки мы сделали на выходных!", часть - абсолютно честно относятся к разработке продукта: изучение новой технологии, митинги в команде, философские дискуссии с QA, что есть баг, а что фича и др. естественные, но от того не менее опасные для развития проекта активности. Все это невозможно предусмотреть заранее. Однако, если трекать процесс разработки продукта, то потом можно сравнить estimate с реальными данными и на основании этого сравнения сделать определенные выводы на будущее. Второй пункт вызывает больше интереса. Честно говоря, я не видел еще подобного способа прогнозирования дат релиза и отдельных mileston'ов (кто видел, подскажите продукт или где почитать). Как мы обычно планируем проект? У нас есть нижняя и верхняя граница оценки определенной задачи, мы выбираем цифру от 0.5 до 1 на этом отрезке (думаю, меньше 0.5 никто не выбирает :)), а затем устанавливаем ее для этой задачи в MS Project или кто чем пользуется. Строим диаграмму Ганта и в результате получаем приблизительные даты mileston'ов и релизов. Джоэль предлагает другой подход, который состоит в вычислении вероятности различных будущих, основанном на методе Монте-Карло. Данный подход достаточно тесно связан с предыдущими результатами работы наших программистов, которые у нас есть. Если мы случайным образом возьмем одно из предыдущих значений отношения оценки выполнения какой-либо задачи к реально затраченному времени (в идеале оно будет равно 1, но, конечно же, будут вариации), и разделим на него текущую оценку новой задачи, то мы получим другое число с учетом предыдущего результата. А теперь представим себе, что мы рассматриваем все задачи всех программистов и для каждой задачи вычисляем 100 различных новых значений, каждое с вероятностью в 1%. Тогда, сложив вместе эти значения (с учетом графика выполнения работ, выходных, праздников и т.д.), мы получим 100 вариантов развития события, 100 вариантов будущего нашего проекта. А уже сопоставив эти 100 графиков мы можем дать вероятность того, что наш проект завершится 10 декабря, 15 января или вообще 30 апреля. У такого подхода есть ряд преимуществ перед обычным, т.к. он дает большую гибкость и учитывает больше факторов, что, соответственно, делает результат более точным. Дальше нам остается только сказать себе, что вероятности 90% нам достаточно и мы можем поставить milestone в данную точку времени и пространства. Кроме этих интересных вещей, Джоэль также дает несколько советов по оценке задач:

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

В общем и целом, это все. Советую прочитать статью Джоэля целиком (а также и другие его статьи), там еще много чего интересного. Вывод: FogBugz 6.0 из простой (пусть и удобной) системы багтрекинга превратился в полноценную систему управления проектами, с интересными и смелыми решениями. Интересно было бы попробовать ее в действии на реальном проекте, а то продукты MS уже как-то приелись :). Посмотрим, чем ответят разработчики других приложений. Kiwi :)