История пользователя (User Story) представляет собой краткое изложение функциональных возможностей, реализация которых необходима для получения конкретным заинтересованным лицом пользы от программного продукта.

Истории пользователя могут быть использованы:

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

Описание

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

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

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

Артефакты

Заголовок (опционально)

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

Описание

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

• роль пользователя или лица [КТО],
• необходимые действия, поведение или функция [ЧТО] и
• выгода или ценность бизнеса, которую получает пользователь, когда история реализуется [ПРИЧИНА, МОТИВ].

Пример использования:

 «Как <роль>, мне необходимо <поведение>, 
 чтобы получить <ценность бизнеса>»

Альтернативный формат, предпочитают те, кто практикует бизнес-анализ в разработке Agile:

 «Для того чтобы получить <ценность бизнеса>, 
 мне как <роли>, необходимо <поведение>»

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

 «Как офицеру безопасности, мне нужно, чтобы только 
 авторизованные пользователи получали доступ к 
 функциональности XYZ, так я могу обеспечить внедрение
 директивы безопасности ABC».

Обсуждение

Истории пользователя служат напоминанием того, что команда должна изучить и понять функцию (feature), описанную в истории и ее значение, которое она будет иметь для клиента. История сама по себе не зафиксирует всё то, что нужно знать о нуждах клиента и информация в истории будет дополняться дальнейшим моделированием по мере разработки.

Критерии приемки

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

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

Критерии приемки часто создаются незадолго до или параллельно с реализацией истории пользователя.

Особенности использования

Преимущества

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

Недостатки

• Этот переговорный подход может поставить в тупик команду, так как у них нет ответов на все вопросы и подробных заготовленных спецификаций.
• Для облегчения оценки, планирования и поставки, многие команды Agile дополняют истории моделями анализа (например, модель данных, бизнес-правила, тесты приемки для пользователей, экранные макеты или прототипы, контекстные диаграммы и диаграммы состояний).
• Большие, громоздкие истории (эпосы) могут быть расплывчатыми и сложными в использовании, если не разбивать их на мелкие истории.
• Истории порождают большее количество историй с помощью декомпозиции, поэтому информация должна быть организована так, чтобы сохранить ее актуальность и значимость.
• Коллекция историй нуждается в управлении (например, при помощи управления бэклогом).
• Истории требуют контекста или «уровня взгляда». Если команда не отследит реализацию истории в обратном направлении (через валидацию) или дополнит их анализом более высокого уровня и артефактами видения (vision), то команда может упустить из виду общую картину.
• Некоторые практикующие специалисты могут запутаться между историями пользователя, вариантами использования и другими техниками описания историй.

--

Усилиями членов IIBA и экспертами сообщества Agile был разработан черновик The Agile Extension of the BABOK, описывающий роль бизнес-аналитика или владельца продукта, а также применяемые техники, в процессе разработки программного обеспечения с использованием методологий, производных от Agile.

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

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

Сертифицированные курсы

Андрей Плетенев. Онлайн курс Agile. SCRUM. Курс включает более 20 уроков с практическими заданиями, которые индивидуально проверяются и комментируются тренером.

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

• Критерии приёмки для требований в Agile
• Дисциплинированная гибкая поставка - Disciplined Agile Delivery
• Проектная документация в Agile
• 5 причин использовать Story Mapping в вашем следующем проекте
• Оценка трудоемкости при планировании релиза в Agile