Компания Microsoft подготовила и применяет несколько методик для покрытия не только ЖЦИС, но и технологической инфраструктуры, их поддерживающей.

В контексте рассмотрения ЖЦПО нас интересует именно методология разработки: как являющийся одним из основных аспект управления и взаимодействия участников процесса, так и другие области знаний (управление рисками, планирование). В целом охватываемые MSF дисциплины описаны в пяти частях (так называемых белых книгах), однако интересно, что командами консультантов Microsoft применяется на практике не этот ресурс, а методика MSF for Agile Software Development, которая является прикладным вариантом MSF и отражает общий методологический подход к итеративной разработке.

Если обратиться непосредственно к процессу разработки и внедрения, то его характеризуют:

• итеративность;
• формирование в качестве результата ИТ-решения.

ИТ-решение - скоординированная поставка набора элементов (таких как программно-технические средства, документация, обучение, сопровождение и внешние коммуникации), необходимых для удовлетворения некоторой бизнес потребности конкретного заказчика.

Именно ИТ-решения (а не просто программные продукты, поставляемые в виде дистрибутивов) являются основным продуктом и результатом процесса разработки и внедрения по MSF (несмотря на то что аналогичная философия лежит в основе многих методологий, все равно термин «программный продукт» является очень распространенным).

Основной состав MSF - это две модели и три дисциплины, которые подробно рассматриваются в пяти белых книгах. В состав MSF входят:

• модели:
  • - модель группы,
  • - модель процессов;
• дисциплины:
• - дисциплина «Управление проектами»,
• - Дисциплина «Управление рисками»,
• - Дисциплина «Управление готовностью».

Модель процессов. Модель процессов - это «основа основ» методологии MSF. Модель процессов MSF основана на сочетании водопадной и спиральной моделей жизненного цикла ИС. Таким образом, в методологии MSF проект реализуется поэтапно, все этапы могут повторяться «по спирали», а между этапами существуют заранее определенные контрольные точки (рис. 7.20).

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

Создание общей картины ИТ-решения. Первый этап модели MSF - это Создание общей картины ИТ-решения. Задачи этапа таковы:

• определить проектную команду;
• определить структуру проекта;
• определить бизнес-цели проекта;
• оценить текущую ситуацию;
• сформировать документ с описанием общей картины и областью действия проекта;
• определить требования пользователей;
• разработать концепции для ИТ-решсния;
• оценить риски;
• закрыть этап.

Рис. 7.20.

Этап содержит в себе две контрольные точки: «Костяк команды сформирован» и «Общая картина ИТ-решения создана».

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

Контрольная точка «Общая картина ИТ-решения создана» предполагает разработку концепции ИТ-решения, которым команда будет руководствоваться в дальнейшем для достижения бизнес-целей, декларированных в проекте. Контрольная точка характеризуется наличием описания того, что входит в проект, а что не входит. При этом документ не является итоговым: к данной точке создается предварительная рецензируемая версия.

Завершение этапа происходит, когда достигнута третья контрольная точка - «Документ общей картины и области действия проекта утвержден».

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

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

Задачи Планирования могут быть сформулированы следующим образом:

• разработать архитектуру ИТ-решения;
• сформировать функциональную спецификацию;
• разработать проектные планы;
• сформировать календарный график работ;
• создать среду разработки, тестирования и тестовой эксплуатации;
• закрыть этап.

Планирование - достаточно сложный и обширный этап, который насчитывает пять контрольных точек:

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

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

Разработка. Этап Разработки подразумевает непосредственное создание ИТ-решения, т.е. написание и документацию программного кода. Убедившись, что задачи предыдущих этапов выполнены, проектная команда приступает к реализации задач, характерных для этапа разработки:

• создать прототип ИТ-решения;
• разработать программные компоненты ИТ-решения;
• создать готовое ИТ-решение (рассматривается как последовательность промежуточных выпусков);
• закрыть разработку (реализовать все функции в ИТ-решении, поставить код и документацию заказчику).

В методологии MSF выделяют следующие результаты разработки:

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

Этап разработки также содержит и контрольные точки, основная из которых - «Итоговое утверждение области действия проекта». Эта контрольная точка считается достигнутой, когда все функции продукта реализованы и прошли предварительное тестирование. Считается, что после этого ИТ-решение пригодно к внешнему тестированию и началу стабилизации.

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

