Рекомендації для випуску версій рішення
Випуск версій рішення допомагає укріпити взаємини між проектною командою і замовником і забезпечити реалізацію в рішенні всіх кращих ідей. Замовникові буде легко погодитися з перенесенням реалізації певних можливостей на пізніші версії, якщо у нього є довіра до проектної групи, заснована на своєчасному постачанні початковою і подальших версій рішення. Ось загальні рекомендації, що полегшують випуск проміжних версій рішення:
• Створюючи плани, передбачайте версіонування.
• Перш за все, поставляйте базову функціональність.
57
• Вибирайте пріоритети, враховуючи ризики.
• Здійснюйте часті ітерації розробки.
• Інституціюйте процедури контролю змін в проекті
• Не створюйте нових версій, якщо вони не збільшують цінність рішення.
Створюючи плани, передбачайте версіонування
Завчасне планування подальших версій дозволяє проектній групі чіткіше прояснити, що повинне бути створене зараз, і з чим можна почекати. Створення довгострокового графіка введення в рішення нової функціональності дає можливість використовувати доступні ресурси і час найкращим чином і уникнути небажаного розповзання рамок проекту.
Перш за все, поставляйте базову функціональність
Надання замовникові простого, компактного, але такого, що відповідає основним потребам рішення має велику цінність, ніж розробка наиполнейшей версії, яка виготовлятиметься тижні, місяці, роки... Упровадивши базову функціональність, розробники отримують міцний фундамент, на основі якого може бути продовжене розвиток рішення. Проектна група також отримує відгуки від замовника, що допомагають вибирати найбільш адекватний шлях еволюції рішення.
|
|
|
Вибирайте пріоритети, враховуючи ризики
Проведення проектною групою оцінювання рисок дозволяє виявити, реалізація якої функціональності зв'язана з найбільшими з них. Докладна інформація про ризики може бути отримана з "Білої книги" дисципліни управління ризиками MSF.
В першу чергу плануйте реалізувати найбільш ризиковані нововведення і зміни і лише після них – менш ризиковані. Наприклад, завдання, пов'язані з великими змінами в архітектурі, має сенс виконати на ранніх етапах проекту, мінімізуючи тим самим вплив цих змін на бюджет і календарний графік.
Здійснюйте часті ітерації розробки
Істотний виграш від версионирования (versioning) рішення полягає в наданні замовникові в адекватні терміни придатного до експлуатації рішення, яке потім послідовно поліпшується. Якщо в цьому процесі відбуваються затримки, то надії замовника на постійне поліпшення продукту виявляються невиправданими. Тому обмежуйте рамки кожної ітерації рішення, щоб створення нової версії відбувалося в прийнятні терміни.
|
|
|
Інституціюйте процедури контролю змін в проекті
Як тільки завершено створення базової версії специфікації, повинен бути негайно введений контроль за змінами планованої функціональності рішення. Принципово важливо, щоб вся проектна група і замовник чітко розуміли значення такого контролю і його процедури.
MSF не наказує конкретний набір правил контролю за змінами. Залежно від розміру і типу проекту , ці процедури можуть бути простими або складними. Проте для забезпечення ефективності контролю необхідна наявність наступних елементів:
• Без аналізу і схвалення як з боку проектної групи, так і з боку замовника запланована функціональність не розширюється і не змінюється.
• В цілях полегшення проведення аналізу запити на зміну функціональності подаються письмово. Це дозволяє групувати подібні запити. У майкрософті вони називаються
запитами на зміну дизайну (design change requests – DCRs) (думаю, що є зважаючи на сам процес групування, і тоді DCR повинне переводитися, напевно, як «організація запитів про зміни»).
|
|
|
58
• Повинні бути проаналізовані вплив, здійсненність і пріоритет кожного запиту на введення нової функціональності. При цьому повинні бути враховані взаємозв'язку з іншими складовими рішення, включаючи призначену для користувача документацію, документацію супроводу, учбові матеріали і виробниче середовище.
• Для кожної запрошуваної зміни повинен бути визначене його вплив на бюджет і календарний графік проекту (деталі див. в розділі "Оцінка від низу до верху").
• Повинні бути визначені члени групи контролю за змінами (change control board), що затверджує або відкидає запитані зміни. До цієї групи повинні входити представники замовника, ролевого кластера "Управління програмою" і інші представники проектної групи і інших зацікавлених сторін. Група контролю за змінами може формуватися різним чином, але, у будь-якому випадку, вона повинна мати повноваження вносити зміни до бюджету, календарний графік і функціональність рішення.
• Повинен вестися моніторинг змін, і всі його результати повинні бути легко доступи. Наприклад, хорошою практикою є створення у функціональній специфікації і інших важливих проектних документах секції для протоколювання змін.
• Ефективне управління змінами можливо тільки при ефективному управлінні конфігураціями.
Дата добавления: 2018-05-09; просмотров: 241; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!