😇
На testengineer.ru мы не размещаем рекламу, но над сайтом регулярно работают несколько человек. Поддержите нас, подписавшись на телеграм-канал "Тестировщик от бога"!
ДомойОбучениеЧто такое user story и как ее писать?

Что такое user story и как ее писать?

Автор

Дата

Категория

User Story переводится с английского как «пользовательская история». Это общее описание функций программы, написанное как бы от имени пользователя. В user-story формулируется, чем функционал приложения ценен для заказчика. 

Само название — user story — указывает, что этот документ имеет формат истории и излагается в повествовательной форме.

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

Шаблон user story

Юзер стори пишется по шаблону «Как [пользователь], я хочу […], чтобы […]». В таком формате поясняется, что именно хочет пользователь или заказчик, и почему.

Рассмотрим этот шаблон подробнее.

  • Пользователь — собирательное название. Если у вас много конечных пользователей, для каждого пишется отдельная юзер стори. Например, если ваш продукт — торговая онлайн-площадка, у вас как минимум будут  user story для покупателя и продавца.
  • «Я хочу…» — в этой части описываются намерения и желания пользователей, то, чего они на самом деле хотят достичь, используя нашу программу. Стоит заострить внимание на том, что здесь не нужно описывать UI, речь идет не о функциях ПО, а о желаниях пользователя.
  • «Чтобы…» — здесь поясняется, как желание из предыдущей части вписывается в общую картину, какую большую проблему нужно решить.

Отличие user story от спецификаций и сценариев использования

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

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

Как писать user story?

Пользовательская история должна быть написана грамотным языком. 

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

  1. Для кого это создается?
  2. Что этот «кто-то» ожидает от системы?
  3. Почему это важно?

Практические советы по написанию user story

  • Лучше написать побольше небольших историй, чем несколько объемных.
  • Писать user story  лучше всей командой, чтобы не пропустить важные для продукта, бизнеса и пользователей вещи.
  • Пользовательскую историю нужно писать простым языком, без рабочего сленга (по возможности). Благодаря этому она будет понятна всем людям, занятым в проекте.
  • Нужно точно описать потребности пользователя.
  • Юзер стори нужно писать так, чтобы по ней можно было тестировать.
  • Код пишется после тестов.
  • В написании  user story не стоит жестко привязываться к каким-то элементам пользовательского интерфейса.
  • В каждой истории должна быть оценка сложности реализации, а также времени, которое потребуется на реализацию.
  • User story должна содержать описание конечного результата.
  • Хорошая user story соответствует модели INVEST.

Модель INVEST

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

  • I – independent. История должна быть независима от других историй.
  • N – negotiable. История обсуждаема, в ней отражается суть, а не детали или конкретные шаги по реализации.
  • V – valuable. История представляет ценность для клиентов и бизнеса.
  • E – estimable. Пригодность для оценки: историю можно оценить по сложности и трудозатратам.
  • S – small. Хорошая история маленькая, ее можно реализовать за одну итерацию.
  • T – testable. История имеет критерии приемки и ее можно протестировать.

Итоги

User story — максимально понятное описание функционала продукта, его особенностей и пользы для конечного пользователя. Польза  user story в том, что она помогает разработчику лучше понять продукт и целевую аудиторию заказчика. Для проверки качества истории используются INVEST-критерии.

Какой была ваша первая зарплата в QA и как вы искали первую работу?

Мега обсуждение в нашем телеграм-канале о поиске первой работы. Обмен опытом и мнения.

1 КОММЕНТАРИЙ

Подписаться
Уведомить о
guest

1 Комментарий
Старые
Новые Популярные
Межтекстовые Отзывы
Посмотреть все комментарии
mary
mary
1 год назад

Жалко, что не хватает реальных примеров. А так спасибо за теорию

$1100*
медианная зарплата в QA в ноябре 2021

*по результатам опроса QA-инженеров в нашем телеграм-канале

Последние публикации

Мы в Telegram

Наш официальный канал
Полезные материалы и тесты
Готовимся к собеседованию
Project- и Product-менеджмент

💬 Telegram-обсуждения

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

Последние комментарии