Тестирование включает следующие виды активности:

• тестирование компонентов;
• тестирование БД;
• тестирование ИТ-инфраструктуры;
• тестирование безопасности;
• тестирование интеграции;
• тестирование эргономичности;
• нагрузочное тестирование;
• регрессивное тестирование;
• ведение отчетности по тестированию.

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

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

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

• основные компоненты развернуты;
• решение развернуто;
• решение стабилизировано;
• решение передано в эксплуатацию заказчику.

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

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

Таблица 7.12

Роли, цели и функциональные области MSF

		Функциональные области
Управление продуктами	Обеспечить бизнес-ценность решения. Определить решение в рамках ограничений проекта. Обеспечить выполнение требований	Коммуникации. Аналитика. Планирование
Управление программой	Реализовать проект в рамках ограничений. Реализовать средства, с помощью которых выполняются требования	Управление проектом. Управление программой. Управление ресурсами. Обеспечение выполнения. Управление качеством. Операции проекта
Разработка	Построить ИТ-решение в соответствии со спецификациями	Разработка ИТ-решения. Технологическое консультирование
Тестирование	Проверить соответствие ИТ-решения заданным условиям качества. Утвердить выпуск ИТ-решения	Все виды тестирования
Выпуск и эксплуатация	Развернуть ИТ-решение и обеспечить переход к эксплуатации. Обеспечить выполнение потребностей и ожиданий бизнес-подразделений заказчика	Управление выпусками. Инфраструктура. Операции. Управление сборками. У правление инструментами
	Оптимизировать удобство использования ИТ-решеиия. Обеспечить готовность пользователей к работе с ИТ-решеиием. Обеспечить выполнение требований и ожиданий пользователей	Специальные возможности. Взаимодействие со службой поддержки. Обучение. Удобство использования. Проектирование пользовательского интерфейса

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

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

Таблица 7.13

Варианты совмещения ролей в MSF

	Управление продуктами	Управление программой	Разработка	Тестирование	и эксплуатация	Взаимодействие с пользователем
Управление продуктами
Управление программой
Разработка
Тестирование
Выпуск и эксплуатация
Взаимодействие с пользователем

Таким образом, в отличие от многих других корпоративных методологий, определенные в MSF этапы/всхи, состав проектной группы, ролевая модель и другие элементы подходят нс только для решений Microsoft. А значит, MSF представляет собой более гибкий и универсальный подход для внедрения других систем или программных продуктов.

On Target. Методология внедрения решений On Target была разработана компанией Navision для внедрения своих программных продуктов. После приобретения Navision корпорацией Microsoft было принято решение доработать On Target, к тому моменту содержавшую шаблоны описаний бизнес-процессов, документации, организационных структур ИТ и квалификационных требований к специалистам (табл. 7.14).

Таблица 7.14

Этапы в методологии On Target

		Действия
Проектирование	Сформировать нефункциональные требования к ИС. Сформировать принципы реализации требований	Проектирование реализации функциональных требований в ИС. Описание интерфейсов и модификаций. Уточнение плана и бюджета
Разработка и тестирование	Разработать И С. Протестировать И С	Разработка и тестирование функциональности. Разработка и тестирование интерфейсов. Разработка модификаций и дополнений
Развертывание	Развернуть систему на предприятии заказчика	Развертывание на рабочие места. Настройка прав и уровней доступа. Верификация начальных данных и операций. Перенос данных. Обучение и подготовка инструкций на рабочие места
Эксплуатация	Запустить ИС в эксплуатацию. Осуществить сдачу- приемку ИС	Запуск ИС в эксплуатацию. Опытная эксплуатация ИС. Сдача-приемка ИС

В силу того что к моменту приобретения Navision у Microsoft уже применялись свои проверенные корпоративные методологии MSF и MOF, в дальнейшем On Target была дополнена и к моменту выведения на рынок Microsoft Dynamics превратилась в результате доработок в MS Dynamics Sure Step/Microsoft Business Solutions Partner Methodology.

Microsoft Business Solutions Partner Methodology. MBS Partner Methodology - это дальнейшее развитие On Target. Эта методология ставит своей целью не просто создание ИС, но также максимальное удовлетворение потребностей заказчика.

Рис. 7.21.

