Пользовательские истории (User stories)
Last updated
Last updated
Пользовательская история (user story): Высокоуровневое пользовательское или бизнес-требование, обычно использующееся в гибких методологиях разработки программного обеспечения. Обычно состоит из одного или нескольких предложений на разговорном или формальном языке, описывающих функциональность, необходимую пользователю, любые нефункциональные требования и включающих в себя критерии приемки. (ISTQB)
В индустрии разработки ПО слово «требование» определяет нашу цель, что именно нужно клиентам и что заставит нашу компанию развивать свой бизнес. Будь то продуктовая компания, которая производит программные продукты, или сервисная компания, которая предлагает услуги в различных областях программного обеспечения, основной базой для всех из них является требование, а успех определяется тем, насколько хорошо эти требования выполняются. Термин «требование» имеет разные названия в разных методологиях проекта. В Waterfall это называется Requirement/Specification Document, в Agile или SCRUM требования документируются в виде «Epic» и «User Story». В модели Waterfall документы с требованиями представляют собой огромные документы на сотни страниц, поскольку весь продукт реализуется за один этап. Но это не относится к Agile / SCRUM, потому что в этих случаях требования предъявляются к небольшим функциям или фичам, поскольку продукт готовится поэтапно.
Пользовательская история определяет требования к любой функциональности или фиче, в то время как критерии приемки (Acceptance Criteria) определяют критерии готовности (Definition of done) для пользовательской истории или требования.
Пользовательская история - это требование для любой функциональности или фичи, которое записано в 1-2 строки. Пользовательская история обычно является самым простым из возможных требований и касается одной-единственной функции/фичи.
Формат:
Как /роль пользователя или клиента/, я хочу /цель, которую нужно достичь/, чтобы я мог /причина цели/.
Например, “Как пользователь WhatsApp, я хочу, чтобы значок камеры в поле ввода чата позволял захватывать и отправлять изображения, чтобы я мог щелкнуть и поделиться своими фотографиями одновременно со всеми своими друзьями.”
Это стандартный формат, но далеко не обязательный или единственно-возможный. Главное в пользовательской истории - это ценность, которую пользователь получит от функции, т.е. User Story - это приём записи требований, который помогает команде разработки понять нужду клиента и после обсуждения выбрать, описать и утвердить то решение, которое удовлетворит эту нужду.
INVEST
Independent
Negotiable
Valuable
Estimable
Small
Testable
Хорошие пользовательские истории должны быть: независимыми (от других), обсуждаемыми (суть), ценными (для бизнеса), оцениваемыми (по сложности), небольшими (за одну итерацию) и тестируемыми (есть критерии)
Job Stories
В целом Job Stories - схожая с US техника. Можно назвать их приёмом-субститутом, ведь обычно они не используются вместе и выполняют максимально похожую функцию. Job Stories представляют требование в виде действия, которое выполняет пользователь. Они не описывают саму функцию, а лишь концентрируют внимание команды на потребности. Job Stories концентрируются на психологической части фичи, на эмоциях, тревогах и прочем, что может возникнуть во время использования функции.
“Тело” JS делится на три части:
Situation: дает контекст обо всей JS, который помогает dev-команде придумать возможное решение;
Motivation: описывает невидимую руку, которая ведет юзера к использованию данной функции;
Expected Outcome: описывает, что получит юзер после использования функции.
Job Stories могут писаться по двум форматам:
В одну строку: When X I want to Y so I can Z" или "When X, actor is Y so that Z;
В три строки:
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.
Источники:
Доп. материал:
