Gaperton (gaperton) wrote,
Gaperton
gaperton

Categories:

Об альтернативном методе оценки сроков (PERT Estimation sux)

Что такое PERT Estimation. Это элемент метода PERT, предназначенный для оценки сроков проекта. А именно, речь идет вот об этих формулах:


Optimistic time (O): the minimum possible time required to accomplish a task, assuming everything proceeds better than is normally expected
Pessimistic time (P): the maximum possible time required to accomplish a task, assuming everything goes wrong (but excluding major catastrophes).
Most likely time (M): the best estimate of the time required to accomplish a task, assuming everything proceeds as normal.
Expected time (TE): the best estimate of the time required to accomplish a task, assuming everything proceeds as normal (the implication being that the expected time is the average time the task would require if the task were repeated on a number of occasions over an extended period of time).
TE = (O + 4M + P) ÷ 6

Метод берет тройную экспертную оценку сроков на вход, и выдает на выход
Pert Estimation = (O + 4M + P) ÷ 6
и
Pert Deviation = (P — O)/6

В литературе по управлению проектами рекомендуют суммировать Pert Estimation по задачам, чтобы получить прогноз итоговых трудозатрат. Также, там говорят, что формулы PERT аддитивны — типа вы суммируете O M P и применяете формулы PERT к ним.

Что в методе хорошо. Хорошо — это тройная оценка. При одинарной оценке вы не знаете, на что именно эксперт перезаложился, когда ее давал. А тут — тройная, все видно, и оптимистичная есть, и пессемистичная, никакой "тенденции к переоценке-недооценке", возникающей из манеры оценщика трактовать единственную оценку вы не увидите. Второе — по ширине интервала P — O вы увидите, насколько сама оценка достоверна, насколько оценщик в ней уверен.

Вроде-бы, здорово. Однако, после примерно 5-летней практики применения того метода, у меня появились вопросы:
Каков физический смысл PERT Deviation? Вот допустим, я хочу выдать на выходе коридор трудозатрат, и вероятность, что я в него впишусь. Как эта штука мне поможет?

Хорошая новость оказалась в том, что PERT Estimation основан на бета-распределении. Однако, дальше идут только плохие новости. А именно:
— формулы приближенные. Точного beta distribution они не дают, это так, нос к лаптю.
— В литературе упоминается благотворный эффект увеличенного количества единиц планирования - погрешности планирования взаимоуничтожаются и повышается точность плана. Так вот, чтобы учесть тот эффект, формулы PERT нельзя трактовать как аддитивные, как пишут в книгах. Потому, среднеквадратичное отклонение для независимых задач надо перед суммированием возводить в квадрат.
— А после этого ответить на вопрос о том, с какой вероятностью я впишусь в срок, скажем, PERT Estimation + PERT Deviation, уже не так просто, потому как наш бета дистрибьюшен (и так приближенный) безнадежно испорчен суммированием. И стал, благодаря ценральной предельной теореме, чем-то средним между гауссовским и бета-распределением.

Короче, что я хочу и не могу получить с PERT Estimation. Да очень простую штуку, вроде этого:
С вероятностью 85% проект завершится в 4 месяца, с вероятностью 98% — 4,5 месяца. При этом, метод должен учитывать независимость задач. Причем, я хочу понимать, как оценка получается, это должно быть просто и прозрачно. И еще, желательно, иметь прямое отношение к теории вероятностей, мне так спокойнее.

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

За основу возьмем гауссовское нормальное распределение. Все равно распределение суммы случайных величин сходится именно к нему (т.е. мы его все равно получим в конце концов, независимо от нашего желания), так что не будем никого обманывать. Да и свойства у него приятные. Вот оно:
http://en.wikipedia.org/wiki/Normal_distribution


На вход будем брать две оценки, как договорились. Внимательно глядя на график нормального распределения, понимаем, что
Точно не уложусь = L = ME — 2*Sigma (вероятность, что проект таки закончится раньше — 2.2%), где ME - это матожидание.
Успею 100% = H = ME + 2*Sigma (Вероятность завершения до этого срока = 97,8%)
То есть

ME = ( L + H ) / 2.
Sigma = ( H - L ) / 4.

