Процес контролю змін
Процес контролю змін дозволяє керівнику проекту приймати інформоване бізнес-рішення, яке задовольняє клієнта і має комерційну цінність, при цьому контролюються витрати на життєвий цикл продукту. Можна відслідковувати статус усіх запропонованих змін і переконатися, що запропоновані вимоги не були втрачені або втрачені. Після затвердження базової версії набору вимог потрібно дотримуватись цього порядку для внесення всіх пропонованих змін до неї.
Клієнти та інші зацікавлені особи часто ухиляються від нового процесу, проте процес контролю змін - не перешкода для модифікації. Це механізм підсумовування та фільтрації, що дає впевненість, що в проект включені найбільш цінні зміни.
Якщо запропонована зміна не настільки важлива, щоб зацікавлена в проекті особа витратила пару хвилин на передачу її через стандартні, прості канали, то варто замислитися про її цінності взагалі. Процес управління повинен бути ретельно задокументований, максимально простий і, що найважливіше, ефективний. Після реєстрації запиту на зміну слід прийняти рішення про його подальшу долі. Рада з управління змінами (change control board, CCB) (іноді її називають радою з управління конфігурацією) була визначена кращим практичним рішенням при розробці ПЗ.
На практиці функції Ради можуть бути делеговані і одній людині (залежно від розмірів проекту). Запит на зміну може бути прийнятий, або відхилений. У першому випадку його необхідно включити в план робіт над проектом, у другому - сформулювати мотивовану відмову.
При прийнятті рішення за запитом необхідно виходити: а) зі ступеня важливості запиту для Замовника, і б) з його вартості для Розробника. Вартість визначається на підставі аналізу впливу зміни.
Процес контролю змін
Рис. Шаблон опису процесу контролю змін
Введення
У вступі описується призначення процесу і визначаються організаційні межі, в яких він застосовується. Якщо цей процес торкається тільки зміни в певних продуктах, їх слід визначити тут. Також вказується, чи існують якісь спеціальні види змін, які не підлягають контролю, наприклад зміни в проміжних або службових продуктах, створених в ході проекту.
Ролі та відповідальності
Необхідно перелічити членів команди - за ролями, не по іменах, які беруть участь у процесі контролю змін, і описати їх обов'язки. На рис. наведені деякі типові ролі; їх можна адаптувати відповідно до конкретної ситуації. Кожна людина може виконувати кілька ролей. Наприклад, голова ради з управління змінами також може отримувати запити, що подаються на зміни. У невеликих проектах декілька, а можливо, і всі ролі виконуються однією людиною.
Рис. Можливі ролі учасників проекту при управлінні змінами
Стан запиту на зміну
Запит на зміну проходить через певні стадії протягом життєвого циклу, причому на кожній стадії він має різні статуси. Можна уявити ці зміни стану, використовуючи діаграму переходу станів. Потрібно оновлювати стан запиту, тільки коли задовольняються певні критерії.
Вхідний критерій
Основним вхідним критерієм для процесу контролю змін є дійсний запит на зміну, отриманий за затвердженими каналах. Всі потенційні ініціатори запитів повинні знати, як подавати запити на зміну, незалежно від того, відправляють вони його, заповнюючи паперову форму або Web-форму, відправляючи повідомлення по електронній пошті або використовуючи засіб контролю змін. Необхідно призначити кожному запиту на зміну унікальний ідентифікатор і направити їх всіх до єдиної точки контакту - одержувачу запиту.
5. Завдання
Наступний крок - це оцінка запиту на предмет технічної здійсненності, витрат і відповідності бізнес-вимогам проекту і обмеженням ресурсів. Голова ради з управління змінами може призначити співробітника для оцінки впливу зміни, аналізу ризику, аналізу небезпеки та ін.. Аналіз дозволяє переконатися, що ймовірні наслідки зміни ясні. Той, кому доручено оцінка, і члени ради з управління змінами повинні також розглянути комерційні і технічні наслідки відхилення зміни. Потім уповноважені члени ради з управління змінами вирішують, затвердити або відхилити запитану зміну. Рада з управління змінами привласнює кожній схваленій зміні рівень пріоритету, або призначає дату реалізації, або призначає цю зміну визначеній збірці або номером версії. Далі рада з управління змінами оповіщає про рішення, оновлюючи стан запиту і повідомляючи всіх членів команди, які займаються модифікацією. Після цього необхідно оновити: документацію вимог, опис дизайну і моделей, компоненти для користувача інтерфейсу, код, документацію тестування, екрани довідки та керівництва для користувачів. Той, хто вносить зміни, робить це встановленим шляхом.
6. Перевірка
Зміни вимоги, як правило, перевіряють за допомогою експертної оцінки, щоб переконатися, що змінені вимоги, варіанти використання і моделі відповідним чином відображають усі аспекти зміни. Інформація про трасуванню допоможе знайти всі частини системи, які ця зміна зачіпає і які, як наслідок, необхідно перевірити. Доручіть декільком членам команди перевірити зміни за допомогою тестування або експертизи. Після цих процедур той, хто займається перевіркою, що встановлює оновлені продукти, зробивши їх доступними іншим членам команди, і перевизначає базову версію, в якій враховані зміни.
7. Вихідний критерій
Всі перераховані далі вихідні критерії повинні бути задоволені, щоб належним чином завершити процес управлінь змінами:
- стан запиту: Rejected (Відхилено), Closed (Закрито) або Canceled (Скасовано);
- всі зміни записані у відповідних розділах;
- ініціатор запиту, голова ради з управління змінами, менеджер проекту та інші значущі учасники проекту оповіщені про деталі зміни і поточний стан запиту на зміну; - матриця зв'язків вимог оновлена.
8. Звіт про стан управління зміни
Необхідно визначите графіки і звіти, які буде використано при узагальненні вмісту бази даних контролю змін. Зазвичай на цих графіках показано кількість запитів на зміну в кожній категорії стану як функція часу. Менеджер проекту використовує ці звіти при контролі станів проекту.
Рада з управління змінами
Рада з управління змінами (change control board, CCB) (іноді її називають радою з управління конфігурацією) була визнана кращим практичним рішенням при розробці ПЗ (McConnell, 1996), Це група людей, незалежно від того, скільки їх-одна людина чи декілька, приймаюча рішення про те, які запропоновані зміни вимог і нові функції прийняти для включення в продукт. Рада з управління змінами також вирішує, які виявлені помилки варто виправити і коли. Офіційне призначення ради з управління змінами дозволяє визначити його структуру та повноваження, а також призначити робочі процедури.
Рада з управління змінами переглядає і затверджує зміни базових версій будь-якої документації проекту, наприклад специфікації вимог. Деякі ради мають повноваження для прийняття рішень і просто інформують менеджерів про внесення цих змін, тоді як інші можуть тільки давати рекомендації менеджерам для прийняття рішень. У невеликому проекті має сенс делегувати прийняття рішень одному або двом співробітникам. У великих проектах та програмах може бути кілька рівнів рад контролю змін: одні відповідають за прийняття бізнес-рішень, наприклад про зміну вимог, а інші за рішення технічного характеру. Рада з управління змінами більш високого рівня затверджує зміни, що дуже сильно впливають на проект. Наприклад, при розробці великої програми, що об'єднує кілька проектів, слід створити раду, що приймає рішення на рівні програми, і окремі поради для кожного проекту. Останні вирішують проблеми і розглядають зміни, що впливають тільки на конкретний проект. Питання, що стосуються інших проектів, і зміни, в результаті яких можливе перевищення витрат або порушення графіка, передаються до ради рівня програми.
Для деяких людей термін «рада з управління змінами» означає неекономічні бюрократичні накладні витрати. Однак це цінна структура, яка допомагає керувати навіть невеликим проектом. Вона не повинна забирати багато часу або бути громіздкою - вона повинна працювати ефективно. Це означає, що Рада з управління змінами розглядає всі запропоновані зміни швидко і приймає своєчасні рішення на підставі аналізу можливого впливу і переваг кожної пропозиції. Ця структура повинна бути не більше і не офіційніше, ніж необхідно для того, щоб упевнитися, що відповідні особи приймають правильні бізнес-рішення по кожній запитуваній зміні.
Склад ради з управління змінами
Члени ради з управління змінами повинні представляти всі групи, яким необхідно приймати участь у прийнятті рішень у межах повноважень ради. Учасники представників наступних областей:
менеджерів проекту або програми;
менеджерів продукту або аналітики вимог;
розробників;
фахівців з тестування або перевірці якості:
маркетологів або представників клієнта;
фахівців, відповідальних за інформацію користувача, документацію;
фахівців технічної служби або служби підтримки;
фахівців з управління конфігурацією.
Тільки деякі з них будуть приймати рішення, проте всіх їх слід проінформувати про рішення, що впливають на їх роботу.
Статут ради з управління змінами
У статуті описуються завдання, область повноважень, членство, виробничі процедури та процес прийняття рішень ради з управління змінами.
В уставі має бути вказана регулярність запланованих нарад і умови скликання спеціальних зустрічей.
Область повноважень вказує, які рішення рада може приймати, а які слід передати раді вищого рівня або менеджера.
Прийняття рішень. Як і всі структури, що приймають рішення, кожна рада з управління змінами повинна визначити відповідні правила та процес прийняття рішення. В описі процесу прийняття рішення слід зазначити таке: - скільки членів ради з управління змінами або осіб, що виконують ключові ролі, складають кворум для прийняття рішень;
чи використовується голосування, консультативний спосіб чи будь-яке інше правило прийняття рішень;
чи може голова ради з управління змінами відхилити колективне рішення ради; - чи повинна рада з управління змінами більш високого рівня або хто-небудь ще ратифікувати рішення.
Рада з управління змінами зважує передбачувані переваги і передбачуване вплив прийняття запропонованої зміни. До переваг належать: економія коштів, збільшення доходу, більше задоволення покупців і конкурентні переваги. Вплив від зміни враховує негативний ефект, яке зміна може зробити на продукти або проект. До них відносяться: збільшення витрат на розробку і підтримку, затримка постачання, зниження якості продукту, зменшення функціональності невдоволення клієнтів. Якщо прорахований вплив на витрати або графік перевищує допустимий поріг повноважень для даної ради, передаються зміни для розгляду менеджменту або раді з управління змінами більш високого рівня. В іншому випадку; процес прийняття рішень ради з управління змінами допоможе затвердити або відхилити запропоновану зміну, Повідомлення про стан
Після того як рада з управління змінами приймає рішення, уповноважений співробітник оновлює стан запиту в базі даних змін. Деякі засоби автоматично генерують повідомлення електронної пошти, щоб інформувати про новий стан ініціатора запиту і всіх, кого зачіпає це зміна Якщо повідомлення електронної пошти не генерується автоматично проінформуйте зацікавлених фахівців особисто для того, щоб вони змогли правильно прийняти цю зміну.
Аналіз впливу зміни
Аналіз впливу забезпечує точне розуміння підтексту запропонованої зміни, що допомагає команді приймати інформовані бізнес-рішення про те, яку зміну схвалити. Аналіз дозволяє виявити компоненти, які можуть знадобитися створити, змінити або відхилити, і оцінити витрати, пов'язані з реалізацією зміни. До того, як розробник відповість: «Звичайно, без проблем», він повинен витратити час на аналіз результату зміни. Голова ради з управління змінами зазвичай просить досвідченого розробника виконати аналіз визначеного результату.
Аналізу результатів змін зачіпає три аспекти.
Визначення можливих наслідків зміни. Часто вони викликають значний хвильовий ефект. Включення безлічі функцій в продукт може знизити його продуктивність до неприйнятного рівня, наприклад, коли системі, яка завантажується щодня, знадобиться 24 години для завершення одного запуску.
Визначення всіх файлів, моделей та документів, які, можливо, доведеться змінити, якщо команда включить всі запитані зміни.
Визначення задач, необхідних для реалізації зміни, і оцінка зусиль, необхідних для виконання цих завдань.