Главная » UML » Технологический процесс управления   проектом

0

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

Цель

Управление программным проектом — это искусство балансирования между конкурирующими целями, а также управление риском и преодоление ограничений. Результатом процесса должен быть продукт, удовлетворяющий потребностям заказчиков (тех, кто оплачивает счета) и конечных пользователей. О значительной сложности этой задачи свидетельствует, например, то, что 100%-ным успехом может похвастаться лишь очень малое число проектов. Цель технологического процесса управления требованиями, как он определен в Rational Unified Process, — максимально возможное облегчение поставленной задачи путем обеспечения руководства проектом. Этот процесс не является рецептом успеха; это скорее рекомендуемый подход к управлению проектом, заметно повышающий шансы на сдачу успешного программного обеспечения. Существует три основные цели процесса управления проектом.

•       Создать контур для управления преимущественно программными проектами

•       Обеспечить практическое руководство по вопросам планирования, кадрового
обеспечения, реализации проекта и наблюдения за проектом

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

Следует отметить, что данный технологический процесс, как он определен в Rational Unified Process, не охватывает все аспекты управления проектом1. Например, не освещаются следующие вопросы.

•   Управление персоналом: наем, обучение, тренировка

1 Управление проектом подробно рассматривается в книге: Walker Royce. Software Project Management: A Unified Framework. Reading, MA: Addison-Wesley Longman, 1998.

 

•       Управление ресурсами: определение, распределение

•       Управление контрактами с поставщиками и заказчиками

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

•       Планирование жизненного цикла итеративного проекта в целом и планирова
ние отдельных итераций

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

•       Наблюдение за прогрессом итеративного проекта и метрики

Планирование итеративного проекта

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

•       Сколько требуется итераций?

•       Насколько они продолжительны?

•    Как определить содержание и цели итерации?
м   Как отследить прогресс итерации?

К целям планирования проекта относятся следующие.

•    Распределение задач и обязанностей в команде

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

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

Два уровня планов

Известны многочисленные претенциозные, но обреченные на провал попытки подробнейшего планирования крупных программных проектов (от начала и до конца) — как планируется строительство небоскреба. Виды деятельности и задачи сотрудников точно определялись и заблаговременно расписывались по дням (и это при общем объеме работ, рассчитанном на месяцы или годы!). Автор лично видел эти графики Гантта и логические сети видов деятельности, которые полностью покрывали стены нескольких комнат и приемных. Чтобы такие планы были реалистичными, нужно четко представлять, что должно быть сделано; должны быть стабильными требования и архитектура; кроме того, должна существовать подобная система, из которой можно позаимствовать подробную структуру декомпозиции работ (work breakdown structure — WBS).

С другой стороны, как можно запланировать программирование сотрудником Джо модуля GGART на 37-ю неделю, если заранее неизвестно даже о существовании этого модуля?

Данный подход оправдал себя в промышленности, где декомпозиция работ более ИЛИ менее стандартна и устойчива, а распределение заданий предопределено, по-

 

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

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

•       крупнозернистый план фаз;

•       набор мелкозернистых планов: планы итераций.
План фаз

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

•    Даты основных вех

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

Вехи первоначальной работоспособности (конец фазы построения; выпущена первая бета-версия)

Вехи выпуска продукта (конец фазы развертывания и жизненного цикла в целом)

•    Схема кадрового обеспечения: какие ресурсы нужны в процессе развития проекта

•    Даты второстепенных вех:, конец каждой итерации и ее основная цель (если она
известна)

План должен создаваться в начале фазы исследования и обновляться по мере необходимости. Для описания плана обычно требуется не более одной-двух страниц. Сам план относится к документ)’ видения и нужен для определения области действия проекта и предположений, сделанных в процессе его развития (см. главу 9).

План итерации

План итерации— это мелкозернистый план, который должен создаваться для каждой итерации. Как правило, в каждый момент времени "активны" два плана итерации.

•       Текущий план итерации (план текущей итерации), используемый для наблюде
ния за прогрессом проекта

•       Следующий план итерации (план следующей итерации), создаваемый во второй
половине текущей итерации, причем к концу итерации он должен быть завершен

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

Представить план итерации можно как окно, перемещающееся по плану фаз и действующее как лупа (рис. 7.1).

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

По теме:

  • Комментарии