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

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

Хорошая новость — есть лучший способ! Они называются корнишонами, но, в отличие от огурца, они здесь не для того, чтобы испортить вам жизнь. (Если только вы не любитель огурцов, я полагаю!) 🥒

TL;DR

Если вы торопитесь, то вот краткое описание (хотя я рекомендую вам продолжить чтение, чтобы получить доступ к шаблонам)

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

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

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

Главное слово здесь — пользователь, т.е. история пользователя ставит в центр внимания пользователя, а не продукт.

История пользователя обычно фокусируется на трех областях:

• В качестве(кого)
• Я хочу(что)
• Чтобы(почему)

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

Кто: Использование персон для составления пользовательских историй

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

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

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

Что: Взаимодействие с пользовательскими историями

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

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

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

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

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

Возвращаясь к нашему предыдущему примеру ввода паролей:

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

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

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

Введите шаблон истории пользователя Gherkin

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

1. Scenario — поведение, которое вы собираетесь описать
2. Given — начальное состояние сценария
3. When — конкретное действие, которое совершает пользователь
4. Then — проверяемый результат, обычно вызванный действием в When
5. And — при необходимости продолжает любую из трех других операций

Возьмем описанный ранее сценарий с паролем:

1. При установке пароля (Scenario),
2. Given что я являюсь администратором учетной записи,
3. WhenЯ ввожу пароль в поле ввода пароля,
4. ThenЯ должен быть предупрежден о требованиях к паролю,
5. And Я должен иметь возможность сразу же вносить исправления,
6. Then что я могу создать защищенную учетную запись.

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

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

Какие способы изложения историй Вам больше всего нравятся? Дайте мне знать! ✌️