Что такое 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 Derivation = (P — O)/6

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

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

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

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

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

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

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


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

Ну вот, дальше дело техники.
Матожидание случайной величины "трудозатраты на задачу" = M = ( H + L ) / 2.
Сигма этой случайной величины S = ( H — L ) / 4.

Для суммы задач, M = Sum( M[i ], i = 1..n ).
S = sqrt( Sum( S[i]^2, i = 1..n ).

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

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

Здравствуйте, Gaperton, Вы писали:

G>За основу возьмем гауссовское нормальное распределение. Все равно распределение суммы случайных величин сходится именно к нему (т.е. мы его все равно получим в конце концов, независимо от нашего желания), так что не будем никого обманывать. Да и свойства у него приятные.

Свойства у него приятные, слов нет. Однако не очень понятно, почему оценки для отдельных задач, по которым выполняется суммирование, не зависят друг от друга.

Здравствуйте, A.Lokotkov, Вы писали:

G>>За основу возьмем гауссовское нормальное распределение. Все равно распределение суммы случайных величин сходится именно к нему (т.е. мы его все равно получим в конце концов, независимо от нашего желания), так что не будем никого обманывать. Да и свойства у него приятные.

AL>Свойства у него приятные, слов нет. Однако не очень понятно, почему оценки для отдельных задач, по которым выполняется суммирование, не зависят друг от друга.

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

Проблема здесь в том, что у человека может быть тендеция к систематической переоценке или недооценке сложности (именно систематической — то есть он везде ошибается в одну сторону). Так вот, именно для борьбы с этим эффектом мы и не просим от него средней оценки — все равно он черти как ее оценит, мы просим его выдавать для каждой задачи широкие (!) коридоры "точно не успею/успею 100% что бы ни случилось". Необходимость задавать коридор уже сама по себе снижает вред от систематической недооценки — он проявляется, когда ты просишь от человека одно значение, и в результате не видишь, что это за оценка — pessimistic или optimistic. Да и сам человек это не осознает. Вот лажа в план и прет.

Здравствуйте, Gaperton, Вы писали:

G>Тут штука не в том, что оценки зависят или не зависят. Дело не в оценках. Длительность задачи — случайная величина. Берешь два разных задачи — даже если задачи связанны какой-нибудь зависимостью, типа конец-начало, то их длительности являются независимыми случайными величинами.

Вот я и не понимаю, почему их длительности являются независимыми случайными величинами. По причине стремления к нулю дисперсии при стремлении кол-ва задач к бесконечности? Получается, нужно очень заранее побить все на много-много маленьких-премаленьких задач?

Здравствуйте, A.Lokotkov, Вы писали:

AL>Здравствуйте, Gaperton, Вы писали:

G>>Тут штука не в том, что оценки зависят или не зависят. Дело не в оценках. Длительность задачи — случайная величина. Берешь два разных задачи — даже если задачи связанны какой-нибудь зависимостью, типа конец-начало, то их длительности являются независимыми случайными величинами.

AL>Вот я и не понимаю, почему их длительности являются независимыми случайными величинами. По причине стремления к нулю дисперсии при стремлении кол-ва задач к бесконечности?

Теоретически, длительности разных задач являются независимыми случайными величинами. Исключение будет только в том случае, если у исполнителя есть возможность накосячить в одной задаче, так, что удлиннится время другой задачи. Но, на практике так будет происходить редко, так, что этим можно пренебречь. Почему так:
1) Если ты бьешь работу на крупные задачи по реализации независимых или слабозависимых подсистем, то здесь, понятное дело, и длительности будут независимы. А именно так обычно бьют работу на раннем этапе — с целью грубой оценки сроков и бюджета. Потом, понятное дело, надо разрабатывать более детальный план, с другой группировкой. А данный метод наиболее силен как раз на первом этапе.
2) Для сильно связанных задач, редко это будет происходить в случае, если у тебя есть четкие критерии завершения и известен scope каждой задачи. В этом случае сложно сильно накосячить, чтобы работа перелезла в другую задачу. Уточнить такой план желательно по результатам архитектурного этапа.
3) Если план все-таки разъехался по ходу разработки — то по-любому надо делать replanning. Такое бывает, ничего страшного.
4) Если длительности задач таки зависимы — это говорит о неверной декомпозиции на задачи, надо переделить. Мне кажется, это всегда можно сделать. Доказать не могу, прошу привести контрпример.

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

