Управление требованиями : Установление границ и планирование итераций

Установление границ и планирование итераций

Preface

Все шаги, совершаемые до этого, имели общую цель:

• Понять мотивацию заказчика;
• Понять пожелания заказчика и помочь их сформулировать;
• Убедиться в оптимальности и возможности решения;
• Согласовать видение продукта.

Анализ проблем, сбор требований и определение системы НЕ были последовательными шагами. В ходе cross-проверок мы постоянно возвращались на предыдущие шаги, используя результат очередного, как проверку полученного на шаге предыдущем, т.е. картинка на самом деле выглядит не блок схемой – а вот такой “пилой”.

Почему вообще необходимы были эти шаги? Представим себе три ситуации:

• Заказчик является экспертом и в состоянии четко и однозначно специфицировать что он хочет.
• Исполнитель является экспертом и в состоянии четко и однозначно специфицировать что нужно.
• Ни заказчик, ни исполнитель экспертами не являются.

Ни в первом, ни во втором случае особых затруднений по подготовке к проекту нет. Предложенный подход как раз применяется в третьем (самом распространенном) случае – когда ни исполнитель, ни заказчик не являются экспертами и испытывают затруднения. То есть, та полная, логичная и последовательная картинка которая складывается у эксперта за счет опыта, в нашем случае получается за счет формулирования правильных вопросов, согласования удачных формулировок ответов и соблюдения процесса выделение stakeholders->выделение проблем->сбор требований->формулирование продукта. Не надо забывать что, так же, результатом анализа не обязательно является contracting. Так же может быть принято решение отказаться от работы, поскольку ожидания заказчика не могут быть ни изменены, ни удовлетворены. Ввязываться в этом случае в разработку продукта бессмысленно и опасно.

Цель

Процесс согласования границ системы должен быть начат когда понятны и согласованны:

• Проблемы;
• Формулировки требований;
• Видение продукта (features);

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

• Полный перечень features и use-cases которые будет реализованы в ходе проекта;
• Распределение features и use-cases по итерациям;

Определение границ продукта и проекта важно сделать ДО того, как начнутся действительно трудоемкие работы по детализации требований и use-cases. Основная задача – согласовать желания заказчиков с реальными возможностями разработчиков. При выполнении этой работы используются атрибуты features и приоритеты сценариев use-cases, полученные на предыдущих шагах. Согласование границ проекта проводится в рамках обычного общения с заказчиком. Принципиальную важность формальное утверждение установленных границ проекта по окончанию этого этапа. Важно так же что утверждение должно быть сделано уполномоченным лицом заказчика (так, что бы потом заказчик не сказал “ну кого вы слушали”). В дальнейшем, безусловно, границы продукта и проекта могут быть подвержены изменению, но уже в ходе строго формального процесса, который будет рассмотрен позже, когда мы будем говорить об управлении изменениями. Почему важно фиксировать границы? По отношению к проекту всегда есть две противоборствующие стороны:

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

Однако при контрактинге мы достигаем договоренности тем, кто расстаётся со своими деньгами, о том, за что именно и сколько именно он готов платить. Это важный момент, именно поэтому удержание проекта от расползания очень важно в тот момент, когда договоренность что и почем мы делаем достигнута.

Установление границ продукта

В целом, важно выполнение следующих правил, которые позволят избежать “расползания проекта”, но облегчать работу по изменению границ:

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

Шаги установления границ проекта:

• Приоритезировать features. Примерные приоритеты значений атрибутов features при выборе набора следующие (сверху вниз):
  • Важность для заказчика: в первую очередь включаются наиболее важные для заказчика.
  • Приоритет для заказчика: в первую очередь включаются наиболее приоритетные для заказчика.
  • Каков риск того, что исходные требования будут изменяться в дальнейшем: лучше избавится от нестабильных требований.
  • Какова сложность реализации (знаем ли мы как?) и какова трудоемкость реализации (сколько нужно времени/ресурсов?). Сложные и трудоемкие задачи надо согласовывать с бюджетом и сроками проекта, а так же с имеющимися ресурсами. Наличие сложных задач повышает риски проекта, которые следует оговорить при согласовании границ проекта.
• Определить приоритеты use-cases в рамках feature. Наиболее важными являются use-cases, которые:
  • Описывают ключевые (самые важные для процесса работы с продуктом) операции;
  • Описывают наиболее часто используемые операции.

Упрощенно это выглядит так: имеем табличку со списком features и оценкой их стоимости/сроков, сортируем её по важности (от важного к опциональному), приоритету (от “надо быстро” до “подождет”), четкости требований (от “зафиксировали” до “никак не договоримся”) и дальше отсекаем по стоимости/срокам.

Распределение по итерациям

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

• С точки зрения заказчика:
  • Более значимые features для заказчика;
  • Те, которые требуются раньше;
• С точки зрения аналитика:
  • Те, где формулировка не ясна (для того, что бы как можно раньше получить feedbacks).
• С точки зрения архитектора:
  • Те, от которых зависят архитектурные решения (для того, что бы как можно раньше их проверить). Для того, что бы учесть точку зрения архитектора, можно так же ввести атрибуты, заполняемые архитектором, например, степень влияния feature на атрибут.

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

• Постоянно снижались риски связанные с:
  • Неопределенностью требований;
  • Сложностью задач;
  • Трудоемкостью задач;
• Продукт заметно улучшался от итерации к итерации.

Реализация use-cases так же расписывается по итерациям. Важно(!) что к итерациям относятся не use-cases целиком, а конкретные сценарии.