Microsoft Solutions Framework (MSF) - методология разработки программного обеспечения, предложенная корпорацией Microsoft. MSF опирается на практический опыт Microsoft и описывает управление людьми и рабочими процессами в процессе разработки решения.

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

• модель команды

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

дисциплины:

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

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

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

Модель команды msf

Модель команды MSF (MSF Team Model) описывает подход MS к организации работающего над проектом персонала и его деятельности в целях максимизации успешности проекта. Данная модель определяет ролевые кластеры, их области компетенции и зоны ответственности, а также рекомендации членам команды, позволяющие им успешно осуществить свою роль по воплощению проекта в жизнь.

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

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

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

Наделение членов команды полномочиями

Концентрация на бизнес-приоритетах

Единое видение проекта

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

Поощрение свободного общения

Успешное использование модели проектной группы MSF основывается на ряде ключевых концепций:

Команда соратников

Сфокусированность на нуждах заказчика

Нацеленность на конечный результат

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

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

Заинтересованные команды работают эффективно

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

управление программой (program manager) - разработка архитектуры решения, административные службы;

разработка (developer) - разработка приложений и инфраструктуры, технологические консультации;

тестирование (QAE) - планирование, разработка тестов и отчетность по тестам;

управление выпуском/логистикой (release manager) - инфраструктура, сопровождение, бизнес-процессы, выпуск готового продукта;

удовлетворение заказчика (user experience) - обучение, эргономика, графический дизайн, техническая поддержка;

управление продуктом (product manager) - бизнес-приоритеты, маркетинг, представительство интересов заказчика.

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

Наличие шести ролевых кластеров не означает, что количество членов команды должно быть кратным шести - один человек может совмещать несколько ролей и наоборот, ролевой кластер может состоять из нескольких лиц в зависимости от размера проекта, его сложности и профессиональных навыков, требуемых для реализации всех областей компетенции кластера. Минимальный коллектив по MSF может состоять всего из трех человек. Модель не требует назначения отдельного сотрудника на каждый ролевой кластер. Смысл состоит в том, что в команде должны быть представлены все шесть качественных целей. Обычно, выделение как минимум одного человека на каждый ролевой кластер обеспечивает полноценное внимание к интересам каждой из ролей, но это экономически оправданно не для всех проектов. Зачастую члены проектной группы могут объединять роли.

В малых проектных группах объединение ролей является необходимым. При этом должны соблюдаться два принципа:

Роль команды разработчиков не может быть объединена ни с какой другой ролью.

Избежание сочетания ролей, имеющих предопределенные конфликты интересов.

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

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

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

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

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

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

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

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

Введение

Структура MSF

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

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

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

Вехи и фазы

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

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

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

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

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

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

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

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

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

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

Литература

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

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

Введение

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

Структура MSF

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

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

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

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

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

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

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

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

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

Методология 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 дает рекомендации по применению превентивного подхода к управлению знаниями на протяжении всего жизненного цикла информационных технологий. Этот процесс состоит из четырех шагов:

Определение

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

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

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

Оценивание

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

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

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

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

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

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

Осмысление

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

