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

Презентацию к данной лекции Вы можете скачать здесь.

23.1. Введение

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

MSF – это методология ведения проектов и разработки решений, базирующаяся на принципах работы над продуктами как самой фирмы Microsoft, так и других компаний, работающих в области IT-индустрии.

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

Microsoft Solutions Framework представляет собой хорошо сбалансированный и гибкий набор методик организации процесса разработки, который может быть адаптирован под потребности практически любого коллектива разработчиков и проекта, вне зависимости от его размера и сложности. MSF поддерживает самые различные подходы к организации процесса разработки, что позволяет команде разработчиков выбирать самый подходящий для них путь. Философия MSF утверждает то, что не существует единой методологии разработки, которая оптимально будет соответствовать требованиям любых проектов. Но, тем не менее, любому проекту необходимо управление. MSF направлена на помощь в обеспечении этого управления. При этом MSF не налагает предписаний, а позволяет команде разработчиков настраивать предоставленные средства. Средства MSF могут быть применены по отдельности или все вместе. Главное – они позволят добиться успеха для многих типов проектов.

Главными принципами MSF можно назвать производительность, интегрируемость и расширяемость.

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

MSF состоит из двух моделей и трех дисциплин. Они подробно описаны в 5 whitepapers [2]:

23.2. Модель процессов MSF

Модель процессов MSF (MSF process model) представляет общую методологию разработки и внедрения IT решений [3]. Особенность этой модели состоит в том, что благодаря своей гибкости и отсутствию жестко навязываемых процедур она может быть применена при разработке весьма широкого круга IT проектов. Эта модель сочетает в себе свойства двух стандартных производственных моделей: каскадной (waterfall) и спиральной (spiral) (рис. 23.1).

Модель процессов в MSF 3.0 была дополнена еще одним инновационным аспектом: она покрывает весь жизненный цикл создания решения, начиная с его отправной точки и заканчивая непосредственно внедрением. Такой подход помогает проектным группам сфокусировать свое внимание на бизнес-отдаче (business value) решения, поскольку эта отдача становится реальной лишь после завершения внедрения и начала использования продукта.

Основные принципы модели процессов:

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

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

Модель процессов MSF тесно связана с базовыми принципами MSF, рассмотренными выше. Вообще говоря, тремя особенностями модели процессов MSF являются:

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

Источник: MSF for Agile Software Development Process Guidance [5]

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

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

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

Модель процессов включает такие основные фазы процесса разработки:

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

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

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

Решение не представляет бизнес-ценности, пока оно не внедрено. Именно по этой причине модель процессов MSF содержит весь жизненный цикл создания решения, включая его внедрение – вплоть до момента, когда решение начинает давать отдачу.

В силу свойственной IT-проектам неопределенности и рискованности, одним из ключевых факторов их успеха являются эффективные компромиссные решения ( trade-offs ).

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

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

Нахождение верного баланса между ресурсами, временем разработки и возможностями – ключевой момент в построении решения, должным образом отвечающего нуждам заказчика.

Треугольник приоритетов является основой для матрицы компромиссов (project tradeoff matrix) – заранее утвержденных представлений о том, какие аспекты процесса разработки будут четко заданы, а какие будут согласовываться или приниматься как есть.

Возможный вариант такой матрицы представлен в табл. 23.1 [4].

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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), концептуальное моделирование данных и начальный выбор используемых технологий. Разработчики же занимаются логическими и физическими аспектами дизайна решения. Данная деятельность требует адекватных технологических знаний и умения определить влияние того или иного технологического выбора на создаваемое решение.