Согласно статистике доля успешно завершенных IT проектов не превышает 30%. Под успешным проектом понимается проект, не выходящий за рамки бюджета и времени, результат которого соответствует ожиданиям заказчика.
| 2000 | 23% | 49% | 28% |
| 1998 | 28% | 46% | 26% |
| 1995 | 40% | 33% | 27% |
| 1994 | 31% | 53% | 16% |
Руководствуясь стремлением повысить отдачу от IT-проектов, компания Майкрософт в 1994 году выпустила пакет руководств по эффективному проектированию, разработке, внедрению и сопровождению решений, основанных на ее технологиях.
$8000 ЗА КОД НА HASKELL / «Фримонады ваше всё!» / Интервью с адептом haskell Александром Граниным
Знания, заложенные в эти руководства, базировались на опыте Майкрософт в реализации проектов крупного масштаба по разработке и сопровождению программного обеспечения, на опыте консультантов Майкрософт и достижениях IT-индустрии в целом.
Результат был представлен в виде двух взаимосвязанных и дополняющих друг друга областях знаний: Microsoft Solutions Framework (MSF) и Microsoft Operations Framework (MOF) .
MOF затрагивает вопросы, связанные с организацией персонала и процессов; технологиями и менеджментом в условиях сложных, распределенных и разнородных IT-сред.
Создание бизнес-решения в рамках отведенных времени и бюджета требует наличия испытанной методологической основы. MSF предлагает проверенные методики для планирования, проектирования, разработки и внедрения успешных IT-решений. Благодаря своей гибкости, масштабируемости и отсутствию жестких инструкций MSF способен удовлетворить нужды организации или проектной группы любого размера. Методология MSF состоит из принципов, моделей и дисциплин по управлению персоналом, процессами, технологическими элементами и связанными со всеми этими факторами вопросами, характерными для большинства проектов.
Основные компоненты MSF
Базовые принципы MSF :
- Распределение ответственности при фиксации отчетности
- Наделяйте членов команды полномочиями
- Концентрируйтесь на бизнес-приоритетах
- Единое видение проекта
- Проявляйте гибкость — будьте готовы к переменам
- Поощряйте свободное общение
MSF состоит из двух моделей и трех дисциплин:
Что делать после установки Windows? Где скачать драйверы и необходимый софт?
- Модель процессов MSF . Представляет собой общую методологию разработки и внедрения IT-решения, охватывающую весь жизненный цикл создания решения. Эта модель сочетает в себе особенности двух классических моделей процессов: спиральной и каскадной.
- Модель проектной группы MSF . Одной из основ MSF является постулат о шести качественных целях, достижение которых определяет успешность проекта. Исходя из этих целей построена модель проектной группы . Она включает в себя шесть ролевых кластеров , каждый из которых имеет свою область компетенции, а также связанные с нею цели и задачи.
- Дисциплина управления проектами. Данная дисциплина описывает основные принципы, концепции и характеристики управления проектом в рамках MSF . Она отвечает вопрос: Что такое управление проектом?
- Дисциплина управления рисками. MSF рассматривает изменения и связанные с ними затруднения как неотъемлемую часть жизненного цикла информационных технологий. MSF отстаивает превентивный подход к работе с рисками. Должна осуществляться непрерывная оценка рисков на протяжении всего жизненного цикла проекта. Данная дисциплина предлагает принципы, идеи и рекомендации, подкрепленные описанием пошагового процесса для успешного активного управления рисками. Этот процесс включает в себя выявление и анализ рисков; планирование и реализацию стратегий по их профилактике и смягчению возможных последствий; отслеживание состояния рисков и извлечение уроков из обретенного опыта.
- Дисциплина управления подготовкой. Данная дисциплина посвящена управлению знаниями, профессиональными умениями и способностями, необходимыми для планирования, создания и сопровождения успешных решений. Дисциплина управления подготовкой MSF описывает фундаментальные принципы MSF и дает рекомендации по применению превентивного подхода к управлению знаниями на протяжении всего жизненного цикла информационных технологий. Эта дисциплина также рассматривает планирование процесса управления подготовкой. Будучи подкрепленной испытанными практическими методиками, дисциплина управления подготовкой предоставляет проектным группам и отдельным специалистам базу для осуществления этого процесса.
Источник: intuit.ru
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, будет являться основой успеха проекта и позволит сделать проектные группы более эффективными и успешными.
Источник: www.tadviser.ru