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

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

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

Ниже описываются основные принципы, ключевые идеи и испытанные методики MSF в применении к модели проектной группы .

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

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

наделяйте членов команды полномочиями;

концентрируйтесь на бизнес-приоритетах;

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

проявляйте гибкость – будьте готовы к переменам;

поощряйте свободное общение.

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

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

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

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

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

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

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

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

В собрана вместе команда равных разработчиков, обеспечивающая полный набор необходимых составляющих, связанных с созданием, использованием и обслуживанием создаваемого продукта. Каждый член команды, или роль , ответственен за удовлетворения нужд своей клиентуры, причем ни один клиент не является важнее другого. MSF for Agile Software Development содержит все необходимые методики и подходы для уверенности в том, что команда разработчиков принимает правильные решения.

MSF for Agile Software Development выделяет 7 ролевых групп :

Управление программой (program management);

Архитектура продукта (architecture);

Разработка (development);

Тестирование (test);

Управление выпуском (release operations);

Удовлетворение потребителя (user experience);

Управление продуктом (product management);

и 6 ролей (рис. 23.6):

менеджер проекта (project manager) – ролевая группа Управление программой;

архитектор (archrect) – ролевая группа Архитектура;

разработчик (developer) – ролевая группа Разработка;

тестер (tester) – ролевая группа Тестирование;

релиз-менеджер (release manager) – ролевая группа Управление выпуском;

бизнес-аналитик (business analyst) – ролевые группы Управление продуктом и Удовлетворение потребителя.

Рис . 23.6. Команда разработчиков MSF for Agile Software Development

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

Каждая ролевая группа в команде имеет зону ответственности (advocacy), в которой роль из этой группы имеет решающий голос.

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

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

Разработка – отвечает за проектирование и осуществление реализации.

Тестирование – отвечает за качество решения с точки зрения заказчика и будущих пользователей.

Управление выпуском – отвечает за гладкое внедрение решения в инфраструктуру заказчика.

Удовлетворение потребителя – отвечает за понимание потребностей пользователей и их надлежащую реализацию в решении.

Управление продуктом – отвечает за понимание того как, и успешное получение бизнес-отдачи от внедрения разрабатываемого решения, которое в результате сможет получить заказчик.

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

Таблица 23.2. Совмещение ролей в MSF
	Архитектура продукта	Управление продуктом	Управление программой	Разработка	Тестирование	Удовлетворение потребителя	Управление выпуском
Архитектура продукта					Не желательно	Не желательно	Не желательно
Управление продуктом							Не желательно
Управление программой					Не желательно	Не желательно
Разработка
Тестирование	Не желательно		Не желательно
Удовлетворение потребителя	Не желательно		Не желательно				Не желательно
Управление выпуском	Не желательно	Не желательно				Не желательно

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

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

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

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

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

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

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

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

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

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

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

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

Вспоминая предыдущую лекцию… Наша предыдущая лекция была посвящена визуальному моделированию в процессе анализа и проектирования и основам языка UML. При этом сначала в качестве введения мы кратко повторили: –типовую схему решения задач с использованием вычислительной техники; –основные положения алгоритмической и объектной декомпозиции; –принципы объектного подхода к анализу и проектированию. Далее мы обсудили, чем вызвана необходимость в визуальном моделировании программных систем и рассмотрели историю языка UML.

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

Введение в методологию MSF и историческая справка… Что такое методология? Методология – принципы и способы организации теоретической и практической деятельности. Совокупность методов, применяемых в какой-либо науке. Для SE сформулируем так: Методология есть принципы и способы организации деятельности проектной группы для создания программного продукта. Программный продукт – решение. Проектная группа – команда.

Введение в методологию MSF и историческая справка… Основные концепции методологии MSF 1: MSF – методология разработки программного обеспечения от компании Microsoft, опирающаяся на практический опыт компании и описывающая управление людьми и управление процессами в ходе разработки решения. 2: MSF состоит из двух моделей и трех дисциплин. Они подробно описаны в пяти документах, так называемых «белых книгах» («whitepapers»), каждый из которых охватывает определенную дисциплину или модель MSF.

Введение в методологию MSF и историческая справка… Основные концепции методологии MSF Дисциплины и модели MSF: –Модель процессов MSF. –Модель проектной группы MSF. –Дисциплина управления проектами MSF. –Дисциплина управления рисками MSF. –Дисциплина управления подготовкой MSF. 3: MSF предлагает несколько оригинальных идей, с которыми мы подробно будем знакомиться далее, а пока просто перечислим их: –Единое видение проекта –Треугольник и матрица компромиссов –Проектная группа – команда равных –Управление рисками –…