Как можно видеть на рис. 7.21, этапы не сильно отличаются от аналогичных в On Target. На этапе Диагностики производится анализ и описание бизнес-процессов компании заказчика, а также выявляются ключевые бизнес-потребности. Производится первоначальное определение бюджета, сроков, границ и результатов проекта. Создается рабочая группа, причем сотрудники заказчика, вошедшие в нее, содействуют в проведении диагностики предприятия. В конце стадии формируются отчеты о проведенной диагностике, фиксируются ограничения проекта, документируются предложения по разработке и внедрению ИС.

Роли в проекте приведены на рис. 7.22.

Рис. 7.22.

На этапе Анализа окончательно формируются Управляющий комитет и проектная группа. Формируются такие документы, как План проекта, Устав проекта, Порядок отчетности, а также определяются условия сдачи-приемки и принципы управления изменениями и рисками. Сотрудники клиента знакомятся с базовой функциональностью продукта за счет проведения тренингов. Требования к ИС уточняются и детализируются, в результате чего формируется Спецификация функциональных требований. Формируются первые варианты интерфейсов, а предприятие начинает готовиться к изменению бизнес-процессов.

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

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

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

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

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

Корпорация Майкрософт выпустила в свет пакет руководств по эффективному проектированию, разработке, внедрению и сопровождению решений, построенных на основе своих технологий. Эти знания базируются на опыте, полученном Майкрософт при разработке и сопровождению программного обеспечения, опыте консультантов Майкрософт, разрабатывавших проекты на предприятиях заказчиков, и лучшем из того, что накопила на данный момент IT-индустрия. Всё это представлено в виде двух связанных и хорошо дополняющих друг друга областей знаний: Microsoft Solutions Framework (MSF) и Microsoft Operations Framework (MOF)
(рис. 7.8).

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

Рис. 7.8. Взаимосвязь и области применения методологий MSF и MOF

В основе Microsoft Solutions Framework лежат следующие идеи:

o идентификация целей проекта и планирование их достижения;

o формирование факторов успеха;

o управление рисками;

o выпуск промежуточных версий;

o планирование активности каждого члена проектной;

o четко обозначенные контрольные точки (вехи);

o проектные команды небольшой численности.

MOF призван обеспечить организации, создающие критически важные (Mission-Critical) IT-решения на базе продуктов и технологий Microsoft, техническим руководством по достижению их надежности (Reliability), доступности (Availability), удобства сопровождения (Supportability) и управляемости (Manageability). MOF затрагивает вопросы, связанные с организацией обучения и работы персонала, процессов, технологиями и менеджментом в условиях сложных (Complex), распределенных (Distributed) и разнородных (Heterogeneous) IT-сред.

Рис. 7.9. Области ключевых компетенций MOF

MOF основан на лучших производственных методиках, собранных в библиотеке IT Infrastructure Library (ITIL), составленной Агентством правительства Великобритании (Central Computer and Telecommunications Agency) и представляет собой свод ключевых компетенций в 4-х основных разделах реализации и использования программного продукта: «Изменения», «Эксплуатация», «Поддержка» и «Оптимизация» (рис. 7.9). Информация по MOF доступна в Internet по адресу http://www.microsoft.com/mof/.

Модель процесса в MSF формируется на базе итеративной и эволюционной моделей ЖЦ, основывается на сценариях использования, работы выполняет небольшая команда (хотя есть способы масштабирования команд для больших проектов), используется подход к тестированию, основанный на контексте. Модель полностью ориентирована на заказчика − принцип «качества обслуживания заказчика.

В модели поддерживаются следующие потоки работ (Workflow):

o Формулировка целей и задач проекта

o Идентификация факторов успеха проекта

o Создание сценариев и тестирование сценариев

o Создание требований по качеству обслуживания

o Планирование итераций

o Создание архитектуры решения

o Реализация задачи по разработке

o Сборка продукта

o Быстрое тестирование, исправление и закрытие ошибок

o Тестирования требований по качеству обслуживания

o Выпуск продукта

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

В модели проектной команды MSF у каждого члена команды имеются четко очерченные роли и зоны ответственности (рис. 7.10). В основу модели положены следующие принципы:

o взаимозависимые и взаимосвязанные роли в малой команде

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

o распределенное управление проектом и ответственность

o каждый сфокусирован на успехе проекта и настроен на работу в течение всего цикла проекта

