Помните миф о кратном удорожании исправления дефектов на поздних стадиях разработки, в 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 дней! Ещё дороже — изменения
организации на этапе требований.
В общем, есть выбор — смерть от нескольких радикальных изменений концепции на последней стадии, или "смерть от тысячи порезов": мелких багов спеки. Это значит, что есть потенциал для улучшения — можно сэкономить целых 31%! Не сотни раз, но тоже немало.
