3.4. Фаза «Стабилизация»

Готовя пилотное развертывание, помните, что его главная цель— выявить проблемы производительности и совместимости. Выявленные проблемы надо устранить в следующих выпусках, после чего можно переходить к развертыванию.Функциональные возможности приложения тестируются на стадии «Разработка», а производительность и совместимость — на стадии «Стабилизация». На этой стадии устраняются все найденные проблемы, а также завершается создание всех материалов, необходимых группам эксплуатации и сопровождения. Вообще одна из задач стадии «Стабилизация» — доделать все, что не закончено. Документация, инструкции по установке, окончательный список проблем с рекомендациями для будущих версий, руководство по развертыванию —все эти материалы на стадии «Стабилизация» приобретают окончательный вид. Фаза «Стабилизация» начинается, когда проектная группа переносит основное внимание с разработки на стабилизацию и выпуск продукта, и заканчивается, когда заказчик принимает продукт. Важная особенность этой фазы — участие пользователей в тестировании продукта. Процесс завершается выпуском продукта.

Этап "Выпуск продукта"

Достижение этапа «Выпуск продукта» — главная задача проектной группы. Он свидетельствует о завершении работы над продуктом и готовности к развертыванию. Происходит перераспределение ответственности за продукт — от группы разработки к группе логистики и сопровождения.

Для достижения этапа «Выпуск продукта» необходимы следующие результаты:

• окончательная версия продукта;

• документация к окончательной версии;

• материалы для сопровождения приложения и поддержки пользователей;

• результаты и средства тестирования;

• архивы проекта;

• обзор всех основных этапов проекта.

На этом этапе продукт готов к выпуску и эксплуатации. Этап «Выпуск продукта» свидетельствует о том, что все участники согласны с тем, что:

• продукт стабилен и все известные ошибки устранены;

• продукт принят заказчиком;

• ответственность за сопровождение передается группе логистики и

сопровождения;

• группа начинает работу над следующей версией продукта.

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

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

• выпуск версий продукта;

• постоянно «живущие» документы;

• планирование процесса с учетом неопределенностей;

• поиск компромиссов;

• управление рисками;

• ориентация на выпуск продукта в срок;

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

• ежедневная сборка продукта;

• контроль «снизу — вверх».

4.1.----------------------Выпуск версий

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

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

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

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

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

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

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

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

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

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

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

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

У этого метода есть несколько серьезных достоинств:

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

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

• позволяет расставить приоритеты на основе технических и бизнес рисков;

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

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

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

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

успех любого проекта зависит от равновесия трех важнейших элементов:

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

элементов. В начале проекта взаимосвязь этих элементов довольно туманна.

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

взаимосвязаны. Изменение одной из них влияет на остальные. Понимание и применение этой концепции дает проектной группе мощный инструмент адекватной реакции на изменение требований или условий в ходе проекта.

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

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

• обучаться;• быстро адаптироваться к переменам;• предусматривать изменения;• действовать эффективно.

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

Существует два принципиально разных подхода к управлению

рисками:1)простое реагирование. Большинство групп в качестве метода управления рисками

практикуют реагирование— они так или иначе реагируют на уже возникшую проблему.

2)превентивное управления рисками. Этот подход предполагает наличие продуманного плана и процесса управления рисками до их реализации, то есть до возникновения проблемы. Процесс

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

рисками продолжается до их исчезновения или, если проблема все же возникла, до ее устранения.

4.5------------------Разбиение больших проектов на ряд независимых (управляемых) частей

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

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

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

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

Подразделение больших проектов на компактные составляющие:

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

• приносит удовлетворение от завершения промежуточных проектов, избавляя от ощущения безысходности, которое появляется у разработчиков больших проектов;

• вовремя сигнализирует о проблемах, поскольку завершение отдельных проектов служит промежуточными этапами большого проекта; если сдача какого-то проекта задерживается, группа имеет возможность скорректировать ход проекта в целом;

• повышает качество конечного продукта, поскольку каждый внутренний проект проходит отдельный контроль качества;

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

4.7.------------Принцип ежедневной сборки.

Некоторые проектные группы практикуют ежедневную сборку приложения с последующей проверкой работоспособности исполняемого модуля. Такая проверка очень важна— без нее ежедневная сборка приложения не имеет смысла.

Ежедневная сборка имеет несколько важных достоинств:

• минимизирует риски, связанные с интеграцией кода — при ежедневной сборке проблемы этого сорта выявляются на ранней стадии, что позволяет вовремя отладить модуль, вызвавший проблему, или изменить соответствующее проектное решение;

• упрощает поиск причин проблемы — при таком подходе не только проще выявить некорректный код, но и выяснить, что и когда случилось с продуктом, прежде чем он перестал работать;

• снижает риск падения качества

4.8.----------Принцип планирование «снизу — вверх»

Работу должны планировать те, кто ее делает. Такой подход:

• повышает точность оценок, поскольку в этом случае они основаны на опыте конкретного разработчика, уже решавшего подобные задачи, а не взяты «с потолка» руководителем;

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

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