Принципи моделі процесу розробки

 

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

– випуск версій продукту;

– постійно «живі» документи;

– планування процесу з урахуванням невизначеностей;

– пошук компромісів;

– керування ризиками;

– орієнтація на випуск продукту в строк;

– розбивка більших проектів на керовані частини;

– щоденне складання продукту;

– контроль «знизу – нагору».

Випуск версій

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

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

– Контакт із замовником.

– Рання версія.

– Обмежене коло розв'язуваних питань.

– Ясність цілей.

– Воля й гнучкість.

– Послідовне й постійне розширення функціональних можливостей продукту.

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

«Живі» документи

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

Планування процесу

Невизначеність і непередбачуваність неминучі. Раз вуж життя повне несподіванок, у плані проекту повинна враховуватися можливість появи непередбачених факторів. Рекомендуємо два підходи до цього нелегкого завдання: резерв часу й планування на основі ризиків.

Резерв часу

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

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

Резервний час не розподіляється між окремими етапами – вони як і раніше повинні завершуватися в строк за графіком. Додавання резервного часу до графіка приводить до появи двох дат випуску. При складанні графіка «знизу – нагору» визначається внутрішня дата випуску. Додавши до неї резервний час, ви одержите зовнішню дату випуску для замовника.

Планування з урахуванням ризиків

Це спосіб, при якому завдання з високим ступенем ризику одержують високий пріоритет, а завдання, сполучені з малим ризиком, – низький. Якщо завдання, пов'язане з високим ступенем ризику, зажадає більше часу, такий план дозволить збільшити виділений час. Переваги:

– він стимулює раннє створення прототипів, що перевіряють коректність концепцій;

– дозволяє швидко вирішити, який набір функціональних можливостей коли випускати;

– дозволяє розставити пріоритети на основі технічних і бізнес-ризиків;

– стимулює розробників прагнути до раннього випуску продукту;

– у випадку недотримання дати випуску дозволяє швидко з'ясувати причини й знайти необхідні компроміси;

– виявлення ризиків, найнебезпечніших для проекту, дозволяє досягти розуміння із замовником.

Пошук компромісів

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

 

Важливо пам'ятати, що три сторони компромісного трикутника взаємозалежні. Зміна однієї з них впливає на інші. Розуміння й застосування цієї концепції дає проектній групі потужний інструмент адекватної реакції на зміну вимог або умов у ході проекту.

Хоча компромісний трикутник – простий і ефективний інструмент, він не відбиває пріоритетів складових його елементів. Один з методів опису пріоритетів і уточнення очікувань проектної групи й замовника – створення матриці альтернатив, приклад якої наведений у таблиці 1.1. Така матриця дозволяє замовникові й групі погодити важливість різних сторін компромісного трикутника і їхні пріоритети: останнє важливо, коли доводиться вирішувати, чим поступитися при пошуку компромісу.

Табл. 1.1. Приклад матриці альтернатив

	Проект 1	Проект 2
Оптимізація	Обмеження	Як вийде	Оптимізація	Обмеження	Як вийде
Ресурси		√		√
Дата випуску	√					√
Характеристики			√		√

 

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

– Оптимізація – вимагає найкращого значення елемента наприкінці проекту.

– Обмеження – обмеженої змінної просто привласнене фіксоване значення; зміст обмеження ресурсів ясний, обмеження дати випуску означає випуск продукту в заданому тимчасовому інтервалі, а обмеження характеристик – це стратегія випуску продукту з базовим набором функціональних можливостей.

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

Матриця альтернатив – зручний метод прийняття рішень. Вона не є істиною в останній інстанції, однак допомагає досягти взаєморозуміння із замовником. Корисність матриці альтернатив для проектної групи визначається тим, що вона вказує області, якими замовник готовий поступитися.

Керування ризиками

Для більшості проектів керування ризиками – найважливіший фактор успіху. Щоб упоратися із проектом, проектна група повинна:

– навчатися;

– швидко адаптуватися до змін;

– передбачати зміни;

– діяти ефективно.

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

