Характеристики модели процессов MSF

Главные и промежуточные вехи

• 
  Главные вехи служат точками перехода от одной фазы к другой. Они также определяют изменения в текущих задачах ролевых кластеров.
  
• 
  В MSF используются обобщенные главные вехи, большинство из которых применимо к любому типу IT проектов.
  
• 
  Промежуточные вехи показывают достижение в ходе проекта определенного прогресса и расчленяют большие сегменты работы на меньшие, обозримые участки.
  
• 
  Промежуточные вехи могут варьироваться от проекта к проекту. MSF рекомендует использовать определенный набор промежуточных вех, но на практике проектная группа может сама устанавливать их в соответствии с особенностями своей работы.
  

Вехи как точки синхронизации

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

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

Вехи как ориентиры производственной ответственности

Хотя ролевой кластер “Управление программой” организует работу над проектом в целом, на каждой из фаз определенные ролевые кластеры имеют ведущее значение. Объем работы, выполняемой различными ролевыми кластерами, меняется в процессе перехода проекта из одной фазы в другую. Использование проектных вех помогает должным образом организовать эти переходные процессы.

Ведущие роли различных фаз

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

Веха	Ведущие ролевые кластеры
Концепция утверждена	Управление продуктом
Планы проекта утверждены	Управление программой
Разработка завершена	Разработка, Удовлетворение потребителя
Готовность решения утверждена	Тестирование, Управление выпуском
Внедрение завершено	Управление выпуском

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

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

Итеративный подход

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

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

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

MSF рекомендует начинать разработку решения с построения, тестирования и внедрения его базовой функциональности. Затем к решению добавляются все новые и новые возможности. Такая стратегия именуется стратегией версионирования. Несмотря на то, что для малых проектов может быть достаточным выпуск одной версии, рекомендуется не упускать возможности создания для одного решения ряда версий. Рис. 7 показывает, как с созданием новых версий эволюционирует функциональность решения.

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

7. 
   Версионирование
   

жүктеу/скачать 0.88 Mb.

Достарыңызбен бөлісу: