- Определение
- Общий шаблон
- Чем отличается от спецификации и юз-кейса
- Как написать юзер-стори
- Несколько практических советов
- Мнемоника: запомни слово INVEST
- Главное
Что это
User Story переводится с английского как «пользовательская история». Это общее описание функций программы, написанное как бы от имени пользователя. В user-story формулируется, чем функционал приложения ценен для заказчика.
Само название — user story — указывает, что этот документ имеет формат истории и излагается в повествовательной форме.
Ключевой компонент гибкой разработки ПО — фокус на людях. Пользовательская история ставит конечных потребителей в центр всего процесса. В ней не используется технический язык, она должна лишь дать команде контекст. Прочитав user story, члены команды понимают, что именно и зачем они делают, и в чем ценность создаваемого им продукта.
Шаблон user story
Юзер стори пишется по шаблону «Как [пользователь], я хочу […], чтобы […]». В таком формате поясняется, что именно хочет пользователь или заказчик, и почему.
Рассмотрим этот шаблон подробнее.
- Пользователь — собирательное название. Если у вас много конечных пользователей, для каждого пишется отдельная юзер стори. Например, если ваш продукт — торговая онлайн-площадка, у вас как минимум будут user story для покупателя и продавца.
- «Я хочу…» — в этой части описываются намерения и желания пользователей, то, чего они на самом деле хотят достичь, используя нашу программу. Стоит заострить внимание на том, что здесь не нужно описывать UI, речь идет не о функциях ПО, а о желаниях пользователя.
- «Чтобы…» — здесь поясняется, как желание из предыдущей части вписывается в общую картину, какую большую проблему нужно решить.
Отличие user story от спецификаций и сценариев использования
Текст юзер стори поясняет роль и действия пользователя в приложении. Пользовательская история в чем-то заменяет спецификации требований и сценарии использования, но все же отличается от них. Различия небольшие, но существенные:
- user story — не подробное описание требований к приложению, а изложение намерений «в общем»
- пользовательская история недлинная и читабельная, она понятна всем людям, занятым в проекте
- в юзер стори указывается ценная функциональность, которую можно реализовать за несколько дней или недель
- пользовательская история не громоздкая, она организована в списки, а их легко изменить при поступлении новой информации
- в начале проекта user story не детализируется (это делается для ускорения процесса разработки)
- пользовательскую историю не нужно поддерживать, после реализации необходимость в ней отпадает.
Как писать user story?
Пользовательская история должна быть написана грамотным языком.
Когда пишете user story, следует следить за тем, чтобы не скатиться в написание техзадания. Истории пользователей фиксируют только самые важные элементы требований:
- Для кого это создается?
- Что этот «кто-то» ожидает от системы?
- Почему это важно?
Практические советы по написанию 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-критерии.
