Как пишется user story

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

Содержание:

Вводная информация о User Stories

Что такое User Stories

Сейчас User Stories являются одним из главных приемов работы бизнес-аналитиков и Product Owner. Бизнес-стейкхолдеры рассказывают эти истории, чтобы показать команде разработки суть и ценность задачи, которую надо реализовать. Они короткие, написаны деловым языком и поэтому понятны всем заинтересованным лицам проекта. 

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

В качестве первого ответа приведем «официальное» определение из книги М. Кона «Пользовательские истории: гибкая методология разработки ПО».

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

Такое определение не помогает разобраться в сути приема и его распространенности среди пользователей.  Неужели главное  —  это записи или то, что детали должны уточняться? Думаю, нет. Поэтому я не бросил копания и начал смотреть другие источники. Множество сайтов предлагает такое определение:

User Story  —  это короткая запись сути задачи в формате «As a … I want to … so that I can …». 

Этот ответ тоже не удовлетворил моё любопытство. Такое определение ставит во главу угла формат. Ведь User Story может существовать и без какой-то части (As a user, I want to save data) и быть написанной без обсуждения интровертным продакт-овнером. Но самое главное — об этом будет ниже — User Story может быть написана по совершенно иному формату!

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

User Story  —  это приём записи требований, который помогает команде разработки понять нужду клиента и после обсуждения выбрать, описать и утвердить то решение, которое удовлетворит эту нужду. 

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

Очень важно отметить, что история и ее ценность может быть направлена не только на какую-то группу пользователей. Она может быть направлена на команду разработки (обновить компонент, добавить компонент, переделать код…), Product Owner или представителей бизнеса.

Далее в статье я использую однострочные примеры пользовательских историй: «Как Х, я хочу Y, чтобы Z«. Тем не менее, многие аналитики использую другой подход, который считается даже более каноничным.

Так, истории пишутся в три строки:

Как Х,
Я хочу Y,
Чтобы Z.

Job Stories

В целом Job Stories — схожая с US техника. Можно назвать их приёмом-субститутом, ведь обычно они не используются вместе и выполняют максимально похожую функцию. Job Stories представляют требование в виде действия, которое выполняет пользователь. Они не описывают саму функцию, а лишь концентрируют внимание команды на потребности.

Job Stories концентрируются на психологической части фичи, на эмоциях, тревогах и прочем, что может возникнуть во время использования функции.

«Тело» JS делится на три части:

• Situation: дает контекст обо всей JS, который помогает dev-команде придумать возможное решение.

• Motivation: описывает невидимую руку, которая ведет юзера к использованию данной функции. 

• Expected Outcome: описывает, что получит юзер после использования функции.

Job Stories могут писаться по двум форматам:

1. В одну строку:
   When X  I want to Y so I can Z» или «When X, actor is Y so that Z.

2. В три строки:
   When X
   I want to Y
   So I can Z.

Пример:

When I want to withdraw money from my bank account, I want to know I have enough money in my account to withdraw some now so that I can go out to dinner with my friends.

Вопросы, которые следует задавать во время написания стори

Во время написания истории для аналитика важен не только её текст, но и то содержание — ценность, проблема — которая описывается этим текстом. Чтобы написать историю, которая сможет решить проблему пользователя, аналитику надо лучше понять пользователя и задать себе следующие вопросы.

• Решает ли это настоящую проблему юзера?

• Есть ли у такого решения какие-либо side effects? Влияет ли это на продукт в целом?

• Какие последствия от такого решения?

Вопросы можно задать и стейкхолдерам. Например, первый вопрос имеет смысл адресовать Product Owner в команде которого вы работае. А второй и третий — самой команде разработки, они наверняка смогут указать на какие-то подводные камни.

А при работе с другими стейкхолдерами и выяснении первопричин нужды у них аналитик может использовать знаменитый приём «5 почему?».

Три С в User Story

Первое определение говорит о коммуникации и карточках, но не упоминает согласие. Эти три понятия образуют «the 3 C’s of User Stories».

• Card  —  по задумке автора метода истории пишутся на физических карточках. В реальности они пишутся в Jira и Confluence, поэтому мы не так ограничены в детальности.

• Conversation  —  каждая стори — это множество митингов вокруг нее, которые и направлены на понимание деталей.

• Confirmation  — перед началом работы клиент дает согласие на данное решение, а команда полностью уверена в выполнимости решения.

User Personas

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

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

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

Наиболее важными деталями персонажа являются его имя, место работы (роль  в системе), место проживания. Причём имя и роль в будущем могут использоваться и при написании историй: 

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

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

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

