Вартість змін у командах розробників ПЗ (Cost of Change on Software Teams)

Мета - скоротити цикл зворотного зв'язку між командою та зацікавленими сторонами, щоб якомога швидше визначити потенційні зміни і таким чином зменшити середню вартість цих змін.

У 1970-х роках доктор Баррі Боем, дослідник комп'ютерних наук, виявив, що середня вартість виправлення дефектів зростає в геометричній прогресії, чим довше ми шукаємо дефект.

Доктор Боем продовжував досліджувати цю закономірність на початку 2010-х років і не дивно, що вона справедлива як для гнучких, так і для традиційних команд.

Середня вартість внесення змін

На рисунку 1 зображено поширені стратегії розгортання, нанесені на криву середньої вартості змін Боема. Як бачите, чим частіше ми випускаємо версії, тим нижча середня вартість внесення змін, а отже, більша ймовірність того, що ми зможемо розвивати наше рішення, щоб задовольнити мінливі потреби наших стейкхолдерів.

Порівняння середніх витрат на усунення потенційних дефектів залежно від того, коли і як вони були виявлені

Це означає, що ми хочемо впроваджувати методи тестування та якості, які мають короткий цикл зворотного зв'язку. На рисунку 2 ми нанесли різні методи на криву вартості змін. Автоматизація тестування має вирішальне значення для цього.

Ощадлива розробка програмного забезпечення також дає важливе розуміння важливості збільшення каденції випусків. Фундаментальним принципом ощадливої розробки є скорочення незавершеного виробництва (work in process - WIP), а ключовим способом досягти цього є менші виробничі випуски та частіше розгортання.

Зменшення незавершеного виробництва підвищує якість, що, в свою чергу, призводить до зниження витрат, і обидва ці фактори дають змогу випускати релізи швидше. Це доброчесний цикл вдосконалення. Зменшення WIP також призводить до зменшення потреби в управлінні роботою і в будь-якому переплануванні у зв'язку зі зміною потреб зацікавлених сторін, що призводить до зменшення накладних витрат і витрат.

Вартість змін (Cost of Change) в PMBOK® 7 (2.6.3.2)

Чим пізніше виявлено дефект, тим дорожче його виправити. Це пов'язано з тим, що роботи з проектування та розробки, як правило, вже були виконані на основі дефектного компонента. Крім того, змінювати діяльність у міру просування життєвого циклу дорожче, оскільки вона зачіпає більше зацікавлених сторін. Це явище характеризується кривою вартості змін (див. Рисунок 2-22).

Щоб протистояти впливу кривої вартості змін, проектні команди розробляють проектний процес, щоб вбудувати в нього якість. Цей підхід може включати аналітиків якості, які працюють з дизайнерами та інженерами, щоб зрозуміти і визначити, як найкраще досягти якості на кожному етапі життєвого циклу проекту.

Проактивна робота над якістю допомагає уникнути високої вартості змін, пов'язаних з виправленням проблем з якістю, виявлених на більш пізніх етапах життєвого циклу. Швидше та економічно ефективніше вирішити проблему дизайну двома інженерами, ніж проблему з компонентом, що впливає на сотні одиниць, або відкликати продукт, що впливає на тисячі клієнтів.

Джерела:

• https://www.pmi.org/disciplined-agile/agile/costofchange
• PMBOK® 7