AL>Получается, нужно очень заранее побить все на много-много маленьких-премаленьких задач?
Да, это было бы идеально. Но надо смотреть правде в глаза — не заранее — заранее если сделать то все расползется нафиг. Подробный план можно делать, когда более-менее понятно, что твоя фигня делает и в общих чертах — как, не раньше. А на начальном этапе — можно вот так:
http://rsdn.ru/Forum/message/2341277.1.aspx

Автор: Gaperton
Дата: 08.02.07

И запланировать replanning на окончание первого этапа.

Да, если крупные задачи в плане группировать от "блоков функциональности" и "целей", то такой план вряд-ли разъедется. Да и составлять его проще. Я могу привести пример шаблона такого плана. Поискать тока надо.

Здравствуйте, Gaperton, Вы писали:

G>Здравствуйте, A.Lokotkov, Вы писали:

AL>>Здравствуйте, Gaperton, Вы писали:

G>>>Тут штука не в том, что оценки зависят или не зависят. Дело не в оценках. Длительность задачи — случайная величина. Берешь два разных задачи — даже если задачи связанны какой-нибудь зависимостью, типа конец-начало, то их длительности являются независимыми случайными величинами.

AL>>Вот я и не понимаю, почему их длительности являются независимыми случайными величинами. По причине стремления к нулю дисперсии при стремлении кол-ва задач к бесконечности?

G>Теоретически, длительности разных задач являются независимыми случайными величинами. Исключение будет только в том случае, если у исполнителя есть возможность накосячить в одной задаче, так, что удлиннится время другой задачи. Но, на практике так будет происходить редко, так, что этим можно пренебречь.

Длительности выполнения задач могут быть зависимыми если есть resource sharing между задачами и они выполняются параллельно. Например один и тот-же девелопер участвует в работах по обоим задачам. Можно утверждать, что это неправильная декомпозиция, но мне кажется, что такое всё-таки допустимо.

Тем не менее, даже в этом случае можно предположить, что длительности задач распределены независимо. Я думаю что погрешность от cубъективной оценки параметров распределения гораздо больше чем ошибки из-за того, что мы считаем распределения независимыми.

Здравствуйте, Gaperton, Вы писали:

G>Проблема здесь в том, что у человека может быть тендеция к систематической переоценке или недооценке сложности (именно систематической — то есть он везде ошибается в одну сторону). Так вот, именно для борьбы с этим эффектом мы и не просим от него средней оценки — все равно он черти как ее оценит, мы просим его выдавать для каждой задачи широкие (!) коридоры "точно не успею/успею 100% что бы ни случилось". Необходимость задавать коридор уже сама по себе снижает вред от систематической недооценки — он проявляется, когда ты просишь от человека одно значение, и в результате не видишь, что это за оценка — pessimistic или optimistic. Да и сам человек это не осознает. Вот лажа в план и прет.

У человека также есть тенденция к систематической самоуверенности. Если Вы попросите человека дать интервал значений на уровне 90% уверенности для 10 не известных ему величин (например вес боинг 747, число книг в библии, длительность беременности африканского слона, масса луны и т.д.) до из 10 таких вопросов в среднем только 4 правильных ответа оказываются внутри заданных человеком интервалов, хотя по постановке задачи должно выходить 9.

Здравствуйте, Gaperton,

В случае нормального распределения существует ненулевая вероятность закончить работу раньше чем она началась (плотность вероятности при x<0 положительна). Можно взять лог-нормальное распределение. У него вероятность отрицательных значений нулевая и есть skew в сторону больших значений, что соответствует моей интуиции, что вероятность затянуть сроки больше чем вероятность закончить раньше.

Хотя всё это мелочи, которыми на практике можно принебречь ради простоты.

Здравствуйте, Risk Server, Вы писали:

RS>Здравствуйте, Gaperton, Вы писали:

G>>Проблема здесь в том, что у человека может быть тендеция к систематической переоценке или недооценке сложности (именно систематической — то есть он везде ошибается в одну сторону). Так вот, именно для борьбы с этим эффектом мы и не просим от него средней оценки — все равно он черти как ее оценит, мы просим его выдавать для каждой задачи широкие (!) коридоры "точно не успею/успею 100% что бы ни случилось". Необходимость задавать коридор уже сама по себе снижает вред от систематической недооценки — он проявляется, когда ты просишь от человека одно значение, и в результате не видишь, что это за оценка — pessimistic или optimistic. Да и сам человек это не осознает. Вот лажа в план и прет.