Не стоит забывать и об еще одной важной детали. Персонажи не могут «гулять» из продукта в продукт, но человек, который создаёт их описание, может обращаться к давно созданным образам как за вдохновением, так и за шаблоном описания.

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

Что же в сухой практике использования User Personas?

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

Отрицательный персонаж

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

Например.

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

Ключевой персонаж

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

Например.

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

INVEST

По критериям INVEST мы можем судить, хорошо ли написана User Story и можно ли над ней работать.

I — Independent — Независимый

Следует избегать зависимости между историями, так как иногда это приводит к проблемам во время имплементации. (пример: задача А не может быть реализована без задачи Б, однако задача А — очень важна, а Б лишь желательно иметь в готовом продукте).

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

Пример.

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

N — Negotiable — Обсуждаемый

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

V — Valuable — Ценный

Каждая User Story должна нести пользу как пользователю, так и продукту, а описание должно создаваться так, чтобы ценность была наиболее очевидна. Так команда разработки будет понимать, зачем это нужно реализовывать.

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

E — Estimable — Оцениваемый

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

• история слишком большая;

• в описании недостаточно данных;

• разработчику нужно больше опыта.

Однако подробнее об оценках поговорим в отделе “Оценка историй”.

S — Small — Компактный

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

T — Testable — Тестируемый

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

Однако не стоит забывать, что стоит писать истории так, чтобы QA-команда могла понять, какие кейсы и сценарии ей тестировать. Для создания этого понимания аналитику требований следует пользоваться критериями приемки и описанием сценариев по Gherkin. Подробнее об этих приемах можно прочитать в разделе “Как добавить деталей к истории”.

Как добавить деталей к истории?

Очень важно понимать, что когда работа над «телом» стори закончена, начинается работа над деталями, которые и помогут команде понять, что надо реализовать. Среди способов добавить детали самыми знаменитыми являются Acceptance Criteria и сценарии по Gherkin.

Acceptance Criteria

Что такое АС

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

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

Их надо понимать максимально буквально, потому что это те критерии по которым мы понимаем, выполнена история или нет.

Для чего нужны

1. Показывают фичу с точки зрения конечного юзера.

2. Для понимания задач бизнеса.

3. Достижения консенсуса с бизнесом относительно какой-то стори.

4. Служат базой для тестов.

5. Помогают эстимировать стори.

Правила написания

1. Мы пишем их не в форме should, а в настоящем времени (суть в том, что человек читает и видит, какими «способностями» обладает юзер или система).

2. Должны быть проверяемы. -> pass/fail result прописан четко.

3. Должны быть измеримы.

4. Пишутся ДО работы над задачей.

5. Включают функциональные и нефункциональные критерии.

6. Содержат примеры.

   1. Пользователь может выбрать цвет. Пример: есть дропдаун с цветами.

7. Не слишком узкие (привязаны к одному юз-кейсу-примеру) и не слишком широкие (понятно где сделано и как работает).

8. Не содержат технического арго.

Что делать, когда надо выбрать одно из нескольких решений?

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

Пример.

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

1. Ресторан должен быть итальянским.
2. Ресторан должен быть должен подавать вегетарианские блюда.
3. В ресторане играет живая испанская гитара.

Gherkin

Gherkin — это способ описания сценариев использования систем, который понятен разработчикам, тестировщикам, бизнесу. Он строится по строгому синтаксису и потому позволяет «обходить» многие вольности естественного языка.

Эти сценарии используются чаще всего для описания критериев приёмки и могут стать отличным помощником для автоматизации тестирования. Их большим минусом является нечитабельность, ведь сценарии представляют из себя длинные тексты, в то время как АС — это чаще всего 1-2 строчки текста.

Пример:

Scenario: Dr Bill posts to his own blog.
GIVEN I am logged in as Dr Bill
WHEN I try to post to my blog
THEN I should see "Your article was published"

Базовый синтаксис Gherkin

• Given — это тоже самое, что Precondition в Use Case. То, что должно быть выполнено перед началом сценария.

• When — то, что приводит в действие систему; главная суть этого юзкейса.

• Then — то, что должно произойти в конце юзкейса.

• And — для усложнения сценария вместе с given, when, then. Считается плохим тоном перегружать сценарий большим количеством and-конструкций, показывает, что в нем слишком много деталей.

• But — используется с Then и указывает на то, что не должно случиться как итог юзкейса.

• Feature — объединение множества сценариев в одну функцию. Включает сторю, АС и сценарии этой стори.

