Методология Microsoft Solutions Framework (MSF)
Три модели MSF
Корпорация Microsoft предлагает технологию организации работы команды разработчиков информационных систем уровня предприятия – Microsoft Solutions Framework (MSF). Эта технология содержит комплект моделей, методик и руководств по управлению проектами разработки ИС.
Управление проектами в MSF рассматривается как управление изменениями и рисками. Существует множество причин, приводящих к неудачам: ошибки в прогнозах, постоянно изменяющиеся требования, нечетко поставленные проектные спецификации и т.п. Поэтому очень важно научиться управлять изменениями и рисками, что и обеспечивает MSF, который объединяет наиболее успешный опыт разработчиков Microsoft, опыт заказчиков и партнеров. Он собирается и анализируется с целью выделить повторяющиеся факторы, обеспечивающие успех проекта. Затем эти факторы успеха интегрируются во взаимосвязанные модели, применение которых позволяет получить технологические решения в контексте конкретного бизнеса.
В состав MSF входят три модели: модель команды, модель проектной группы и модель процесса проектирования. Эти модели можно использовать как самостоятельно, так и в различных комбинациях, в зависимости от задач и потребностей, стоящих перед разработчиками.
Модель команды отвечает на вопрос: как должна быть построена и структурирована проектная группа, для того чтобы можно было оптимизировать процесс проектирования по срокам, качеству и затратам. Структура команды должна позволять отслеживать постоянно изменяющиеся требования в проекте и создавать качественный продукт в условиях ограничений на время и ресурсы. Чтобы быть эффективной, группа, как правило, должна быть небольшой по численности. Предлагаются следующие характеристики такой команды:
|
|
|
- каждый общается с каждым и каждый делает реальную работу;
- общие для всех членов группы цели и планы;
- каждый понимает как проблемы конечного пользователя, так и проблемы разработчика;
- каждый несет ответственность за свою работу, в том числе и перед группой.
Первое утверждение в этом списке – «каждый общается с каждым» - отрицает иерархический способ структурирования проектной группы. Для проектной группы MSF вопрос «кто кому подчинен?» не имеет смысла. Модель команды существенно отличается правилами формирования и составом от традиционных проектных групп. Как правило, в традиционную проектную группу не входят такие традиционные для проекта роли, как конечные пользователи и структуры, выполняющие контроль качества и обучение пользователей. Их отсутствие в составе группы повышает риски, удлиняет сроки проектирования, снижает качество продукта.
|
|
|
Таким образом, модель команды представляет собой самоуправляемые малые команды, члены которой полностью понимают и принимают свои роли, четко понимают цели и задачи проекта, несут полную ответственность перед заказчиком и членами команды.
Недостатком такой модели команды является ограниченный контроль высшего руководства за внутренними взаимоотношениями и процессами в проектной группе.
Целью такой команды является создание качественного продукта, который:
- удовлетворяет ожидания и заказчика и конечных пользователей;
- удовлетворяет проектным ограничениям;
- соответствует реальным потребностям заказчика;
- понятен в использовании конечным пользователям;
- просто внедряется.
Модель проектной группы создана на основе характеристик модели команды, рассмотренных выше. Она определяет основные роли, закрепленные за членами проектной группы (рис. 2.10). В основу модели проектной группы положены следующие идеи.
Рис. 2.10. Модель проектной группы MSF
Для каждого члена группы определяется роль и зоны ответственности на весь период работы над проектом. То есть каждый сфокусирован на успехе проекта и настроен на работу в течение всего цикла проекта. Ключевым фактором успеха являются коммуникации между членами проектной группы. При этом реализуется параллельная работа всех участников группы над проектом, в состав которого в обязательном порядке включаются пользователи и обучающий персонал.
|
|
|
Модель проектной группы MSF практически не связана с организационной структурой, в одной проектной группе могут работать специалисты из различных подразделений. За каждым членом проектной группы закрепляется конкретная роль, для которой строится план работы, являющийся составной частью общего плана проекта. При этом каждая роль в модели проектной группы имеет свою особую компетенцию.
Рассмотрим более подробно каждую из этих ролей, указанных на рис. 2.10.
Менеджер проекта обеспечивает коммуникационный канал между заказчиком и проектной группой, управляет ожиданиями заказчика, разрабатывает и поддерживает бизнес-контекст проекта. Его задача – определить и обеспечить удовлетворение заказчика. Обычно для этой роли выбирают квалифицированного пользователя, сотрудника коммерческого отдела или другого представителя заказчика, если он понимает задачи и механизм бизнеса.
Менеджер программы управляет коммуникациями и взаимоотношениями в проектной группе, является фактическим координатором, разрабатывает функциональные спецификации и управляет ими, ведет график проекта и отчитывается по состоянию проекта, инициирует принятие критичных для хода проекта решений.
|
|
|
Разработчик принимает технические решения, которые могут быть реализованы и использованы, создает продукт, удовлетворяющий спецификациям и ожиданиям заказчика, консультирует другие роли в ходе проекта. Он участвует также в создании функциональных спецификаций, отслеживает и исправляет ошибки за приемлемое время.
В контексте конкретного проекта роль разработчика может подразумевать установку программного обеспечения, настройку продукта и др.
Следует иметь в виду, что разработка клиент-серверных систем требует детального знания высокоуровневых языков программирования, визуального программирования, сетевых технологий и проектирования баз данных. Поэтому в группу разработчиков обычно включают технических специалистов из всех этих областей, а в качестве руководителя группы разработчиков назначают специалиста, который знает и понимает ключевые моменты каждой из этих технических областей.
Тестер обеспечивает не только проверку кода, но и тестирование функциональных спецификаций, пользовательских интерфейсов, системы обеспечения производительности, планов внедрения и используемую терминологию. Эта роль обеспечивает выявление всех особенностей и задач еще до выпуска версии продукта, разрабатывает стратегию тестирования и планы тестирования для каждой базы проекта.
Инструктор отвечает за снижение затрат на дальнейшее сопровождение продукта и обеспечение максимальной эффективности пользователя. Следует особо отметить, что речь идет о производительности пользователя, а не системы. Для обеспечения максимальной эффективности работы пользователей инструктор собирает статистику по производительности пользователей и создает решения для повышения производительности с использованием таких технологий, как мультимедиа, видео, HTML, встроенные системы подсказки, тренажеры и т.п. Инструктор принимает участие во всех обсуждениях пользовательского интерфейса и архитектуры продукта.
Логистик обеспечивает простое внедрение и развитие продукта, его задача исключить ситуацию, когда внедрение продукта стоит дороже его разработки. Логистик должен обеспечить, чтобы заказчик был готов к внедрению, чтобы вовремя были выполнены все подготовительные работы и существовала необходимая инфраструктура.
Помимо перечисленных ролей можно выделить еще «роли поддержки». Это специалисты и эксперты в ключевых точках инфраструктуры. Они привлекаются к работе, когда это необходимо, но не принимают решений.
Если численность проектной группы меньше шести человек, то часть ролей может совмещать и выполнять один человек. При численности проектной группы больше шести человек одна роль может быть закреплена за несколькими специалистами, среди которых назначается лидер группы.
Параметры различных ролей в составе проектной группы можно формализовать в виде следующей таблицы.
Таблица 2
Дата добавления: 2019-07-17; просмотров: 191; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!