RS>У человека также есть тенденция к систематической самоуверенности. Если Вы попросите человека дать интервал значений на уровне 90% уверенности для 10 не известных ему величин (например вес боинг 747, число книг в библии, длительность беременности африканского слона, масса луны и т.д.) до из 10 таких вопросов в среднем только 4 правильных ответа оказываются внутри заданных человеком интервалов, хотя по постановке задачи должно выходить 9.

Мне кажется, тут другой случай. Мы же не просим его оценить уверенность в своем ответе. Мы просим его дать оценку сверху с огромным запасом — чтоб было наверняка.

Однако, мы обсуждали — как трактовать его "100% успею". Варианта было два — М+S (84%) или M+2S (98%). Возможно, правильнее будет выбирать M+S (это была моя первая мысль — но я переправил потом на 2S). Не знаю.

Здравствуйте, Risk Server, Вы писали:

G>>Теоретически, длительности разных задач являются независимыми случайными величинами. Исключение будет только в том случае, если у исполнителя есть возможность накосячить в одной задаче, так, что удлиннится время другой задачи. Но, на практике так будет происходить редко, так, что этим можно пренебречь.

RS>Длительности выполнения задач могут быть зависимыми если есть resource sharing между задачами и они выполняются параллельно. Например один и тот-же девелопер участвует в работах по обоим задачам. Можно утверждать, что это неправильная декомпозиция, но мне кажется, что такое всё-таки допустимо.

Чтобы себя не путать — надо разделять трудозатраты/длительность и сроки. Планирование идет в несколько этапов — сначала вы оцениваете трудозатраты (возможно, при выполнении работ известным человеком, тогда та оценка поручается ему), а потом, когда эта оценка выполнена, выполняете ресурсное планирование, и переводите трудозатраты и длительности в конкретные даты сроков (учитывая выходные, конфликты ресурсов, и прочее). Лучше всегда делать планирование последовательно, отделяя сроки от трудозатрат. Это сильно защищает мозг от вывихов при планировании.

Здесь речь идет об оценке трудозатрат, тут "длительности" абстрактные, ресурсное планирование будет выполняться позже, и конфликты буду тоже позже, пока их нет, мы рассматриваем идеальную ситуацию. Так проще.

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

Однако, и зависимостями также можно во многих случаях пренебречь — критические пути важны тогда, когда нам надо любой ценой успеть раньше, и мы неограниченны в ресурсах и бюджете (метод критических путей и был разработан для подобных проектов — во времена гонки вооружений и космических R&D проектов). А в большинстве коммерческих софтверных проектов ресурсы сильно ограничены, и длительность проектов обычно слишком большая, чтобы проект был задержан на критическом пути и он играл существенную роль.

RS>Тем не менее, даже в этом случае можно предположить, что длительности задач распределены независимо. Я думаю что погрешность от cубъективной оценки параметров распределения гораздо больше чем ошибки из-за того, что мы считаем распределения независимыми.

В этом согласен на 100%.

Здравствуйте, Risk Server, Вы писали:

RS>Здравствуйте, Gaperton,

RS>В случае нормального распределения существует ненулевая вероятность закончить работу раньше чем она началась (плотность вероятности при x<0 положительна). Можно взять лог-нормальное распределение. У него вероятность отрицательных значений нулевая и есть skew в сторону больших значений, что соответствует моей интуиции, что вероятность затянуть сроки больше чем вероятность закончить раньше.

Ну, это в сущности неважно. Нас строго говоря возможность отрицательных значений не интересует — в методе-то завязки на их возможность нет, значит, она никак и не сыграет. Для нас то означает, что вероятность закочить раньше нижней оценки ненулевая, и она около 2 процентов. Плюс — подмена распределения тебе ничего не даст — оно все равно обратно к нормальному сойдется на сумме задач. Если хочешь быть более пессимистичным лучше трактуй пессемистичную оценку как M + S. Тогда формулы для тебя будут

S = ( H — L ) / 3.
M = H — S.

Вот и все. Собственно, это и был мой первый вариант, я потом передумал и решил что H == M + 2*S. Но сейчас не знаю даже.