Можно обработать и тройную оценку, как в PERT Estimation. Пока я не понимаю, как лучше - две или три. Мне кажется, в пользу тройной оценки говорит то, что имея центральную оценку, человек будет меньше ошибаться с пессимистичной оценкой. Если брать три оценки, то делается обработка, очевидно так:

ME = ( L + 2*M + H ) / 4.
Sigma = ( H - L ) / 4.

Центр "колокольчика" нормального распределения будет находится в этом случае посередине между центром ( H - L ) / 2 и оценкой M. Мне кажется, достаточно разумно. Уж по крайней мере лучше, чем в PERT, там центральная оценка идет с весом 4 и фактически полностью забивает граничные оценки.

Ну вот, дальше дело техники.

Для суммы задач, ME = Sum( ME[i ], i = 1..n ), это понятно. А вот насчет сигмы все сложнее.

В предположении, что прогнозы продолжительности задач (случайные величины) у нас независимы, мы имеем сигму

S = sqrt( Sum( S[i]^2, i = 1..n )).

Однако, на практике не все прогнозы продолжительности можно трактовать как независимые. Почему так — да потому, что при недооценке сложности одного крупного модуля (что легко сделать на раннем этапе, когда нет детального дизайна) вверх дружно полезут длительности всех задач, к нему относящихся. Поэтому, надо разделять зависимые прогнозы от независимых, и трактовать их по разному - для зависимых прогнозов надо суммировать сигму простым образом, не через квадраты.

Короче говоря — какие задачи у нас еще будут зависимы по длительностям. Фазы разаботки одного блока/модуля. Предположим, их 4 — требования, дизайн/архитектура, разработка, отладка/доводка. Пусть мы завели четыре таких задачи, и их оценили. Так как они относятся к одному модулю, то в случае недооценки сложности этого модуля увеличатся продолжительности всех четырех задач одновременно. Другими словами, случайные величины сроков этих задач зависимы, и для них надо просто суммировать сигму.

Отсюда следует, что независимыми можно считать только агрегатные оценки по независимым по функциональности модулям и фрагментам системы (включая все активности по их разработке). Декомпозицию крупной задачи наугад тоже нельзя трактовать как набор независимых задач. Задача интеграционного тестирования будет _зависимой_ с предыдущим этапом. Вообще, очень похоже, что зависимость задач окончание-начало сигнализирует о зависимости прогнозов сроков работ. Надо по реальным планам проверить.

Что это означает для планирования. Для аккуратного обращения с сигмой, надо рассматривать задачи в виде иерархии, и вводить разные правила сумирования для груповых задач и для подзадач.
1) Для этапов работ (когда этап означает фазу разработки) — надо выполнять прогноз простым суммированием исходных оценок.
2) Для независимых по реализуемым функциям работ внутри этапа, которые могут быть выполнены в параллель — суммирование через квадраты по изложенным правилам.
3) Для итераций (когда этап реализует добавочную функиональность, независимую или слабозависимую от результатов предыдущей итерации) — надо также суммировать через квадраты.

Короче говоря, мораль такая. Если делать по простому, и забить на благотворное влияние независимых задач, уменьшающее разброс всего плана — то вполне можно применять PERT Estimation так, как написано в книге, суммируя все оценки. В этом случае, правда, вся его ценность сведется к тройной оценке, можно никаких формул не наворачивать, толку все равно ноль.

Однако, что мы все-таки можем получить в результате нашего нового метода. А вот что:
С вероятностью 84,2% (ладно, не будем морочить голову, и так все приближенное — пусть будет 85%), или если по человечески — то "скорее всего" у меня трудозатраты уложатся в M + S
И с вероятностью 97,8% (лана, лана, пусть будет 98%), то есть "наверняка", они не превысят M + 2*S.

Вот, теперь наконец у меня есть точный (насколько это вообще возможно) метод оценки трудозатрат для заказных проектов fixed cost. И я могу предсказывать свою маржу на раннем этапе, и по человечески, без жевания соплей, отвечать на вопросы о рисках. Может и не точно, как в аптеке, но по крайней мере буду знать, что говорю. Чего и желаю всем последователям вотерфола , ну и agile тоже. :) Короче, проверим метод на практике.
Subscribe
  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

  • 30 comments