• Background — устанавливает precondition сразу для всех сценариев, чтобы не переписывать.

• Scenario Outline / Examples — используются вместе, чтобы скомбинировать несколько сценариев, где попадаются разные сообщения.

Пример:

1) Пишется сценарий-скелет.

Scenario Outline: Dr Bill posts to his own blog.
Given I Have published <number of blogs>
When  I try to post a new blog
Then I should see <message> 

2) Создается таблица с примерами.

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

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

• Steps — это Given, When, Then в виде нумерованных шагов.

Короткий отзыв об использовании Gherkin

Сложно сделать однозначный вывод относительно полезности Gherkin. Я много раз пытался начать постоянно использовать его на проекте. Gherkin отлично подходит для описания сложных сценариев с ветвлением, вариантами. Тем не менее, этот способ не вызвал положительные отзывы со стороны (вообще не вызвал) команды разработки или тестирования. Получается так, что балом в «деталях» к историям правят критерии приёмки — именно на них команда смотрит чаще всего во время оценки и изучения задач.

Болезни плохих пользовательских историй

Как не все фломастеры красные, так и не все пользовательские истории хорошие. Существует несколько типичных черт, которые характерны плохим историям. Давайте рассмотрим наиболее распространенные из них. 

Слишком много информации про функционал в “So that …”

“So that” — это часть про ценность истории, а не функции, которые будут в её рамках реализованы.

Антипример.

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

Потенциальная проблема из этой истории в том, что команда видит “заказ сохранялся где-то”, то на этом и заканчивает рассмотрение истории, эстимацию, так как думает, что задача-то и не очень сложная, а ведь тут так много функционала!

Пример возможного решения.

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

Мы расширили часть “I want…”, чтобы каждая “хотелка” из третьей части истории была соотнесена с функцией из второй части. Так команда точно увидит, что задача не такая простая и там есть над чем подумать.Но даже такая история не становится хорошей, ведь кто угодно замучается читать такой длинный “исторический роман”.

“Исторический” роман

Истории должны быть короткими. В идеале они должны помещаться на канцелярский стикер, который должен клеиться на реальную доску.

Антипример.

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

Как поступить с такой большой историей? Её следует разделить на несколько!

Пример.

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

Как посетитель кафе, я хочу видеть чеки, чтобы я сравнивать их.

Слишком конкретные

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

Антипример.

