Что такое MSF

Продолжаю публиковать конспекты семинаров по методологиям управления проектами.

Этот посвящен MSF. Автором семинара является мой коллега Антон Сальник. Конспект опубликован с его согласия.

Оглавление

Введение

Структура MSF

Модель проектной группы

Ролевые кластеры

Масштабирование модели проектной группы

Модель процессов

Вехи и фазы

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

Фазы и вехи модели процессов MSF

Фаза выработки концепци (Envisioning)

Фаза планирования (Planning)

Фаза разработки (Development)

Фаза стабилизации (Stabilizing)

Фаза внедрения(Deploying)

О чем еще рассказывается в модели процессов

Дисциплина управления проектами

Дисциплина управления рисками

Дисциплина управления подготовкой

Новые версии MSF

Литература

Масштабирование проектных групп

Таблица совместимости ролей

Введение

Microsoft Solutions Framework, далее MSF, представляет собой подход компании Microsoft к управлению IT-проектами. В данном обзоре будет рассмотрена версия 3.0 данной методологии, опубликованная в июне 2002 года.

Структура MSF

Технология MSF состоит из двух моделей:

• Модель проектной группы;

• Модель процессов.

И трех дисциплин:

• Дисциплина управления проектами;

• Дисциплина управления рисками;

• Дисциплина управления подготовкой.

Все они довольно подробно описаны в 5 whitepapers [1]. Рассмотрим все эти части более детально.

Модель проектной группы

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

К основным принципам и ключевым концепциям, определяющих проектную группу MSF относятся:

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

• Единое видение проекта. А именно единое четкое понимание целей и задач проекта.

• Распределение ответственности при фиксации отчетности.

• Нацеленность на необходимый заказчику конечный результат;

• Наличие у сотрудников необходимых полномочий;

• Открытое общение;

• Установка на отсутствие дефектов;

• Стремление к совершенствованию;

• Гибкость и готовность к переменам;

• Заинтересованность и энтузиазм.

Ролевые кластеры

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

Модель проектной группы MSF определяет шесть ролевых кластеров. Они ответственны за различные области компетенции (functional areas) и связанные с ними цели и задачи. Иногда ролевые кластеры называются просто ролями. Одна роль (или один кластер) может быть представлена одним или несколькими сотрудниками, в зависимости от размера проекта, его сложности и профессиональных навыков, требуемых для реализации всех областей компетенции кластера.

Управление продуктом

Цель: Удовлетворенные заказчики.

Область компетенций:

• Маркетинг;

• Бизнес-отдача (бизнес-приоритеты);

• Представление интересов заказчика;

• Планирование продукта.

Управление программой

Цель: Достижение результата в рамках проектных ограничений.

Область компетенций:

• Управление проектом;

• Выработка архитектуры решения;

• Контроль производственного процесса;

• Административные службы.

Разработка

Цель: Создание продукта в соответствии со спецификацией.

Область компетенций:

• Технологическое консультирование;

• Проектирование и осуществление реализации;

• Разработка приложений;

• Разработка инфраструктуры.

Тестирование

Цель: Одобрение выпуска продукта только лишь после того, как все дефекты выявлены и улажены.

Область компетенций:

• Планирование тестов;

• Разработка тестов;

• Отчетность по тестам.

Удовлетворение потребителя

Цель: Повышение эффективности пользователя, увеличение потребительской ценности продукта.

Область компетенций:

• Обеспечение технической поддержки;

• Обучение;

• Эргономика;

• Графический дизайн;

• Интернационализация;

• Общедоступность (обеспечение возможности работы для пользователей с ограниченными физическими возможностями);

Управление выпуском

Цель: Беспроблемное внедрение и сопровождение продукта.

Область компетенций:

• Инфраструктура;

• Сопровождение;

• Бизнес-процессы;

• Управление выпуском готового продукта.

• 
  

Принципы MSF формируют такой подход к управлению проектами, при котором:

• ответственность за управление проектом распределенная между лидерами ролевых кластеров внутри команды — каждый член проектной группы отвечает за общий успех проекта и качество создаваемого продукта.

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

Как следует из вышесказанного, одна из характерных особенностей MSF — отсутствие должности менеджера проекта!

Масштабирование модели проектной группы

Модель проектной группы MSF предлагает разбиение больших команд (более 10 человек) на малые многопрофильные группы направлений (feature teams). Эти малые коллективы работают параллельно, регулярно синхронизируя свои усилия.

• В одном ролевом кластере может быть много людей;

• Один человек может взять на себя несколько ролей;

• Большие коллективы:

  • создаем группы направлений;

  • создаем функциональные группы;

