Управление рисками. Модель процессов

3. Модель процессов MSF for Agile Software Development

Модель процессов MSF^{2Раздел подготовлен на основе материалов белой книги [5.1] и руководства [5.11]} представляет общую методологию разработки и внедрения IT- решений. Особенность этой модели состоит в том, что благодаря своей гибкости и отсутствию жестко навязываемых процедур она может быть применена при разработке весьма широкого круга IT проектов. Эта модель сочетает в себе свойства двух стандартных производственных моделей: каскадной (waterfall) и спиральной (spiral).

Рис. 5.2. Модели процесса (слева направо): каскадная, спиральная, MSF. Источник: белая книга

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

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

3.1. Принципы модели процессов

3.1.1. Взаимодействуйте с заказчиками

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

3.1.2. Поощряйте свободный обмен информацией в проекте

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

3.1.3. Создавайте единое видение проекта

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

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

3.1.4. Следите за качеством продукта

MSF настаивает на том, что каждый участник проектной группы должен ощущать ответственность за качество разрабатываемого решения. Она не может быть делегирована одним членом команды другому или же от одной ролевой группы другой. Несмотря на наличие в команде ролевых групп "Удовлетворение потребителя" и "Тестирование", прямая задача которых - следить за качеством решения и повышать его, все остальные ролевые группы также постоянно должны иметь в виду нужды конечного пользователя.

3.1.5. Проявляйте гибкость - будьте готовы к изменениям

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

3.1.6. Ставьте "вехи"

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

3.1.7. Будьте готовы к внедрению сегодня

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

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

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

3.2.1. Треугольник компромиссов

Хорошо известна взаимозависимость между ресурсами проекта (людскими и финансовыми), его календарным графиком (временем) и реализуемыми возможностями (рамками). Эти три переменные образуют треугольник компромиссов (tradeoff triangle) [5.1].

Рис. 5.3. Треугольник компромиссов. Источник: белая книга

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

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