В чем разница между историями пользователей и требованиями?

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

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

Я как ______, хочу ______, чтобы я мог ______.

Пример:

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

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

Что такое история пользователя?

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

По сути, история пользователя — это четко сформулированное требование. По нескольким причинам формат истории пользователя стал самым популярным способом выражения требований в Agile:

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

Определите цели пользователя и сразу рассмотрите бизнес-ценность каждого требования в истории пользователя.

Истории пользователей обычно считаются содержащими три элемента — 3C:

• CARD — должна быть написана на карточке или стикере.
• CОбсуждение — получить подробную информацию от владельца продукта (Владелец продукта).
• CПодтверждение — убедиться, что он реализован правильно. Должен соответствовать критериям приемки пользователем.

Формат истории пользователя

Формат истории пользователя следующий:

Я как <роль>, Я хочу <цель>, чтобы <выгода>

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

На уровне проекта:

Как <директор по маркетингу>, Я хочу <улучшить обслуживание клиентов>, чтобы <мы удержим наших клиентов>.

• Создание SMART-целей и INVEST для пользовательских историй
• Тема против эпика против пользовательской истории против задачи
• Что такое DEEP в продуктовом бэклоге?
• Как написать продуктовую визуализацию для проекта Scrum?
• Как использовать доску Scrum для гибкой разработки?
• Кто создает элементы продуктового бэклога или пользовательские истории в Scrum?
• Что такое оценка в гибкой разработке?
• Что такое балл истории в гибкой разработке? Как оценить пользовательскую историю?
• Разделение пользовательских историй — вертикальный срез против горизонтального среза