Должны ли быть написаны пользовательские истории в формате Gerkhin?

Question

Мы пишем истории пользователей в стандартном предписании Как X Я хочу Y, так что Z. Теперь, когда популярность формата BDD и Gerkhin для определения требований, кто-нибудь имеет опыт переключения своих пользовательских историй в формат gerkhin. Считаете ли вы, что проще и интуитивно вызывать требования к бизнесу в этом формате, и получили ли вы какие-либо выгоды в этом?

Answer 1

Вы все еще начинаете каждую функцию с As an X I want a Y so that Z в озерке. Однако это обычно обернуто так, что его преимуществом является его наиболее важный аспект, , например. от https://github.com/cucumber/cucumber/wiki/Gherkin

Feature: Some terse yet descriptive text of what is desired 
In order to realize a named business value /*Z*/ 
As an explicit system actor /*X*/ 
I want to gain some beneficial outcome which furthers the goal /*Y*/ 

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

Для получения более подробной информации имеют хорошее чтение через http://dannorth.net/introducing-bdd/

Answer 2

Я бы продолжил писать «Истории пользователей» в формате «Как ... я хочу ... так ...» и написать критерии приема, используя Gherkin.

Answer 3

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

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

Answer 4

User Stories уже имеют простой определенный формат

As a <Type of User> 
I want <To perform some action> 
So that <I receive some value> 

Формат Огурец (Огурец тип огурца используется для изготовления маринадов), как правило, используется для документируя Acceptance Criteria в программном обеспечении, таком как инструмент автоматизации тестирования огурца. Возьми? Формат огурца, используемый в огурце? Формат Gherkin использует параметр «Дано ... Когда ... Затем ...».

Огурец Формат:

Given <A Certain scenario> 
When <I perform some action> 
Then <I receive some result> 

В моем опыте Acceptance Criteria написан во многих различных форматах из маркированных списков, чтобы разделенная запятая списков и выбег предложений. Таким образом, формат Геркина обеспечивает стандартный способ описания Acceptance Criteria, предотвращая комплекс или состав Acceptance Criteria с его упрощенным форматом.

Использование простого формата Огурца для Acceptance Criteria имеет еще одно интересное преимущество. Поскольку Acceptance Criteria должен быть простым и точным в этом формате, каждая деталь должна быть задокументирована в собственном задании ... Затем ... Затем. Таким образом, когда мы начинаем рассматривать количество выражений Gherkin для конкретного User Story, так как количество операторов выходит за пределы 15 или 20, это знак того, что наш User Story может быть Epic или Feature, маскирующимся как User Story.То есть мы должны нарезать User Story на меньшие User Stories с меньшим количеством ожогов Acceptance Criteria для каждого User Story. См соответствующие сообщения ниже на блоге ProDataMan для получения более подробной информации ...

What makes a good User Story

Acceptance Criteria - Are we done yet?

Definition of Done