• Малые коллективы:

  • смотрим таблицу совместимости ролей (из таблицы можно сделать вывод, что минимальный размер команды – 3 человека: удовлетворение потребителя, управление продуктом, Тестирование; Управление программой и выпуском; Разработка);

Модель процессов

Модель процессов MSF (MSF process model) представляет общую методологию разработки и внедрения IT-решений, а именно описывает последовательность действий, осуществляемых в ходе реализации проекта.

Модель процессов MSF объединяет в себе принципы каскадной и спиральной моделей.

Тремя особенностями модели процессов MSF являются:

• Подход, основанный на фазах и вехах.

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

Вехи и фазы

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

MSF вводит два типа вех: главные (major) и промежуточные (interim). Они имеют следующие особенности:

• Главные вехи служат точками перехода от одной фазы к другой. Они также определяют изменения в текущих задачах ролевых кластеров.

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

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

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

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

Фазы и вехи модели процессов MSF

Модель процессов MSF покрывает процесс создания решения с самого его начала и до момента окончательного внедрения. Каждая фаза заканчивается главной вехой, результаты которой становятся видимыми за пределами проектной команды.

Для каждой фазы модели процессов MSF определяет:

• Что (какие артефакты) является результатом этой фазы;

• Над чем работает каждый из ролевых кластеров на этой фазе;

Фаза выработки концепци (Envisioning)

Основными задачами фазы выработки концепции являются создание ядра проектной группы и подготовка документа общего описания и рамок проекта (vision/scope document).

Веха: Концепция утверждена.

Результаты:

• Общее описание и рамки проекта (vision/scope document).

• Документ оценки рисков (risk assessment document).

• Описание структуры проекта (project structure document).

Рекомендуемые промежуточные вехи:

• Ядро проектной группы сформировано

• Черновой вариант концепции проекта составлен

Фаза планирования (Planning)

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

Веха: Планы проекта утверждены.

Результаты:

• Функциональная спецификация;

• План управления рисками;

• Сводный план и сводный календарный график проекта.

Рекомендуемые промежуточные вехи:

• Верификация технологий;

• Базовая версия функциональной спецификации создана;

• Базовая версия сводного плана проекта создана;

• Базовая версия сводного календарного графика проекта создана;

• Среды разработки и тестирования развернуты.

Фаза разработки (Development)

На фазе разработки проектная группа фокусируется на создании компонент решения (включая как документацию, так и программный код). Следует обратить внимание, что активность проектной команды на этом этапе не ограничивается написанием разработчиками кода – все ролевые кластеры принимают деятельное участие в создании и тестировании решения.

Веха: Разработка завершена.

Результаты:

• Исходный и исполнимый код приложений;

• Скрипты установки и конфигурирования;

• Окончательная функциональная спецификация;

• Материалы поддержки решения;

• Спецификации и сценарии тестов.

Рекомендуемые промежуточные вехи:

• Концепция подтверждена;

• Билд 1 завершен;

• Билд 2 завершен;

• Билд n завершен.

Фаза стабилизации (Stabilizing)

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

Веха: Готовность решения утверждена

Результаты:

• Окончательный продукт (golden release);

• Документация выпуска (release notes);

• Материалы поддержки решения;

• Результаты и инструментарий тестирования;

• Исходный и исполнимый код приложений;

• Проектная документация;

• Анализ пройденной фазы (milestone review).

Рекомендуемые промежуточные вехи:

