В мире Agile основным элементом требований принято считать истории пользователей (user stories, пожелания).
В классическом Скрам, (таком, о котором говорят его создатели), не найти ни спецификаций, ни описания вариантов использования (use cases), ни, тем более, документов с пугающим словом ТЗ.
Вся работа по проекту построена вокруг небольших по размеру, понятных каждому участнику проекта пожеланий, которые легко оцениваются, легко обсуждаются с заказчиком и которые можно реализовать в рамках короткой итерации продолжительностью одну-две недели.
"Как автор блога, я могу отмечать свои сообщения произвольными тегами, чтобы сообщения образовывали тематические группы, удобные для поиска информации по интересующей моего читателя тематике" - вот пример классической истории пользователя.
Хорошей практикой является добавление к каждой истории набора приемочных критериев, по которым будет оцениваться правильной реализации истории. Например, приемочные критерии могут быть:
- "Можно задать новый тег или выбрать существующий из списка"
- "На сообщение может быть задано несколько тегов"
- "Теги сообщений образуют облако тегов"
- "Облако тегов доступно на любой странице блога".
В большинстве проектных команд (по крайней мере, в России), приемочные критерии к историям не пишутся - вместо этого перечисленные выше детали истории записываются в ее описание.
Все это хорошо известные вещи, с историями пользователей мы все работаем далеко не первый год.
Но существует еще один термин, гораздо менее распространенный у нас - Epic (эпик). Что же это такое, зачем оно и чем отличается от историй пользователей?
Дело в том, что начиная формировать истории пользователей, т.е. собирать требования к проекту, мы обычно движемся от более общего к более частному - сначала определяемся с концепцией проекта, выделем основные персоны (пользователи системы), формируем перечень основных фич, и дальше эти фичи детализируем на отдельные пожелания.
Получаем примерно такую структуру требований:
- персона (например, автор блога)
- активность в системе (публикация сообщения)
- действие (ввести текст сообщения и опубликовать его; отметить сообщение тегами; сохранить черновик сообщения)
В данном примере активность в системе как раз и есть Epic - то есть по сути, это просто большая история пользователя, отличительной особеностью которой является наличие явной ценности для пользователя (персоны).
"Как автор блога, я должен иметь возможность публиковать свои сообщения в блоге, чтобы заинтересовывать читателей и формировать лояльное сообщество вокруг моего блога" - это пример epic'а.
Давайте посмотрим на различия в приведенных примерах истории пользователя и эпика:
- эпик всегда больший по функциональности, по отношению к истории пользователя, и может даже не умещаться в одной итерации.
- эпик несет в себе явную ценность - сформировать сообщество читателей и комментаторов блога, с которыми можно обсуждать интересующие темы. В случае же с тегами на сообщения - это просто небольшая функциональная возможность сервиса.
Mike Cohn, наиболее влиятельный в Agile сообществе гуру историй пользователей, предлагает описывать эпики по тому же шаблону, что и истории пользователей, как в приведенном выше примере.
В гугл же можно найти ссылки на довольно известные Agile блоги, в которых авторы трактуют epic как просто группу историй, например "Публикация сообщений" - не указывая при этом приобретаемой ценности для пользователя.
На самом деле, конечно, и персона, и эпик, и история пользователя - это всего навсего инструменты, которыми вы можете пользоваться для управления требованиями в своих проектах. И то, как именно вы их применяете, зависит, в первую очередь, от вашего понимания "как это делать правильно".
Используя Devprom в своих проектах, мы записываем Активности в системе (epic) в качестве Функций, в привязке к которым создаются Пожелания (истории пользователей). При этом Персоны - это просто теги ("Блоггер Иванов"), по которым легко можно получить срез всей требуемой этой персоне функциональности.
Даже если ваш заказчик находится далеко, просто дайте ему ссылку на журнал пожеланий продукта в Devprom - и он с удовольствием обдумает небольшие, быстрые для прочтения и восприятия пожелания и дополнит их, обсудит с вами в комментариях или отметит себе отдельным тегом "уточнить".
Комментариев нет:
Отправить комментарий