Ф УНКЦИОНАЛЬНЫЕ РОЛИ В КОЛЛЕКТИВЕ РАЗРАБОТЧИКОВ

МОДЕЛИ ПРОЕКТНОЙ ГРУППЫ КОНЦЕПЦИИ M ICROSOFT S OLUTION F RAMEWORK (MSF) Предлагается образовывать небольшие мобильные коллективы как атомарные производственные единицы с общей ответственностью за выполняемые задания так называемые проектные группы. Вместо понятия роли для группы в целом определяются ролевые кластеры, которые заполняются точно так же, как происходит распределение ролей. В то время как за успех проекта ответственна вся команда, каждый из ее ролевых кластеров, определяемых моделью, ассоциирован с одной из проектных целей и работает над ее достижением.

Р ОЛЕВЫЕ КЛАСТЕРЫ МОДЕЛИ ПРОЕКТНОЙ ГРУПП MSF

У ПРАВЛЕНИЕ ПРОДУКТОМ ( PRODUCT MANAGEMENT ) Ключевая цель кластера обеспечивать удовлетворение интересов заказчика. Для ее достижения кластер должен содержать следующие области компетенции: планирование продукта, планирование доходов, представление интересов заказчика, маркетинг.

У ПРАВЛЕНИЕ ПРОГРАММОЙ ( PROGRAM MANAGEMENT ) Задача обеспечить реализацию решения в рамках ограничений проекта, что может рассматриваться как удовлетворение требований к бюджету проекта и к его результату. Области компетенции кластера: управление проектом; выработка архитектуры решения; контроль производственного процесса; административные службы.

Р АЗРАБОТКА ( DEVELOPMENT Первостепенной задачей кластера является построение решения в соответствии со спецификацией. Области компетенции кластера: технологическое консультирование; проектирование и осуществление реализации; разработка приложений; разработка инфраструктуры.

Т ЕСТИРОВАНИЕ ( TEST ) Задача кластера одобрение выпуска продукта только после того, как все дефекты выявлены и устранены. Области компетенции кластера: разработка тестов; отчетность о тестах; планирование тестов.

У ДОВЛЕТВОРЕНИЕ ПОТРЕБИТЕЛЯ ( USER EXPERIENCE ) Цель кластера повышение эффективности использования продукта. Области компетенции кластера: общедоступность (возможности работы для людей с недостатками зрения, слуха и др.); интернационализация (эксплуатация в иноязычных средах); обеспечение технической поддержки; обучение пользователей; удобство эксплуатации (эргономика); графический дизайн.

У ПРАВЛЕНИЕ ВЫПУСКОМ ( RELEASE MANAGEMENT ) Задача кластера беспрепятственное внедрение и сопровождение продукта. Области компетенции кластера: инфраструктура (infrastructure); сопровождение (support); бизнес-процессы (operations); управление выпуском готового продукта (commercial release management).

ПЕРЕЧЕНЬ РОЛЕЙ В КОЛЛЕКТИВЕ РАЗРАБОТЧИКОВ Заказчик (Customer) реально существующий (в организации, которой подчинена команда, или вне ее) инициатор разработки или кто-либо иной, уполномоченный принимать результаты (как текущие, так и окончательные) разработки. Планировщик ресурсов (Planner) выдвигает и координирует требования к проектам в организации, осуществляющей данную разработку, а также развивает и направляет план выполнения проекта с точки зрения организации. Менеджер проекта (Project Manager) отвечает за развитие проекта в целом, гарантирует, что распределение заданий и ресурсов позволяет выполнить проект, что работы и предъявление результатов идут по графику, что результаты соответствуют требованиям. В рамках этих функций менеджер проекта взаимодействует с заказчиком и планировщиком ресурсов.

Р ОЛИ В КОЛЛЕКТИВЕ РАЗРАБОТЧИКОВ Руководитель команды (Team Leader) производит техническое руководство командой в процессе выполнения проекта. Для больших проектов возможно привлечение нескольких руководителей подкоманд, отвечающих за решение частных задач. Архитектор (Architect) отвечает за проектирование архитектуры системы, согласовывает развитие работ, связанных с проектом. Проектировщик подсистемы (Designer) отвечает за проектирование подсистемы или категории классов, определяет реализацию и интерфейсы с другими подсистемами

РОЛИ В КОЛЛЕКТИВЕ РАЗРАБОТЧИКОВ Эксперт предметной области (Domain Expert) отвечает за изучение сферы приложения, поддерживает направленность проекта на решение задач данной области. Разработчик (Developer) реализует проектируемые компоненты, владеет и создает специфичные классы и методы, осуществляет кодирование и автономное тестирование, строит продукт. Это широкое понятие, которое может подразделяться на специальные роли (например, разработчик классов). В зависимости от сложности проекта команда может включать различное число разработчиков. Разработчик информационной поддержки (Information Developer) создает документацию, сопровождающую продукт, когда выпускается версия. Включаемые в нее инсталляционные материалы, равно как ссылочные и учебные, а также материалы помощи предоставляются на бумажных и машинных носителях. Для сложных проектов возможно распределение этих задач между несколькими разработчиками информационной поддержки.

РОЛИ В КОЛЛЕКТИВЕ РАЗРАБОТЧИКОВ Специалист по пользовательскому интерфейсу (Human Factors Engineer) отвечает за удобство применения системы. Работает с заказчиком, чтобы удостовериться, что пользовательский интерфейс удовлетворяет требованиям. Тестировщик (Tester) проверяет функциональность, качество и эффективность продукта. Строит и исполняет тесты для каждой фазы развития проекта. Библиотекарь (Librarian) отвечает за создание и ведение общей библиотеки проекта, которая содержит все проектные рабочие продукты, а также за соответствие рабочих продуктов стандартам.

П РИНЦИПЫ СОВМЕЩЕНИЯ РОЛЕЙ : Не следует допускать совмещения ролей, которые имеют конфликтные или противоречивые интересы. Если такое совмещение все-таки используется, то необходимо предусматривать механизмы, которые будут демпфировать противоречия. Представление ролей с конфликтными интересами различным людям обеспечивает равновесие противоречащих точек зрения. Прибегать к совмещению ролей для участников проекта, основной ролью которых является разработка, означает заведомое увеличение сроков выполнения соответствующих работ. По этой причине для них допустимы лишь такие совмещения, которые действительно необходимы в данный момент развития проекта (например, в некоторых авральных ситуациях) и которые не требуют постоянной деятельности в течение длительного срока. Если работнику поручается несколько ролей, то он всегда должен знать, какую из них он выполняет в данный момент.

Р ОЛИ ДЕЙСТВУЮЩИХ ЛИЦ ПРОЕКТА И СОВМЕЩЕНИЕ РОЛЕЙ Роли Характеристика совмещения ролей Менеджер и архитектор Желательно Менеджер и руководитель команды Противоречиво Руководитель команды и архитектор Возможно Руководитель команды и проектировщик подсистемы Нежелательно Менеджер и разработчик Не допускается Для различных разработчиков Эффективно с ограничениями(обычное дело) Создание документации (все сотрудники)Успешно распределяется Специалист по интерфейсу и менеджер Разумно Эксперт предметной области и менеджер Зачастую разумно Специалист по интерфейсу и эксперт предметной области Редко бывает эффективно Эксперт предметной области и разработчик Бывает полезно Специалист по интерфейсу и разработчик Часто полезно Библиотекарь и один из разработчиков Допустимо Тестировщики и другие члены команды Перекрестно Эксперт предметной области, тестировщик Оправданно