• Точка конвергенции (В точке конвергенции (bug convergence) становится заметен существенный прогресс в устранении ошибок, то есть скорость устранения ошибок начинает превосходить скорость их обнаружения. Точка конвергенции дает проектной группе возможность понять, что процесс тестирования близится к концу.

• Точка достижения нуля (Точка достижения нуля (zero-bug bounce) – это момент, когда впервые все выявленные ошибки оказываются устраненными.)

• Версии-кандидаты

• Контрольное тестирование завершено

• Тестирование приемлемости для потребителей завершено

• Пилотное внедрение завершено

Фаза внедрения(Deploying)

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

Веха: Внедрение завершено.

Результаты:

• Информационные системы эксплуатации и поддержки;

• Процедуры и процессы;

• Базы знаний, отчеты, журналы протоколов (logbooks);

• Версии проектных документов, массивы данных (load sets) и программный код, разработанные во время проекта;

• Отчет о завершении проекта (project close-out report);

• Окончательные версии всех проектных документов;

• Показатели удовлетворенности заказчика и потребителей;

• Описание последующих шагов.

Рекомендуемые промежуточные вехи:

• Ключевые компоненты развернуты;

• Внедрение на местах завершено;

• Внедренное решение стабилизировано.

О чем еще рассказывается в модели процессов

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

• Дается множество определений.

Дисциплина управления проектами

Носителем профессиональных управленческих навыков и организатором работы команды в MSF является ролевой кластер “Управление программой”. Однако типовые управленческие обязанности при этом распределяются среди лидеров всех ролевых кластеров проектной группы.

Данный дисциплина не предоставляет конкретных рецептов управления проектами и не содержит объяснений многочисленных методов работы, применяемых опытными менеджерами. Однако он показывает, как принципы MSF формируют такой подход к управлению проектами, при котором:

• Ответственность за управление проектом распределена среди лидеров ролевых кластеров внутри команды.

• Профессиональные менеджеры выступают в качестве консультантов и наставников команды, а не выполняют функции контроля над ней.

Распределение ответственности по управлению проектом среди лидеров групп

Для лидеров групп и ролевого кластера «Управление программой» инструментом управления проектом, облегчающим создание планов и календарных графиков, является WBS. Иерархическая структура работ (WBS) — это структуризация работ проекта, отражающая его основные результаты и определяющая его рамки. Работа, не описанная в WBS, находится вне границ проекта. В MSF создание WBS является коллективной деятельностью, в которую вовлекаются все ролевые кластеры. Каждая роль ответственна за предоставление детального описания собственной работы.

Дисциплина управления рисками

Дисциплина управления рисками MSF заимствует хорошо известную модель процесса непрерывного управления рисками, разработанную Software Engineering Institute (SEI). При этом интерпретация этой модели дается в контексте опыта Microsoft. Данная дисциплина предлагает принципы, идеи и рекомендации, подкрепленные описанием шестишагового процесса для успешного активного управления рисками. Этот процесс включает в себя:

• Выявление рисков (risk identification) – это фаза, позволяющая членам проектной группы вынести на обсуждение всей команды факты наличия рисков.

• Анализ рисков (risk analysis) – это фаза преобразования накопленных во время предыдущего шага оценок и данных в форму, позволяющую осуществить приоритезацию рисков. Приоритизация рисков (risk prioritization) позволяет проектной группе управлять наиболее важными из них, выделяя для этого необходимые ресурсы.

• Планирование рисков (risk planning) выполняется исходя из информации, полученной на этапе их анализа, и имеет своей целью выработку стратегий, планов и конкретных шагов.

• Мониторинг рисков (risk tracking) выполняется для наблюдения за конкретными рисками и прогрессом в осуществлении составленных планов.

• Корректирование ситуации (risk control) представляет собой процесс исполнения принятых в отношении рисков планов и контроля за ходом их исполнения.

• Извлечение уроков (risk learning) формализует процесс усвоения накопленного за время работы над проектом опыта в форме, доступной для использования как внутри проектной группы, так и на уровне всего предприятия.

Дисциплина управления подготовкой

Данная дисциплина посвящена управлению знаниями, профессиональными умениями и способностями, необходимыми для планирования, создания и сопровождения успешных решений. Дисциплина управления подготовкой MSF дает рекомендации по применению превентивного подхода к управлению знаниями на протяжении всего жизненного цикла информационных технологий. Этот процесс состоит из четырех шагов:

• Определение

1. Проектные сценарии (scenarios).

2. Квалификационные требования (competencies).

3. Профессиональные навыки (proficiencies).

• Оценивание

1. Измерение знаний, умений, способностей (measure knowledge, skills, abilities).

2. Анализ несоответствий (analyze gaps).

3. Создание учебных планов (create learning plans).

• Корректировка

1. Обучение (train).

2. Мониторинг прогресса (track progress).

• Осмысление

1. Анализ результатов (review results).

2. Управление знаниями (manage knowledge).

Новые версии MSF

Новая версия MSF 4.0 была представлена в 2005 году. В данной версии произошло разделение методологии на два направления: MSF for Agile Software Development и MSF for CMMI Process Improvement. MSF for Agile Software Development в определенной степени отражает тенденции последнего времени, связанные с появлением методологий, предлагающих максимально облегченный и гибкий подход к процессу разработки. MSF for CMMI Process Improvement - это строгий, документированный процесс, рассчитанный на большие команды и длительный процесс разработки, что предполагает больше верификации, больше планирования, процедуры утверждения, отслеживание потраченных ресурсов и т.д. Данная версия выглядит, как облегченный вариант 3.0 и ориентирована на продукты Microsoft, а именно Visual Studio 2005 Team System и MS Project.

Литература

4. Модель процессов MSF, версия 3.1;

5. Модель проектной группы MSF, версия 3.1;

6. Дисциплина управления рисками MSF, версия 1.1;

7. Дисциплина управления проектами MSF, версия 1.1;

8. Дисциплина управления подготовкой MSF, версия 1.1.

Ресурс: http://www.microsoft.com/rus/msf

Масштабирование проектных групп

Таблица совместимости ролей