И все же оценки не точны. Однако по мере уточнения информации и уже в ходе самой деятельности оценки становятся точнее и точнее. Эта идея получила название "конус неопределенности".
В 1981 Барри Боэм (Barry W. Boehm) впервые предложил эту идею, проанализировав 60 проектов разработки ПО, а в 2000 году обновил уже по 160 проектам.
В 1998 Стив Макконнелл (Steve McConnell) назвал ее "конусом неопределенности" (источник + видео в конце статьи).
Главное
На рисунках ниже показаны первоначальные границы неопределенности Боэма по мере развития проекта в последовательном процессе (каскадная, водопадная модель, waterfall) и МакКоннела.- На этапе оценки проекта оценка обычно отклоняется от истины на 60–160% по Боэму и в 4 раза по МакКоннелу. Например, оцениваемый в 10 недель проект может занять от 6 до 16 недель.
- После формулирования требований оценка может отклоняться на ±15% в любом направлении по Боэму и в 1,5 раза по МакКоннелу. При плановом сроке 10 недель может занимать от 8,5 до 11,5.
- И так далее, постепенно сужая границы.
Важно! Если не стараться снижать неопределенность, то границы ошибки не будут сокращаться, и вместо конуса вы получите "облако неопределенности", как показано ниже на розовых рисунках.
Дополнительно
Рисунок из книги Майка Кона "Agile. Оценка и планирование проектов":
Светло-розовое облако неопределенности образуется, если вы не занимаетесь активным прояснением/уточнением:
Если вы активно стараетесь прояснять требования, проектные решения, получаете обратную связь от пользователей, то облако сокращается до конуса:
Эту тему мы подробно обсуждаем с группой на курсе "Основы Agile и Scrum". Полный список курсов и воркшопов читайте здесь.
Читайте также:
- Итеративная модель
- Спринт в Скраме
- Водопадный процесс (каскадный, waterfall)
Источники:
- Construx's The Cone of Uncertainty
- Managing Size Creep in Software Development Projects @ PMI.org
- Видео по теме от самого Steve McConnell: