Написана Consumer Story от лица пользователя, так как этот метод используют именно для того, чтобы описать потребности клиентов. В ходе собрания по планированию спринта или итерации команда решает, какие истории она выполнит в ходе этого спринта. На этом этапе команды обсуждают требования каждой пользовательской истории и связанные функциональные возможности. Это шанс проявить свои навыки и https://deveducation.com/ творческий потенциал и внести вклад в воплощение истории в жизнь вашей командой. По завершении согласования требования добавляются в историю. Пользовательские истории изящно вписываются в методики Agile, такие как Scrum и Kanban.
Что Такое Use Case? Теория И Примеры
Для ее реализации обычно понадобится программист, тестировщик, возможно дизайнер интерфейса или аналитик, возможно даже и инженер или другие профессионалы. На практике этого часто сложно добиться, поэтому просто более подходящими обычно принято считать те истории, в которых таких зависимостей меньше. Это значит, что к концу итерации/спринта у нас точно будет готовый функционал, а не «зависнувший в воздухе» и не готовый к использованию. Однако, когда вы работаете с командой, у вас есть общее видение того, кем является этот человек. Возможно, это один из ваших клиентов или участников ваших глубинных интервью. X — это персонаж, от имени которого ведется повествование.
Писать Person Story нужно от лица пользователя, так как этот инструмент используют именно для того, чтобы описать потребности ЦА. Для написания User Story следует знать свою целевую аудиторию, поэтому стоит проводить опросы и интервью. При создании Person Story изучают целевую аудиторию, создают описание пользователя. Для составления Consumer Story уделяют внимание пожеланиям клиентов, поэтому их потребности важно изучать. Для создания хороших User Stories проводят опросы и исследования целевой аудитории. Consumer Story должна нести ценность продукта или его функции.
Пользовательскую историю можно создавать разными методами. Её пишут простым, понятным языком, чтобы разработчики и другие члены команды понимали, зачем нужна эта функция и как она поможет пользователю. «Я как главный бухгалтер хочу иметь возможность просматривать всю подготовленную документацию за месяц, чтобы контролировать правильность заполнения отчетности». Ещё одна практика, которой можно пользоваться при работе с user story. Есть еще один вариант описания критериев приемки, который очень любят тестировщики — модель Given-When-Then. Не стоит тратить ресурсы на описание юзкейсов, если у вас небольшие проекты — интеграционные сервисы, мало интерфейсов и пользователей, или вообще нет пользователей.
В зависимости от контекста и потребностей проекта, вы можете адаптировать этот шаблон. Простой формат историй облегчает общение между различными участниками проекта — разработчиками, дизайнерами, менеджерами и заказчиками. Это снижает риск недопонимания и ошибок в интерпретации требований. Для масштабных Person Story, и для бэклогов можно построить наглядную карту методом Person Story Mapping (USM). С такой картой удобнее работать, когда пользовательская история достаточно сложная, и включает в себя много переменных.
Когда пользовательская история готова к реализации, карточку передают разработчикам. Стандартная пользовательская история — это короткое предложение, в котором указаны пользователь, функция и ожидаемый результат. Важно описывать Person story с точки зрения пользователя, а не технических деталей. Формулируйте историю так, чтобы пользователь мог понять, что вы описываете, и как это поможет ему решить свою задачу. Этот формат позволяет формулировать пользовательские истории в ясном и лаконичном формате. В нем вы указываете, кто пользователь (As a…), что он хочет (I want…) и зачем ему это нужно (So that…).
Например, это может быть привычный всем Trello, за рубежом нередко используют Kanban. Инкремент — это уже готовый продукт по итогам каждого спринта, обычно он демонстрируется на митапах внутри команды. Как пользователь приложения, я хочу быстро регистрироваться через VK, чтобы сэкономить время на регистрацию.
Зачем Нужны User Story
Это своего рода «доказательство», что история соответствует требованиям заказчика. Чтобы сделать действительно хороший продукт, нужно не только писать код, но и понимать потребности своих пользователей. Для этого в разработке используют Consumer Story — небольшие истории, описывающие желания и действия пользователя с точки зрения его потребностей. Иногда Consumer story нуждаются в дополнительной информации, чтобы разработчики могли лучше понимать задачу. Добавление примеров использования, требований к дизайну или примеров данных может помочь лучше сформулировать историю и избежать недопонимания. Еще в критерии приемки можно дописать ожидания того, кто проектировал эту историю.
В результате — после такого рассказа — историю можно записать достаточно коротко, при этом вся команда, которая участвовала в обсуждении истории, будет понимать, о чем идет речь. Чтобы быстрее пройти по всем этапам написания, можно использовать несколько рекомендаций — Фреймворк они касаются определения пользователя, а также его запроса. Проще всего визуализировать через такие инструменты, где предусмотрено создание досок и карточек.
Если задача требует большей проработки, можно отложить ее на потом. Одна из важных мелочей, которой часто не уделяют должного внимания — нумерация. Именно грамотно продуманная нумерация позволит организовать трассировку требований и поддерживать актуальность документации, связанной с требованиями. И, конечно же, эта важная деталь упростит поиск историй для вас пользовательская история и ваших коллег. Трекинговые системы, такие как Jira, поддерживают практически любую нумерацию. Практика показывает, что простой структуры в виде фразы часто недостаточно для работы с пользовательской историей.
Это описание юзер-стори из 1−2 предложений, которое содержит цель и краткую информацию о более детальных требованиях. Цель — определить, насколько важна эта функция для достижения общих целей проекта. Это касается конечной ценности продукта, которую получит пользователь. Кроме того, хорошая Person story должна быть актуальной и регулярно обновляться в соответствии с изменением требований пользователей и бизнес-целей. Она должна быть лаконичной, понятной и описывать только одну конкретную функцию или задачу.
Обычно для этого используются многофункциональные инструменты по управлению проектом в команде. Так любой член команды может зайти в систему и посмотреть стори и любые пометки к ней от коллег. Scrum — это что-то из мира практики, то есть метод помогает усовершенствовать работу в отделе. И нужно быть к этому готовым — методика Scrum и обучает, как к этому быть готовым. ✔️Как пассажир, я хочу выбирать такси разного класса в приложении. ✔️ Как пассажир, я хочу выбирать такси разного класса в приложении, чтобы выбирать уровень комфорта.
Как Написать Хорошую Пользовательскую Историю
- Проще всего визуализировать через такие инструменты, где предусмотрено создание досок и карточек.
- Там можно составить карту пользовательских историй, а затем внести ее в Jira».
- История должна содержать достаточно информации для начала работы.
Первое, что бросается в глаза — не сформулирована ценность данной истории. Также обратите внимание, что тот, кто пишет историю пользователя, гораздо менее важен, чем тот, кто участвует в ее обсуждении. Команды согласовывают ожидания, выявляют возможные проблемы, генерируют идеи и разрабатывают описанный в истории функционал, включая тестирование и реализацию изменений.