Спонсор: Microsoft
Опубликован: 27.06.2009 | Доступ: свободный | Студентов: 1622 / 28 | Оценка: 4.12 / 3.62 | Длительность: 13:51:00
Специальности: Программист
Лекция 4:

Модели процессов и команды методологии MSF

< Лекция 3 || Лекция 4: 1234 || Лекция 5 >

Фаза планирования

На фазе планирования (planning) производится основная работа по составлению планов проекта. Она включает в себя подготовку проектной группой функциональной спецификации, разработку дизайнов, подготовку рабочих планов, оценку проектных затрат и сроков разработки различных составляющих проекта.

В начале фазы планирования проектная группа анализирует и документирует проектные требования. Они разделяются на четыре общих категории: бизнес-требования (business requirements), потребительские требования (user requirements), эксплуатационные требования (operational requirements) и системные требования, относящиеся к решению в целом (system requirements). В ходе проектирования решения и создания его функциональной спецификации необходимо следить за соответствием (traceability) между имеющимися требованиями и проектируемой функциональностью. Это соответствие не обязательно будет взаимооднозначным. Оно служит одним из способов контроля корректности дизайна и его пригодности для достижения поставленных перед решением целей.

Процесс проектирования – это систематический способ продвижения от абстрактных концепций к конкретным техническим деталям. Он начинается с методичного анализа профилей пользователей (user profiles, иногда называемых "персонажами" - "personas"), которые описывают различные типы пользователей (включая персонал сопровождения) и их рабочие функции. Значительная часть этой работы часто проводится во время фазы выработки концепции. Затем формируется набор сценариев использования (usage scenarios), в каждом из которых моделируется выполнение какой-либо операции определенным типом пользователя (например, регистрация посетителей в отеле или администрирование паролей пользователей в компьютерной системе). В конце концов, каждый сценарий использования разбивается на последовательность специфических действий, называемых примерами пользования (use cases), которые необходимо выполнить пользователю для осуществления операции. Этот процесс анализа действий пользователей называется стори-боардинг ("story boarding").

Существует три уровня процесса проектирования: концептуальный дизайн (conceptual design), логический дизайн (logical design) и физический дизайн (physical design). Работа над логическим дизайном начинается через некоторое время после начала концептуального дизайна, и работа над физическим дизайном стартует через некоторое время после начала работы над логическим.

Результаты процесса проектирования документируются в функциональных спецификациях (functional specifications). Функциональные спецификации детально описывают вид и поведение каждой составляющей решения. Также для всех составляющих описывается их архитектура и дизайн.

Функциональная спецификация служит многим целям:

  • Инструкции команде разработчиков о том, что они должны будут создать.
  • Основа для оценивания объема работы.
  • Четкое соглашение с заказчиком о том, что должно быть сделано.
  • Синхронизация работы всей проектной команды.

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

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

Члены проектной группы, представляющие каждый из ролевых кластеров, оценивают необходимое для выполнения запланированных задач время и составляют календарный график сдачи результатов. Затем происходит синхронизация календарных графиков с последующей их интеграцией в сводный календарный график проекта (master project schedule).

Кульминацией фазы планирования является веха "Планы проекта утверждены" (project plans approved). Она знаменует собой достижение детального соглашения между заказчиком и проектной группой о составе поставляемого решения и сроках поставок. Также на этой вехе проектная группа уточняет оценки рисков, корректирует (при необходимости) приоритеты и окончательно оценивает требуемые ресурсы.

Фаза разработки

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

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

Фаза стабилизации

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

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

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

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

Фаза стабилизации завершается вехой "Готовность решения утверждена" (Release Readiness Approved). В состоянии, достигнутом к этому моменту, решение уже готово к полному внедрению в производственную среду.

Фаза внедрения

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

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

Модель команды Microsoft Solutions Framework

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

Шесть ролевых кластеров модели проектной группы – это "Управление продуктом" (product management), "Управление программой" (program management), "Разработка" (development), "Тестирование" (test), "Удовлетворение потребителя" (user experience) и "Управление выпуском" (release management). Они ответственны за различные области компетенции (functional areas) и связанные с ними цели и задачи. Иногда ролевые кластеры называются просто ролями. Но в любом случае суть концепции остается той же – построить основу производственных отношений и связанную с ней модель команды такими, чтобы они были приспосабливаемыми (масштабируемыми) для удовлетворения нужд любого проекта. Одна роль (или один кластер) может быть представлена одним или несколькими сотрудниками, в зависимости от размера проекта, его сложности и профессиональных навыков, требуемых для реализации всех областей компетенции кластера.

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

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

Таблица 3. Области компетенции и функции ролевых кластеров MSF
Цель Область компетенции Функции
Управление продуктом Удовлетворенные заказчики

Маркетинг

Бизнес-отдача (бизнес-приоритеты)

Представление интересов заказчика

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

Выступает в роли представителя заказчика

Формирует общее видение/рамки проекта

Организует работу с требованиями заказчика

Развивает сферы применения в бизнесе

Формирует ожидания заказчика

Определяет компромиссы между параметрами "возможности продукта / время / ресурсы"

Организует маркетинг, PR и евангелизацию

Разрабатывает, поддерживает и исполняет план коммуникаций

Управление программой Достижение результата в рамках проектных ограничений

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

Выработка архитектуры решения

Контроль производственного процесса

Административные службы

Управляет процессом разработки с целью получения готового продукта в отведенные сроки

Формулирует спецификацию продукта и разрабатывает его архитектуру

Регулирует взаимоотношения и коммуникацию внутри проектной группы

Следит за временным графиком проекта и готовит отчетность о его состоянии

Проводит в жизнь важные компромиссные решения

Разрабатывает, поддерживает и исполняет сводный план и календарный график проекта

Организует управление рисками

Разработка Создание продукта в соответствии со спецификацией

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

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

Разработка приложений

Разработка инфраструктуры

Определяет детали физического дизайна

Оценивает необходимые время и ресурсы на реализацию каждого элемента дизайна

Разрабатывает или контролирует разработку элементов

Подготавливает продукт к внедрению

Консультирует команду по технологическим вопросам

Тестирование Одобрение выпуска продукта только лишь после того, как все дефекты выявлены и улажены

Планирование тестов

Разработка тестов

Отчетность по тестам

Обеспечивает обнаружение всех дефектов

Разрабатывает стратегию и планы тестирования

Осуществляет тестирование

Удовлетворение потребителя Повышение эффективности пользователя, увеличение потребительской ценности продукта

Обеспечение технической поддержки

Обучение

Эргономика

Графический дизайн

Интернационализация

Общедоступность (обеспечение возможности работы для пользователей с ограниченными физическими возможностями)

Представляет интересы потребителя в команде

Организует работу с требованиями пользователя

Проектирует и разрабатывает системы поддержки производительности

Определяет компромиссы, относящиеся к удобству использования и потребительским качествам продукта

Определяет требования к системе помощи и ее содержание

Разрабатывает учебные материалы и осуществляет обучение пользователей

Управление выпуском Беспроблемное внедрение и сопровождение продукта

Инфраструктура

Сопровождение

Бизнес-процессы

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

Представляет интересы отделов поставки и обслуживания продукта

Организует снабжение проектной группы

Организует внедрение продукта

Вырабатывает компромиссы в управляемости и удобстве сопровождения продукта

Организует сопровождение и инфраструктуру поставки

Организует логистическое обеспечение проектной группы

< Лекция 3 || Лекция 4: 1234 || Лекция 5 >
Сергей Черенкевич
Сергей Черенкевич
Казахстан