Введение в методологию MSF и историческая справка… Историческая справка 1993 год – стремясь достичь максимальной отдачи от IT- проектов, компания Microsoft выпустила в свет пакет руководств по эффективному проектированию, разработке, внедрению и сопровождению решений, построенных на основе своих технологий. Эти знания базировались на опыте, полученном Microsoft при работе над большими проектами по разработке и сопровождению ПО, опыте консультантов Microsoft и лучшем из того, что накопила на тот момент IT индустрия год – MSF год – MSF год – MSF 4.0.

Введение в методологию MSF и историческая справка Источники информации –Основным источником, безусловно, являются белые книги (в настоящий момент доступные для версии MSF 3.0). –Немало сведений можно найти на сайте компании Microsoft, включая разделы портала TechNet (–Кроме того, желающие могут прослушать авторизованные курсы, связанные с MSF. –Информация по последней версии MSF 4.0:

Нововведения версии MSF 4.0… Два направления в MSF 4.0 –MSF for Agile Software Development –MSF for CMMI Process Improvement Мы рассматриваем MSF for Agile Software Development CMMI (Capability Maturity Model Integration) – существенно более формализованная методология, чем Agile development, ориентированная на разработку ПО в больших коллективах.

Нововведения версии MSF 4.0… Основные положения MSF for Agile Software Development Предлагает максимально облегченный и гибкий подход к процессу разработки. Другой пример подобных методологий - Extreme Programming (XP). Agile направление в MSF ориентируется на небольшие команды (5-6 человек). Предполагает, что информация о разрабатываемом продукте не просто выясняется в процессе разработки, а может и будет изменяться по ходу. Таким образом, первая рабочая версия системы должна быть создана как можно раньше, а сам продукт фактически проявляется из прототипов путем повторения итераций в цикле разработки.

Нововведения версии MSF 4.0… Основные положения MSF for Agile Software Development Элементы методологии: –рекомендованные процессы создания IT-проектов; –структура итераций; –роли членов команды; –шаблоны документов (Excel, Word); –шаблоны Microsoft Project; –отчеты; –портал проекта (шаблон сайта SharePoint). MSF for Agile Software Development ориентирован на использование итеративной и эволюционной модели процесса разработки и основан на сценариях (вариантах) использования.

Нововведения версии MSF 4.0 Инструментальная поддержка MSF 4.0 В отличие от предыдущих редакций инструментальная поддержка в среде разработки Microsoft Visual Studio 2005 Team System. Среда Visual Studio 2005 может выступать теперь в качестве интегрирующего средства, из которого можно работать со всеми инструментами, обеспечивающими стадии процесса разработки от создания планов проекта до проведения различных видов тестирования, включая создание и выполнение тестовых сценариев.

Формирование команды. Модель проектной группы MSF for Agile Software Development… Основные принципы построения команды Методология MSF считает, что успешная работа команды над проектом существенным образом зависит от ее структуры и распределения зон ответственности ролевых групп. Построение команды в MSF соответствует ряду ключевых концепций, часть которых кажутся очевидными, другие сродни «ноу-хау».

Формирование команды. Модель проектной группы MSF for Agile Software Development… Основные принципы построения команды Очевидные концепции (1): –Концентрация на нуждах заказчика (customer-focused mindset) – главный приоритет любой хорошо работающей проектной группы. –Означает обязательное понимание бизнес-задач заказчика и стремление к их решению со стороны команды. –Не менее важным является активное участие заказчика в проектировании решения и получение его отзывов в ходе процесса разработки.

Формирование команды. Модель проектной группы MSF for Agile Software Development… Основные принципы построения команды Очевидные концепции (2): –Нацеленность на конечный результат (product mindset) – каждый участник проектной группы должен рассматривать собственную работу в качестве самостоятельного проекта или же вклада в какой-либо больший проект. –Установка на конечный продукт означает, что получению конечного результата проекта уделяется больше внимания, чем процессу его достижения. –Из этого не следует, что сам процесс может быть плох или непродуман – просто он существует для получения конечной цели, а не ради себя самого.

Формирование команды. Модель проектной группы MSF for Agile Software Development… Основные принципы построения команды Очевидные концепции (3): –Установка на отсутствие дефектов (zero-defect mindset) – это стремление к высочайшему уровню качества. Цель команды – выполнение своей работы с максимально возможным качеством, в идеале таким образом, что если от команды потребуют поставить результат завтра, она будет способна поставить что-то работающее. –В успешной команде каждый сотрудник чувствует ответственность за качество продукта. –Она не может быть делегирована одним членом команды другому или же от одной ролевой группы другой.

Формирование команды. Модель проектной группы MSF for Agile Software Development… Основные принципы построения команды Ноу-хау (1): –«Проектная группа – команда равных» (teem of peers). Концепция означает равноправное положение каждой из ролей в команде. –Чтобы достичь успеха в рамках команды равных, каждый из ее членов, независимо от роли, должен нести ответственность за качество продукта, понимать интересы заказчика и сущность решаемой бизнес-задачи. –В то же время, принятие решения методом консенсуса между ролями не тождественно принятию решения методом консенсуса между сотрудниками. –Каждая ролевая группа требует определенной организационной иерархии для распределения работы и управления ее ресурсами.

Формирование команды. Модель проектной группы MSF for Agile Software Development… Основные принципы построения команды Ноу-хау (2): –Стремление к самосовершенствованию (willingness to learn) – это приверженность идее неустанного саморазвития посредством накопления опыта и обмена знаниями. –Оно позволяет членам проектной группы извлекать пользу из отрицательного опыта сделанных ошибок, равно как и воспроизводить успехи, используя проверенные методы работы других людей. –По окончанию основных фаз проекта и по завершению проекта в целом предполагается проведение открытых обсуждений его состояния и доброжелательный, но объективный анализ.

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

Формирование команды. Модель проектной группы MSF for Agile Software Development… Ролевые группы и роли Ролевые группы (кластеры) –Управление программой (program management) –Архитектура продукта (architecture) –Разработка (development) –Тестирование (test) –Управление выпуском (release operations) –Удовлетворение потребителя (user experience) –Управление продуктом (product management)

Формирование команды. Модель проектной группы MSF for Agile Software Development… Ролевые группы и роли Роли: –менеджер проекта (project manager) – ролевая группа Управление программой –архитектор (archrect) – ролевая группа Архитектура –разработчик (developer) – ролевая группа Разработка –тестер (tester) – ролевая группа Тестирование –релиз-менеджер (release manager) – ролевая группа Управление выпуском –бизнес-аналитик (business analyst) – ролевые группы Управление продуктом и Удовлетворение потребителя

В последние годы мы видим, что ведущие поставщики средств разработки ПО (в первую очередь IBM Rational и Borland) от выпуска отдельных инструментов переходят к созданию комплексных платформ управления жизненным циклом приложений (ALM). Microsoft пока не форсирует процесс формирования полного спектра ALM-решений для автоматизации различных этапов производства ПО, хотя движется именно в этом направлении и основной акцент делает на средствах проектирования и разработки - Visio, Visual Studio и т. д.

Однако для реализации идеологии ALM на практике необходим не только набор инструментов сам по себе, но и общая методологическая база. Microsoft уже более десяти лет занимается развитием собственной ALM-методологии под названием Microsoft Solutions Framework (MSF). Может показаться неожиданным, но MSF в целом - по сути платформно-независимая методология, детально описывающая отдельные процессы на уровне абстракций. Инструменты самой Microsoft присутствуют в ней в минимальной степени, лишь как примеры реализации тех или иных рекомендаций. Вместе с тем, хотя и неявно, концепция эта четко выражает общую нацеленность средств разработки корпорации (круг задач, для решения которых они предназначены), что очень хорошо видно из анализа динамики ее развития. Так, если десять лет назад MSF была ориентирована на создание локальных клиентских приложений, то сегодня - на разработку и внедрение сложных систем масштаба предприятия.

v “Модель процессов MSF”;

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

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

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

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

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

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

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

Как легко заметить, модель MSF предлагает несколько иную разбивку на этапы ЖЦ ПО и их наименование, отличающуюся от общепринятого на сегодняшний день списка ALM-этапов, которого, в частности, придерживаются компании Borland и IBM Rational. Речь здесь не идет просто о разных названиях одних и тех же видов деятельности. Объективная проблема категоризации заключается в том, что выделение самостоятельных этапов в жизненном цикле приложений весьма условно, особенно если речь идет об итерационной циклической модели разработки. Например, широкое использование визуальных методов проектирования с автоматической генерацией кода фактически стирает грань между проектированием и кодированием. А тестирование вообще пронизывает всю жизнь программы. Имеются и субъективные факторы, которые определяются различиями стратегических бизнес-целей разных поставщиков методологий. Именно этим объясняется то, что Microsoft - основу бизнеса которой составляют не средства разработки, а платформенное ПО, - больше внимания (по сравнению с теми же IBM Rational и Borland) уделяет общим вопросам организации процесса создания приложений, а также их внедрению.

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

методологий других разработчиков ALM-продуктов.

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

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

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

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

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

· Разработка

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

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

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

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

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

· Наделение соответствующими полномочиями ролевых кластеров.

Таким образом, все ролевые кластеры в команде равноправны. Однако иерархия отчётности при этом не нарушается, а остается прежней. Это путь к качественному продукту. Составление календарных планов работ осуществляется руководителем соответствующего ролевого кластера. Это побуждает к большей ответственности за свои сроки и обязательства, чем за те, которые на тебя спустили сверху. Каждый ролевой кластер принимает участие в принятии решений о завершении фаз проекта. Противоречия разрешаются методом компромиссов. Кроме того хорошей практикой является вход в состав группы представителей заказчика, что увеличивает заинтересованность и активное содействие внедрению со стороны заказчика. Кроме того, заказчик становится более информированным о ходе проекта т.к. информация по проекту между кластерами доступна членам команды. Например, если разрабатывается система автоматизации предприятия, хорошей, на мой взгляд, практикой будет назначить руководителем кластера Управление выпуском (по сути, это внедрение и материальное обеспечение внедрения) представителя заказчика, а исполнителями же внедрения - сотрудников компании-исполнителя. В случае успеха слава за удачу (речь идет не о финансовом поощрении) разделится поровну между всеми участниками проекта. А вот ответственность распределена в соответствии с ролевым кластером. Менеджер проекта (ролевой кластер Управление программой) будет отвечать, если проект не уложится в срок и в смету, разработка – если не выполнит разработку в названный ей же срок, тестирование – если в выпущенной версии будут возникать проблемы и т.д. Этап планирования не завершиться пока все ролевые кластеры не будут согласны с планом проекта. Это, конечно, несколько увеличит срок принятия решений, зато многократно уменьшит вероятность ошибочных решений. Однако, по мнению Microsoft, такой подход намного сильнее стимулирует творчество, ответственность, коммуникации и взаимопонимание в проектной группе, чем привычный нам, вид управления самодержца.

Модель процессов MSF сочетает в себе качества двух классических моделей: каскадной и спиральной.

Процесс MSF ориентирован на "вехи" ( milestones ). Вехи – ключевые точки процесса разработки, которые характеризуют достижение какого–либо существенного результата.

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

Каскадная и спиральная модели процессов

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

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

Каскадная модель (waterfall)

Рис. 5.1.

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

На рисунке: Ромбы соответствуют вехам, стрелки – фазам.

Спиральная модель.

Рис. 5.2.

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

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

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

Рис. 5.3.

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

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

   Поскольку выработка единого видения проекта и следование ему настолько важны, MSF выделяет для этих целей отдельную фазу (этап) разработки – "Выработка концепции".

2. Проявляйте гибкость – будьте готовы к переменам. В противоположность каскадной модели MSF основывается на принципе непрерывной изменяемости условий проекта при неизменной эффективности управления.
3. Концентрируйтесь на бизнес - приоритетах. Разрабатываемый продукт должен приносить определенную выгоду или отдачу конечным пользователям. В случае организаций – бизнес – отдачу.

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

4. Поощряйте свободное общение. Исторически многие организации строили свою работу по принципу need-to-know, то есть сведения к минимуму информированности сотрудников.

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

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

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

MSF версии 3.0 интегрирует в себе две ранние модели процессов: модель разработки приложений ( application development - AD) и модель внедрения инфраструктуры (infrastructure deployment - ID). Новая единая модель покрывает процесс создания решения с самого его начала и до момента окончательного внедрения. Таким образом, использовавшаяся ранее четырехфазная схема расширена до пяти фаз. Каждая фаза заканчивается главной вехой , результаты которой становятся видимыми за пределами проектной команды.

Рис. 5.4.

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

На фазе выработки концепции (envisioning phase ) закладывается одна из фундаментальных основ успеха проекта – создание и сплочение проектной группы на основе выработки единого видения. Проектная группа должна четко представить себе, что она хочет сделать для заказчика и сформулировать свою цель таким образом, чтобы максимально мотивировать как заказчика, так и саму проектную команду. Выработка высокоуровневого взгляда на цели и условия проекта может рассматриваться как ранняя форма планирования; она подготавливает почву для процессов создания детальных планов, которые будут осуществлены непосредственно во время фазы планирования.

Основными задачами фазы выработки концепции являются создание ядра проектной группы (см. ниже) и подготовка документа общего описания и рамок проекта ( vision /scope document). Формирование видения проекта и специфицирование его рамок (Видение ( vision ) – это ничем не ограничиваемое представление о том, каким должно быть решение; Рамки (scope) же дают четкие границы того, что из предложенного этим видением будет реализовано в условиях существующих проектных ограничений).

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

Также во время фазы выработки концепции производится выявление и анализ бизнес требований. Более детально эти требования рассматриваются во время фазы планирования.

Ведущим ролевым кластером на фазе выработки концепции является "Управление продуктом".

Введение

Структура 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.

Декларация по УСН