Требования в Agile: что такое Epic и в чем отличие от User Story?

В мире Agile основным элементом требований принято считать истории пользователей (user stories, пожелания).

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

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

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

Все это хорошо известные вещи, с историями пользователей мы все работаем далеко не первый год.
Но существует еще один термин, гораздо менее распространенный у нас - Epic (эпик). Что же это такое, зачем оно и чем отличается от историй пользователей?

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

Получаем примерно такую структуру требований:
  1. персона (например, автор блога)
  2. активность в системе (публикация сообщения)
  3. действие (ввести текст сообщения и опубликовать его; отметить сообщение тегами; сохранить черновик сообщения)

В данном примере активность в системе как раз и есть Epic - то есть по сути, это просто большая история пользователя, отличительной особеностью которой является наличие явной ценности для пользователя (персоны).

"Как автор блога, я должен иметь возможность публиковать свои сообщения в блоге, чтобы заинтересовывать читателей и формировать лояльное сообщество вокруг моего блога" - это пример epic'а.

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

Mike Cohn, наиболее влиятельный в Agile сообществе гуру историй пользователей, предлагает описывать эпики по тому же шаблону, что и истории пользователей, как в приведенном выше примере.
В гугл же можно найти ссылки на довольно известные Agile блоги, в которых авторы трактуют epic как просто группу историй, например "Публикация сообщений" - не указывая при этом приобретаемой ценности для пользователя.

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

Используя Devprom в своих проектах, мы записываем Активности в системе (epic) в качестве Функций, в привязке к которым создаются Пожелания (истории пользователей). При этом Персоны - это просто теги ("Блоггер Иванов"), по которым легко можно получить срез всей требуемой этой персоне функциональности.


Даже если ваш заказчик находится далеко, просто дайте ему ссылку на журнал пожеланий продукта в Devprom - и он с удовольствием обдумает небольшие, быстрые для прочтения и восприятия пожелания и дополнит их, обсудит с вами в комментариях или отметит себе отдельным тегом "уточнить".

Комментариев нет:

Отправить комментарий