Максим Крамаренко ([info]maximkr) wrote,
@ 2009-05-24 22:40:00
Previous Entry  Add to memories!  Tell a Friend  Next Entry
Про планирование работ
Пытаюсь разобраться с мат. статистикой, нужна помощь :-) Задача такая: у нас есть план работ и оценка времени выполнения каждой задачи. Нужно узнать вероятность того, что все будет сделано к определенной дате.

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

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

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

Со здравым смыслом это все вроде согласуется: оценка времени выполнения работы в плане не может быть бесконечной, в реальности разработчик может не справится с задачей вовремя, пролететь по срокам, а в итоге весь проект может быть закрыт. Также может быть ситуация, когда вроде бы простая по плану задача распадается на 20 подзадач с соответствующим увеличением сроков: случайно-низкая производительность в знаменателе для конкретной задачи приводит к резкому росту затрат времени на задачу.

А теперь вопрос - как решается эта проблема в методиках типа PERT ? Судя по тому что я читал, там просто обрабатываются оценки времени выполнения каждой подзадачи, а в итоге получается вероятность реального выполнения проекта к заданному времени. Evidence-Based Scheduling - из той же оперы.

Где ошибка ?
 

(9 comments) - (Post a new comment)


[info]thesz
2009-05-24 08:20 pm UTC (link)
http://gaperton.livejournal.com/34265.html

"Может быть, поможет быть. Может быть, поможет." ;)

(Reply to this) (Thread)

[info]maximkr
2009-05-24 09:03 pm UTC (link)
Презентацию смотрел, но не понял. Gaperton по поводу метрик пишет:
1) Выполнить прогноз объема в удобной метрике.
2) Перейти к SLOC
3) Пользуясь корреляцией SLOC/time (производительность) выполнить прогноз времени.

Но даже если объем и производительность распределены по нормальному закону, то оценка времени (объем/производительность) будет распределена по Коши.

В статье про evidence-based scheduling я в качестве примера без всякой задней мысли писал
"Могут быть ошибки и в обратную сторону - (реальный пример) мы собирались делать хитрый импорт в TrackStudio, а потом нашли JitterBit и поняли, что будет достаточно просто вырезать лишнее."

Так вот, импорт через JitterBit сделали, заработало, но оказалось слишком сложным в использовании. Т.е. задача "сделать импорт через JitterBit" была решена, а задача "сделать простой CSV импорт" - нет. Пришлось-таки писать хитрый CSV Import, winzard сейчас как раз доделывает :-)

Причем это не первая попытка - сначала мы пытались реализовать импорт через CloverETL. Там тоже все заработало, но под конец выяснилось, что этот CloverETL не умеет импортировать строчки больше 2 (или 4?) кб., "будет в следующей версии". Как можно было ожидать, что спец. тулза для импорта данных может иметь такие ограничения ? Как раз типичный пример, когда вроде бы небольшая по объему задача деленная на нашу (мою) неспособность заранее предсказать удобство/юзабельность полученного результата приводит к резкому росту реальных сроков.

(Reply to this) (Parent)(Thread)

[info]thesz
2009-05-24 09:10 pm UTC (link)
Лучше всего ему задать вопрос.

(Reply to this) (Parent)

[info]gaperton
2009-05-31 10:47 pm UTC (link)
> Но даже если объем и производительность распределены по нормальному закону, то оценка времени (объем/производительность) будет распределена по Коши.

Корректная математика, описывающая данные процессы, изложена в книгах по PSP/TSP.

Если кратко, то ошибка у тебя в том, что время и объем зависимые случайные величины, и они дают неплохую корреляцию. Надо посчитать линейную регрессию время-объем, и, при наличии корреляции, пользоваться при прогнозе ей.

(Reply to this) (Parent)(Thread)

[info]maximkr
2009-06-01 11:01 am UTC (link)
Да, но объем и производительность - вроде бы независимые. Получается, что хотя между объемом и временем будет значительная корреляция, но время будет распределено по Коши, т.е. распределение будет иметь толстые "хвосты" и пренебречь вероятностью "маловероятных" событий тут нельзя.

С другой стороны, если задача с большим объемом все-таки попадет сотруднику с низкой производительностью (на этом классе задач), то менеджер может передать задачу кому-то еще или подключить другого сотрудника. Т.е. если ошиблись по времени "вниз" - ничего не делаем, если "вверх" - может скорректировать.