Існує два принципово різних підходи до керування ризиками. Більшість груп як метод керування ризиками практикують реагування – вони так чи інакше реагують на вже виниклу проблему. Другі – прихильники превентивного керуванні ризиками. Цей підхід, припускає наявність продуманого плану й процесу керування ризиками до їхньої реалізації, тобто до виникнення проблеми. Процес керування ризиками повинен бути не тільки продуманим, але й постійним. При превентивному керуванні ризики постійно контролюються, а інформація про стан найважливіших ризиків є основою для прийняття рішень на всіх стадіях проекту. Керування ризиками триває до їхнього зникнення або, якщо проблема все-таки виникла, до її усунення.

Орієнтація на випуск у строк

Орієнтація на випуск у строк означає відношення до дати випуску продукту як до імперативу. Природно, спочатку група планує виконання проекту й погодить із замовником всі елементи компромісного трикутника. Коли ж дата випуску погоджена, цей елемент компромісного трикутника більше не використовується при прийнятті яких-небудь рішень коригувального характеру (звичайно ж, за винятком безвихідних ситуацій).

Орієнтація на випуск продукту в строк має масу переваг.

– Мобілізує проектну групу – для випуску продукту в строк проектній групі прийде мобілізувати всі свої здатності.

– Розставляє пріоритети по ступені важливості завдань – функціональні можливості продукту впорядковуються по пріоритетах, щоб при необхідності можна було відмовитися від реалізації характеристик з низьким пріоритетом.

– Надає в розпорядження групи потужний інструмент прийняття рішень – всі рішення приймаються на основі їхнього зв'язку з випуском продукту в строк.

– Забезпечує мотивацію проектної групи – відсутність фіксованої дати випуску значно погіршує моральний клімат у колективі, створюючи відчуття безцільності.

Випуск продукту до фіксованої дати забезпечується плануванням «знизу – нагору» і наявністю резерву часу. Очевидно, ретельне планування є запорукою випуску продукту в строк.

Розбивка великих проектів на керовані частини

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

Кожний внутрішній випуск жадає від двох до чотирьох місяців; для кожного з них варто передбачити час і ресурси на розробку, оптимізацію, тестування й стабілізацію. Крім того, треба передбачити приблизно 25-процентний резерв часу на випадок непередбачених обставин. Для кожного внутрішнього випуску група розробки реалізує конкретний набір функціональних можливостей. Якщо він допускає тестування, група виконує повний цикл тестування, налагодження й повторного тестування, як якби продукт готувався до здачі замовникові. Коли якість коду стане задовільним, група переходить до розробки наступного набору функціональних можливостей. Цей метод також дозволяє уникнути проблем, які характерні для інтеграції всіх компонентів великого проекту лише на останній стадії.

Щоденне складання

Звичайно в ході проекту доводиться «збирати» виконується модуль, що (або модулі) із сотень або навіть тисяч вихідних файлів. Деякі проектні групи практикують щоденне складання додатка з наступною перевіркою працездатності модуля, що виконується. Така перевірка дуже важлива – без її щоденне складання додатка не має змісту.

Щоденне складання має кілька важливих переваг:

– мінімізує ризики, пов'язані з інтеграцією коду – при щоденному складанні проблеми цього сорту виявляються на ранній стадії, що дозволяє вчасно налагодити модуль, що викликав проблему, або змінити відповідне проектне рішення;

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

– знижує ризик падіння якості.

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

Стандарти щоденного складання й тестування в різних проектах розрізняються, однак можна порекомендувати наступні мінімальні вимоги:

– удала компіляція всіх файлів і компонентів;

– удале складання всіх модулів і компонентів;

– відсутність помилок, що перешкоджають запуску додатка;

– проходження тесту на працездатність.

Планування «знизу – нагору»

Роботу повинні планувати ті, хто неї робить. Це:

– підвищує точність оцінок – оскільки в цьому випадку вони засновані на досвіді конкретного розробника, що вже вирішував подібні завдання, а не взяті «зі стелі» керівником;

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