Какой ролевой кластер msf осуществляет выявление и анализ бизнес требований к ис

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

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

• Выступает в роли представителя Заказчика
• Формирует общее видение/рамки проекта
• Организует работу с требованиями Заказчика
• Развивает сферы применения в бизнесе
• Формирует ожидания Заказчика
• Определяет компромиссы между параметрами «возможности продукта / время / ресурсы»
• Организует маркетинг, PR
• Разрабатывает, поддерживает и исполняет план коммуникаций

• Управление проектом
• Выработка архитектуры решения
• Контроль производственного процесса
• Административные службы

• Управляет процессом разработки с целью получения готового продукта в отведенные сроки
• Формулирует спецификацию продукта и разрабатывает его архитектуру
• Регулирует взаимоотношения и коммуникацию внутри проектной группы
• Следит за временным графиком проекта и готовит отчетность о его состоянии
• Проводит в жизнь важные компромиссные решения
• Разрабатывает, поддерживает и исполняет сводный план и календарный график проекта
• Организует управление рисками

• Технологическое консультирование
• Проектирование и осуществление реализации
• Разработка приложений
• Разработка инфраструктуры

• Определяет детали физического дизайна
• Оценивает необходимые время и ресурсы на реализацию каждого элемента дизайна
• Разрабатывает или контролирует разработку элементов
• Подготавливает продукт к внедрению
• Консультирует команду по технологическим вопросам

• Планирование тестов
• Разработка тестов
• Отчетность по тестам

• Обеспечивает обнаружение всех дефектов
• Разрабатывает стратегию и планы тестирования
• Осуществляет тестирование

• Обеспечение технической поддержки
• Обучение
• Эргономика
• Графический дизайн
• Интернационализация
• Общедоступность (обеспечение возможности работы для пользователей с ограниченными физическими возможностями)

• Представляет интересы отделов поставки и обслуживания продукта
• Организует снабжение проектной группы
• Организует внедрение продукта
• Вырабатывает компромиссы в управляемости и удобстве сопровождения продукта
• Организует сопровождение и инфраструктуру поставки
• Организует обеспечение проектной группы

Можно выделить три направления, в которых осуществляется масштабирование проектной команды .

Cистема управления проектами ПМ Форсайт

Первое — создание групп направлений . Группы направлений (feature teams) — это компактные мини-команды, отвечающие за определенные компоненты создаваемого решения и образующие матричную организационную структуру (см. рис. 3.2). В них входят по одному или несколько членов из разных ролевых кластеров . Такие команды имеют четко определенную задачу и ответственны за все относящиеся к ней вопросы, начиная от планирования и кончая запуском в эксплуатацию.

Рис. 3.2. Разделение проектной команды на группы направлений [5]

Второе — создание функциональных групп . Функциональные группы — это группы, существующие внутри ролевых кластеров . Они создаются в больших проектах, когда необходимо сгруппировать работников внутри ролевых кластеров по их областям компетенции ( рис. 3.3). Например, в команде разработчиков возможна группировка сотрудников в соответствии с назначением разрабатываемых ими модулей: интерфейс пользователя, реализация бизнес-логики или объектов данных. В отличие от групп направлений , функциональные группы имеют внутреннюю иерархическую структуру.

Рис. 3.3. Разделение проектной команды на функциональные группы [5]

Третье направление масштабирования — объединение ролей. Как правило, выделение одного человека на каждый ролевой кластер обеспечивает полноценное исполнение каждой из ролей, но это экономически оправдано не для всех проектов. Зачастую в малых проектных группах члены группы могут объединять роли. При этом MSF рекомендует соблюдать два принципа.

Во-первых, роль команды разработчиков не может быть объединена ни с какой другой ролью. Разработчики — это создатели проекта, и они не должны отвлекаться от своей главной задачи. Наделение разработчиков дополнительными обязанностями лишь делает более вероятным выход из календарного графика проекта.

Второй принцип — это избежание сочетания ролей, имеющих предопределенные конфликты интересов .

Рекомендации MSF по возможностям объединения ролей приведены на рис. 3.4.

Роль менеджера проекта возлагается на кластер «Управление программой» . Основные функции этого кластера — управление проектом , выработка архитектуры решения, контроль производственного процесса и организация деятельности административных служб. В небольших проектах все эти функции могут успешно осуществляться одним менеджером программы. Но по мере роста объема и сложности проекта в этом ролевом кластере выделяются две ветви специализации: работа над архитектурой и спецификациями и управление проектом .

Организация взаимодействия между проектной командой и заказчиками (заинтересованными лицами) распределяется среди ролевых кластеров «Управление программой» и «Управление продуктом» . «Управление продуктом» обеспечивает отчетность в части характеристик решения, а «Управление программой» — отчетность о ходе проекта.

Источник: intuit.ru

