Методология разработки ПО Microsoft Solutions Framework (MSF)

Андрей Колесов

Обзор подготовлен на базе материалов, представленных в учебном курсе для подготовки к экзамену по программе сертификации Microsoft Certified Solution Developer N 70-300: Analyzing Requirements and Defining Microsoft .NET Solution Architectures. Русский перевод этого курса выпущен в 2004 г. издательством "Русская Редакция" под названием "Анализ требований и создание архитектуры решений на основе Microsoft .NET".

В последние годы мы видим, что ведущие поставщики средств разработки ПО (в первую очередь IBM Rational и Borland) от выпуска отдельных инструментов переходят к созданию комплексных платформ управления жизненным циклом приложений (application lifecycle management, ALM). Microsoft (http://www.microsoft.com) пока не форсирует процесс формирования полного спектра ALM-решений для автоматизации различных этапов производства ПО, хотя движется именно в этом направлении (об этом свидетельствуют последние новости с конференции TechEd"2004, см. врезку), и основной акцент делает на средствах проектирования и разработки - Visio, Visual Studio и т. д.

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

Структура процессов MSF

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

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

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

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

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

Создание общей картины приложения

На этом этапе решаются следующие основные задачи:

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

На этапе выделяются две промежуточные контрольные точки: "Организован костяк команды" и "Создана общая картина решения".

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

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

Этап завершается контрольной точкой "Утверждение документа общей картины и области действия проекта".

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

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

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

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

В ходе данного этапа решаются такие задачи:

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

Контрольные точки этапа планирования связаны с достижением следующих результатов:

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

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

Разработка

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

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

Результаты этапа предполагают следующие элементы:

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

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

Стабилизация

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

Тестирование подразумевает следующие основные виды работ:

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

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

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

Развертывание

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

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

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

Комментарии по поводу этапов работ

Добавим к изложенному выше несколько важных замечаний. В целом те же самые идеи лежат в основе всех современных промышленных методологий разработки ПО (IBM/Rational, Borland, Microsoft и т. д.). И здесь нет ничего удивительного: именно этим отличаются выверенные временем технологии от кустарного производства. Но в то же время в каждой методологии есть свой подход к выделению различных этапов разработки и зачастую используется собственная терминология, что усложняет проведение параллелей между ними. Проблема эта усугубляется и отсутствием устоявшейся русской терминологии.

Общепринятый на сегодня список ALM-этапов, которого, в частности, придерживаются Borland и Rational, выглядит следующим образом:

Defining (определение требований);
Designing (анализ и проектирование);
Developing (разработка);
Testing (тестирование);
Deploying (развертывание).

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

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

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

Microsoft для разработчиков - новости с TechEd"2004

На проходившей в конце мая в Сан-Диего (шт. Калифорния, США) конференции Microsoft TechEd"2004 был сделан целый ряд важных объявлений относительно развития средств разработки, новых инициатив в области безопасности информационных систем и поддержки жизненного цикла продуктов Microsoft.

На конференции были представлены два новых инструмента, предназначенных для интеграции с текущей версией Visual Studio .NET 2003. Первый из них, Web Services Enhancements 2.0 (WSE 2.0), позволяет повысить уровень безопасности создаваемых Web-сервисов за счет использования самых последних спецификаций протоколов WS-Security (на базе утвержденных в 2004 г. стандартов OASIS), в том числе WS-Policy, WS-Security Policy, WS-Trust и WS-SecurityConversation. Версия WSE 2.0 для VS.NET доступна уже сейчас. Кроме того, Microsoft планирует использовать эту технологию для решения задач интеграции данных и приложений: специальный модуль BizTalk Server Adapter for WSE 2.0 представлен пока лишь в виде предварительной технической версии.

Второй инструмент - Microsoft Office Information Bridge Framework (IBF), реализованный сейчас в виде бета-версии, - дает возможность использовать Microsoft Office в качестве интеллектуальных клиентских приложений при работе с Web-сервисами, созданными с помощью WSE 2.0. IBF представляет собой набор из нескольких компонентов, предназначенных для разработчиков и пользователей. Один из них устанавливается со стороны Office 2003 Pro и обеспечивает взаимодействие с IBF-приложениями прямо из офисных документов через смарт-теги. Второй компонент IBF - конструктор Information Bridge Metadata Designer, подключаемый к среде VS.NET и обеспечивающий визуальную разработку Web-сервисов с использованием модели безопасности WSE 2.0. В состав IBF входит также Information Bridge Metadata Service - серверный программный модуль, позволяющий передавать на клиентское ПО данные от запущенных на выполнение бизнес-приложений через Web-сервисы.

Однако для разработчиков, пожалуй, наиболее интересна информация о намерении существенно расширить в VS.NET возможности управления всем жизненным циклом приложений. Представленная на TechEd"2004 версия Visual Studio 2005 (кодовое имя Whidbey) Enterprise Edition получила название Visual Studio Team System (VSTS). Предполагается, что эта система будет поставляться в трех основных вариантах: Team Architect, Team Developer и Team Test.

Предназначенный для архитекторов программных решений инструмент Team Architect включает три конструктора для проектирования распределенных приложений, моделирования логической инфраструктуры и автоматической генерации кода. Последний из них (class designer) выполняет двухстороннюю синхронизацию между визуальной моделью проекта и программным кодом. Примечательно, что в нем используется не классический UML, а собственная нотификация языка моделирования Microsoft. Для поддержки UML в Visual Studio будет по-прежнему использоваться Visio, но встроенные средства самого VS развиваются в несколько ином направлении.

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

Следует отметить, что Team Architect представляет собой развитие средств, уже имеющихся в текущей версии VS 2003. Функциональность же Team Developer лишь в незначительной степени покрывается текущей версией VS.NET 2003, для эффективного решения подобных задач сегодня требуется подключать соответствующие расширения для VS от третьих фирм. Но в VS 2005 разработчики смогут применять встроенные средства самой Microsoft.

Что же касается третьей составляющей VSTS - Team Test, предназначенной для нагрузочного тестирования приложений, то данная функциональность ранее была доступна лишь в автономных продуктах других поставщиков. Теперь же она появилась непосредственно в среде VS 2005, причем в исполнении Microsoft. При этом особое внимание будет уделено задачам тестирования Web-сервисов, в том числе с использованием скриптов, работающих с различными транспортными протоколами, и режимов удаленного мониторинга.

Из всей этой информации следует, что Microsoft наращивает возможности своего инструментария в направлении создания комплексных систем масштаба предприятия, включая в него средства автоматизированной поддержки всех этапов жизненного цикла приложений и постепенно вытесняя соответствующие расширения от третьих фирм. Тем не менее многие независимые поставщики одобрительно восприняли сделанные объявления, так как новшества VSTS позволят поднять на качественно новый уровень сотрудничество в рамках "партнерской экосистемы VS", охватывающей несколько десятков компаний-разработчиков. В частности, о своей поддержке будущего продукта на TechEd"2004 уже заявили Borland, Compuware, Telelogic AB и Unisys.

Формирование проектных команд

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

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

Менеджер программы (program manager) управляет собственно разработкой ПО и несет ответственность за его поставку в соответствии с утвержденными спецификациями.

Разработчик (developer) занимается разработкой ПО в соответствии с заданными спецификациями.

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

Менеджер по выпуску (release manager) отвечает за развертывание и поддержку продукта, проверяет корректность ИТ-инфраструктуры заказчика на предмет ее готовности к эксплуатации ПО.

Специалист по удобству использования (user experience specialist) занимается изучением и решением проблем пользователей, оценивает продукт с точки зрения соответствия их потребностям.

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

Возможное совмещение ролей в проектной команде

	Менеджер продукта	Менеджер программы	Разработчик	Тестиров-щик	Менеджер по выпуску	Специа-лист по удобству исполь-зования
Менеджер продукта		-	-	+	-+	-+
Менеджер программы	-		-	-+	+	-+
Разработчик	-	-		-	-	-
Тестиров-щик	+	-+	-		+	+
Менеджер по выпуску	-+	+	-	+		-+
Специалист по удобству исполь-зования	+	-+	-	+	-+
Примечание: "- " - совмещение не рекомендуется, "-+ " - нежелательно, "+ " - возможно.

Кроме собственно исполнителей проекта, в команду могут входить и другие лица:

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

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

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

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

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

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

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

Учитывая, что зафиксировано ____________, мы определим _____________ и в случае необходимости скорректируем ____________________.

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

Учитывая, что зафиксированы РЕСУРСЫ, мы определим ГРАФИК и в случае необходимости скорректируем ФУНКЦИОНАЛЬНОСТЬ.

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

Русская версия Visual Basic .NET

В отличие от продуктов Microsoft массового спроса (Windows, Office), которые переведены на несколько десятков национальных языков, средства разработки Visual Studio .NET представлены сейчас лишь восемью локализованными версиями (французская, немецкая, испанская, итальянская, японская, корейская и два варианта китайских). Освоение русского языка началось лишь в этом году с одного инструмента, но зато самого массового, Visual Basic .NET Standard Edition (поставки его начались в мае 2004 г.). Чтобы представить себе значимость этого проекта, нужно иметь в виду, что полный объем локализации VS.NET 2003 составляет около 20 млн слов (включая всю справочную систему), что существенно превышает аналогичные показатели всего пакета Microsoft Office 2003. VB.NET Standard - это подмножество VS.NET, объем его локализации - 5,6 млн слов.

Нужно отметить, что редакция Standard не пользовалась до сих пор большим спросом со стороны профессиональных разработчиков. Тем не менее, по мнению сотрудников московского представительства Microsoft, наличие русской документации непременно повысит интерес разработчиков к VB.NET Standard, тем более что, несмотря на усеченные функции по сравнению с версией VS.NET Pro, с помощью этого инструмента можно создавать весьма широкий круг приложений, компонентов и Web-сервисов промышленного уровня. В отличие от VS.NET Pro, VB.NET Standard не может создавать элементы управления для Windows и Web, мобильные приложения, а также мощные серверные решения. Конечно же, в VB.NET не входят другие языки программирования - VC++, VC# и VJ#. Но подчеркнем, что VS.NET Pro стоит более 1000 долл. (вариант Upgrade - 550 долл.), а VB.NET Standard - всего 100 долл.

И все же появление русского VB.NET в основном связано с намерением Microsoft активно продвигать свои инструментальные средства в более широкие круги программистов, в первую очередь - в сферу образования, в частности, подготовки разработчиков.

Что касается перспектив расширения линейки русскоязычных средств разработки, сотрудники Microsoft говорят об этом достаточно осторожно. Однако вероятность появления русской версии будущей VS 2005 представляется достаточно большой.

Вспоминая предыдущую лекцию… Наша предыдущая лекция была посвящена визуальному моделированию в процессе анализа и проектирования и основам языка UML. При этом сначала в качестве введения мы кратко повторили: –типовую схему решения задач с использованием вычислительной техники; –основные положения алгоритмической и объектной декомпозиции; –принципы объектного подхода к анализу и проектированию. Далее мы обсудили, чем вызвана необходимость в визуальном моделировании программных систем и рассмотрели историю языка UML.

Вспоминая предыдущую лекцию Затем была рассмотрена структура и основные понятия UML, представлена постановка учебной задачи, на которой далее будет иллюстрироваться изучаемый материал на протяжении всего курса (Система бронирования билетов для авиакомпании). Наконец, мы подробно осветили средства UML для: –визуального описания функциональной модели: актеры, варианты использования, диаграммы вариантов использования, диаграммы действия; –описания структуры системы: классы, объекты и интерфейсы; пакеты, подсистемы и компоненты; –описания отношений между элементами модели: зависимость, ассоциация, обобщение, реализация.

Введение в методологию MSF и историческая справка… Что такое методология? Методология – принципы и способы организации теоретической и практической деятельности. Совокупность методов, применяемых в какой-либо науке. Для SE сформулируем так: Методология есть принципы и способы организации деятельности проектной группы для создания программного продукта. Программный продукт – решение. Проектная группа – команда.

Введение в методологию MSF и историческая справка… Основные концепции методологии MSF 1: MSF – методология разработки программного обеспечения от компании Microsoft, опирающаяся на практический опыт компании и описывающая управление людьми и управление процессами в ходе разработки решения. 2: MSF состоит из двух моделей и трех дисциплин. Они подробно описаны в пяти документах, так называемых «белых книгах» («whitepapers»), каждый из которых охватывает определенную дисциплину или модель MSF.

Введение в методологию MSF и историческая справка… Основные концепции методологии MSF Дисциплины и модели MSF: –Модель процессов MSF. –Модель проектной группы MSF. –Дисциплина управления проектами MSF. –Дисциплина управления рисками MSF. –Дисциплина управления подготовкой MSF. 3: MSF предлагает несколько оригинальных идей, с которыми мы подробно будем знакомиться далее, а пока просто перечислим их: –Единое видение проекта –Треугольник и матрица компромиссов –Проектная группа – команда равных –Управление рисками –…

Введение в методологию MSF и историческая справка… Историческая справка 1993 год – стремясь достичь максимальной отдачи от IT- проектов, компания Microsoft выпустила в свет пакет руководств по эффективному проектированию, разработке, внедрению и сопровождению решений, построенных на основе своих технологий. Эти знания базировались на опыте, полученном Microsoft при работе над большими проектами по разработке и сопровождению ПО, опыте консультантов Microsoft и лучшем из того, что накопила на тот момент IT индустрия год – MSF год – MSF год – MSF 4.0.

Введение в методологию MSF и историческая справка Источники информации –Основным источником, безусловно, являются белые книги (в настоящий момент доступные для версии MSF 3.0). –Немало сведений можно найти на сайте компании Microsoft, включая разделы портала TechNet (–Кроме того, желающие могут прослушать авторизованные курсы, связанные с MSF. –Информация по последней версии MSF 4.0:

Нововведения версии MSF 4.0… Два направления в MSF 4.0 –MSF for Agile Software Development –MSF for CMMI Process Improvement Мы рассматриваем MSF for Agile Software Development CMMI (Capability Maturity Model Integration) – существенно более формализованная методология, чем Agile development, ориентированная на разработку ПО в больших коллективах.

Нововведения версии MSF 4.0… Основные положения MSF for Agile Software Development Предлагает максимально облегченный и гибкий подход к процессу разработки. Другой пример подобных методологий - Extreme Programming (XP). Agile направление в MSF ориентируется на небольшие команды (5-6 человек). Предполагает, что информация о разрабатываемом продукте не просто выясняется в процессе разработки, а может и будет изменяться по ходу. Таким образом, первая рабочая версия системы должна быть создана как можно раньше, а сам продукт фактически проявляется из прототипов путем повторения итераций в цикле разработки.

Нововведения версии MSF 4.0… Основные положения MSF for Agile Software Development Элементы методологии: –рекомендованные процессы создания IT-проектов; –структура итераций; –роли членов команды; –шаблоны документов (Excel, Word); –шаблоны Microsoft Project; –отчеты; –портал проекта (шаблон сайта SharePoint). MSF for Agile Software Development ориентирован на использование итеративной и эволюционной модели процесса разработки и основан на сценариях (вариантах) использования.

Нововведения версии MSF 4.0 Инструментальная поддержка MSF 4.0 В отличие от предыдущих редакций инструментальная поддержка в среде разработки Microsoft Visual Studio 2005 Team System. Среда Visual Studio 2005 может выступать теперь в качестве интегрирующего средства, из которого можно работать со всеми инструментами, обеспечивающими стадии процесса разработки от создания планов проекта до проведения различных видов тестирования, включая создание и выполнение тестовых сценариев.

Формирование команды. Модель проектной группы MSF for Agile Software Development… Основные принципы построения команды Методология MSF считает, что успешная работа команды над проектом существенным образом зависит от ее структуры и распределения зон ответственности ролевых групп. Построение команды в MSF соответствует ряду ключевых концепций, часть которых кажутся очевидными, другие сродни «ноу-хау».

Формирование команды. Модель проектной группы MSF for Agile Software Development… Основные принципы построения команды Очевидные концепции (1): –Концентрация на нуждах заказчика (customer-focused mindset) – главный приоритет любой хорошо работающей проектной группы. –Означает обязательное понимание бизнес-задач заказчика и стремление к их решению со стороны команды. –Не менее важным является активное участие заказчика в проектировании решения и получение его отзывов в ходе процесса разработки.

Формирование команды. Модель проектной группы MSF for Agile Software Development… Основные принципы построения команды Очевидные концепции (2): –Нацеленность на конечный результат (product mindset) – каждый участник проектной группы должен рассматривать собственную работу в качестве самостоятельного проекта или же вклада в какой-либо больший проект. –Установка на конечный продукт означает, что получению конечного результата проекта уделяется больше внимания, чем процессу его достижения. –Из этого не следует, что сам процесс может быть плох или непродуман – просто он существует для получения конечной цели, а не ради себя самого.

Формирование команды. Модель проектной группы MSF for Agile Software Development… Основные принципы построения команды Очевидные концепции (3): –Установка на отсутствие дефектов (zero-defect mindset) – это стремление к высочайшему уровню качества. Цель команды – выполнение своей работы с максимально возможным качеством, в идеале таким образом, что если от команды потребуют поставить результат завтра, она будет способна поставить что-то работающее. –В успешной команде каждый сотрудник чувствует ответственность за качество продукта. –Она не может быть делегирована одним членом команды другому или же от одной ролевой группы другой.

Формирование команды. Модель проектной группы MSF for Agile Software Development… Основные принципы построения команды Ноу-хау (1): –«Проектная группа – команда равных» (teem of peers). Концепция означает равноправное положение каждой из ролей в команде. –Чтобы достичь успеха в рамках команды равных, каждый из ее членов, независимо от роли, должен нести ответственность за качество продукта, понимать интересы заказчика и сущность решаемой бизнес-задачи. –В то же время, принятие решения методом консенсуса между ролями не тождественно принятию решения методом консенсуса между сотрудниками. –Каждая ролевая группа требует определенной организационной иерархии для распределения работы и управления ее ресурсами.

Формирование команды. Модель проектной группы MSF for Agile Software Development… Основные принципы построения команды Ноу-хау (2): –Стремление к самосовершенствованию (willingness to learn) – это приверженность идее неустанного саморазвития посредством накопления опыта и обмена знаниями. –Оно позволяет членам проектной группы извлекать пользу из отрицательного опыта сделанных ошибок, равно как и воспроизводить успехи, используя проверенные методы работы других людей. –По окончанию основных фаз проекта и по завершению проекта в целом предполагается проведение открытых обсуждений его состояния и доброжелательный, но объективный анализ.

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

Формирование команды. Модель проектной группы MSF for Agile Software Development… Ролевые группы и роли Ролевые группы (кластеры) –Управление программой (program management) –Архитектура продукта (architecture) –Разработка (development) –Тестирование (test) –Управление выпуском (release operations) –Удовлетворение потребителя (user experience) –Управление продуктом (product management)

Формирование команды. Модель проектной группы MSF for Agile Software Development… Ролевые группы и роли Роли: –менеджер проекта (project manager) – ролевая группа Управление программой –архитектор (archrect) – ролевая группа Архитектура –разработчик (developer) – ролевая группа Разработка –тестер (tester) – ролевая группа Тестирование –релиз-менеджер (release manager) – ролевая группа Управление выпуском –бизнес-аналитик (business analyst) – ролевые группы Управление продуктом и Удовлетворение потребителя

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

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

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

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

Создание бизнес-решения в рамках отведенных времени и бюджета требует наличия испытанной методологической основы. MSF предлагает проверенные методики для планирования, проектирования, разработки и внедрения успешных IT-решений. Благодаря своей гибкости, масштабируемости и отсутствию жестких инструкций MSF способен удовлетворить нужды организации или проектной группы любого размера. Методология MSF состоит из принципов, моделей и дисциплин по управлению персоналом, процессами, технологическими элементами и связанными со всеми этими факторами вопросами, характерными для большинства проектов. Информация по MSF доступна в Internet по адресу http://www.microsoft.com/msf/.

MOF призван обеспечить организации, создающие критически важные (mission-critical) IT‑решения на базе продуктов и технологий Майкрософт, техническим руководством по достижению их надежности (reliability), доступности (availability), удобства сопровождения (supportability) и управляемости (manageability). MOF затрагивает вопросы, связанные с организацией персонала, процессов; технологиями и менеджментом в условиях сложных (complex), распределенных (distributed) и разнородных (heterogeneous) IT-сред. MOF основан на лучших производственных методиках, собранных в IT Infrastructure Library (ITIL), составленной Central Computer and Telecommunications Agency - Агентством правительства Великобритании. Информация по MOF доступна в Internet по адресуhttp://www.microsoft.com/mof/.

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

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

Microsoft Solutions Framework представляет собой согласованный набор концепций, моделей и правил .

На сайте компании Майкрософт http://www.microsoft.com/rus/msdn/msf/default.mspx представлены переводы следующих документов:

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

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

Дисциплина управления рисками MSF. Управление рисками - это одна из основных дисциплин в Microsoft Solution Framework. В методологии MSF с самого начала учитывается, что IT-проекты могут изменяться в процессе реализации, что вносит дополнительную неопределенность. В дисциплине управления рисками MSF предлагается упреждающий подход к управлению рисками, их постоянная оценка и учет при принятии решений.

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

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

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

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

5.4.1. Управление рисками в MSF for Agile Software Development

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

В ходе всего проекта команда должна уделять внимание дисциплине управления рисками. Основные ее характеристики:

§ она всеобъемлюща и принимает во внимание все составляющие проекта: людей, бизнес-процессы, технологические элементы и т.д.;

§ она включает в себя пошаговый, систематический и воспроизводимый процесс управления рисками проекта;

§ ее использование непрерывно на протяжении всего жизненного цикла проекта;

§ она превентивна и не исходит из идеологии действия по факту случившегося.

§ она вовлекает всю проектную группу в непрерывное извлечение уроков из полученного опыта.