Лекция 6. Общие замечания к модели разработки MSF

Принципы модели процесса разработки

 

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

1) выпуск версий продукта,

2) постоянно “живущие” документы,

3) планирование процесса с учетом неопределенностей,

4) поиск компромиссов,

5) управление рисками,

6) ориентация на выпуск продукта в срок,

7) разбиение больших проектов на управляемые части,

8) ежедневная сборка продукта,

9) контроль “снизу-вверх”.

 

Выпуск версий

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

 

Преимущества последовательного выпуска версий продукта:

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

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

3) Ограниченный круг решаемых вопросов: выпуск версий позволяет всегда иметь дело с относительно компактным кругом вопросов и решать эти проблемы на стадии выпуска очередной версии.

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

5) Свобода и гибкость: выпуск версий дает группе больше свободы в выборе приоритетов и придает дополнительную гибкость процессу проектирования, позволяя своевременно реагировать на изменение бизнес-требований.

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

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

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

 

Планирование процесса

 

Неопределенность и непредсказуемость неизбежны. Следовательно план проекта должен учитывать появление непредсказуемых факторов. Рекомендуется два подхода: резерв времени и планирование на основе рисков.

 

Резерв времени

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

 

Планирование с учетом рисков

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

1) он стимулирует раннее создание прототипов, проверяющих корректность концепций,

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

3) позволяет расставить приоритеты на основе технических и бизнес-рисков,

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

5) в случае несоблюдения даты выпуска позволяет быстро выяснить причины и найти необходимые компромиссы,

6) выявление рисков, наиболее опасных для проекта, позволяет достичь понимания с заказчиком.

 

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

 

Поиск компромиссов

 

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

 

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

 

	Оптимизация	Ограничения	Как получится
Ресурсы		+
Дата выпуска	+
Характеристики			+

 

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

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

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

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

 

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