Юзер стори как пишется

Статья будет полезная 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? Для чего она нужна? И как “рассказать” правильную историю?

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

Первое знакомство с маркетингом началось с того, что любой продукт, который мы создаем начинается с потребности. У каждого из нас есть разные потребности: кушать, ходить в туалет, красиво одеваться, получать социальное признание и не только. Под каждую из этих потребностей создаются продукты (товары, услуги), которые решают так называемую “внутреннюю боль”.

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

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

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

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

Какие задачи решает user story

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

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

Как писать user story

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

Я как <тип пользователя>, хочу <действие>, потому что <причина>

По существу, чтобы заполнить форму, вам необходимо:

• определить тот тип пользователей, который вас интересует (как правило, это ваша целевая аудитория)
• понять те действия, которые нужны пользователям
• выяснить почему именно эти действия нужны

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

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

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

Давайте перейдем к конкретным примерам и поймем как же это работает.

–

Простите, что прерываю чтение. Присоединяйтесь к моему telegram канал. Свежие анонсы статей, развитие digital продуктов и growth hack, там все. Жду вас! Продолжаем…

–

Пример истории пользователя: эмоджи

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

Понимаю, как тяжело это представить…

И вот все бы ничего, да видите вы, что время, которое проводят пользователя а вашей платформе, начинает сокращаться. Если раньше в среднем за день человек проводил у вас час, то сейчас это уже 52 минуты. “В чем дело?”, – подумаете вы. Проведете опрос, поговорите с пользователями, в конце концов спросите совет у друзей и тут станет понятно, что пользователям стало скучно, хочется чего-то новенького.

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

Я как пользователь социальных сетей, хочу чего-то новенького, так как мне скучно.

Поштурмили немного с командой и придумали эмоджи (смайлы или эмоциональные реакции). Докрутили немного user story:

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

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

Если историй много

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

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

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

Не забудьте про измерения

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

Критерии приемки – показатели, которые будут подтверждать результат ваших трудов.

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

Два основных вопроса для критериев приемки:

• Какие показатели будем измерять, чтобы померить эффект от новой фишки?
• Какие показатели считать успешными, а какие нет?

Маленький секрет

Будь то разработка на гибких методологиях или же маркетинговое исследование, в результате которого появились истории пользователя, вам обязательно потребуется тесный контакт с реальными пользователями. Команда, которая делает что-то для определенных людей, должна периодически общаться с этими людьми. Узнавайте у своих пользователей, правильно ли вы поняли их боль, делайте customer development и оттачивайте свой функционал до блеска. В противном случае, вы просто один раз снимите данные с пользователей, “запилите” что-то, а в итоге это будет никому не нужно.

Закругляемся

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

Алексей А.

---

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

• Менеджер по продукту: кто это
• Техническое задание

---

Интересный ролик от компании Under Armor, атмосферное и заряженное видео.

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

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. Записаться на данные курсы можно на нашем сайте.

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