Часті ітерації розробки і впровадження

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

Уникання розповзання рамок проекту

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

Оцінка з низу до верху

У IT-проектах попередні оцінки тривалості завдань, їх вартості і тому подібне повинні виходити від тих, хто потім виконуватиме оцінювану роботу. Підхід "від низу до верху" (bottom-up estimating) дає наступні переваги:

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

Відповідальність. Ті, хто використовує в роботі власні оцінки, відчувають велику відповідальність, як за свою роботу, так і за адекватність зроблених оцінок.

Уповноваженість (empowerment) проектної групи. Календарний графік, складений самою проектною групою, а не продиктований зверху керівництвом, надихає проектну групу, оскільки він складений на основі тих оцінок, які самі члени проектної групи вважають реалістичними.

Інтеграція представлених проектною групою оцінок

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

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

Застосування A

Зміни в порівнянні з попередньою версією MSF

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

Спершу була розроблена модель процесів для розробки застосувань (Application Development - AD). Її метою була консолідація всього кращого з культури і процесів, продуктів майкрософту, що використовуються командами, для створення програмного забезпечення і його розповсюдження серед замовників і партнерів.

Пізніше клієнти майкрософту почали потребувати аналогічного керівництва для великомасштабного впровадження програмних продуктів і апаратного забезпечення на своїх підприємствах. Щоб задовольнити цю потребу, модель розробки застосувань була адаптована до моделі процесів впровадження інфраструктури (Infrastructure Deployment - ID).

77