Выбирайте приоритеты, учитывая риски
Проведение проектной группой оценивания рисков позволяет выявить, реализация какой функциональности сопряжена с наибольшими из них. Подробная информация о рисках может быть получена из “Белой книги” дисциплины управления рисками MSF.
В первую очередь планируйте реализовать наиболее рискованные нововведения и изменения и только после них – менее рискованные. Например, задачи, связанные с большими изменениями в архитектуре, имеет смысл выполнить на ранних этапах проекта, минимизируя тем самым влияние этих изменений на бюджет и календарный график.
Осуществляйте частые итерации разработки
Существенный выигрыш от версионирования (versioning) решения заключается в предоставлении заказчику в адекватные сроки пригодного к эксплуатации решения, которое затем последовательно улучшается. Если в этом процессе происходят задержки, то надежды заказчика на постоянное улучшение продукта оказываются неоправданными. Поэтому ограничивайте рамки каждой итерации решения, чтобы создание новой версии происходило в приемлемые сроки.
Институциируйте процедуры контроля изменений в проекте
Как только завершено создание базовой версии спецификации, должен быть незамедлительно введен контроль за изменениями планируемой функциональности решения. Принципиально важно, чтобы вся проектная группа и заказчик четко понимали значение такого контроля и его процедуры.
MSF не предписывает конкретный набор правил контроля за изменениями. В зависимости от размера и типа проекта, эти процедуры могут быть простыми или сложными. Однако для обеспечения эффективности контроля необходимо наличие следующих элементов:[SB2]
· Без анализа и одобрения как со стороны проектной группы, так и со стороны заказчика запланированная функциональность не расширяется и не изменяется.
· В целях облегчения проведения анализа запросы на изменение функциональности подаются в письменном виде. Это позволяет группировать подобные запросы. В Майкрософт они называются запросами на изменение дизайна (design change requests – DCRs[SB3] ).
· Должны быть проанализированы влияние, осуществимость и приоритет каждого запроса на введение новой функциональности. При этом должны быть учтены взаимосвязи с другими составляющими решения, включая пользовательскую документацию, документацию сопровождения, учебные материалы и производственную среду.
· Для каждого запрашиваемого изменения должно быть определено его влияние на бюджет и календарный график проекта (детали см. в разделе “Оценка снизу вверх”).
· Должны быть определены члены группы контроля за изменениями (change control board), утверждающей или отвергающей запрошенные изменения. В эту группу должны входить представители заказчика, ролевого кластера “Управление программой” и прочие представители проектной группы и других заинтересованных сторон. Группа контроля за изменениями может формироваться различным образом, но, в любом случае, она должна иметь полномочия вносить изменения в бюджет, календарный график и функциональность решения.
· Должен вестись мониторинг изменений, и все его результаты должны быть легко доступы. Например, хорошей практикой является создание в функциональной спецификации и других важных проектных документах секции для протоколирования изменений.
· Эффективное управление изменениями возможно только при эффективном управлении конфигурациями.
Целостный взгляд на разработку и внедрение
Как уже было отмечено ранее, решение не представляет бизнес-ценности, пока оно не внедрено. Именно по этой причине модель процессов MSF содержит весь жизненный цикл создания решения, включая его внедрение – вплоть до момента, когда решение начинает давать отдачу.
Преимущества интегрированной модели процессов
Модель процессов, интегрирующая разработку и внедрение решения, имеет следующие преимущества:
Сосредоточение на нуждах предприятия
Предприятия (и в особенности руководители предприятий) обычно рассматривают разработку и внедрение решения как нечто неразделимое. Даже если разработка решения прошла удачно, заказчики не увидят отдачи до тех пор, пока оно не внедрено на предприятии.