Ролевые кластеры модели проектной группы

Во время фазы стабилизации производится тестирование разработанного решения. При этом внимание фокусируется на его эксплуатации в реалистичной модели производственной среды. Проектная группа занимается приоритезацией и устранением ошибок, а также подготовкой решения к выпуску.

Результатами фазы стабилизации являются:

· Окончательный продукт (golden release).

· Документация выпуска (release notes).

· Материалы поддержки решения.

· Результаты и инструментарий тестирования.

· Исходный и исполнимый код приложений.

· Анализ пройденной фазы (milestone review).

Во время этой фазы проектная группа внедряет технологии и компоненты решения, стабилизирует внедренное решение, передает работу персоналу поддержки и сопровождения и получает со стороны заказчика окончательное одобрение результатов проекта. По завершению внедрения проектная группа производит анализ выполненной работы и удовлетворенности заказчика.

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

Результаты фазы внедрения включают в себя:

· Информационные системы эксплуатации и поддержки.

· Процедуры и процессы.

· Базы знаний, отчеты, журналы протоколов (logbooks).

· Версии проектных документов, массивы данных (load sets) и программный код, разработанные во время проекта.

· Отчет о завершении проекта (project close-out report).

· Окончательные версии всех проектных документов.

· Показатели удовлетворенности заказчика и потребителей.

· Описание последующих шагов.

Распределение ответственности при фиксации отчетности

Наделяйте членов команды полномочиями

Концентрируйтесь на бизнес-приоритетах

Единое видение проекта

Проявляйте гибкость – будьте готовы к переменам

Поощряйте свободное общение

Сфокусированность на нуждах заказчика

Нацеленность на конечный результат

Установка на отсутствие дефектов

Стремление к самосовершенствованию

Заинтересованные команды работают эффективно

Ролевые кластеры модели проектной группы MSF

Ключевая цель ролевого кластера “Управление продуктом” (product management) – довольные заказчики. Проект не может считаться успешным, если он не привел к удовлетворению потребностей заказчика.

Ролевой кластер “Управление программой”

Основная задача этого ролевого кластера – обеспечить реализацию решения в рамках ограничений проекта, что может рассматриваться как удовлетворение требований спонсора проекта к его результату. Для этого “Управление программой” контролирует календарный график проекта, объем работы и отведенный на проект бюджет. Рассматриваемый кластер обеспечивает своевременное достижение требуемых результатов и удовлетворение ожиданий спонсора на протяжении проекта.

Ролевой кластер “Разработка”

Первостепенной задачей ролевого кластера “Разработка” является построение решения в соответствии со спецификацией. Ее выполнение означает создание решения, соответствующего ожиданиям заказчика и условиям, сформулированным в функциональной спецификации. Также данный ролевой кластер строго следует выработанной архитектуре и дизайну решения, которые совместно с функциональной спецификацией составляют сводное описание конечного продукта.

В дополнение к функции непосредственной разработки решения на данный ролевой кластер возлагаются обязанности по технологическому консультированию проектной группы. В этом качестве разработчики занимаются подготовкой исходных данных для проектирования и выбора технологического инструментария решения. Также ролевой кластер “Разработка” создает функциональные прототипы для проверки правильности принятых решений и уменьшения рисков.

Ролевой кластер “Тестирование”

Задача ролевого кластера “Тестирование” (test) – одобрение выпуска продукта только лишь после того, как все дефекты выявлены и улажены. Любое программное обеспечение содержит дефекты. Но нужно обнаружить и уладить (address) все из них до того, как продукт выпущен. Улаживание дефекта может подразумевать различные решения, начиная от устранения и заканчивая документированием способов обхода дефекта (work-around). Поставка продукта с известным дефектом, но с описанием способов его обхода является более предпочтительной, чем поставка продукта с невыявленным дефектом, который в дальнейшем станет сюрпризом – как для проектной команды, так и для заказчика.

Ролевой кластер “Удовлетворение потребителя”

Цель этого ролевого кластера (удовлетворение потребителя — user experience) – повышение эффективности использования продукта. Кластер состоит из шести областей компетенции: общедоступность (accessibility), интернационализация (internationalization), обеспечение технической поддержки (technical communications), обучение пользователей (training), удобство эксплуатации (usability) и графический дизайн (graphic design).

Ролевой кластер “Управление выпуском”

Цель этого ролевого кластера – беспрепятственное внедрение и сопровождение продукта. Эта роль служит связующим звеном между проектной группой и группами процессов сопровождения. Данный ролевой кластер включает в себя следующие области компетенции:

· Управление выпуском готового продукта (commercial release management).

Понравилась статья? Добавь ее в закладку (CTRL+D) и не забудь поделиться с друзьями:

Источник: studopedia.ru

Home