o эффективные коммуникации между членами команды являются ключевым фактором успеха;

o параллельная работа всех участников команды над проектом

o пользователи и обучающий персонал включены в команду.

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

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

Рис. 7.10. Роли членов проектной команды MSF

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

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

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

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

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

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

Помимо перечисленных ролей, можно выделить еще «роли поддержки и сопровождения». Это специалисты и эксперты в ключевых точках инфраструктуры. Они привлекаются к работам, когда это необходимо, но не принимают решений. Если численность проектной комнды меньше шести человек, то часть ролей может совмещаться, и их будет выполнять один человек. MSF дает рекомендации по совместимости нескольких различных ролей. На рис. 7.11 показаны рекомендации по совмещению ролей.

В настоящее время существуют наборы программных продуктов для поддержки командной работы. На наш взгляд одним из таких интересных и недорогих наборов является следующий: Visual Studio Team System 2010 (интегрированное средство управления программными проектами), SQL Server 2008 (одно из наиболее эффективных средств для хранения и управления данными) и BizTalk Server 2010 (средство для управления и автоматизации бизнес-процессов), с помощью которого можно полностью реализовать все задачи по разработке мобильного программного приложения небольшой по численности командой.

Методология Scrum

Методология Scrum – это набор принципов, на которых строится процесс разработки, позволяющий в жёстко фиксированные небольшие промежутки времени («спринты») от двух до четырех недель предоставлять конечному пользователю работающее ПО с новыми возможностями, для которых определён наибольший приоритет. Возможности ПО к реализации в очередном спринте определяются в начале спринта на этапе планирования и не могут изменяться на всём его протяжении. При этом строго-фиксированная небольшая длительность спринта придаёт процессу разработки предсказуемость и гибкость .

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

В методологии Scrum имеется всего три роли.

Scrum Master – самая важная роль в методологии. Как правило, эту роль в проекте играет менеджер проекта или team-leader. В обязанности Scrum Master"а входит обеспечение максимальной работоспособности и продуктивности команды, четкого взаимодействия между всеми участниками проекта, своевременное решение всех проблем, тормозящих или останавливающих работу, ограждение команды от всех воздействий извне во время итерации и обеспечение следования процессу всех участников проекта.

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

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

Рис. 7.12. Процессы и артефакты в методологии Scrum

Артефакты в методологии Scrum (рис. 7.12):

Product Backlog – это имеющихся на данный момент список деловых и технических требований к системе с указанием приоритетов. Product Backlog включает в себя задачи, технологии, проблемы, запросы ошибки и т.д. Элементы этого списка называются «историями» (User Story) или элементами Backlog’a (Backlog Items). Product backlog открыт для редактирования для всех участников Scrum-процесса.

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

Burndown chart показывает, сколько уже исполнено и сколько ещё остаётся сделать.

Результатом Sprint является готовый продукт, который можно передавать заказчику. Каждый sprint представляет собой «водопад». В течение спринта делаются все работы по сбору требований, дизайну, кодированию и тестированию продукта.

Такая итеративная разработка, в конце которой создается готовый к использованию продукт, применяется во многих гибких методологиях. Но в Scrum хорошо реализован процесс сбора функций и их распределение по итерациям. Спорный момент здесь – отсутствие жестко заданного распределения ролей и обязанностей в команде. Принцип «все ответственны за всё» работает далеко не всегда, наоборот, четкое распределение ролей позволит сконцентрироваться сотрудникам только на тех работах, где они могут принести максимум пользы.

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

Тем не менее, методология Scrum является одной из самых применяемых гибких (Agile) методологий, когда необходимо в сжатые сроки небольшой командой изготовить и передать заказчику качественный продукт.

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

В последние годы мы видим, что ведущие поставщики средств разработки ПО (в первую очередь IBM Rational и Borland) от выпуска отдельных инструментов переходят к созданию комплексных платформ управления жизненным циклом приложений (ALM). Microsoft пока не форсирует процесс формирования полного спектра ALM-решений для автоматизации различных этапов производства ПО, хотя движется именно в этом направлении и основной акцент делает на средствах проектирования и разработки - Visio, Visual Studio и т. д.

