Версии. Модель проектной группы

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

Ролевая группа выполняет следующие задачи:

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

Разработка

Ролевая группа выполняет следующие задачи:

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

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

Ролевая группа выполняет следующие задачи:

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

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

Ролевая группа выполняет следующие задачи:

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

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

Ролевая группа выполняет следующие задачи:

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

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

Ролевая группа выполняет следующие задачи:

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

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

Модель проектной группы в MSF может масштабироваться в зависимости от числа участников. Масштабирование модели проектной группы MSF for Agile Software Development на случай больших команд выходит за рамки нашего курса. Мы рассмотрим ситуацию, когда один человек может выполнять в проектной группе несколько ролей (небольшая команда, относительно несложный проект).

В этом случае MSF предлагает рекомендации по возможному объединению ролей. Рассмотрим их в виде таблицы.

4.4. Учебный пример. Формирование команды

Применим полученные знания к сформулированному на предыдущей лекции учебному примеру "Система бронирования билетов для авиакомпании".

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

Несмотря на то, что модель проектной группы MSF выделяет ровно 6 ролей, идею о том, чтобы каждому участнику нашей команды выдать по одной роли и на этом успокоиться, следует оставить, как в корне неверную. При таком подходе, мы должны будем взвалить тяжесть разработки системы на одного человека, что, конечно же, не приведет к успеху. Отсюда очевидно, что разработчиков должно быть больше одного, а остальные роли придется совмещать. Как именно, сейчас обсудим.

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

Во-вторых, отбросим в сторону другую крайность - разработчиками не могут быть все. Отдельный участник команды должен заниматься тестированием. Ему же можно выдать "в нагрузку" роль бизнес-аналитика.

Незадействованными остались ролевые группы "Управление программой" и "Управление выпуском". Соответственно роли менеджер проекта и релиз-менеджер достаются еще одному участнику.

В итоге получаем следующее (возможное) распределение:

• Участник 1 - менеджер проекта и релиз-менеджер
• Участник 2 - архитектор и разработчик
• Участник 3 - бизнес-аналитик и тестер
• Участник 4 - разработчик
• Участник 5 - разработчик
• Участник 6 - разработчик

5. Что дальше?

Тема следующей лекции - Управление рисками и модель процессов в MSF.