Здравствуйте, Gaperton, Вы писали:

G>Здравствуйте, Risk Server, Вы писали:

RS>>Здравствуйте, Gaperton,

RS>>В случае нормального распределения существует ненулевая вероятность закончить работу раньше чем она началась (плотность вероятности при x<0 положительна). Можно взять лог-нормальное распределение. У него вероятность отрицательных значений нулевая и есть skew в сторону больших значений, что соответствует моей интуиции, что вероятность затянуть сроки больше чем вероятность закончить раньше.

G>Ну, это в сущности неважно. Нас строго говоря возможность отрицательных значений не интересует — в методе-то завязки на их возможность нет, значит, она никак и не сыграет. Для нас то означает, что вероятность закочить раньше нижней оценки ненулевая, и она около 2 процентов. Плюс — подмена распределения тебе ничего не даст — оно все равно обратно к нормальному сойдется на сумме задач. Если хочешь быть более пессимистичным лучше трактуй пессемистичную оценку как M + S. Тогда формулы для тебя будут

G>S = ( H — L ) / 3.
G>M = H — S.

G>Вот и все. Собственно, это и был мой первый вариант, я потом передумал и решил что H == M + 2*S. Но сейчас не знаю даже.

Была, кстати, еще одна мысль. Делать два рассчета трудозатрат, один в предположении H == M + 2*S, а второй — H == M + S

После чего на выход давать коридор величин, полученный двумя разными рассчетами в качестве оценки сроков проекта. Вроде такого:
Вероятность 98%: 45-50 дней.
Вероятность 85%: 41-46 дней.

Мысль была отложена на полку по причине не до конца ясного автору физического смысла этого фокуса. Может, вы объясните?

Здравствуйте, Gaperton, Вы писали:

G>Была, кстати, еще одна мысль. Делать два рассчета трудозатрат, один в предположении H == M + 2*S, а второй — H == M + S

G>После чего на выход давать коридор величин, полученный двумя разными рассчетами в качестве оценки сроков проекта. Вроде такого:
G>Вероятность 98%: 45-50 дней.
G>Вероятность 85%: 41-46 дней.

G>Мысль была отложена на полку по причине не до конца ясного автору физического смысла этого фокуса. Может, вы объясните?

Пожалуй, на этом и остановлюсь пока. А там видно будет. Скоро выложу таблицу в Excel. Осталось придумать, как обрабатывать оценки строк кода...

Здравствуйте, Gaperton, Вы писали:

G>Здравствуйте, Gaperton, Вы писали:

G>>Здравствуйте, Risk Server, Вы писали:

RS>>>Здравствуйте, Gaperton,

RS>>>В случае нормального распределения существует ненулевая вероятность закончить работу раньше чем она началась (плотность вероятности при x<0 положительна). Можно взять лог-нормальное распределение. У него вероятность отрицательных значений нулевая и есть skew в сторону больших значений, что соответствует моей интуиции, что вероятность затянуть сроки больше чем вероятность закончить раньше.

G>>Ну, это в сущности неважно. Нас строго говоря возможность отрицательных значений не интересует — в методе-то завязки на их возможность нет, значит, она никак и не сыграет. Для нас то означает, что вероятность закочить раньше нижней оценки ненулевая, и она около 2 процентов. Плюс — подмена распределения тебе ничего не даст — оно все равно обратно к нормальному сойдется на сумме задач. Если хочешь быть более пессимистичным лучше трактуй пессемистичную оценку как M + S. Тогда формулы для тебя будут

G>>S = ( H — L ) / 3.
G>>M = H — S.

G>>Вот и все. Собственно, это и был мой первый вариант, я потом передумал и решил что H == M + 2*S. Но сейчас не знаю даже.

G>Была, кстати, еще одна мысль. Делать два рассчета трудозатрат, один в предположении H == M + 2*S, а второй — H == M + S

G>После чего на выход давать коридор величин, полученный двумя разными рассчетами в качестве оценки сроков проекта. Вроде такого:
G>Вероятность 98%: 45-50 дней.
G>Вероятность 85%: 41-46 дней.

G>Мысль была отложена на полку по причине не до конца ясного автору физического смысла этого фокуса. Может, вы объясните?