Однако для реализации идеологии ALM на практике необходим не только набор инструментов сам по себе, но и общая методологическая база. Microsoft уже более десяти лет занимается развитием собственной ALM-методологии под названием Microsoft Solutions Framework (MSF). Может показаться неожиданным, но MSF в целом - по сути платформно-независимая методология, детально описывающая отдельные процессы на уровне абстракций. Инструменты самой Microsoft присутствуют в ней в минимальной степени, лишь как примеры реализации тех или иных рекомендаций. Вместе с тем, хотя и неявно, концепция эта четко выражает общую нацеленность средств разработки корпорации (круг задач, для решения которых они предназначены), что очень хорошо видно из анализа динамики ее развития. Так, если десять лет назад MSF была ориентирована на создание локальных клиентских приложений, то сегодня - на разработку и внедрение сложных систем масштаба предприятия.

v “Модель процессов MSF”;

v “Модель проектной группы MSF”;

v “Дисциплина управления проектами MSF”;

v “Дисциплина управления рисками MSF”;

v “Дисциплина управления подготовкой MSF”.

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

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

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

Как легко заметить, модель MSF предлагает несколько иную разбивку на этапы ЖЦ ПО и их наименование, отличающуюся от общепринятого на сегодняшний день списка ALM-этапов, которого, в частности, придерживаются компании Borland и IBM Rational. Речь здесь не идет просто о разных названиях одних и тех же видов деятельности. Объективная проблема категоризации заключается в том, что выделение самостоятельных этапов в жизненном цикле приложений весьма условно, особенно если речь идет об итерационной циклической модели разработки. Например, широкое использование визуальных методов проектирования с автоматической генерацией кода фактически стирает грань между проектированием и кодированием. А тестирование вообще пронизывает всю жизнь программы. Имеются и субъективные факторы, которые определяются различиями стратегических бизнес-целей разных поставщиков методологий. Именно этим объясняется то, что Microsoft - основу бизнеса которой составляют не средства разработки, а платформенное ПО, - больше внимания (по сравнению с теми же IBM Rational и Borland) уделяет общим вопросам организации процесса создания приложений, а также их внедрению.

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

методологий других разработчиков ALM-продуктов.

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

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

Проектная группа разделяется на шесть ролевых кластеров, соответствующих шести качественно различным задачам проекта:

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

· Управление программой

· Разработка

· Тестирование

· Удовлетворение потребителя

· Управление выпуском

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

· Распределение ответственности при фиксации отчетности;

· Наделение соответствующими полномочиями ролевых кластеров.

Таким образом, все ролевые кластеры в команде равноправны. Однако иерархия отчётности при этом не нарушается, а остается прежней. Это путь к качественному продукту. Составление календарных планов работ осуществляется руководителем соответствующего ролевого кластера. Это побуждает к большей ответственности за свои сроки и обязательства, чем за те, которые на тебя спустили сверху. Каждый ролевой кластер принимает участие в принятии решений о завершении фаз проекта. Противоречия разрешаются методом компромиссов. Кроме того хорошей практикой является вход в состав группы представителей заказчика, что увеличивает заинтересованность и активное содействие внедрению со стороны заказчика. Кроме того, заказчик становится более информированным о ходе проекта т.к. информация по проекту между кластерами доступна членам команды. Например, если разрабатывается система автоматизации предприятия, хорошей, на мой взгляд, практикой будет назначить руководителем кластера Управление выпуском (по сути, это внедрение и материальное обеспечение внедрения) представителя заказчика, а исполнителями же внедрения - сотрудников компании-исполнителя. В случае успеха слава за удачу (речь идет не о финансовом поощрении) разделится поровну между всеми участниками проекта. А вот ответственность распределена в соответствии с ролевым кластером. Менеджер проекта (ролевой кластер Управление программой) будет отвечать, если проект не уложится в срок и в смету, разработка – если не выполнит разработку в названный ей же срок, тестирование – если в выпущенной версии будут возникать проблемы и т.д. Этап планирования не завершиться пока все ролевые кластеры не будут согласны с планом проекта. Это, конечно, несколько увеличит срок принятия решений, зато многократно уменьшит вероятность ошибочных решений. Однако, по мнению Microsoft, такой подход намного сильнее стимулирует творчество, ответственность, коммуникации и взаимопонимание в проектной группе, чем привычный нам, вид управления самодержца.

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

Процесс MSF ориентирован на "вехи" ( milestones ). Вехи – ключевые точки процесса разработки, которые характеризуют достижение какого–либо существенного результата.

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