Как посетитель ресторана, я хочу, чтобы разные виды продуктов были обозначены разными цветами (мясо — #FF0000, крупы — #A52AFA, овощи —  #808000), чтобы я мог легко различать их.

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

Пример.

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

1. Для мяса используется цвет #FF0000.
2. Для круп используется цвет #A52AFA.
3. Для овощей используется цвет #808000.

“Хочу делать, чтобы делать”

Одной из распространенных хворей историй является  главной болезнью плохой пользовательской истории автор считает истории “хочу Х чтобы Х”.

Антипример:

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

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

Вывод

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

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

Источники

1. When Is a Story Done? Three Criteria to Decide, — Atomic Object. URL: https://medium.com/@atomicobject/when-is-a-story-done-three-criteria-to-decide-1979c7edd1fe

2. What is Acceptance and Evaluation Criteria in the context of Business Analysis?, — Business Analysis Excellence. URL: https://business-analysis-excellence.com/acceptance-evaluation-criteria-context-business-analysis/#:~:text=In%20the%20case%20of%20a,’%20or%20’a%20fail

3. Gherkin for Business Analysts, — Hewitt, Ryan. URL: https://www.modernanalyst.com/Resources/Articles/tabid/115/ID/3810/Gherkin-for-Business-Analysts.aspx

4. Agile Extension to BABOK, — IIBA.

5. Business Analysis Body Of Knowledge, — IIBA.

6. 10.1 Acceptance and Evaluation Criteria. URL: https://www.slideshare.net/maddyiscrazy/101-acceptance-and-evaluation-criteria

7. 7 Tips for Writing Acceptance Criteria with Examples, — Prasad, Durga. URL:  https://agileforgrowth.com/blog/acceptance-criteria-checklist/

8. Identifying and Improving Bad User Stories, — Suscheck, Charles; Fuqua, Andrew. URL: https://www.agileconnection.com/article/identifying-and-improving-bad-user-stories

9. Разработка требований к программному обеспечению, — Вигерс, Карл.

10. Пользовательские истории гибкая разработка программного обеспечения, — Кон, М.

11. Пользовательские истории. Искусство гибкой разработки ПО, — Паттон, Дж.

12. Психбольница в руках пациентов, — Купер, А.

• Определение
• Общий шаблон
• Чем отличается от спецификации и юз-кейса
• Как написать юзер-стори
• Несколько практических советов
• Мнемоника: запомни слово INVEST
• Главное

Что это

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-критерии.

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

---

Что такое пользовательские истории и их значение для разработки

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

Прежде чем рассказать о структуре юзер стори, важно понять, для чего они вообще нужны и по каким правилам работают. Отвечаем — многие топовые компании по разработке ПО, игр или приложений работают по методике Scrum, которая основывается на образе мышления Agile.

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

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

Agile-разработка в целом — это все этапы разработки по порядку. Каждый этап перетекает в другой, и так по кругу. Наглядно это выглядит так:

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

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

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

Инкремент — это уже готовый продукт по итогам каждого спринта, обычно он демонстрируется на митапах внутри команды.

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

---

Зачем нужны юзер стори

Пользовательские истории, как уже сказали, много значат для отдела разработки и выпуска удачного продукта. Поэтому их нужно создавать вдумчиво и кропотливо, но при этом понятно и просто. Разберем, насколько вообще важны юзер стори — для этого рассмотрим их преимущества.

Помогают сосредоточиться на пользователях — несмотря на наличие списков, которые включают все актуальные задачи команды, пользовательские истории помогают их уточнять и сосредотачивать именно на пользователях.

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

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

Увеличивают мотивацию — если команда все делает правильно и в итоге добивается хорошего результата, это мотивирует работать еще лучше и усерднее.

---

Структура пользовательской истории

Ценность юзер стори разобрали — теперь можно подробнее изучить, как они пишутся, и что собой представляет их структура.

Структура юзер стори едина для каждой — она состоит из трех частей:

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

Таким образом, структура приобретает следующий вид:

Как пользователь, я хочу действие, чтобы выгода/цель

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

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

Хватает пары фраз, чтобы написать такую карточку — в ней обозначают, кто целевой клиент, чего он хочет, и какую выгоду получает.

---

Принципы и шаги написания пользовательской истории

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

Принципы написания юзер стори называют INVEST — их разработал опытный программист Билл Уэйк. Давайте изучим их — всего принципов шесть:

• I означает Independent (независимость) — истории должны быть осуществимы, вне зависимости от обстоятельств;
• N означает Negotiable (открытость) — история должна быть открытой для обсуждения, то есть простой и понятной каждому;
• V означает Valuable (ценность) — все заинтересованные люди должны получить ценность от выполнения истории — пользователи, разработчики, владельцы проекта;
• E означает Estimable (оценочность) — история должна подходить для обсуждения и ее оценки в дальнейшем;
• S означает Small (лаконичность) — история должна иметь небольшой размер, в идеале не превышать одного сложноподчиненного предложения с простыми составными частями;
• T означает Testable (тестируемость) — чтобы завершить историю, ее нужно сначала протестировать, и она должна подходить для тестирования.

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

---

Шаг №1: проверьте пользовательские потребности

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

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

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

---

Шаг №2: создайте эпики

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

Это может выглядеть как обычный список из историй пользователей:

«— как пользователь, я хочу яркую обложку приложения, чтобы не терять его из виду на рабочем столе;

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

— как пользователь, я хочу поделиться своим профилем через QR-код, чтобы не тратить свое и чужое время на ручной поиск профиля».

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

---

Шаг №3: создавайте пользовательские истории на основе эпиков

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

Система составления стори наглядно будет выглядеть так:

---

Шаг №4: визуализация пользовательской истории

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

Проще всего визуализировать через такие инструменты, где предусмотрено создание досок и карточек. Например, это может быть привычный всем Trello, за рубежом нередко используют Kanban.

---

Шаг №5: проверьте все истории по критериям приемлемости

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

---

Рекомендации по написанию юзер стори

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

Определяем, «кто» будет вашим пользователем: 

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

Определяем, «что» нужно пользователю:

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

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

---

7 примеров юзер стори и эпиков

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

Пример №1: авторизация в кабинете сайта

Сначала начнем с составления эпика, его основная тема — как быстро авторизоваться в кабинете.

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

• кто — как покупатель;
• что хочет — я хочу быстро зарегистрироваться через Google;
• зачем — чтобы быстрее перейти к покупкам.

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

Следующий пункт каждого эпика — это пояснения к теме. Необязательно включать этот пункт, но для понимания контекста он необходим. Здесь нужно обозначить, с чего вообще решили, что пользователь сталкивается или может столкнуться с этой проблемой. Варианты могут быть такие:

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

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

То есть в этом пункте нужно прямо и описать действия для решения проблемы:

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

Так, эпик приобретет такой вид:

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

---

Пример №2: как сделать меню ресторана в приложении более интересным

Подробный пример с описанием всех шагов был выше — надеемся, что логика ясна.

Поэтому далее будем показывать только то, как выглядит финальный вариант эпика и историй:

---

Пример №3: создание приложения под интернет-магазин косметики

---

Пример №4: как повысить лояльность клиентов через раздел с отзывами

---

Пример №5: улучшить пользовательский интерфейс приложения

---

Пример №6: добавить плейлист в приложение, который можно пополнять через поиск

---

Пример №7: улучшить безопасность приложения банка

Вывод

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

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

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

*запрещенная в РФ организация

22.09.2020

User Story (Пользовательская История) — это краткое, точное и понятное описание функционала продукта или его особенностей, представляющих ценность для пользователя. 

О том, как правильно писать User Stories, будет рассказано в представленной статье.

Что такое User Story и кому она необходима

User Stories составляются с точки зрения потенциального пользователя того и иного продукта и применяются:

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

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

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

Как правильно писать User Story

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

Сбор информации для User Story проводится при помощи количественных и качественных исследований (интервью, опросов, изучения фокус-групп) и определения наиболее актуальных и «больных» потребностей пользователя. Этот процесс может выглядеть как:

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

• оформление рабочих карт или записок, содержащих задачи по написанию User Story;

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

Чтобы правильно написать User Story, необходимо:

• получить ответы от пользователей на заданные им вопросы;

• разбивать крупные истории на несколько небольших (со сроками создания в 1-2 дня) с четким детальным описанием конкретных задач;

• прописывать в User Story критерии приемки для простоты тестирования соответствия готового продукта требованиям пользователей;

• использовать для User Story в дизайне скетчи или наброски. 

ЦРК БИ (ЦЕНТР РАЗВИТИЯ КОМПЕТЕНЦИЙ В БИЗНЕС-ИНФОРМАТИКЕ) НИУ ВШЭ приглашает всех желающих научиться писать User Story. Записаться на данные курсы можно на нашем сайте.

← Назад к списку

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

О чем речь? User Story в переводе с английского означает «пользовательская история». Ее задача – как можно более понятно описать особенности конкретного продукта, его функциональные возможности и ценность для конечного потребителя.

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

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

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

• Что они делают?
• Зачем?
• В чем заключается ценность разработки?

Скачать файл

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

• User Story не перечисляет подробно требования к ресурсу. Повествование делается в общих чертах.
• User Story не может быть слишком длинным документом. Важно, чтобы он был простым для восприятия и понятным любому специалисту, имеющему отношение к разработке.
• UserStory – это текст, который показывает, чем ценно приложение. На реализацию главной функциональности должно уйти всего несколько дней или недель.
• UserStory имеет свою структуру, в ней много списков, в которые легко вносить изменения.
• В начале проекта нет необходимости в детализации юзер стори. Это действие нужно в том случае, если хочется ускорить процесс разработки приложения.
• UserStory не нуждается в поддержке, как только ресурс будет реализован, пользовательская история перестанет быть нужной.

Задачи, решаемые User Story

Сразу отметим, что создание User Story имеет огромную важность, так как решает большое количество задач:

• Рассказывает о потребностях целевой аудитории.
• Оказывает содействие в группировке потребностей на задачи для разработчиков проекта.
• Принимает участие в оценке ресурсов, которые пригодятся в работе.
• Делает контекст задачи максимально понятным для всех участников команды.
• Является базой, на основании которой будет проводиться тестирование с настоящими пользователями.
• Дает возможность правильно расставить приоритеты среди поставленных разработчиками задач.

Этот перечень не окончательный. На самом деле список задач гораздо шире. Кроме того, User Story применяется не только для разработки приложений. Историю следует воспринимать как представление себя в контексте некоторой ситуации. С ее помощью появляется возможность четче понять потребности целевой аудитории.

Преимущества пользовательских историй

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

На этом преимущества не заканчиваются. Остальные приведем ниже:

• Фокус на пользователе. Разработка приложения – это не просто последовательное выполнение дел, а решение проблем целевой аудитории.
• UserStory дает возможность коллективу работать слаженно. Главная задача заключается в определении преимущественного решения для пользователя, а также лучшего способа решения сформулированной задачи.
• Пример удачной UserStory – это документ, который позволяет находить нестандартные решения. С ее помощью разработчики определяют критический и творческий подход к выбору наилучшего пути достижения конечной цели.
  

  

  Читайте также

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

Простой шаблон User Story

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

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

Есть смысл детального рассмотрения шаблона:

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

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

Если говорить простым языком, то пользовательская история – это ответ на 3 вопроса, которые укомплектованы в одно предложение:

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

Чтобы стало понятнее, рассмотрим конкретные примеры:

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

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

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

Критерии INVEST для User Story

INVEST — термин, который используют для их запоминания. По ним можно провести аналитику User Story и сделать вывод, насколько качественно выполнена работа.

• Independent (Независимый)

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

• Negotiable (Обсуждаемый)

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

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

• Valuable (Ценный)

Каждая User Story имеет полезное значение. Польза проявляется не только в отношении конечного потребителя, но и самого продукта. С ее помощью можно четче определить его ценность и понять, для чего нужна реализация.

• Estimable (Оцениваемый)

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

• Small (Компактный)

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

• Testable (Тестируемый)

Любая User Story нуждается в тестировании. Необходимо убедиться, что она действительно имеет что-то такое, что можно реализовать.

7 полезных советов по написанию пользовательской истории

• Пользовательская история должна быть краткой. Если объем больше, чем допустимый, лучше выполнить написание нескольких маленьких UserStory.
• Авторами пользовательской истории должна быть вся команда разработчиков. Так, вы не упустите ценные нюансы и доведете User Story до совершенства.
  

  

  Читайте также

• Не нужно использовать рабочий сленг, если есть возможность. Помните, чем понятнее пользовательская история, тем лучше. Старайтесь писать ее простым языком, это даст возможность понять ее всем, кто задействован в процессе.
• Разработчики должны оценить в истории, насколько сложной будет реализация, и сколько времени будет потрачено на работу.

История должна включать в себя максимально подробное описание потребностей пользователей.

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

7 распространенных ошибок при составлении User Story

• Предположим, что вы написали качественную UserStory, которая полностью отвечает критериям INVEST и успешно прошла тестирование. Вы считаете, что работа по созданию истории выполнена. Но в один момент ваш клиент решил изменить требования. Если вы не внесете изменения, пользы будет мало. Поэтому, даже если результат превзошел все ожидания, корректировки все же нужно сделать.
• Как бы хорошо не была написана история, старайтесь, чтобы она была понятна не только для вас и заказчика. Использование специфических и профессиональных терминов является нежелательным. Также следует избегать аббревиатур и сокращений.
• Полный лист формата А4 – это много для пользовательской истории. Перечитайте ее и подумайте, какие данные лишние?
• Если у продукта несколько типов пользователей, это нужно отразить в истории. Многие разработчики пишут UserStory лишь для одного типа, тем самым не раскрывают полностью ценность продукта.
• Вы перегружаете свой бэклог историями, вследствие чего вам самим тяжело в них разобраться. Есть смысл навести порядок, убрать то, что уже утратило свою актуальность.
• У вас уже реализовано большое количество Story, а вот заказчики не торопятся принимать их. Но ваш успех зависит именно от последних. Поторопите владельцев продукта, если работы будут приняты слишком поздно, у вас не останется времени на редактирование.

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

Итак, User Story – это мощный инструмент, который позволяет создать нужный продукт. При использовании методики обязательно поддерживайте связь со своей командой и клиентами, а также своевременно вносите изменения.

Перевод статьи
«Engineering guide to writing correct User Stories».

Люди, работающие по методологии Agile,
одержимы написанием user stories. И это,
конечно, очень мощный инструмент. Но по
своему опыту могу сказать, что множество
людей пишут их неправильно.

Взгляните на этот пример:

Как пользователь
Я хочу получать webhooks о проблемах на Gitlab
Чтобы я мог помещать все текущие задачи в список

На вид совершенно нормальная user story,
правда? Но на самом деле эта маленькая
история имеет несколько проблем. И если
вы не можете найти в ней как минимум 8
ошибок, вам действительно стоит прочесть
эту статью.

Статья делится на три основные части:

1. Улучшение user story в рамках текущего
   формата.
2. Переписывание user stories с применением
   BDD, чтобы сделать их проверяемыми.
3. Связывание user stories с тестами, исходным
   кодом и документацией.

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

Обнаружение и исправление
проблем

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

User stories имеют тенденцию упускать
некоторые из этих характеристик. Нам
нужно это исправить.

Последовательность в терминах

Желания «Получать webhooks о проблемах»
и «помещать все текущие задачи в список»
как-то связаны между собой? «Проблемы»
и «задачи» это одно и то же или все-таки
нет? Ведь это могут быть как совершенно
разные вещи, так и просто неудачный
побор слов. Как нам это определить?

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

Допустим, в нашем случае после консультаций с экспертами мы обнаружили, что «задачи» и «проблемы» это одно и то же. Теперь нам нужно удалить неправильный термин.

Как пользователь
Я хочу получать webhooks о проблемах на Gitlab
+++Чтобы я мог помещать все текущие проблемы в список
---Чтобы я мог помещать все текущие задачи в список

Прекрасно. Использование
одинаковых слов для одинаковых сущностей
делает наши требования более понятными
и последовательными.

Желания пользователей и ваши
желания это не одно и то же

Когда мы изменили
последнюю строку, я обратил внимание,
что цель пользователя – «помещать все
текущие проблемы в список». Зачем бедный
пользователь хочет составлять списки
проблем? В чем смысл этих действий?
Никакой пользователь ничего подобного
не хочет. Это просто некорректное
требование.

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

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

Как пользователь
Я хочу получать webhooks о проблемах на Gitlab
+++Чтобы я мог просматривать и отслеживать прогресс по 
этим проблемам
---Чтобы я мог помещать все текущие проблемы в список

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

Убираем технические детали

Вам когда-нибудь
доводилось встречать человека, который
хотел бы именно «получать webhooks о
проблемах»? Это никому не нужно. В данном
случае мы тоже смешиваем разные вещи.

Есть четкое разделение
между целями пользователя и техническими
способами их достижения. И «получать
webhooks о проблемах» это определенно детали
реализации. Завтра webhooks могут измениться
на WebSockets, всплывающие уведомления и
т. п. А цели пользователя при этом
останутся прежними.

Как пользователь
+++Я хочу иметь обновляемую информацию о проблемах на Gitlab
---Я хочу получать webhooks о проблемах на Gitlab
Чтобы я мог просматривать и отслеживать прогресс по этим 
проблемам

Видите? Теперь осталась
только важная информация, без деталей
реализации.

Уточнение ролей

Из контекста довольно
понятно, что речь идет о каком-то
инструменте, связанном с разработкой.
Мы используем Gitlab и issue management. Так что
не сложно догадаться, что у нас есть
разные категории пользователей: джуниоры,
мидлы и сеньоры. Возможно, менеджеры
проектов, а также другие люди.

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

О каких пользователях
идет речь в данной конкретной user story?
Будут ли джуниоры точно так же отслеживать
прогресс, как менеджеры проектов и
архитекторы? Очевидно, что нет.

+++Как архитектор
---Как пользователь
Я хочу иметь обновляемую информацию о проблемах на Gitlab
Чтобы я мог просматривать и отслеживать прогресс 
по этим проблемам

После обдумывания
вариантов мы можем разделить user stories по
ролям пользователей. А это позволяет
нам более тонко контролировать
поставляемый функционалом и то, кому
мы этот функционал поставляем.

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

Делаем user stories проверяемыми

Проблема с приведенной
выше user story в том, что она по-прежнему не
проверяемая. Как нам проверить, что эта
история (на данный момент или все еще)
является рабочей для наших пользователей?
Мы не можем этого сделать.

У нас нет четкой связи
между этой user story и нашими тестами. Было
бы прекрасно, если бы можно было писать
user stories в качестве тестов…

Погодите, но ведь это возможно! Для этого у нас есть BDD («разработка через поведение») и язык gherkin. Именно для этого BDD и создавалась изначально. Это означает, что для того чтобы чтобы сделать нашу user story проверяемой, мы можем переписать ее в формате gherkin.

История: Отслеживание прогресса проблем
    Как архитектор
    Я хочу иметь обновляемую информацию относительно проблем
    на Gitlab
    Чтобы я мог просматривать и отслеживать прогресс по этим
    проблемам
    Сценарий: получен новый валидный webhook о проблеме
        Дано: webhook о проблеме валидный
        Когда он получен
        Тогда создана новая проблема

Вот теперь user story
является проверяемой. Мы можем использовать
ее в качестве теста и отслеживать ее
статус. Более того, теперь у нас есть
связь между нашими требованиями высшего
порядка и деталями реализации, а это
позволяет нам понять, как конкретно мы
будем выполнять требования. Обратите
внимание: мы не подменяли требования
бизнеса деталями реализации, мы их
дополнили этими деталями.

Обнаружение неполноты

Когда мы привыкли
писать наши user stories на gherkin, мы начали
писать сценарии для наших user stories. И мы
обнаружили, что для каждой user story может
быть несколько сценариев.

Двайте рассмотрим
первый написанный нами сценарий: «получен
новый валидный webhook о проблеме».
Погодите, но что происходит, когда мы
получаем невалидный webhook? Должны мы
сохранять эту проблему или нет? Может,
кроме сохранения проблемы нужно сделать
что-то дополнительно?

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

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

Теперь мы можем добавить
еще два сценария, чтобы сделать нашу
user story полной.

История: Отслеживание прогресса проблем
    Как архитектор
    Я хочу иметь обновляемую информацию относительно проблем
    на Gitlab
    Чтобы я мог просматривать и отслеживать прогресс 
    по этим проблемам
    Сценарий: получен новый валидный webhook о проблеме
        Дано: webhook о проблеме валидный
        И webhook о проблеме аутентифицирован
        Когда он получен
        Тогда создана новая проблема
    Сценарий: получен новый невалидный webhook о проблеме
        Дано: webhook о проблеме невалидный
        Когда он получен
        Тогда проблема не создается
    Сценарий: получен новый валидный неаутентифицированный webhook о проблеме
        Дано: webhook о проблеме валидный
        И webhook о проблеме не-аутентифицирован
        Когда он получен
        Тогда проблема не создается
        И сохраняется дата webhook-а для дальнейшего
        расследования

Мне нравится, что теперь
эта простая user story ощущается как нечто
сложное. Потому что таким образом на
наше обозрение выставляется ее внутренняя
сложность. И мы можем подогнать наш
процесс разработки к этой растущей
сложности.

Упорядочиваем user stories по
степени важности

Сейчас непонятно,
насколько важно для архитекторов
«просматривать и отслеживать прогресс
по проблемам». Это более важно, чем
другие наши user stories? Поскольку это кажется
довольно сложным, может, вместо этого
нам следует заняться чем-то более простым
и вместе с тем более важным?

Расстановка приоритетов
важна для каждого продукта, и игнорировать
ее нельзя. Даже если user stories это
единственный наш способ записи требований.
Существуют разные методы для расстановки
приоритетов в требованиях, но мы
рекомендуем придерживаться метода
MoSCoW. В основе этого простого метода
лежат четыре главных категории: must,
should, could и won’t. Подразумевается, что у нас
в проектной документации будет отдельная
таблица приоритетов всех пользовательских
историй.

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

После обсуждения этой
темы с разными архитекторами, которые
работают с нашим продуктом, мы обнаружили,
что требование в нашей user story это
абсолютный must:

Функционал	Приоритет
Аутентифицированные пользователи должны иметь возможность отсылать приватные сообщения.	Must
Архитекторы должны отслеживать прогресс проблем.	Must
Должны быть уведомления о входящих приватных сообщениях.	Should
Можно было бы поддерживать сообщения нескольких провайдеров.	Could
Зашифрованные приватные сообщения не поддерживаются.	Won’t

Итак, теперь мы можем
изменить название нашей user story, чтобы
обозначить приоритет:

История: Архитекторы должны отслеживать прогресс проблем

Можно даже поставить
гиперссылку на таблицу с приоритетами
требований в файле с user story.

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

Связывание всего воедино

Если не уделять этому
делу достаточно внимания, вы вскоре
утонете в перепутанных user stories, тестах,
исходном коде и документации. По мере
роста вашего проекта станет просто
невозможно сказать, какие части приложения
за какие use-cases бизнеса отвечают. Чтобы
разобраться с этой проблемой, нам нужно
связать все вместе: требования, код,
тесты и документацию. Наша цель –
получить примерно следующее:

Для иллюстрации этого
принципа я использую Python.

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

Обычно я определяю
пакет под названием usecases и собираю в
нем все use-cases, чтобы было легко их
просматривать одновременно. Каждый
файл содержит простой класс (или функцию),
выглядит это так:

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

Таким образом наши
тесты, код и документы будут максимально
связаны. И нам не придется слишком о них
беспокоиться. Можно даже автоматизировать
этот процесс и проверить, все ли классы
внутри usecases/ имеют директиву ..
literalinclude в своей документации.

Этот класс также можно
использовать для тестирования нашей
user story. Таким образом мы свяжем требования,
тесты и собственно логику, реализующую
эту user story.

Готово!

Заключение

Это руководство поможет вам писать лучшие user stories, фокусироваться на нуждах пользователей, поддерживать чистоту кода и максимально использовать один и тот же код для различных (но сходных) целей.