(Reply to this) (Parent)(Thread)

[info]gaperton
2009-06-01 11:23 am UTC (link)
Ну не знаю. Наличие корелляции означает, что точки на плоскости время-объем ложатся вокруг прямой на этой плоскости. Продуктивность - это угол наклона данной прямой, и она в PSP/TSP (да и в статистике) не трактуется как случайная величина. Дело, по всей видимости в этом. Соответственно, продуктивность - одна, и при умножении ошибка прогноза будет распределена, кажется по хи-квадрат, так?

Кроме того, для разных людей корелляция своя. И более того, для разных классов задач она тоже своя. В PSP/TSP ты считаешь индивидуальные корелляции разработчиков, и бьешь задачи на классы, для каждого - своя корелляция.

(Reply to this) (Parent)(Thread)

[info]maximkr
2009-06-01 12:34 pm UTC (link)
Да, похоже дело именно в том, как трактовать продуктивность (производительность) - как случайную величину или как константу для каждого работника/класса задач. В теории массового обслуживания производительность в самом деле константа.

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

Вот тут нашел статью про оптимизацию уровня запаса сырья на лесоперерабатывающем предприятии, там как раз производительность рассматривается как случайная величина, правда ссылок на литературу других авторов нет :-)
http://www.rae.ru/use/pdf/2006/12/2006_12_61.pdf

===
Известные из «Теории управления запасами» две основные модели – с фиксированным размером заказа и
фиксированным интервалом между заказами имеют ряд ограничений при их практическом применении. В частности, они не учитывают вероятностный характер основных параметров предприятия таких, например, как производительность. При оперативном планировании работы лесоперерабатывающего предприятия возникает необходимость в учете случайных
факторов, существенно влияющих на процесс производства. К таким факторам можно отнести непредусмотренные сбои в
поступлении сырья, энергии, рабочей силы, отказы, профилактика и обслуживание оборудования.
...
Модель отказа системы (случай отсутствия сырья на лесоперерабатывающем предприятии) определим следующим
образом. Производительность предприятия (объем сырья, перерабатываемого за единицу времени) определим как
случайную величину, подчиняющуюся в общем случае нормальному закону распределения с известными оценками среднего значения и среднеквадратического отклонения. Для каждого конкретного случая закон распределения производительности предприятия должен быть получен из статистической обработки данных по фактической производительности.
===

Индивидуальные корреляции для каждого типа задач и каждого разработчика - это ведь тоже способ снизить разброс производительности. Но как определить, достаточно ли группировки по разработчикам и данным типам задач, может быть нужно делить на большее количество типов задач или добавить еще параметров (количество выпитого накануне спиртного) ? Когда можно переходить к аналитическому описанию зависимости ? Может есть тут какие критерии ?

(Reply to this) (Parent)

[info]vit_r
2009-05-24 08:59 pm UTC (link)
В статистике переменные НЕЗАВИСИМЫЕ.
В реальной жизни оценки времени выполнения создают обратную связь. То есть результат измерений будет влиять на систему.

Что из этого следует? Проект надо оценивать как целое. Что выбирается за основу измерений - не важно. Главное, чтоб была правильная база. Лучше всего какую-нибудь метрику, которую можно вывести из ТЗ.

(Reply to this)

Как вариант...
[info]vorobiev
2009-05-25 09:55 am UTC (link)
Недавно прочитал книгу Голдратта "Ключевая цепь." Если посмотреть на эту книгу с точки зрения статистики, то там рекомендуется отказаться от независимости задач в проекте и перейти как раз к анализу зависимостей, чтобы выделить некоторую достаточно небольшую подпоследовательность задач, которая дает основу проекта - ключевую цепь. После чего назначить каждому этапу МИНИМАЛЬНОЕ время на выполнение, а весь буфер времени сложить в конце. Тогда возникают следующие эффекты:
1. Убирается фактор "откладывания на потом" и "бесконечной оптимизации" к которой некоторые разработчики имеют склонность.
2. Четко виден размер оставшегося буфера.
3. Можно отслеживать ключевые проблемные места для перераспределения ресурсов/пересмотра планов
4. Команда работает интенсивно но в состоянии успеха, а не вечного запаздывания.

(Reply to this)

(9 comments) - (Post a new comment)

Create an Account
Forgot your login or password?
Login w/ OpenID
English • Español • Deutsch • Русский…