Модель Microsoft Solutions Framework (msf)
1.1 Принципы, концепции и методики msf
Существует две основные модели организации коллектива при разработке ПО:
1) Иерархическая модель
2) Модель группы
Иерархическая модель организации определяет начальников и подчиненных. Однако, если в современных производственных средах один менеджер проекта отвечает за все тонкости разработки и принимает все важные решения, возникает множество проблем, ведущих к провалу проекта.
Недостатки иерархической модели:
нехватка информации;
невозможность учесть все особенности проекта;
отсутствие полноценной связи между всеми участниками проекта, так как вся информация идет в одном направлении — вверх по иерархии, к главному менеджеру;
трудность освоения новых технологий, необходимых при создании кроссплатформенных приложений;
сложность расстановки приоритетов.
Кроме того, опыта одного человека чаще всего недостаточно для быстрого решения задачи и для интеграции приложения в существующую инфраструктуру.
Поэтому для анализа современных решений необходимо использовать модель (рис. 1), представляющую собой иерархию уровней управления процессом разработки ПО [1].
Рис. 1. Иерархия уровней управления процессом разработки ПО
В организациях, построенных на основе иерархической модели, затруднен обмен информацией — в этой модели он, по определению, осуществляется через посредников. Дабы сгладить недостатки иерархической модели, в проектной группе предусматривается распределение обязанностей руководителя между членами коллектива. При этом за проект отвечает не один человек, а все члены группы — каждый за свой участок.
Модель группы не определяет структуру коллектива с точки зрения отдела кадров. В такую разностороннюю группу привлечены ресурсы из разных отделов организации. Задача модели проектной группы — определить цели проекта и распределить обязанности. Руководители каждого направления с помощью выделенных им ресурсов выполняют возложенную на них часть работы. Обязанности ролей определяются работой над проектом, а не деятельностью «штатной единицы». При этом руководители направлений выполняют свои обычные функции: составляют график выплаты премий, распределяют отпуска и контролируют эффективность работы сотрудников. Начальник может оценить степень участия и эффективность работы сотрудников в проектной группе, но это — прерогатива менеджера, а не проектной группы.
Далее в курсовой работе поочередно будут рассмотрены современные модели проектных групп: Microsoft Solutions Framework (MSF), Rational Unified Process (RUP) и Extreme Programming (XP).
Модель проектной группы MSF (MSF Team Model) описывает подход Майкрософт к организации работающего над проектом персонала и его деятельности в целях максимизации успешности проекта. Данная модель определяет ролевые кластеры, их области компетенции и зоны ответственности, а также рекомендации членам проектной группы, позволяющие им успешно осуществить свою миссию по воплощению проекта в жизнь [2].
Microsoft Solutions Framework представляет собой хорошо сбалансированный набор методик организации процесса разработки, который может быть адаптирован под потребности практически любого коллектива разработчиков. MSF содержит не только рекомендации общего характера, но и предлагает адаптируемую модель коллектива разработчиков, определяющую взаимоотношения внутри коллектива, гибкую модель проектного планирования, основанного на управлении проектными группами, а также набор методик для оценки рисков.
MSF предлагает использовать в процессе создания и функционирования проектной группы ряд принципов, концепций и методик:
Основные принципы:
распределение ответственности при фиксации отчетности - все члены команды отвечают за успех проекта; они разделяют честь и славу в случае положительного результата и должны совершенствовать свой профессиональный уровень, работая над уроками менее удачных проектов;
наделение членов команды необходимым для работы уровнем полномочий;
концентрация на бизнес-приоритетах - необходимость принятия решений проектной группой на основе полного понимания бизнеса заказчика и при активном его участии в реализации проекта;
единое видение проекта, формирующего целостный подход проектной группы к разработке IT-решения;
гибкость, переменчивость - присутствие всех командных ролей и их вовлеченность в процесс принятия решений, обусловленных происходящими переменами;
поощрение свободного общения - открытый и честный обмен информацией как внутри команды, так и с ключевыми заинтересованными лицами вне ее;
Ключевые принципы:
команда соратников - равноправное положение каждой из ролей в команде;
сфокусированность на нуждах заказчика - обязательное понимание его бизнес-задач и стремление к их решению со стороны команды;
нацеленность на конечный результат;
установка на отсутствие дефектов;
стремление к самосовершенствованию;
создание заинтересованности и высокого морального духа команды;
Испытанные методики:
создание малых многопрофильных проектных групп - большая оперативность действий в сравнении с крупными коллективами;
коллективная работа - меньше препятствий для эффективного обмена информацией;
всеобщее участие в проектировании [2].
Сегодня основные принципы и концепции модели проектной группы MSF во многом еще являются чуждыми большинству IT – компаниям, поскольку здесь разрушаются некоторые стереотипы (например, диктаторские полномочия и соответствующая ответственность менеджера проекта) и предлагается несколько непривычная структура проектной группы. Тем не менее, с каждым годом увеличивается число компаний, осознавших достоинства данной модели и ее преимущества перед другими.
Внедрение модели проектной группы MSF уже помогло компании Damgaard выпустить в срок новую систему управления предприятием АХАРТА, используемого более чем в 20 странах мира, компании Navision – увеличить штат разработчиков в несколько раз без дополнительных затрат на обучение, группе разработчиков из Unitied Airline – создать крупнейшую в мире систему резервирования авиабилетов в срок и без перерасхода выделенного бюджета.
Внедрение модели MSF необходимо для любой растущей компании. В частности Damgaard и Navision внедрили MSF Team model именно в тот момент, когда начался интенсивный рост численности разработчиков. В соответствии с данной модель были четко определены обязанности каждого члена команды.