Мне кажется, что оценивать интервал [M-2S,M+2S] правильнее, чем делать оценки для M+S и M+2S. В случае нормального распределения разницы никакой нет, и одна пара чисел однозначно определяет вторую.
Зато в первом случае у нас есть 98% confidence interval независимо от распределения. А уже потом, когда все задачи сложены, распределение суммы стремится к нормальному, как Вы ранее сами и отмечали, можно взять 98% confidence interval, вычислить из него M и S для суммарного распределения и уже оттуда считать интервалы на любом уровне значимости.

Здравствуйте, Gaperton, Вы писали:

G>Здравствуйте, Risk Server, Вы писали:

RS>>Здравствуйте, Gaperton, Вы писали:

G>>>Проблема здесь в том, что у человека может быть тендеция к систематической переоценке или недооценке сложности (именно систематической — то есть он везде ошибается в одну сторону). Так вот, именно для борьбы с этим эффектом мы и не просим от него средней оценки — все равно он черти как ее оценит, мы просим его выдавать для каждой задачи широкие (!) коридоры "точно не успею/успею 100% что бы ни случилось". Необходимость задавать коридор уже сама по себе снижает вред от систематической недооценки — он проявляется, когда ты просишь от человека одно значение, и в результате не видишь, что это за оценка — pessimistic или optimistic. Да и сам человек это не осознает. Вот лажа в план и прет.

RS>>У человека также есть тенденция к систематической самоуверенности. Если Вы попросите человека дать интервал значений на уровне 90% уверенности для 10 не известных ему величин (например вес боинг 747, число книг в библии, длительность беременности африканского слона, масса луны и т.д.) до из 10 таких вопросов в среднем только 4 правильных ответа оказываются внутри заданных человеком интервалов, хотя по постановке задачи должно выходить 9.

G>Мне кажется, тут другой случай. Мы же не просим его оценить уверенность в своем ответе. Мы просим его дать оценку сверху с огромным запасом — чтоб было наверняка.

G>Однако, мы обсуждали — как трактовать его "100% успею". Варианта было два — М+S (84%) или M+2S (98%). Возможно, правильнее будет выбирать M+S (это была моя первая мысль — но я переправил потом на 2S). Не знаю.

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

Да и чем более знакома целовеку предметная область, тем меньше по-идее должен быть overconfidence bias. Например я ошибся на порядок в оценке веса боинга, но врядли я скажу что могу закончить за 20 дней, работу которая реально занимает 200.

Вот шаблон. Public beta, так сказать. Пробуйте, говорите, что не так.

http://files.rsdn.ru/20496/G-Estimation.xls

Идея та же, что и в предыдущем методе, http://rsdn.ru/Forum/message/1156301.1.aspx

Автор: Gaperton
Дата: 04.05.05

Изменения следующие.

1) Планирование идет в днях. Так проще. Соответственно, коридор допустимой продуктивности будет 60-160 строк в день для отдельных задач, и — я бы на вашем месте при планировании держал коэффициент в коридоре 60-120. Больших цифр достичь для длителного проекта практически нереально, меньшие означают либо дикую сложность и незнакомость задачи, либо откровенное пинание балды. Получается это так — нормальная "промышленная" продуктивность — 20-30 строк кода в час при групповой работе. Нормальное количество "чистых" часов, посвещаемых работе — 3, максимум 4 часа в день. Итого — имеем 60-120. Вообще — рекомендую снять статистику по закрытым проектам, и взять ваши реальные показатели. Это до ужаса интересно, и очень просто .

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

Еще — когда оцениваете продолжительность задачи в днях — имейте в виду, это "чистые" рабочие дни, без учета выходных и праздников. Т.е. неделя — это 5 дней, не 7.

Попробуйте плз для своих текущих проектов — отпишите впечатление. Нужна обратная связь.

Здравствуйте, Gaperton, Вы писали:

G>Матожидание случайной величины "трудозатраты на задачу" = M = ( H + L ) / 2.
G>Сигма этой случайной величины S = ( H — L ) / 4.

G>И с вероятностью 97,8% (лана, лана, пусть будет 98%), то есть "наверняка", они не превысят M + 2*S.

Странно как-то, для одной задачи: M + 2*S = H и от L не зависит.

Здравствуйте, Vlad ABC, Вы писали:

VA>Здравствуйте, Gaperton, Вы писали:

