Помните миф о кратном удорожании исправления дефектов на поздних стадиях разработки, в 100 и 1000 раз? Но нас в первую очередь интересует разработка требований, что тут будет дефектом? Можно отследить изменения требований, их источники и влияние на проект. И тут есть исследование 2011 года 'Software Requirements Change Taxonomy: Evaluation by Case Study' — "Таксономия изменений требований: оценка на основе кейса". Авторы указывают следующие источники изменений в требованиях: Рынок (включая сюда регуляторные требования); Организация-потребитель — изменения, связанные со сменой стратегического направления одного из потребителей / изменения договоров / политического климата; Концепция проекта — поменялась решаемая проблема, направление развития продукта, приоритеты, стейкхолдеры или процессы; Спецификация — уточнение спецификации для устранения неопределенности, двусмысленности, несогласованности, повышения понимания (это как раз можно отнести к дефектам требований); * Техническое решение — изменения, отражающие технические ограничения, принципиально новый дизайн или элегантность решения. К внутренним причинам можно отнести только спецификацию — остальное меняется из-за внешних факторов. В статье рассмотрен один проект из британского госсектора, стоимостью более миллиона фунтов (45-50 млн. руб по курсу 2010 г.), выполненный по водопадному подходу (был конкурс и внешний подрядчик) и длившийся примерно полтора года — в общем, похоже на довольно типовой проект. Всего в требования было внесено 282 изменения: 67 на этапе сбора, 97 — при проектировании и разработке, 9 на этапе системного тестирования и 109 на этапе приемки пользователями. По источникам на разных этапах они распределились так: — этап требований: 30 — организация; 22 — спецификация; 15 — концепция. — этап разработки: 58 — спецификация; 33 — решение; 4 — организация; по 1 — концепция и рынок. — этап системного тестирования: 5 — спецификация; 3 — решение; 1 — концепция. — этап приемки пользователями: 102 — спецификация; 7 — концепция. В сумме, для 187 изменений из 282 источником была сама спецификация — её уточняли, дополняли и детализировали. На втором и третьем месте с небольшим разрывом между собой, но с огромным отставанием от спецификации — решение (36) и организация (34). Так как это внутренний проект для одной организации, рынок тут практически не стал источником изменений (и в дальнейшем его не анализировали). Дальше интереснее — нам важно не количество изменений, а их влияние на перерасход бюджета проекта, причем бюджета в человеко-днях. Ведь в деньгах можно намерять много чего (часто при измерении в деньгах сбиваются со стоимости исправления на стоимость последствий), а потраченные дополнительные человеко-дни — более объективная характеристика. Стоимость задержки по источникам изменений и этапам, по убыванию: 1. Изменения спецификации на этапе приемки пользователями: 737 дней(!) 2. Изменения организации на этапе требований: 638 дней 3. Изменения концепции на этапе требований: 266 дней 4. Спецификация на этапе разработки: 222 5. Спецификация на этапе требований: 194 6. Концепция(!) на этапе приемки пользователями: 163 (!) + по мелочи Изменения распределились в форме ванны: 46% (1097 человеко-дней) на этапе работы с требованиями и 38% (900 человеко-дней) — на этапе приемки. Делаем вывод: отложенный фидбэк — путь к запланированным переделкам. Изменение требований на этапе сбора требований — нормальный рабочий процесс, а вот на приемке этого хотелось бы избежать. Но самое интересное — удельный вес изменений в зависимости от источника. Да, косяков в спецификации больше всего. Но в основном они мелкие: медианное значение — 4 дня. А вот одно изменение концепции на этапе приемки "стоит" 20 дней! Ещё дороже — изменения организации на этапе требований. В общем, есть выбор — смерть от нескольких радикальных изменений концепции на последней стадии, или "смерть от тысячи порезов": мелких багов спеки. Это значит, что есть потенциал для у