в облаке
Попробовать

Совместная приоритезация требований

31.03.2014 16:31

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

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

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

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

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

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

  • Команда создает визуализацию для требования, как только приходит понимание, что у ценности есть визуализация. Не для всех требований требуется визуализация. Например, требование к качеству систем “доступность: 95%” вряд ли будет кандидатом для создания визуализации. Подобное требование будет, скорее всего, представлено в виде карточки требования к уровню качества, прикрепленной к доске планирования проекта. Хорошей практикой считается ограничение визуализации для важных требований.
  • Команда разрабатывает требование путем добавления информации к визуализации и отражения важных изменений в элементах баклога. Например, команда может создать пользовательскую историю типа спайк для того, чтобы получить больше информации о требовании. Подобное действие выполняется регулярно во время сеансов пересмотра бэклога.
  • Команда также определяет уровень зрелости требования. Уровень зрелости – это визуальный индикатор, позволяющий команде сфокусировать работу в нужном направлении. Требование должно пройти процесс созревания от уровня звезды до уровня дороги, во время которого это требование обсуждают, понимают и в итоге разделяют на пользовательские истории и задачи. Как правило, команда вкладывает больше усилий в требования, которые находятся на грани реализации (на уровне дерева), чем на что-то неопределенное в будущем (на уровне звезды), а также в требования, для которых уровень зрелости еще не согласован, то есть когда некоторые заинтересованные лица утверждают, что они все еще находятся на уровне облаков, а другие утверждают, что они уже перешли на уровень дерева.

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

  • Бизнес-Ценность (используйте покер планирования для согласования номера)
  • Подходящее для визуализации (бизнес процесс, взаимодействие пользователя, элемент «сторителлинга» (рассказ историй), статистика, …)
  • Структурное влияние (низкое, среднее, высокое)
  • Соответствие со стратегическим планом разработки (низкое, среднее, высокое).

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

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

--

Автор: Rainer Grau

http://re-magazine.ireb.org/issues/2014-1-learning-to-fly/innovation-arena/

Еще интересные статьи на эту тему: