Методология msf
Microsoft Solutions Framework (MSF) разработан корпорацией Microsoft как методология ведения IT-проектов. MSF представляет каждую фазу проекта как:
Выработка концепции (Envisioning)
Планирование (Planning)
Разработка (Developing)
Стабилизация (Stabilizing)
Внедрение (Deploying)
В 1994 году, стремясь достичь максимальной отдачи от IT-проектов, Microsoft выпустила в свет пакет руководств по эффективному проектированию, разработке, внедрению и сопровождению решений, построенных на основе своих технологий. Эти знания базируются на опыте, полученном Microsoft при работе над большими проектами по разработке и сопровождению программного обеспечения, опыте консультантов Microsoft и лучшем из того, что накопила на данный момент IT-индустрия. Всё это представлено в виде двух взаимосвязанных и хорошо дополняющих друг друга областей знаний.
Наиболее популярные прикладные варианты MSF, разработанные Microsoft:
• методика внедрения решений в области Управления проектами;
• методика управления IT-проектами на базе методологий MSF и Agile.
Модель проектной группы MSF
Модель проектной группы MSF (MSF Team Model) описывает подход Майкрософт к организации работающего над проектом персонала и его деятельности в целях максимизации успешности проекта. Данная модель определяет ролевые кластеры, их области компетенции и зоны ответственности, а также рекомендации членам проектной группы, позволяющие им успешно осуществить свою миссию по воплощению проекта в жизнь.
работе команды:
1. Распределение ответственности при фиксации отчетности
2. Наделяйте членов команды полномочиями
3. Концентрируйтесь на бизнес-приоритетах
4. Единое видение проекта
5. Проявляйте гибкость — будьте готовы к переменам
6. Поощряйте свободное общение
Успешное использование модели проектной группы MSF основывается на ряде ключевых концепций (key concepts):
1. Команда соратников
2. Сфокусированность на нуждах заказчика
3. Нацеленность на конечный результат
4. Установка на отсутствие дефектов
5. Стремление к самосовершенствованию
6. Заинтересованные команды работают эффективно
MSF основан на постулате о шести качественных целях, достижение которых определяет успешность проекта. Эти цели обуславливают модель проектной группы. В то время как за успех проекта ответственна вся команда, каждый из её ролевых кластеров, определяемых моделью, ассоциирован с одной из упомянутых шести целей и работает над её достижением.
В проектную группу входят такие ролевые кластеры:
• управление программой
• управление продуктом
• разработка
• тестирование
• управление релизом
• удовлетворение потребителя
Они ответственны за различные области компетенции (functional areas) и связанные с ними цели и задачи. Иногда ролевые кластеры называются просто ролями. Но в любом случае суть концепции остается той же — построить основу производственных отношений и связанную с ней модель команды такими, чтобы они были приспосабливаемыми (масштабируемыми) для удовлетворения нужд любого проекта.
Как уже было сказано выше, проектная группа по MSF состоит из шести ролевых кластеров, каждый из которых отвечает за:
• управление программой (program manager) — разработку архитектуры решения, административные службы;
• разработку (developer) — разработку приложений и инфраструктуры, технологические консультации;
• тестирование (QAE) — планирование, разработку тестов и отчетность по тестам;
• управление выпуском (release manager) — инфраструктуру, сопровождение, бизнес-процессы, выпуск готового продукта;
• удовлетворение заказчика (user experience) — обучение, эргономику, графический дизайн, техническую поддержку;
• управление продуктом (product manager) — бизнес-приоритеты, маркетинг, представительство интересов заказчика.
Наличие шести ролевых кластеров не означает, что количество членов команды должно быть кратным шести — один человек может совмещать несколько ролей и наоборот, ролевой кластер может состоять из нескольких лиц в зависимости от размера проекта, его сложности и профессиональных навыков, требуемых для реализации всех областей компетенции кластера. Минимальный коллектив по MSF может состоять всего из трех человек. Модель не требует назначения отдельного сотрудника на каждый ролевой кластер. Смысл состоит в том, что в команде должны быть представлены все шесть качественных целей. Обычно, выделение как минимум одного человека на каждый ролевой кластер обеспечивает полноценное внимание к интересам каждой из ролей, но это экономически оправданно не для всех проектов. Зачастую члены проектной группы могут объединять роли.
В малых проектных группах объединение ролей является необходимым. При этом должны соблюдаться два принципа:
1. Роль команды разработчиков не может быть объединена ни с какой другой ролью.
2. Избежание сочетания ролей, имеющих предопределенные конфликты интересов.
Как и в любой другой командной деятельности, подходящая комбинация ролей зависит от самих членов команды, их опыта и профессиональных навыков. На практике совмещение ролей встречается нередко. И если проектная группа производит его обдуманно и управляет связанными с таким объединением рисками, возникающие проблемы будут минимальными.
MSF не предоставляет конкретных рецептов управления проектами и не содержит объяснений разнообразных методов работы, которые применяют опытные менеджеры. Принципы MSF формируют такой подход к управлению проектами, при котором:
• ответственность за управление проектом распределенная между лидерами ролевых кластеров внутри команды — каждый член проектной группы отвечает за общий успех проекта и качество создаваемого продукта.
• профессиональные менеджеры выступают в качестве консультантов и наставников команды, а не выполняют функции контроля над ней — в эффективно работающей команде каждый её член имеет необходимые полномочия для выполнения своих обязанностей и уверен, что получит от коллег все необходимое.
Как следует из вышесказанного, одна из характерных особенностей MSF — отсутствие должности менеджера проекта!
Модель проектной группы MSF предлагает разбиение больших команд (более 10 человек) на малые многопрофильные группы направлений (feature teams). Эти малые коллективы работают параллельно, регулярно синхронизируя свои усилия. Кроме того, когда ролевому кластеру требуется много ресурсов, формируются т. н. функциональные группы (functional teams), которые затем объединяются в ролевые кластеры.
Использование ролевых кластеров не подразумевает и не навязывает никакой специальной структуры организации или обязательных должностей. Административный состав ролей может широко варьироваться в разных организациях и проектных группах. Чаще всего роли распределяются среди различных подразделений одной организации, но иногда часть их отводится сообществу потребителей или внешним по отношению к организации консультантам и партнерам. Ключевым моментом является четкое определение работников, ответственных за каждый ролевой кластер, их функций, ответственности и ожидаемого вклада в конечный результат.
Модель проектной группы MSF не обеспечивает успех сама по себе. Есть много других факторов, определяющих успех или неудачу проекта, но структура проектной группы, безусловно, вносит существенный вклад.
Подходящая структура команды является фундаментом успеха, и реализация модели MSF с использованием лежащих в её основе принципов поможет сделать проектные группы более эффективными и, как следствие, более успешными.
Метод PERT (Program Evaluation And Review Technique), был создан корпорацией «Локхид», консалтинговой фирмой «Буз, Аллен энд Гамильтон» в ВМС США при разработке ракетной системы «Поларис». Оба метода были основаны на использовании сетевых диаграмм, но Методика Критического Пути оперировала только одной длительностью работы, в то время как методика PERT учитывала четыре длительности - оптимистическую, пессимистическую, наиболее вероятную и средневзвешенную. Т.е. основное различие двух методов заключается в различном подходе к длительности операций.
Метод критического пути исходит из того, что длительность операций можно оценить с достаточно высокой степенью точности и определенности.
Метод «ПЕРТ» допускает неопределенность продолжительности операций и анализирует влияние этой неопределенности на продолжительность работ по проекту в целом. В настоящее время более широко применяют метод критического пути, а не метод анализа и оценки а планов. Системы управления работами по реализации проектов, в основе которых лежит метод критического пути, в настоящее время применяются во всем мире. Методика PERT появилась при выполнении проекта, окружающая среда которого характеризовалась высокой степенью неопределенности, поэтому приходилось оценивать разные варианты завершения работ.
Степень неопределенности проектной среды, в которой создавалась Методика Критического Пути, была существенно меньше, и исполнители могли довольно точно оценить длительность работ, основываясь на предыдущем опыте.
С тех пор эти методики взаимно интегрировались, и сейчас при планировании в основном используется Методика Критического Пути.
Метод критического пути (Critical Path Method - CPM). Предположение о неограниченности ресурсов, критичен только срок выполнения.
Метод критического пути — эффективный инструмент планирования расписания и управления сроками проекта.
В основе метода лежит определение наиболее длительной последовательности задач от начала проекта до его окончания с учетом их взаимосвязи. Задачи, лежащие на критическом пути (критические задачи), имеют нулевой резерв времени выполнения, и, в случае изменения их длительности, изменяются сроки всего проекта. В связи с этим, при выполнении проекта критические задачи требуют более тщательного контроля, в частности, своевременного выявления проблем и рисков, влияющих на сроки их выполнения и, следовательно, на сроки выполнения проекта в целом. В процессе выполнения проекта критический путь проекта может меняться, так как при изменении длительности задач некоторые из них могут оказаться на критическом пути.
Расчёт критического пути.
Если начальный момент выполнения проекта положить равным нулю, то сроки окончания у первых работ сетевого графика, то есть работ, выходящих из первого события, будет определяться их продолжительностью. Время наступления любого события следует положить равным самому позднему времени окончания непосредственно входящих в это событие работ: считается, что работа в сетевом графике не может начаться, пока не завершены все предшествующие для нее работы.
В процессе решения — методом «эстафеты» — просматриваются все дуги сетевого графика. Пусть очередная просматриваемая дуга связывает вершины i и j. Если для вершины i определено предположительное время его свершения и это время плюс продолжительность работы больше предположительного времени наступления события j, тогда для вершины j устанавливается новое предположительное время наступления, равное предположительному времени наступления события i плюс продолжительность работы рассматриваемой дуги. Решение заканчивается, когда очередной просмотр дуг не вызывает ни одного исправления предположительного значения времени начала / окончания работ/событий.
В результате может быть определено событие с самым поздним временем наступления, и путь от начальной вершины в эту конечную будет считаться критическим и определять продолжительность выполнения проекта. Наряду с общей продолжительностью выполнения проекта, критический путь определяет другие характеристики сетевого графика, играющие важную роль при планировании реализации нововведения, минимизации сроков и расходов на разработку.
Суть решения задачи сокращения сетевого графика сводится к привлечению дополнительных ресурсов к выполнению работ, лежащих на критическом пути, снятием работ, не лежащих на критическом пути, запараллеливанием работ.