![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
piggymouseA few questions to colleagues more knowledgeable than me.
- Context: software / systems design & development.
- Assumptions: I'm focused here on pure misestimation risk. I know that projects rarely die because of misestimation risks, but political and business stuff is not usually quantifiable.
- We all know that our duration/cost estimates are usually off by a wide margin. I wonder what real-world quantitative data are available on the distribution of the error. Is it Gaussian with a definite offset? Or non-Gaussian with a definite and stable positive skew? In Taleb's terms, are we in Mediocristan or Extremistan here?
- On the nature of distribution again. Let's forget for the moment the productivity differences between individual contributors (well known to be huge). Do we observe significant outlier events in software development, e.g. an estimation error of several orders of magnitude? — provided that we implement the basic process hygiene, i.e. our stories are small enough, we use consensus techniques like planning poker, we're on a familiar ground technologically, etc.
- Has anyone ever tried to apply the math usually used in various financial pricing models (either poor old CAPM or some more sophisticated stuff like Black-Scholes and all its descendants) to project estimates? Any references?
- In the same vein, but more general, have there been any attempts to analyze projects using analogies with derivative instruments (e.g. viewing a fixed-price bid as a swap of some kind)?
Thanks all for any answers.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2010-08-31 08:08 am (UTC)А ты пытаешься их притащить в другую совершенно область.
==
Я уже не говорю, что не надо устраивать казино ещё и из software development'а :)
no subject
Date: 2010-08-31 08:09 am (UTC)К финансам модели, основанные на Гауссе, не подходят совершенно. Но мне не очевидно, что ошибки эстимейтов такие уж фрактальные.
И опять-таки эта проблема вторична по сравнению с более печальными вещами, типа не пролюбить stakeholder identification.
no subject
Date: 2010-08-31 08:31 am (UTC)no subject
Date: 2010-08-31 09:51 am (UTC)no subject
Date: 2010-08-31 01:11 pm (UTC)no subject
Date: 2010-08-31 01:15 pm (UTC)или ты не об оценке трудоемкости проекта спрашиваешь?
no subject
Date: 2010-08-31 01:43 pm (UTC)Functional points это всё-таки промежуточная и мягкая метрика. Финальные жёсткие метрики это бабло и время. Если FP позволяют уменьшить ошибку в оценке жёстких метрик (и изменить распределение ошибки соответственно), это типа хорошо.
Сами по себе FP техника довольно тупая, насколько я помню. Мне интересно, нет ли более сложных техник.
no subject
Date: 2010-08-31 01:50 pm (UTC)no subject
Date: 2010-08-31 01:54 pm (UTC)no subject
Date: 2010-08-31 01:56 pm (UTC)no subject
Date: 2010-08-31 10:08 pm (UTC)а) это работает для схожих задач в схожих условиях
б) есть базовая статистика по прошлым проектам
в) есть минимум грубая спецификация. И всё, что туда не вошло к проекту не относится. А много ли клиентов делают вменяемую спецификацию? А, если ты сделал спецификацию и позабыл что-то пунктов на дюжину?
г) рекомендуют это с проектов весом пунктов от полусотни. Чтоб статистика съедала аберрации
д) в виденных случаях применяют это конторы для внутренних проектов. То есть речи о конкуренции по цене и поиске оптимального минимума не идёт.
Практически для контрактных работ многие создают большую серую зону (в основном по качеству). При удачности гадания по бюджету клиент получает отличный продукт, при неудачности - качество продукта клиента не очень устраивает, но всё ограничивается спорами насчёт неточности в техзадании.