Выбирайте приоритеты, учитывая риски

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

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

Осуществляйте частые итерации разработки

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

Институциируйте процедуры контроля изменений в проекте

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

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

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

· В целях облегчения проведения анализа запросы на изменение функциональности подаются в письменном виде. Это позволяет группировать подобные запросы. В Майкрософт они называются запросами на изменение дизайна (design change requests – DCRs[SB3]).

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

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

· Должны быть определены члены группы контроля за изменениями (change control board), утверждающей или отвергающей запрошенные изменения. В эту группу должны входить представители заказчика, ролевого кластера “Управление программой” и прочие представители проектной группы и других заинтересованных сторон. Группа контроля за изменениями может формироваться различным образом, но, в любом случае, она должна иметь полномочия вносить изменения в бюджет, календарный график и функциональность решения.

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

· Эффективное управление изменениями возможно только при эффективном управлении конфигурациями.

Целостный взгляд на разработку и внедрение

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

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

Модель процессов, интегрирующая разработку и внедрение решения, имеет следующие преимущества:

Сосредоточение на нуждах предприятия

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