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

Віхи як орієнтири виробничої відповідальності

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

Провідні ролі різних фаз

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

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

Аналіз пройдених віх

Кожна головна віха надає можливість осмислити і витягувати уроки з фази, що тільки що завершилася. Аналіз пройдених віх під час спеціальних зборів (post-milestone reviews), що проводяться, допомагає підвищити віддачу від такого осмислення. MSF окремо розглядає збори, на яких результати фази обговорюються разом із замовником і іншими зацікавленими сторонами (milestone reviews), і подальше лікування уроків усередині колективу (postmilestone reviews). Остаточні збори такого роду проводяться вже після завершення проекту. У деяких організаціях вони носять назву постмортемів (postmortems).

Ітеративний підхід

Характеристики ітеративного підходу

Ітеративний підхід до процесу розробки широко використовується в MSF. Програмний код, документація, дизайн, плани і інші робочі матеріали створюються, як правило, ітеративними методами.

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

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

55

для одного вирішення ряду версій. Рис. 7 показує, як із створенням нових версій еволюціонує функціональність рішення.

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

Створення "живої" документації

Ітеративний підхід до процесу розробки вимагає використання гнучкого способу ведення документації. "Живі" документи (living documents) повинні змінюватися у міру еволюції проекту. Такий підхід істотно відрізняється від принципів ведення документації в каскадній моделі, де процес розробки починається лише після того, як готові і зафіксовані всі вимоги і специфікації.

Документація проектів MSF, також як і програмний код, розробляється ітеративно. Часто, плани спочатку мають форму опису високорівневих "підходів" ("approaches"). На фазі вироблення концепції вони розповсюджуються серед членів проектної групи і інших зацікавлених осіб для отримання відгуків. Після переходу до фази планування ці документи поступово допрацьовуються. Розроблені детальні плани знову поступають на перевірку всім зацікавленим сторонам, і описаний процес повторюється ітеративно. Типи планів і загальна кількість документів, що описують їх, можуть варіюватися від проекту до проекту.

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

Ранні базові версії, відкладені підсумкові версії

Створення базових (попередніх) версій проектних документів на раніших етапах (baseline early) дає членам проектної групи можливість почати роботу над своїми завданнями з мінімальними затримками. Аналогічно, відкладена на максимально довгий термін остаточна фіксація документів (freeze late) дозволяє вносити до них життєво важливі зміни впродовж всього етапу розробки. Але така гнучкість вимагає дуже уважного відношення до контролю за змінами (tracking changes). Дуже важливо забезпечити їх належний моніторинг і виключити можливість несанкціонованої зміни проектній документації.

Щоденні білди

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

56

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

Великі, складні проекти часто розділяються на менші під-проекти, кожен з яких розробляється і тестується окремою командою і потім вливається в загальне рішення. Для таких проектів, типових в практиці розробки продуктів майкрософтом, щоденні білди (daily builds) є фундаментальній, невід'ємній складовій робочого процесу. В першу чергу розробляється базова функціональність рішення, і лише потім створюються додаткові його можливості. Розробка і тестування ведуться безперервно і одночасно, будучи паралельними процесами. Щоденні білди служать верифікацією сумісності всієї розробленої програмної коди і дозволяють групам напрямів просуватися в своїй роботі до наступних ітерацій розробки і тестування.

Відмітимо, що щоденні білди рішення не потрапляють в реальне виробниче середовище. Лише після того, як рішення добре протестоване і стабілізоване, здійснюється його пілотний (або бета) випуск, що частково встановлюється в виробниче середовище.

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

Управління конфігураціями проекту

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

Управління конфігураціями часто плутають з управлінням змінами в проекті (project change control), обговорюваним нижче. Насправді ці два завдання взаємозв'язані, але не ідентичні. Управління конфігураціями – це протоколювання і контроль станів елементів проекту. Управління ж змінами – це процес розгляду і схвалення проектних змін. Управління конфігураціями забезпечує проектну групу інструментами, необхідними для ефективного управління змінами.

Наприклад, проектна група працює над електронною системою викликів медичної допомоги, що зв'язує мережу лікарень. Вона зберігає настройки, вибрані для сервера Microsoft® BizTalk®, і відстежує зміни, вироблювані в ході розробки і тестування. Це приклад управління конфігурацією. Потім, слідуючи недавно прийнятому урядовому нормативному акту, вноситься пропозиція доповнити систему новою схемою електронного обміну даними (EDI). Керівники проектної групи зустрічаються із спонсором і членами команди супроводу, щоб проаналізувати запропоновані зміни, оцінити їх технологічні ризики і вплив на вартість і календарний графік проекту. Це приклад контролю за змінами.

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

Рекомендації для випуску версій рішення

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

•Створюючи плани, передбачайте версіонування.

•Перш за все, поставляйте базову функціональність.

57

•Вибирайте пріоритети, враховуючи ризики.

•Здійснюйте часті ітерації розробки.

•Інституціюйте процедури контролю змін в проекті

•Не створюйте нових версій, якщо вони не збільшують цінність рішення.

Створюючи плани, передбачайте версіонування

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

Перш за все, поставляйте базову функціональність

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

Вибирайте пріоритети, враховуючи ризики

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

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

Здійснюйте часті ітерації розробки

Істотний виграш від версионирования (versioning) рішення полягає в наданні замовникові в адекватні терміни придатного до експлуатації рішення, яке потім послідовно поліпшується. Якщо в цьому процесі відбуваються затримки, то надії замовника на постійне поліпшення продукту виявляються невиправданими. Тому обмежуйте рамки кожної ітерації рішення, щоб створення нової версії відбувалося в прийнятні терміни.

Інституціюйте процедури контролю змін в проекті

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

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

•Без аналізу і схвалення як з боку проектної групи, так і з боку замовника запланована функціональність не розширюється і не змінюється.

•В цілях полегшення проведення аналізу запити на зміну функціональності подаються письмово. Це дозволяє групувати подібні запити. У майкрософті вони називаються

запитами на зміну дизайну (design change requests – DCRs) (думаю, що є зважаючи на сам процес групування, і тоді DCR повинне переводитися, напевно, як «організація запитів про зміни»).

58