Microsoft Solution Framework Team Model

[[Методология разработки программного обеспечения 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

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

Таблица 1. Матрица совместимости ролевых кластеров MSF.

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

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

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

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

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

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

Рис.2. Совмещение ролевых кластеров в минимальной команде разработки.

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

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

Рис.3. Масштабирование проектной группы (вариант).

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

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