Модель проектной группы MSF (MSF Team Model) описывает подход Майкрософт к организации работающего над проектом персонала и его деятельности в целях максимизации успешности проекта. Данная модель определяет ролевые кластеры, их области компетенции и зоны ответственности, а также рекомендации членам проектной группы, позволяющие им успешно осуществить свою миссию по воплощению проекта в жизнь.

Обзор модели команды MSF

MSF основан на постулате о шести качественных целях, достижение которых определяет успешность проекта. Эти цели обуславливают модель проектной группы. В то время как за успех проекта ответственна вся команда, каждый из ее ролевых кластеров, определяемых моделью, ассоциирован с одной из упомянутых шести целей и работает над ее достижением.

Шесть ролевых кластеров модели проектной группы — это «Управление продуктом» (product management), «Управление программой» (program management), «Разработка» (development), «Тестирование» (test), «Удовлетворение потребителя» (user experience) и «Управление выпуском» (release management). Они ответственны за различные области компетенции (functional areas) и связанные с ними цели и задачи. Иногда ролевые кластеры называются просто ролями. Но в любом случае суть концепции остается той же — построить основу производственных отношений и связанную с ней модель команды такими, чтобы они были приспосабливаемыми (масштабируемыми) для удовлетворения нужд любого проекта. Одна роль (или один кластер) может быть представлена одним или несколькими сотрудниками, в зависимости от размера проекта, его сложности и профессиональных навыков, требуемых для реализации всех областей компетенции кластера.

Рассмотрим подробно ролевой кластер «Тестирование»

Цель работы кластера «Тестирование»

Одобрение выпуска продукта только лишь после того, как все дефекты выявлены и улажены

Область компетенции:

• Планирование тестов

• Разработка методологии и плана тестирования.
• Участие в установлении стандарта качества (quality bar).
• Разработка спецификаций тестов.

• Разработка и поддержка автоматизированных тестов (automated test cases), инструментов и скриптов.
• Проведение тестов с целью определения состояния проекта.
• Управление билдами (manage the build process).

• Доведение до сведения проектной группы информации о качестве продукта.
• Мониторинг найденных ошибок с целью обеспечения их улаживания до выпуска продукта.

Функции:

• Обеспечивает обнаружение всех дефектов
• Разрабатывает стратегию и планы тестирования
• Осуществляет тестирование

Любое программное обеспечение содержит дефекты. Но нужно обнаружить и уладить (address) все из них до того, как продукт выпущен. Улаживание дефекта может подразумевать различные решения, начиная от устранения и заканчивая документированием способов обхода дефекта (work-around). Поставка продукта с известным дефектом, но с описанием способов его обхода является более предпочтительной, чем поставка продукта с невыявленным дефектом, который в дальнейшем станет сюрпризом — как для проектной команды, так и для заказчика.

Чтобы достичь успеха, команда тестировщиков должна фокусироваться на определенных ключевых задачах. Они структурируются в виде трех областей компетенции.

Планирование тестов

Данная область компетенции (планирование тестов — test planning) ролевого кластера «Тестирование» формулирует методологию нахождения и урегулирования проблем качества продукта.

Команда тестировщиков разрабатывает планы и методики тестирования и таким образом формирует стратегию, используемую в проекте для тестирования решения. Планы тестирования включают в себя описание типов тестов, тестируемых составляющих и информацию о требуемых ресурсах (как человеческих, так и технических).

Существенная часть работы данной области компетенции заключается в участии в выработке требуемого уровня качества (quality bar) продукта. Эта деятельность включает в себя предоставление проектной группе метрик контроля качества и критериев успешности решения.

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

Разработка тестов

Эта область компетенции (разработка тестов — test engineering) ответственна за предусмотренные планом тестирования мероприятия, направленные на нахождение и урегулирование всех проблем качества создаваемого продукта. В их числе – работа по созданию и поддержке тестовых сценариев (test cases), разработка средств, скриптов и документации процесса тестирования, управление ежедневными билдами (daily builds), проведение на них тестов с целью четкого определения уровня завершенности продукта.

Отчетность о тестах

Данная область компетенции (отчетность о тестах — test reporting) снабжает проектную группу информацией о текущих изъянах в решении, также как и о достигнутых успехах. Благодаря этому проектная группа имеет четкую картину текущего состояния разработки.

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

Задачи ролевого кластера «Тестирование» на разных фазах проекта

Фаза выработки концепции

Стратегии тестирования; критерии приемлемости, их влияние на разработку решения.

Фаза планирования

Оценка дизайна; требования тестирования; план и календарный график тестирования.

Фаза разработки

Функциональное тестирование; выявление проблем; тестирование документации; доработка плана тестирования.

Фаза стабилизации

Тестирование; сообщение об ошибках и их статусе; тестирование конфигурации.

Источник: www.software-testing.ru