Правда ли что в модели команды разработчиков msf
Место веб-разработчика в команде MSF
23.3. Модель проектной группы MSF for Agile Software Development
Модель проектной группы MSF разрабатывалась в течение нескольких лет и возникла в результате осмысления недостатков пирамидальной, иерархической структуры традиционных проектных групп.
В соответствии с моделью MSF проектные группы строятся как небольшие многопрофильные команды, члены которых распределяют между собой ответственность и дополняют области компетенций друг друга. Это дает возможность четко сфокусировать внимание на нуждах проекта. Проектную группу объединяет единое видение проекта, стремление к воплощению его в жизнь, высокие требования к качеству работы и желание самосовершенствоваться.
MSF включает в себя ряд основных принципов. Вот те из них, которые имеют отношение к успешной работе команды [6]:
Успешное использование модели проектной группы MSF основывается на ряде ключевых концепций (key concepts) [6]:
MSF for Agile Software Development выделяет 7 ролевых групп [6]:
Каждая ролевая группа в команде имеет зону ответственности (advocacy), в которой роль из этой группы имеет решающий голос.
Рассмотрим рекомендации по возможному совмещению ролей в виде табл. 23.2 [3].
| Архитектура продукта | Управление продуктом | Управление программой | Разработка | Тестирование | Удовлетворение потребителя | Управление выпуском |
|---|---|---|---|---|---|---|
| Архитектура продукта | Нет | Да | Да | Не желательно | Не желательно | Не желательно |
| Управление продуктом | Нет | Нет | Нет | Да | Да | Не желательно |
| Управление программой | Да | Нет | Нет | Не желательно | Не желательно | Да |
| Разработка | Да | Нет | Нет | Нет | Нет | Нет |
| Тестирование | Не желательно | Да | Не желательно | Нет | Да | Да |
| Удовлетворение потребителя | Не желательно | Да | Не желательно | Нет | Да | Не желательно |
| Управление выпуском | Не желательно | Не желательно | Да | Нет | Да | Не желательно |
В малых проектных группах объединение ролей является необходимым. При этом должны соблюдаться два принципа:
Как и в любой другой командной деятельности, подходящая комбинация ролей зависит от самих членов команды, их опыта и профессиональных навыков. На практике совмещение ролей встречается нередко. И если проектная группа производит его обдуманно и управляет связанными с таким объединением рисками, возникающие проблемы будут минимальными.
MSF не предоставляет конкретных рецептов управления проектами и не содержит объяснений разнообразных методов работы, которые применяют опытные менеджеры. Принципы MSF формируют такой подход к управлению проектами, при котором:
Как следует из вышесказанного, одна из характерных особенностей MSF – отсутствие должности менеджера проекта.
Модель проектной группы MSF не обеспечивает успех сама по себе. Есть много других факторов, определяющих успех или неудачу проекта, но структура проектной группы, безусловно, вносит существенный вклад.
Подходящая структура команды является фундаментом успеха, и реализация модели MSF с использованием лежащих в ее основе принципов поможет сделать проектные группы более эффективными и, как следствие, более успешными.
23.4. Роль Веб-разработчика в MSF for Agile Software Development
Веб-разработчик по методологии MSF входит в ролевой кластер «Разработка».
Первостепенной задачей ролевого кластера «Разработка» является построение решения в соответствии со спецификацией [6]. Ее выполнение означает создание решения, соответствующего ожиданиям заказчика и условиям, сформулированным в функциональной спецификации. Также данный ролевой кластер строго следует выработанной архитектуре и дизайну решения, которые совместно с функциональной спецификацией составляют сводное описание конечного продукта.
В дополнение к функции непосредственной разработки решения на данный ролевой кластер возлагаются обязанности по технологическому консультированию проектной группы. В этом качестве разработчики занимаются подготовкой исходных данных для проектирования и выбора технологического инструментария решения. Также ролевой кластер «Разработка» создает функциональные прототипы для проверки правильности принятых решений и уменьшения рисков.
Участник ролевого кластера «Разработка» имеет следующие обязанности:
23.4.1. Технологическое консультирование
В данные обязанности входит:
Область компетенции «Технологическое консультирование» (technology consulting) служит ресурсом разрешения технических проблем. Выполняя роль технологических консультантов, разработчики должны предоставлять необходимую информацию для проектирования, оценки и верификации технологий; проводить предварительные исследования с целью минимизации рисков.
На фазе выработки концепции данная область компетенции анализирует требования заказчиков и потребителей с точки зрения их реализуемости. «Технологическое консультирование» вносит свой вклад в подготовку документа общего описания проекта, оценивая технические проблемы, влияющие на возможность реализации проекта при заданных параметрах. «Технологическое консультирование» взвешивает все «за» и «против» каждого подхода к реализации и определяет адекватность изначально выбранных технологических средств. В рамках этой деятельности разработчики могут вести исследовательскую работу, проводить консультации с другими сторонами как внутри организации, так и вне ее, вести обсуждение с поставщиками технологий. В целях дополнительной верификации «Технологическое консультирование» может разрабатывать прототипы (версии решения с неполной функциональностью), чтобы подтвердить с их помощью жизнесп особность анализируемых концепций. Это особенно важно в проектах, требующих исп ользования новых технологий, или же в тех предметных областях, где у проектной группы отсутствует достаточный опыт.
23.4.2. Проектирование и осуществление реализации
В данные обязанности входит:
Область компетенции «Проектирование и осуществление реализации» (implementation architecture and design) связана с набором задач, относящихся к определению архитектуры решения и его проектированию.
Ролевой кластер «Управление программой» ответственен за общую архитектуру решения и ее позиционирование в рамках архитектуры предприятия. Тем не менее, ролевой кластер «Разработка» ответственен за соответствие архитектуры реализации решения архитектуре предприятия. Это касается специфики приложений, данных и технологического инструментария решения.
MSF предлагает трехуровневый процесс проектирования: концептуальный дизайн ( conceptual design ), логический дизайн ( logical design ) и физический дизайн ( physical design ). «Управление программой» и «Управление продуктом» совместно осуществляют концептуальный дизайн. Он включает в себя сценарии использования (user scenarios ), высокоуровневый анализ требований к удобству эксплуатации (usability), концептуальное моделирование данных и начальный выбор используемых технологий. Разработчики же занимаются логическими и физическими аспектами дизайна решения. Данная деятельность требует адекватных технологических знаний и умения определить влияние того или иного технологического выбора на создаваемое решение.
Правда ли что в модели команды разработчиков msf
Основными новшествами MSF является следующее.
Ниже мы рассмотрим эти положения более детально.
Основные принципы
Модель команды
Основные принципы. Главная особенность модели команды в MSF является то, что она «плоская», то есть не имеет официального лидера. Все отвечают за проект в равной степени, уровень заинтересованности каждого в результате очень высок, а коммуникации внутри группы четкие, ясные, дружественные и ответственные. Конечно, далеко не каждая команда способна так работать – собственно, начальники для того и нужны, чтобы нести основной груз ответственности за проект и, во многом, освободить от него других. Демократия в команде возможна при высоком уровне осознанности и заинтересованности каждого, а также в ситуации равности в профессиональном уровне (пусть и в разных областях – см. различные ролевые кластеры в команде, о которых речь пойдет ниже). С другой стороны, в реальном проекте, в рамках данной модели команды, можно варьировать степень ответственности, в том числе вплоть до выделения, при необходимости, лидера.
Одной из особенностей отношений внутри команды является высокая культура дисциплины обязательств:
Ролевые кластеры. MSF основан на постулате о семи качественных целях, достижение которых определяет успешность проекта. Эти цели обуславливают модель проектной группы и образуют ролевые кластеры (или просто роли ) в проекте. В каждом ролевом кластере может присутствовать по одному или несколько специалистов, некоторые роли можно соединять одному участнику проекта. Каждый ролевой кластер представляет уникальную точку зрения на проект, и в то же время никто из членов проектной группы в одиночку не в состоянии успешно представлять все возможные взгляды, отражающие качественно различные цели. Для разрешения этой дилеммы команда соратников ( команда равных, team of peers ), работающая над проектом, должна иметь четкую форму отчетности перед заинтересованными сторонами ( stakeholders ) при распределенной ответственности за достижение общего успеха. В MSF следующие ролевые кластеры (часто их называют ролями) – см. рис. 9.1.
| Управление продуктом | Управление программой | Разработка | Тестирование | Удовлетворение потребителя | Управление выпуском | Архитектура |
| Управление продуктом | – | – | + | + | +– | – |
| Управление программой | – | – | +– | +– | + | + |
| Разработка | – | – | – | – | – | + |
| Тестирование | + | +– | – | + | + | +– |
| Удовлетворение потребителя | + | +– | – | + | +– | +– |
| Управление выпуском | +– | + | – | + | +– | + |
| Архитектура | – | + | + | +– | +– | + |
В частности, нельзя совмещать разработку и тестирование, поскольку, как обсуждалось выше, необходимо, чтобы у тестеровщиков был сформирован свой, независимый взгляд на систему, базирующийся на изучении требований.
Часто функциональные группы имеют внутреннюю иерархическую структуру. Например, менеджеры программы могут быть подотчетны ведущим менеджерам программы, которые в свою очередь отчитываются перед главным менеджером программы. Подобные структуры могут также появляться внутри областей компетенций. Но важно помнить, что эти иерархии не должны затенять модель команды MSF на уровне проекта в целом.
Модели процессов и команды методологии MSF
Модель процессов Microsoft Solutions Framework
Модель процессов MSF представляет собой общую методологию разработки и внедрения IT-решений. Благодаря своей гибкости данная модель может использоваться для разработки широкого круга IT-решений, она охватывает весь жизненный цикл создания решения, с самых ранних этапов до внедрения. Модель процессов MSF сочетает в себе качества двух классических моделей: каскадной и спиральной.
Процесс MSF ориентирован на «вехи» ( milestones ). Вехи – ключевые точки процесса разработки, которые характеризуют достижение какого–либо существенного результата.
Модель процессов MSF учитывает постоянные изменения требований к конечному продукту, процесс разработки состоит из коротких циклов и представляет собой поступательное движение от простейших ранних версий продукта к его окончательному виду.
Каскадная и спиральная модели процессов
Модель процессов описывает последовательность действий при реализации проекта, по сути, модель процессов определяет жизненный цикл проекта.
Каскадная модель (waterfall)
На рисунке: Ромбы соответствуют вехам, стрелки – фазам.
Данная модель предпочтительна для быстрой разработки небольших решений. В ней учитываются постоянные изменения и пересмотр проектных требований к конечному продукту. Имеет место постоянное и тесное взаимодействие разработчиков с заказчиком, который оценивает ход и результаты работы на протяжении всего процесса работы над проектом. К недостаткам спиральной модели можно отнести низкую степень формализации, порой тяжело понять на какой конкретной стадии (планирование, разработка т пр.) находится проект.
Модель процессов MSF
Модель процессов MSF объединяет в себе упорядоченность каскадной модели с гибкостью спиральной.
Поскольку выработка единого видения проекта и следование ему настолько важны, MSF выделяет для этих целей отдельную фазу (этап) разработки – «Выработка концепции».
Поскольку программный продукт способен привнести отдачу только после своего внедрения в среду организации, MSF включает в жизненный цикл создания решения фазу внедрения.
Модель процессов MSF предлагает свободный и открытый обмен информацией между всеми участниками проекта, как внутри команды разработчиков, так и с ключевыми заинтересованными лицами. Это должно служить средством снижения недопонимания, неопределенности и необоснованных затрат.
Поэтому, MSF предлагает проводить анализ хода работ в определенных временных точках. Обязательное документирование результатов иллюстрирует прогресс работы над проектом, как для разработчиков, так и для заказчика.
Фазы модели процессов MSF
Фаза выработки концепции
На фазе выработки концепции (envisioning phase ) закладывается одна из фундаментальных основ успеха проекта – создание и сплочение проектной группы на основе выработки единого видения. Проектная группа должна четко представить себе, что она хочет сделать для заказчика и сформулировать свою цель таким образом, чтобы максимально мотивировать как заказчика, так и саму проектную команду. Выработка высокоуровневого взгляда на цели и условия проекта может рассматриваться как ранняя форма планирования; она подготавливает почву для процессов создания детальных планов, которые будут осуществлены непосредственно во время фазы планирования.
Основными задачами фазы выработки концепции являются создание ядра проектной группы (см. ниже) и подготовка документа общего описания и рамок проекта ( vision /scope document). Формирование видения проекта и специфицирование его рамок (Видение ( vision ) – это ничем не ограничиваемое представление о том, каким должно быть решение; Рамки (scope) же дают четкие границы того, что из предложенного этим видением будет реализовано в условиях существующих проектных ограничений).
Управление рисками представляет собой итеративный процесс, осуществляемый на протяжении всего жизненного цикла проекта. Во время фазы выработки концепции проектная группа готовит документ оценки рисков и представляет главные риски проекта вместе с общим описанием и рамками проекта.
Также во время фазы выработки концепции производится выявление и анализ бизнес требований. Более детально эти требования рассматриваются во время фазы планирования.
Ведущим ролевым кластером на фазе выработки концепции является «Управление продуктом».
Место веб-разработчика в команде MSF
23.3. Модель проектной группы MSF for Agile Software Development
Модель проектной группы MSF разрабатывалась в течение нескольких лет и возникла в результате осмысления недостатков пирамидальной, иерархической структуры традиционных проектных групп.
В соответствии с моделью MSF проектные группы строятся как небольшие многопрофильные команды, члены которых распределяют между собой ответственность и дополняют области компетенций друг друга. Это дает возможность четко сфокусировать внимание на нуждах проекта. Проектную группу объединяет единое видение проекта, стремление к воплощению его в жизнь, высокие требования к качеству работы и желание самосовершенствоваться.
MSF включает в себя ряд основных принципов. Вот те из них, которые имеют отношение к успешной работе команды [6]:
Успешное использование модели проектной группы MSF основывается на ряде ключевых концепций (key concepts) [6]:
MSF for Agile Software Development выделяет 7 ролевых групп [6]:
Каждая ролевая группа в команде имеет зону ответственности (advocacy), в которой роль из этой группы имеет решающий голос.
Рассмотрим рекомендации по возможному совмещению ролей в виде табл. 23.2 [3].
| Архитектура продукта | Управление продуктом | Управление программой | Разработка | Тестирование | Удовлетворение потребителя | Управление выпуском |
|---|---|---|---|---|---|---|
| Архитектура продукта | Нет | Да | Да | Не желательно | Не желательно | Не желательно |
| Управление продуктом | Нет | Нет | Нет | Да | Да | Не желательно |
| Управление программой | Да | Нет | Нет | Не желательно | Не желательно | Да |
| Разработка | Да | Нет | Нет | Нет | Нет | Нет |
| Тестирование | Не желательно | Да | Не желательно | Нет | Да | Да |
| Удовлетворение потребителя | Не желательно | Да | Не желательно | Нет | Да | Не желательно |
| Управление выпуском | Не желательно | Не желательно | Да | Нет | Да | Не желательно |
В малых проектных группах объединение ролей является необходимым. При этом должны соблюдаться два принципа:
Как и в любой другой командной деятельности, подходящая комбинация ролей зависит от самих членов команды, их опыта и профессиональных навыков. На практике совмещение ролей встречается нередко. И если проектная группа производит его обдуманно и управляет связанными с таким объединением рисками, возникающие проблемы будут минимальными.
MSF не предоставляет конкретных рецептов управления проектами и не содержит объяснений разнообразных методов работы, которые применяют опытные менеджеры. Принципы MSF формируют такой подход к управлению проектами, при котором:
Как следует из вышесказанного, одна из характерных особенностей MSF – отсутствие должности менеджера проекта.
Модель проектной группы MSF не обеспечивает успех сама по себе. Есть много других факторов, определяющих успех или неудачу проекта, но структура проектной группы, безусловно, вносит существенный вклад.
Подходящая структура команды является фундаментом успеха, и реализация модели MSF с использованием лежащих в ее основе принципов поможет сделать проектные группы более эффективными и, как следствие, более успешными.
23.4. Роль Веб-разработчика в MSF for Agile Software Development
Веб-разработчик по методологии MSF входит в ролевой кластер «Разработка».
Первостепенной задачей ролевого кластера «Разработка» является построение решения в соответствии со спецификацией [6]. Ее выполнение означает создание решения, соответствующего ожиданиям заказчика и условиям, сформулированным в функциональной спецификации. Также данный ролевой кластер строго следует выработанной архитектуре и дизайну решения, которые совместно с функциональной спецификацией составляют сводное описание конечного продукта.
В дополнение к функции непосредственной разработки решения на данный ролевой кластер возлагаются обязанности по технологическому консультированию проектной группы. В этом качестве разработчики занимаются подготовкой исходных данных для проектирования и выбора технологического инструментария решения. Также ролевой кластер «Разработка» создает функциональные прототипы для проверки правильности принятых решений и уменьшения рисков.
Участник ролевого кластера «Разработка» имеет следующие обязанности:
23.4.1. Технологическое консультирование
В данные обязанности входит:
Область компетенции «Технологическое консультирование» (technology consulting) служит ресурсом разрешения технических проблем. Выполняя роль технологических консультантов, разработчики должны предоставлять необходимую информацию для проектирования, оценки и верификации технологий; проводить предварительные исследования с целью минимизации рисков.
На фазе выработки концепции данная область компетенции анализирует требования заказчиков и потребителей с точки зрения их реализуемости. «Технологическое консультирование» вносит свой вклад в подготовку документа общего описания проекта, оценивая технические проблемы, влияющие на возможность реализации проекта при заданных параметрах. «Технологическое консультирование» взвешивает все «за» и «против» каждого подхода к реализации и определяет адекватность изначально выбранных технологических средств. В рамках этой деятельности разработчики могут вести исследовательскую работу, проводить консультации с другими сторонами как внутри организации, так и вне ее, вести обсуждение с поставщиками технологий. В целях дополнительной верификации «Технологическое консультирование» может разрабатывать прототипы (версии решения с неполной функциональностью), чтобы подтвердить с их помощью жизнесп особность анализируемых концепций. Это особенно важно в проектах, требующих исп ользования новых технологий, или же в тех предметных областях, где у проектной группы отсутствует достаточный опыт.
23.4.2. Проектирование и осуществление реализации
В данные обязанности входит:
Область компетенции «Проектирование и осуществление реализации» (implementation architecture and design) связана с набором задач, относящихся к определению архитектуры решения и его проектированию.
Ролевой кластер «Управление программой» ответственен за общую архитектуру решения и ее позиционирование в рамках архитектуры предприятия. Тем не менее, ролевой кластер «Разработка» ответственен за соответствие архитектуры реализации решения архитектуре предприятия. Это касается специфики приложений, данных и технологического инструментария решения.
MSF предлагает трехуровневый процесс проектирования: концептуальный дизайн ( conceptual design ), логический дизайн ( logical design ) и физический дизайн ( physical design ). «Управление программой» и «Управление продуктом» совместно осуществляют концептуальный дизайн. Он включает в себя сценарии использования (user scenarios ), высокоуровневый анализ требований к удобству эксплуатации (usability), концептуальное моделирование данных и начальный выбор используемых технологий. Разработчики же занимаются логическими и физическими аспектами дизайна решения. Данная деятельность требует адекватных технологических знаний и умения определить влияние того или иного технологического выбора на создаваемое решение.