Каскадная и спиральная модели процессов

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

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

Каскадная модель (waterfall)

Рис. 5.1.

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

На рисунке: Ромбы соответствуют вехам, стрелки – фазам.

Спиральная модель.

Рис. 5.2.

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

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

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

Рис. 5.3.

Базовые принципы:

1. Единое видение проекта. Изначально и у заказчика и у проектной группы имеется свое понимание целей и задач проекта , а также того, что должно быть достигнуто в ходе работы над проектом. Успех проекта невозможен без наличия единого видения и понимания проекта у заказчика и проектной группы, поскольку отсутствие ясности делает невозможным цели.

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

2. Проявляйте гибкость – будьте готовы к переменам. В противоположность каскадной модели MSF основывается на принципе непрерывной изменяемости условий проекта при неизменной эффективности управления.
3. Концентрируйтесь на бизнес - приоритетах. Разрабатываемый продукт должен приносить определенную выгоду или отдачу конечным пользователям. В случае организаций – бизнес – отдачу.

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

4. Поощряйте свободное общение. Исторически многие организации строили свою работу по принципу need-to-know, то есть сведения к минимуму информированности сотрудников.

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

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

Фазы модели процессов MSF

MSF версии 3.0 интегрирует в себе две ранние модели процессов: модель разработки приложений ( application development - AD) и модель внедрения инфраструктуры (infrastructure deployment - ID). Новая единая модель покрывает процесс создания решения с самого его начала и до момента окончательного внедрения. Таким образом, использовавшаяся ранее четырехфазная схема расширена до пяти фаз. Каждая фаза заканчивается главной вехой , результаты которой становятся видимыми за пределами проектной команды.

Рис. 5.4.

Фаза выработки концепции

На фазе выработки концепции (envisioning phase ) закладывается одна из фундаментальных основ успеха проекта – создание и сплочение проектной группы на основе выработки единого видения. Проектная группа должна четко представить себе, что она хочет сделать для заказчика и сформулировать свою цель таким образом, чтобы максимально мотивировать как заказчика, так и саму проектную команду. Выработка высокоуровневого взгляда на цели и условия проекта может рассматриваться как ранняя форма планирования; она подготавливает почву для процессов создания детальных планов, которые будут осуществлены непосредственно во время фазы планирования.

Основными задачами фазы выработки концепции являются создание ядра проектной группы (см. ниже) и подготовка документа общего описания и рамок проекта ( vision /scope document). Формирование видения проекта и специфицирование его рамок (Видение ( vision ) – это ничем не ограничиваемое представление о том, каким должно быть решение; Рамки (scope) же дают четкие границы того, что из предложенного этим видением будет реализовано в условиях существующих проектных ограничений).

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

Также во время фазы выработки концепции производится выявление и анализ бизнес требований. Более детально эти требования рассматриваются во время фазы планирования.

Ведущим ролевым кластером на фазе выработки концепции является "Управление продуктом".

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

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

• модель команды

  модель процессов

дисциплины:

• дисциплина управление проектами

  дисциплина управление рисками

  дисциплина управление подготовкой

Модель команды msf

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

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

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

Распределение ответственности при фиксации отчетности

Наделение членов команды полномочиями

Концентрация на бизнес-приоритетах

Единое видение проекта

Гибкость и готовность к переменам

Поощрение свободного общения

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

Команда соратников

Сфокусированность на нуждах заказчика

Нацеленность на конечный результат

Установка на отсутствие дефектов

Стремление к самосовершенствованию

Заинтересованные команды работают эффективно

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

управление программой (program manager) - разработка архитектуры решения, административные службы;

разработка (developer) - разработка приложений и инфраструктуры, технологические консультации;

тестирование (QAE) - планирование, разработка тестов и отчетность по тестам;

управление выпуском/логистикой (release manager) - инфраструктура, сопровождение, бизнес-процессы, выпуск готового продукта;

удовлетворение заказчика (user experience) - обучение, эргономика, графический дизайн, техническая поддержка;

управление продуктом (product manager) - бизнес-приоритеты, маркетинг, представительство интересов заказчика.

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

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

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

Роль команды разработчиков не может быть объединена ни с какой другой ролью.

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

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

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

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

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

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

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

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

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

Закрытие ИП