Понятие User Story
User Story, или пользовательская история, помогает увидеть функции продукта глазами конечного потребителя. Основную часть User Story пишут кратко, без технических деталей и лишних подробностей.
Главное — сделать фокус на целях и потребностях людей. Они короткие, написаны деловым языком и поэтому понятны всем заинтересованным лицам проекта
Главное в пользовательской истории — это ценность, которую пользователь получит от функции
В основной части User Story обычно указывают:
● категорию, к которой относится пользователь;
● действие, которое он или она хотели бы совершить;
● результат, который ожидает получить пользователь после действия.
В историю обязательно включают критерии приёмки — условия, которые должны быть выполнены , чтобы история считалась завершённой.
1. Фокусироваться на преимуществах для пользователя.
Бывает, что в User Story описывают только функциональность системы, а о том, зачем это пользователю, забывают.
Нужно обязательно добавить результат или ценность для пользователя — обычно это часть с союзом «чтобы».
2. Создавать небольшие и выполнимые User Story.
Не стоит писать объёмные истории, которые потребуют много времени для разработки.
Лучше написать несколько небольших
3. Добавлять детали в критерии приёмки.
В пользовательской истории описание будущих функций продукта должно быть общим, без деталей дизайна и разработки, например: «Как пользователь, я хочу быстро найти кнопку на главной странице, которая позволит мне зарегистрироваться на сайте».
Все уточнения вносят в критерии приёмки во время обсуждения User Story в команде.
Стиль:
Истории пишутся в три строки:
Как Х,
Я хочу Y,
Чтобы Z.
Три С в User Story
Первое определение говорит о коммуникации и карточках, но не упоминает согласие. Эти три понятия образуют "the 3 C's of User Stories".
Card — по задумке автора метода истории пишутся на физических карточках. В реальности они пишутся в Jira и Confluence, поэтому мы не так ограничены в детальности.
Conversation — каждая стори — это множество митингов вокруг нее, которые и направлены на понимание деталей.
Confirmation — перед началом работы клиент дает согласие на данное решение, а команда полностью уверена в выполнимости решения.
Комментариев нет:
Отправить комментарий