G>>Матожидание случайной величины "трудозатраты на задачу" = M = ( H + L ) / 2.
G>>Сигма этой случайной величины S = ( H — L ) / 4.

G>>И с вероятностью 97,8% (лана, лана, пусть будет 98%), то есть "наверняка", они не превысят M + 2*S.

VA>Странно как-то, для одной задачи: M + 2*S = H и от L не зависит.

Ничего ИМХО странного тут нет . Для одной задачи Н — это одна из двух экспертных оценок, что тебя просят для этой задачи дать . Она, понятное дело, не зависит от L, которая является второй твоей экспертной оценкой . А пользуясь уравнением, которое ты привел, из пары оценок H и L мы вычисляем M и S.

Вообще суть состоит не в том, чтобы что-то измерить для одной задачи. Суть метода — обработать оценки по нескольким задачам, и дать вероятностную оценку трудозатрат всего проекта. В качестве estimation для отдельной задачи надо просто тупо брать M = ( H + L ) / 2, матожидание времени ее завершения. И все. Что тут еще можно сделать, имея на входе только пару чисел, интересно? Много из них не наматематишь.

Здравствуйте, Gaperton, Вы писали:

G>1) Планирование идет в днях. Так проще. Соответственно, коридор допустимой продуктивности будет 60-160 строк в день для отдельных задач, и — я бы на вашем месте при планировании держал коэффициент в коридоре 60-120. Больших цифр достичь для длителного проекта практически нереально, меньшие означают либо дикую сложность и незнакомость задачи, либо откровенное пинание балды. Получается это так — нормальная "промышленная" продуктивность — 20-30 строк кода в час при групповой работе. Нормальное количество "чистых" часов, посвещаемых работе — 3, максимум 4 часа в день. Итого — имеем 60-120. Вообще — рекомендую снять статистику по закрытым проектам, и взять ваши реальные показатели. Это до ужаса интересно, и очень просто .

Обновленная версия.
http://files.rsdn.ru/20496/G-Estimation%20v2.xls
Теперь "продуктивность" считается раздельно для лучшего и худшего случая. В самом деле — минимальная оценка сроков это та, раньше которой успеть нельзя по любому, так? Логично предположить, что для этого случая придется писать меньше кода (минимальная оценка объема) и иметь максимальную продуктивность? Вот она и выведена отдельно для лучших и худших случаев. Теперь есть возможность проверить достоверность минимальных и максимальных оценок сроков и объемов между собой.

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

Здравствуйте, A.Lokotkov, Вы писали:

AL>Здравствуйте, Gaperton, Вы писали:

G>>Тут штука не в том, что оценки зависят или не зависят. Дело не в оценках. Длительность задачи — случайная величина. Берешь два разных задачи — даже если задачи связанны какой-нибудь зависимостью, типа конец-начало, то их длительности являются независимыми случайными величинами.

AL>Вот я и не понимаю, почему их длительности являются независимыми случайными величинами. По причине стремления к нулю дисперсии при стремлении кол-ва задач к бесконечности? Получается, нужно очень заранее побить все на много-много маленьких-премаленьких задач?

Короче, ты прав. Теперь я понимаю, почему именно умные дядьки в книгах советовали суммировать O P M. Нет лучше способа понять суть проблемы, чем изобретение велосипеда.

Выяснил я это просто — я взял вчера вечером детальный план по одному из наших проектов (150 задач), запланированный по PERT, и прогнал на своей таблице. Результат = 251 день при сигме 5 дней. Вы верите в такой точный прогноз на раннем этапе? Я — нет . Это противоречит здравому смыслу, это бред. Долго думал, в чем состоит проблема, после чего понял, что ты абсолютно прав насчет зависимости задач. Причина состоит в том, что я трактую зависимые задачи как независимые, что приводит к занижению стандартного отклонения. Почему так — да потому, что при недооценке сложности одного крупного модуля (что легко сделать на раннем этапе, когда нет детального дизайна) вверх дружно полезут длительности всех задач, к нему относящихся. При количестве задач в плане около 150 выходит лажа — потому что в этом случае надо просто суммировать сигму, а не через квадраты.

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

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

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

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

Если пытаться учесть независимость задач, то можно начать хитрить, как это сделал я, но получается как-то чуточку сложно. Вопрос — стоит ли это результата. Короче, мне надо подумать. Всем спасибо!