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

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

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

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

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

• "Можно задать новый тег или выбрать существующий из списка"
• "На сообщение может быть задано несколько тегов"
• "Теги сообщений образуют облако тегов"
• "Облако тегов доступно на любой странице блога".

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

Все это хорошо известные вещи, с историями пользователей мы все работаем далеко не первый год.

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

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

Получаем примерно такую структуру требований:

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

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

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

Давайте посмотрим на различия в приведенных примерах истории пользователя и эпика:

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

Mike Cohn, наиболее влиятельный в Agile сообществе гуру историй пользователей, предлагает описывать эпики по тому же шаблону, что и истории пользователей, как в приведенном выше примере).

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

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

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

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

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

Требование – это возможность, которой должен обладать продукт или что-то, что продукт должен делать для удовлетворения потребностей потребителя.

Функция – это набор взаимосвязанных требований, которые позволяют пользователю достичь бизнес-цели или удовлетворить бизнес-потребность.

И сразу пример (из той же статьи):

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

Для данного проекта вот пример функции: "Заказ за один шаг".

Вот несколько требований, связанных с этой функцией:

• пользователь должен иметь возможность включить функцию заказа за один шаг в своем аккаунте;
• пользователь должен иметь возможность выключить функцию заказа за один шаг в своем аккаунте;
• пользователь должен иметь возможность заказать книги всего за один шаг;
• …
• пользователь должен иметь возможность отменить заказ в течение 30 минут после осуществления заказа."

В системе управления проектами DEVPROM пожелания пользователей (user stories) так же группируются по продуктовым функциям (это одна из опций методологии проекта), и далее, уже в процессе работы аналитиков, превращаются в требования.

Такая группировка пожеланий чрезвычайно удобна при работе менеджера продукта (Product Owner, Product Manager) с беклогом разрабатываемого продукта (Product Backlog), позволяя сегментировать большой список пожеланий пользователей, отслеживать состояние реализации каждой функции и планировать выход на рынок тех или иных продуктовых фич к нужному сроку.

Если честно, более удобного инструмента для работы менеджера продукта с продуктовым беклогом лично я не встречал.

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

А какими инструментами для управления продуктами пользуетесь вы? Excel не в счет :)

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

Водопадная модель

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

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

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

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

Итерационная модель

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

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

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

Отсутствие формализованных требований

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

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

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

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

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

Анализ бизнес потребностей

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

При работе над Agile проектами часто возникает вопрос, как организовать процесс сбора требований к разрабатываемой системе.

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

Кстати, когда-то давно, 6 лет назад, мы еще не знали про Scrum, но уже работали по такой же схеме :)

Как можно здесь организовать работу аналитика? Очень просто - включать в журнал пожелания (product backlog) отдельные пожелания по сбору требований (в DEVPROM их можно отмечать тегом Аналитика, для быстрого доступа). Эти пожелания живут обычной жизнью и так же приоритезируются, как и остальные пожелания.

При планировании очередной итерации в нее включаются как пожелания на девелопмент, так и пожелания на сбор аналитики для следующего функционала.

Таким образом, к началу новой итерации, разработчики будут иметь полное описание требуемого функционала, подготовленное для них аналитиком.

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

Согласитесь, нет ничего приятнее для proxy product оунера, чем одним кликом посмотреть все вопросы, требующие обсуждения с заказчиком, а так же их важность для команды (приоритеты).

P.S. В проекте может выделенного аналитика не быть - тогда его место займет команда. Но об этом в одном из следующих постов про сбор требований в Agile проектах.