Место веб-разработчика в команде MSF

23.3. Модель проектной группы MSF for Agile Software Development

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

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

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

Ниже описываются основные принципы, ключевые идеи и испытанные методики MSF в применении к модели проектной группы.

MSF включает в себя ряд основных принципов. Вот те из них, которые имеют отношение к успешной работе команды [6]:

1. распределение ответственности при фиксации отчетности;
2. наделяйте членов команды полномочиями;
3. концентрируйтесь на бизнес-приоритетах;
4. единое видение проекта;
5. проявляйте гибкость – будьте готовы к переменам;
6. поощряйте свободное общение.

Успешное использование модели проектной группы MSF основывается на ряде ключевых концепций (key concepts) [6]:

1. команда соратников;
2. сфокусированность на нуждах заказчика;
3. нацеленность на конечный результат;
4. установка на отсутствие дефектов;
5. стремление к самосовершенствованию;
6. заинтересованные команды работают эффективно.

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

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

MSF for Agile Software Development выделяет 7 ролевых групп [6]:

• Управление программой (program management);
• Архитектура продукта (architecture);
• Разработка (development);
• Тестирование (test);
• Управление выпуском (release operations);
• Удовлетворение потребителя (user experience);
• Управление продуктом (product management);

и 6 ролей (рис. 23.6):

• менеджер проекта (project manager) – ролевая группа Управление программой;
• архитектор (archrect) – ролевая группа Архитектура;
• разработчик (developer) – ролевая группа Разработка;
• тестер (tester) – ролевая группа Тестирование;
• релиз-менеджер (release manager) – ролевая группа Управление выпуском;
• бизнес-аналитик (business analyst) – ролевые группы Управление продуктом и Удовлетворение потребителя.

Рис. 23.6. Команда разработчиков MSF for Agile Software Development

Они ответственны за различные области компетенции (functional areas) и связанные с ними цели и задачи. Иногда ролевые кластеры называются просто ролями. Но в любом случае суть концепции остается той же – построить основу производственных отношений и связанную с ней модель команды такими, чтобы они были приспосабливаемыми (масштабируемыми) для удовлетворения нужд любого проекта.

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

• Управление программой – отвечает за управление проектом, за то, что ожидания заинтересованных сторон будут верны, поняты и проведены через проект.
• Архитектура продукта – отвечает за систему в целом, вырабатывает архитектуру решения, включая сервисы, технологии и стандарты, которые будут использованы в ходе работы над решением.
• Разработка – отвечает за проектирование и осуществление реализации.
• Тестирование – отвечает за качество решения с точки зрения заказчика и будущих пользователей.
• Управление выпуском – отвечает за гладкое внедрение решения в инфраструктуру заказчика.
• Удовлетворение потребителя – отвечает за понимание потребностей пользователей и их надлежащую реализацию в решении.
• Управление продуктом – отвечает за понимание того как, и успешное получение бизнес-отдачи от внедрения разрабатываемого решения, которое в результате сможет получить заказчик.

Наличие шести ролевых кластеров не означает, что количество членов команды должно быть кратным шести – один человек может совмещать несколько ролей и наоборот, ролевой кластер может состоять из нескольких лиц в зависимости от размера проекта, его сложности и профессиональных навыков, требуемых для реализации всех областей компетенции кластера. Минимальный коллектив по MSF может состоять всего из трех человек. Модель не требует назначения отдельного сотрудника на каждый ролевой кластер. Смысл состоит в том, что в команде должны быть представлены все шесть качественных целей. Обычно, выделение как минимум одного человека на каждый ролевой кластер обеспечивает полноценное внимание к интересам каждой из ролей, но это экономически оправданно не для всех проектов. Зачастую члены проектной группы могут объединять роли.

Рассмотрим рекомендации по возможному совмещению ролей в виде табл. 23.2 [3].

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

1. Роль команды Разработчиков не может быть объединена ни с какой другой ролью.
2. Избегание сочетания ролей, имеющих предопределенные конфликты интересов.

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

MSF не предоставляет конкретных рецептов управления проектами и не содержит объяснений разнообразных методов работы, которые применяют опытные менеджеры. Принципы MSF формируют такой подход к управлению проектами, при котором:

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

Как следует из вышесказанного, одна из характерных особенностей MSF – отсутствие должности менеджера проекта.

Модель проектной группы MSF предлагает разбиение больших команд (более 10 человек) на малые многопрофильные группы направлений (feature teams). Эти малые коллективы работают параллельно, регулярно синхронизируя свои усилия. Кроме того, когда ролевому кластеру требуется много ресурсов, формируются т. н. функциональные группы (functional teams), которые затем объединяются в ролевые кластеры.

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

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

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

23.4. Роль Веб-разработчика в MSF for Agile Software Development

Веб-разработчик по методологии MSF входит в ролевой кластер "Разработка".

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

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

В качестве создателей решения разработчики осуществляют низкоуровневое проектирование решения и его элементов, оценивают трудозатраты на реализацию и затем осуществляют построение самого решения. Разработчики сами оценивают собственные затраты и отслеживают расписание, поскольку их повседневная деятельность сопряжена с различными нештатными ситуациями. Эта концепция называется оцениванием снизу вверх (bottom-up estimation) и является фундаментальной частью философии MSF. Цель данной концепции состоит в достижении большей обоснованности календарного плана и увеличении чувства ответственности тех, кто определяет сроки этого плана, и от чьей производительности зависит его выполнение.

Участник ролевого кластера "Разработка" имеет следующие обязанности:

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

23.4.1. Технологическое консультирование

В данные обязанности входит:

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

Область компетенции "Технологическое консультирование" (technology consulting) служит ресурсом разрешения технических проблем. Выполняя роль технологических консультантов, разработчики должны предоставлять необходимую информацию для проектирования, оценки и верификации технологий; проводить предварительные исследования с целью минимизации рисков.

На фазе выработки концепции данная область компетенции анализирует требования заказчиков и потребителей с точки зрения их реализуемости. "Технологическое консультирование" вносит свой вклад в подготовку документа общего описания проекта, оценивая технические проблемы, влияющие на возможность реализации проекта при заданных параметрах. "Технологическое консультирование" взвешивает все "за" и "против" каждого подхода к реализации и определяет адекватность изначально выбранных технологических средств. В рамках этой деятельности разработчики могут вести исследовательскую работу, проводить консультации с другими сторонами как внутри организации, так и вне ее, вести обсуждение с поставщиками технологий. В целях дополнительной верификации "Технологическое консультирование" может разрабатывать прототипы (версии решения с неполной функциональностью), чтобы подтвердить с их помощью жизнесп особность анализируемых концепций. Это особенно важно в проектах, требующих исп ользования новых технологий, или же в тех предметных областях, где у проектной группы отсутствует достаточный опыт.

23.4.2. Проектирование и осуществление реализации

В данные обязанности входит:

• соотнесение архитектуры решения с архитектурой предприятия;
• создание и реализация логического и физического дизайна решения.

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

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

MSF предлагает трехуровневый процесс проектирования: концептуальный дизайн (conceptual design), логический дизайн (logical design) и физический дизайн (physical design). "Управление программой" и "Управление продуктом" совместно осуществляют концептуальный дизайн. Он включает в себя сценарии использования (user scenarios), высокоуровневый анализ требований к удобству эксплуатации (usability), концептуальное моделирование данных и начальный выбор используемых технологий. Разработчики же занимаются логическими и физическими аспектами дизайна решения. Данная деятельность требует адекватных технологических знаний и умения определить влияние того или иного технологического выбора на создаваемое решение.