Планирование на основе требований на примере xp

Планирование включает следующие работы:

• оценивание,

• планирование версий и итераций.

Оценивание представляет собой определение объема работ в разрезе историй пользователя. Каждая история оценивается в пунктах. Один пункт равен "идеальной" (сорокачасовой) неделе, целиком посвященной программированию. Если оценка лежит в пределах от 1 до 3 пунктов - то он ставится на карточке истории. Если оценка менее 1 - на карточке ставится 0. Это - так называемый "песок". Если оценка превышает 3 пункта - мы имеем дело с "эпопеей". В этом случае карточка помечается, как "split" и подлежит процедуре разделения. Другая стратегия работы с такой карточкой -попытаться вместить ее в оптимальный срок путем исключения декораций. В случае, если история пользователя сложна для экспресс-оценки - необходимо провести исследование или "гвоздь" планирования.

Планирование версий и итераций

Планирование в XP базируется на следующих основных понятиях: производительность, приоритеты, стоимость версии, составление плана версий, составление плана итераций.

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

Ключевую роль в назначении приоритетов играет, безусловно, заказчик. Однако и Разработчик имеет право голоса при отборе историй, которые должны попасть в версию (вопросы архитектуры, ключевой функциональности и т.п.).

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

План версий дает Заказчику начальное понимание стоимости проекта. Эта оценка дает ему возможность отказаться от проекта в начальной его стадии, если сроки и (или) цена являются неприемлемыми.

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

Анализ требований и управление рисками

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

Управление риском - комплекс мероприятий по выявлению, оценке, предотвращению и контролю рисков проекта.

Как пишет К.Вигерс [15.5], "Если что-либо нехорошее уже произошло с вашим проектом, то это - проблема, а не риск… Управление риском означает работу с потенциальной опасностью до того, как она перейдет в кризисную фазу". Менеджеры проектов должны выявлять риск и управлять им, начиная с факторов, связанных с требованиями, в сотрудничестве с представителями Заказчика.

Стратегии и работы по управлению риском

Управление риском включает в себя действия, показанные на рис. 15.1[15.5].

Рис. 15.1.

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

Так, все риски принято делить на прямые (те, на которые Разработчик может так или иначе влиять) и косвенные (независимые от Разработчика) [15.6].

М. Фаулер [15.7]предложил разделить все риски на четыре категории:

• риски, связанные с требованиями,

• технологические риски,

• риски, связанные с квалификацией персонала,

• политические риски.

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

Анализ риска сводится к исследованию и описанию потенциальных последствий конкретных факторов риска для проекта, а также вероятности их проявления.

Определение приоритетов состоит из поиска ответов на два вопроса: насколько вероятно проявление риска в проекте; насколько разрушительны могут быть последствия его проявления.

Обнаруженные риски помещаются в специальный документ - risk list.

Существуют три основные стратегии поведения в отношении рисков:

Предотвращение риска, передача риска, принятие риска.

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

Передача риска - перераспределение работ проекта таким образом, чтобы кто-то другой (Заказчик, партнер и т.п.) отвечал за работу с ним.

Принятие риска обязывает Разработчика "заботиться" о нем. Мероприятия по контролю риска (risk control) включают планирование, разрешение и мониторинг.

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

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

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

¹⁾ http://www.agilealliance.org