66211

Модель проектной группы MSF для небольших команд

Доклад

Информатика, кибернетика и программирование

Задачи ролевых групп Группа Управление программой : управляет процессом разработки с целью получения готового продукта в отведенные сроки; регулирует взаимоотношения и коммуникацию внутри проектной группы; следит за временным графиком проекта и готовит отчетность о его состоянии...

Русский

2014-08-15

66 KB

4 чел.

Модель проектной группы MSF для небольших команд

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

Основные принципы построения команды

Построение команды в MSF соответствует ряду ключевых концепций. К очевидным можно отнести следующие принципы.

  •  Концентрация на нуждах заказчика. Это главный приоритет любой приличной проектной группы. Он подразумевает обязательное понимание разработчиками бизнес-задач заказчика, активное участие заказчика в проектировании решения и получение его отзывов в ходе процесса разработки.
  •  Нацеленность на конечный результат. Получению конечного результата проекта уделяется больше внимания, чем процессу его достижения. Каждый участник проектной группы должен рассматривать собственную работу как самостоятельный проект или вклад в "общее дело".
  •  Установка на отсутствие дефектов. Это стремление к высочайшему уровню качества. В успешной команде ответственность за качество продукта не может быть делегирована, каждый сотрудник чувствует свою ответственность.

Концепции, считающиеся "ноу-хау" методологии MSF:

  •  "Проектная группа – команда равных". Концепция означает равноправное положение каждой из ролей в команде. Каждый из членов команды, независимо от роли, должен нести ответственность за качество продукта, понимать интересы заказчика и сущность решаемой бизнес-задачи. Решения принимаются методом консенсуса между ролями, но не методом консенсуса между сотрудниками (каждая ролевая группа требует определенной организационной иерархии).
  •  Стремление к самосовершенствованию. Это неустанное саморазвитие посредством накопления опыта и обмена знаниями. По завершению проекта и по окончанию основных его фаз предполагается проведение открытых обсуждений и объективный анализ.

К концепции команды равных в MSF тесно примыкает идея о том, что каждая ролевая группа имеет зону ответственности и защищает интересы заинтересованных лиц из этой зоны.

Модель проектной группы MSF выделяет 7 ролевых групп и 6 ролей (рис. 1).

Задачи ролевых групп 

Группа "Управление программой":

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

"Архитектура продукта"

  •  формулирует спецификацию решения и разрабатывает его архитектуру;
  •  определяет структуру развертывания (внедрения) решения.

"Разработка"

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

"Тестирование"

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

"Управление выпуском"

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

"Удовлетворение потребителя"

  •  представляет интересы потребителя в команде;
  •  организует работу с требованиями пользователя;
  •  определяет компромиссы, относящиеся к удобству использования и потребительским качествам продукта;
  •  определяет требования к системе помощи и её содержание;
  •  разрабатывает учебные материалы и осуществляет обучение пользователей.

"Управление продуктом"

  •  выступает в роли представителя заказчика;
  •  организует работу с требованиями заказчика;
  •  формирует ожидания заказчика;
  •  формирует общее видение и рамки проекта;
  •  определяет компромиссы между параметрами "возможности продукта / время / ресурсы";
  •  организует маркетинг;
  •  разрабатывает, поддерживает и исполняет план коммуникаций.

Для каждой ролевой группы определены заинтересованные стороны, как внутри, так и вне команды, с которыми группа должна взаимодействовать и чьи интересы представлять.

Зоны ответственности ролевых групп

Каждая ролевая группа в команде имеет зону ответственности, в которой роль из этой группы имеет решающий голос.

Ролевая группа

Зона ответственности

Управление программой

управление проектом;

верная трактовка ожидания заинтересованных сторон и их проведение через проект

Архитектура продукта

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

Разработка

проектирование и осуществление реализации

Тестирование

качество решения с точки зрения заказчика и будущих пользователей

Управление выпуском

гладкое внедрение решения в инфраструктуру заказчика

Удовлетворение потребителя

понимание потребностей пользователей и их надлежащую реализацию в решении.

Управление продуктом

представляет бизнес-сторону проекта и обеспечивает его согласованность со стратегическими целями заказчика (успешное получение бизнес-отдачи от внедрения разрабатываемого решения).

Рекомендации по возможному объединению ролей

Архи-тектура

Упр-е

прод.

Упр-е

прогр.

Разра-

ботка

Тестир.

Удовл.

потр-ля

Упр-е

вып.

Архи-тектура

– –

+

+

Упр-е

прод.

– –

– –

– –

+

+

Упр-е

прогр.

+

– –

– –

+

Разра-

ботка

+

– –

– –

– –

– –

– –

Тестир.

+

– –

+

+

Удовл.

потр-ля

+

– –

+

Упр-е

вып.

+

– –

+

– –  нельзя;

– не желательно;

+ – можно.

Доп. вопросы

  •  Объясните запреты на объединение ролей.
  •  Приведите пример распределения Ваших одногруппников по ролевым группам, аргументируя (хоть как-нибудь) это распределение.


Рис. 1.
Модель команды в MSF

правление программой

Удовлетворение потребителя

Менеджер программы

Архитектор

Разработчик

Тестер

Релиз-менеджер

Бизнес-аналитик

Управление выпуском

Тестирование

Разработка

Управление продуктом

Архитектура продукта


 

А также другие работы, которые могут Вас заинтересовать

65179. Математик, которого я знаю – Карл Гаусс 54 KB
  Сам того не подозревая Гаусс переоткрыл формулу для определения суммы членов арифметической прогрессии. Талант юного математика не остался без внимания герцога Брауншвейгского и в 1788 при его поддержке Гаусс поступил в закрытую школу Коллегиум...
65181. Математик, которого я знаю – Леонард Эйлер 38.96 KB
  Леонард Эйлер родился 15 апреля 1707 года в швейцарском городе Базеле. Его отец Павел Эйлер был пастором в Рихене близ Базеля и имел некоторые познания в математике. В 1725 году Эйлер узнает что для него есть место в качестве физиолога при медицинском...
65184. Основание Болонской Академии и творчество Аннибале Каррачи 16.44 KB
  Есть вечный идеал красоты заявляли братья Карраччи он воплощён в искусстве античности Возрождения и прежде всего в творчестве Рафаэля. Его уровень зависел по мнению братьев Карраччи не только от ловкости кисти но и от образования...
65186. СИСТЕМЫ СЧИСЛЕНИЯ 22.15 KB
  Различают непозиционные и позиционные системы счисления. Непозиционные системы сложны и громоздки при записи чисел и мало удобны при выполнении арифметических операций например: Римская непозиционная система счисления.
65187. Виды термической обработки 34 KB
  В любительской практике для определения температуры раскаленной детали по цвету можно использовать приведенную таблицу Закалка придает стальной детали большую твердость и износоустойчивость.