Управление знаниями (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.

(Microsoft Solutions Framework)

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

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

Являясь гибридом каскадной и спиральной моделей, модель жизненного цикла MSF сочетает простоту управления каскадной модели с гибкостью спиральной (см. рис. 6.10).

Рис. 6.10 . Построение модели жизненного цикла MSF на базе каскадной и спиральной моделей.

Модель жизненного цикла MSF ориентирована на «вехи» (milestones) – ключевые точки проекта, характеризующие достижение какого-либо существенного результата. Этот результат может быть оценен и проанализирован. В модели предусматривается наличие основных вех (завершение главных фаз модели) и промежуточных, отражающих внутренние этапы главных фаз.

Базовыепринципы MSF:

Единое видение проекта - четкое и одинаковое понимание целей и задач проекта членами проектной группы и заказчиком.

Гибкость - непрерывная изменяемость условий проекта при неизменной эффективности управленческой деятельности.

3. Сконцентрированность на бизнес-приоритетах - независимо от того, нацелен ли разрабатываемый продукт на организации или индивидуумов, он должен принести в некоторой форме выгоду или отдачу. В отношении индивидуумов это может означать, например, эмоциональное удовлетворение – как в случае компьютерных игр, в отношении организаций – это бизнес‑отдача (business value).

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

Основными фазами модели MSF являются:

1. Создание общей картины приложения (Envisioning ) .На этом этапе решаются следующие основные задачи: оценка существующей ситуации; определение состава команды, структуры проекта, бизнес-целей, требований и профилей пользователей; разработка концепции решения и оценка риска. Устанавливаются две промежуточные вехи: «Организован костяк команды» и «Создана общая картина решения».

2. Планирование (Panning). Этап состоит из трех стадий:

Концептуальное проектирование - определение набора сценариев использования системы,

Логическое проектирование - решение представляется в виде набора сервисов

Физическое проектирование - уточняются используемые технологии и интерфейсы.

3. Разработка (Developing). Создается вариант решения проблемы, в виде кода и документации очередного прототипа, включая спецификации и сценарии тестирования. Основная веха этапа – «Окончательное утверждение области действия проекта». Продукт готов к внешнему тестированию и стабилизации.

4. Стабилизация (Stabilizing). Подготовка к выпуску окончательной версии продукта, доводка его до заданного уровня качества. Здесь выполняется комплекс работ по тестированию (обнаружение и устранение дефектов), проверяется сценарий развертывания продукта. Когда решение становится достаточно устойчивым, проводится его пилотная эксплуатация в тестовой среде с привлечением пользователей и применением реальных сценариев работы.

5. Развертывание (Deploying). Выполняется установка решения и необходимых компонентов окружения, проводится его стабилизация в промышленных условиях и передача проекта в руки группы сопровождения. Кроме того, анализируется проект в целом на предмет уровня удовлетворенности заказчика.

ТЕМА 4: ПРОЦЕССЫ УПРАВЛЕНИЯ ПРОЕКТАМИ: ИНИЦИАЦИЯ, ПЛАНИРОВАНИЕ, ИСПОЛНЕНИЕ, КОНТРОЛЬ, ЗАВЕРШЕНИЕ.

Процессы инициации

2. Процессы планирования

Процессы исполнения

Олег Большаков

Методология разработки программного обеспечения Microsoft Solution Framework появилась в 1994 году. В основу методологии MSF заложен накопленный опыт компании Майкрософт в области управления человеческими ресурсами и рабочими процессами в ходе разработки программных решений. Данные знания базируются на опыте работы компании Майкрософт над крупными проектами по разработке и сопровождению программного обеспечения, а также прочего опыта IT-индустрии.

Основу методологии составляют модели и дисциплины.

• модель проектной группы;
• модель процессов.

Дисциплины:

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

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

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

В проектную группу входят следующие ролевые кластеры (рис.1):

• Управление продуктом (Product Management) . Ключевая цель данного ролевого кластера - довольные заказчики. Проект не может считаться успешным, если он не привел к удовлетворению потребностей заказчика. Возможна ситуация, когда проектная группа уложилась в бюджет и сроки, но успех не был достигнут, так как не были удовлетворены бизнес-нужды заказчика.
• Управление программой (Program Management). Основная задача этого ролевого кластера - обеспечить реализацию решения в рамках ограничений проекта. Для этого контролируются календарный график проекта, объем работы и отведенный на проект бюджет. Рассматриваемый кластер обеспечивает своевременное достижение требуемых результатов и удовлетворение ожиданий спонсора на протяжении проекта.
  В версии MSF 4 из данного ролевого кластера был выведен кластер "Управление архитектурой", который подразумевает организацию и выполнение высокоуровневого проектирования решения, создание функциональной спецификации ПО и управление этой спецификацией в процессе разработки, определение рамок проекта и ключевых компромиссных решений.
• Разработка (Development) . Первостепенной задачей ролевого кластера "Разработка" является построение решения в соответствии со спецификацией. Ее выполнение означает создание решения, соответствующего ожиданиям заказчика и условиям, сформулированным в функциональной спецификации. Также данный ролевой кластер строго следует выработанной архитектуре и дизайну решения, которые совместно с функциональной спецификацией составляют сводное описание конечного продукта.
• Тестирование (Test) . Задача данного ролевого кластера - одобрение выпуска продукта только лишь после того, как все дефекты выявлены и улажены. Любое программное обеспечение содержит дефекты. Но нужно обнаружить и уладить все из них до того, как продукт выпущен. Улаживание дефекта может подразумевать различные решения, начиная от устранения и заканчивая документированием способов обхода дефекта. Поставка продукта с известным дефектом, но с описанием способов его обхода является более предпочтительной, чем поставка продукта с невыявленным дефектом.
• Удовлетворение потребителя (User Experience) . Цель этого ролевого кластера - повышение эффективности использования продукта.
• Управление выпуском (Release Management) . Цель этого ролевого кластера - беспрепятственное внедрение и сопровождение продукта. Эта роль служит связующим звеном между проектной группой и группами процессов сопровождения.

Наличие перечисленных ролевых кластеров не означает, что команда должна состоять строго из такого же количества участников. Один сотрудник вполне может объединять несколько ролей, однако при этом некоторые роли не рекомендуется объединять, а некоторые роли объединять вообще недопустимо. В таблице 1 представлена матрица совместимости ролевых кластеров.

Д - допустимо, Н - недопустимо, Н/Ж - не желательно

Анализируя данную матрицу можно сделать следующие выводы:

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

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

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

• Удовлетворение потребителя, Управление продуктом, Тестирование.
• Управление программой, Управление выпуском.
• Разработка.

Отметим, что такое распределение ролей по матрице допустимо без ограничений, причем соблюдены два основных ограничения: роль разработчика не совмещена ни с одной другой ролью; и нет совмещения ролей, имеющих предопределенные конфликты интересов. Также следует отметить рекомендацию Майкрософт касаемо совмещения ролей: когда проектная команда состоит из шести или меньшего количества участников, выполняющих все проектные роли - деятельность по управлению проектом осуществляется ролевым кластером "Управление программой".

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

В качестве заключительного вывода к статье можно привести слова Стива Макконнелла (Steve C McConnell): "Даже при наличии квалифицированных, мотивированных и трудолюбивых людей неверная структура команды способна свести на нет их усилия, вместо того чтобы привести их к успеху. Слабая структура команды может послужить причиной увеличения времени разработки, снижения качества, понижения морального духа, повышения текучести кадров и, в конечном итоге, привести к провалу проекта".

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

Компания Microsoft подготовила и применяет несколько методик для покрытия не только ЖЦИС, но и технологической инфраструктуры, их поддерживающей.

В контексте рассмотрения ЖЦПО нас интересует именно методология разработки: как являющийся одним из основных аспект управления и взаимодействия участников процесса, так и другие области знаний (управление рисками, планирование). В целом охватываемые MSF дисциплины описаны в пяти частях (так называемых белых книгах), однако интересно, что командами консультантов Microsoft применяется на практике не этот ресурс, а методика MSF for Agile Software Development, которая является прикладным вариантом MSF и отражает общий методологический подход к итеративной разработке.

Если обратиться непосредственно к процессу разработки и внедрения, то его характеризуют:

• итеративность;
• формирование в качестве результата ИТ-решения.

ИТ-решение - скоординированная поставка набора элементов (таких как программно-технические средства, документация, обучение, сопровождение и внешние коммуникации), необходимых для удовлетворения некоторой бизнес потребности конкретного заказчика.

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

Основной состав MSF - это две модели и три дисциплины, которые подробно рассматриваются в пяти белых книгах. В состав MSF входят:

• модели:
  • - модель группы,
  • - модель процессов;
• дисциплины:
• - дисциплина «Управление проектами»,
• - Дисциплина «Управление рисками»,
• - Дисциплина «Управление готовностью».

Модель процессов. Модель процессов - это «основа основ» методологии MSF. Модель процессов MSF основана на сочетании водопадной и спиральной моделей жизненного цикла ИС. Таким образом, в методологии MSF проект реализуется поэтапно, все этапы могут повторяться «по спирали», а между этапами существуют заранее определенные контрольные точки (рис. 7.20).

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

Создание общей картины ИТ-решения. Первый этап модели MSF - это Создание общей картины ИТ-решения. Задачи этапа таковы:

• определить проектную команду;
• определить структуру проекта;
• определить бизнес-цели проекта;
• оценить текущую ситуацию;
• сформировать документ с описанием общей картины и областью действия проекта;
• определить требования пользователей;
• разработать концепции для ИТ-решсния;
• оценить риски;
• закрыть этап.

Рис. 7.20.

Этап содержит в себе две контрольные точки: «Костяк команды сформирован» и «Общая картина ИТ-решения создана».

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

Контрольная точка «Общая картина ИТ-решения создана» предполагает разработку концепции ИТ-решения, которым команда будет руководствоваться в дальнейшем для достижения бизнес-целей, декларированных в проекте. Контрольная точка характеризуется наличием описания того, что входит в проект, а что не входит. При этом документ не является итоговым: к данной точке создается предварительная рецензируемая версия.

Завершение этапа происходит, когда достигнута третья контрольная точка - «Документ общей картины и области действия проекта утвержден».

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

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

Задачи Планирования могут быть сформулированы следующим образом:

• разработать архитектуру ИТ-решения;
• сформировать функциональную спецификацию;
• разработать проектные планы;
• сформировать календарный график работ;
• создать среду разработки, тестирования и тестовой эксплуатации;
• закрыть этап.

Планирование - достаточно сложный и обширный этап, который насчитывает пять контрольных точек:

• функциональная спецификация создана;
• план управления рисками создан;
• среда разработки и тестирования определена;
• план и календарный график проекта созданы;
• проектные планы утверждены.

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

Разработка. Этап Разработки подразумевает непосредственное создание ИТ-решения, т.е. написание и документацию программного кода. Убедившись, что задачи предыдущих этапов выполнены, проектная команда приступает к реализации задач, характерных для этапа разработки:

• создать прототип ИТ-решения;
• разработать программные компоненты ИТ-решения;
• создать готовое ИТ-решение (рассматривается как последовательность промежуточных выпусков);
• закрыть разработку (реализовать все функции в ИТ-решении, поставить код и документацию заказчику).

В методологии MSF выделяют следующие результаты разработки:

• исходный программный код и исполняемые файлы;
• сценарии установки и конфигурации для развертывания;
• итоговая функциональная спецификация;
• элементы поддержки ИТ-решения;
• спецификации и сценарии тестирования.

Этап разработки также содержит и контрольные точки, основная из которых - «Итоговое утверждение области действия проекта». Эта контрольная точка считается достигнутой, когда все функции продукта реализованы и прошли предварительное тестирование. Считается, что после этого ИТ-решение пригодно к внешнему тестированию и началу стабилизации.

Стабилизация. Этап Стабилизации нужен, чтобы довести продукт до требуемого уровня качества. Стабилизация предполагает проведение всеобъемлющего тестирования с целью обнаружения и устранения дефектов. Кроме того, в рамках этапа Стабилизации проверяются сценарии развертывания и осуществляется пробная эксплуатация ИТ-ретения.

Тестирование включает следующие виды активности:

• тестирование компонентов;
• тестирование БД;
• тестирование ИТ-инфраструктуры;
• тестирование безопасности;
• тестирование интеграции;
• тестирование эргономичности;
• нагрузочное тестирование;
• регрессивное тестирование;
• ведение отчетности по тестированию.

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

Важнейшая контрольная точка - это «Появление версии ИТ-решения, в которой не найдено критических ошибок». После этого выпускается несколько финальных версий, одна из которых, признанная наиболее удачной, развертывается для пробной эксплуатации. Финальная контрольная точка для этого этапа - «Подтверждение готовности продукта к развертыванию в промышленной среде».

Развертывание. Этап Развертывания включает установку ИТ-решения, промышленную стабилизацию и окончательную передачу заказчику и группе сопровождения. Основные контрольные точки этапа:

• основные компоненты развернуты;
• решение развернуто;
• решение стабилизировано;
• решение передано в эксплуатацию заказчику.

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

Модель группы. Управление проектной командой - важная часть MSF. Методология включает детально проработанную Модель группы. Модель группы возникла как ответ на потребность в четком понимании ролей, обязанностей и задач каждого члена проектной команды (табл. 7.12). Считается, что такая модель способствует мотивации сотрудников, упрощает работу и повышает эффективность их деятельности.

Таблица 7.12

Роли, цели и функциональные области MSF

		Функциональные области
Управление продуктами	Обеспечить бизнес-ценность решения. Определить решение в рамках ограничений проекта. Обеспечить выполнение требований	Коммуникации. Аналитика. Планирование
Управление программой	Реализовать проект в рамках ограничений. Реализовать средства, с помощью которых выполняются требования	Управление проектом. Управление программой. Управление ресурсами. Обеспечение выполнения. Управление качеством. Операции проекта
Разработка	Построить ИТ-решение в соответствии со спецификациями	Разработка ИТ-решения. Технологическое консультирование
Тестирование	Проверить соответствие ИТ-решения заданным условиям качества. Утвердить выпуск ИТ-решения	Все виды тестирования
Выпуск и эксплуатация	Развернуть ИТ-решение и обеспечить переход к эксплуатации. Обеспечить выполнение потребностей и ожиданий бизнес-подразделений заказчика	Управление выпусками. Инфраструктура. Операции. Управление сборками. У правление инструментами
	Оптимизировать удобство использования ИТ-решеиия. Обеспечить готовность пользователей к работе с ИТ-решеиием. Обеспечить выполнение требований и ожиданий пользователей	Специальные возможности. Взаимодействие со службой поддержки. Обучение. Удобство использования. Проектирование пользовательского интерфейса

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

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

Таблица 7.13

Варианты совмещения ролей в MSF

	Управление продуктами	Управление программой	Разработка	Тестирование	и эксплуатация	Взаимодействие с пользователем
Управление продуктами
Управление программой
Разработка
Тестирование
Выпуск и эксплуатация
Взаимодействие с пользователем

Таким образом, в отличие от многих других корпоративных методологий, определенные в MSF этапы/всхи, состав проектной группы, ролевая модель и другие элементы подходят нс только для решений Microsoft. А значит, MSF представляет собой более гибкий и универсальный подход для внедрения других систем или программных продуктов.

On Target. Методология внедрения решений On Target была разработана компанией Navision для внедрения своих программных продуктов. После приобретения Navision корпорацией Microsoft было принято решение доработать On Target, к тому моменту содержавшую шаблоны описаний бизнес-процессов, документации, организационных структур ИТ и квалификационных требований к специалистам (табл. 7.14).

Таблица 7.14

Этапы в методологии On Target

		Действия
Проектирование	Сформировать нефункциональные требования к ИС. Сформировать принципы реализации требований	Проектирование реализации функциональных требований в ИС. Описание интерфейсов и модификаций. Уточнение плана и бюджета
Разработка и тестирование	Разработать И С. Протестировать И С	Разработка и тестирование функциональности. Разработка и тестирование интерфейсов. Разработка модификаций и дополнений
Развертывание	Развернуть систему на предприятии заказчика	Развертывание на рабочие места. Настройка прав и уровней доступа. Верификация начальных данных и операций. Перенос данных. Обучение и подготовка инструкций на рабочие места
Эксплуатация	Запустить ИС в эксплуатацию. Осуществить сдачу- приемку ИС	Запуск ИС в эксплуатацию. Опытная эксплуатация ИС. Сдача-приемка ИС

В силу того что к моменту приобретения Navision у Microsoft уже применялись свои проверенные корпоративные методологии MSF и MOF, в дальнейшем On Target была дополнена и к моменту выведения на рынок Microsoft Dynamics превратилась в результате доработок в MS Dynamics Sure Step/Microsoft Business Solutions Partner Methodology.

Microsoft Business Solutions Partner Methodology. MBS Partner Methodology - это дальнейшее развитие On Target. Эта методология ставит своей целью не просто создание ИС, но также максимальное удовлетворение потребностей заказчика.

Рис. 7.21.

Как можно видеть на рис. 7.21, этапы не сильно отличаются от аналогичных в On Target. На этапе Диагностики производится анализ и описание бизнес-процессов компании заказчика, а также выявляются ключевые бизнес-потребности. Производится первоначальное определение бюджета, сроков, границ и результатов проекта. Создается рабочая группа, причем сотрудники заказчика, вошедшие в нее, содействуют в проведении диагностики предприятия. В конце стадии формируются отчеты о проведенной диагностике, фиксируются ограничения проекта, документируются предложения по разработке и внедрению ИС.

Роли в проекте приведены на рис. 7.22.

Рис. 7.22.

На этапе Анализа окончательно формируются Управляющий комитет и проектная группа. Формируются такие документы, как План проекта, Устав проекта, Порядок отчетности, а также определяются условия сдачи-приемки и принципы управления изменениями и рисками. Сотрудники клиента знакомятся с базовой функциональностью продукта за счет проведения тренингов. Требования к ИС уточняются и детализируются, в результате чего формируется Спецификация функциональных требований. Формируются первые варианты интерфейсов, а предприятие начинает готовиться к изменению бизнес-процессов.

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

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

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

Развертывание начинается с официальной сдачи проекта заказчику. Заказчик оценивает достижение целей проекта на основе определенных ранее критериев успеха. Далее начинается подготовка системы к запуску в промышленную эксплуатацию. Производится обучение конечных пользователей. Осуществляется первоначальная поддержка специалистами исполнителя. В конце этапа происходит официальное завершение проекта, который оценивается заказчиком.

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