Проработка всех возможных сценариев очень важна, поскольку такой подход позволяет избежать некоторых достаточно неприятных сюрпризов на последующих этапах создания мобильного приложения. User story (или история пользователя) – это метод описания продукта или функциональности через ситуацию из жизни реального пользователя. Простыми словами, ситуация, в которой будущий продукт или функциональность решает задачу конкретной целевой аудитории. Некоторые из этих гибких пользовательских историй, несомненно, будут эпическими. Позднее эпосы будут разложены на более мелкие истории, которые с большей готовностью поместятся в одну итерацию. Кроме того, новые истории могут быть написаны и добавлены в портфель продуктов в любое время и кем угодно.
- Например, «Улучшить сайт» — плохая история, непонятно, что нужно сделать, и непонятно, как эту историю оценить.
- Этот пункт говорит не о самом описании под историей, а о ее размере, времени на реализацию.
- Пользовательские истории редко включают в себя сведения о производительности или нефункциональных требованиях, поэтому нефункциональные тесты (например, время отклика) могут быть пропущены.
- Пользовательские истории приоритизируются клиентом по важности для системы, разбиваются на серию задач и оцениваются разработчиками.
- История это то над чем работают более одного человека, а задача это то, над чем работает только один.
На основе этих требований и следует формировать пользовательскую историю. Она должна вести виртуального пользователя по всем страницам приложения, решая на каждом этапе совершенно конкретную задачу. В итоге шаги трансформируются в разделы, а решения — в функционал.
Инструменты
В принципе, при необходимости заказчик может добавлять новые пользовательские истории, менять приоритеты и т.д. При этом разработчик со своей стороны обязан объяснить заказчику, чем чревато будет предложенное изменение или добавление. Живое общение на этой стадии — залог успеха в будущем. Ведь создание успешного мобильного приложения – это блестящая идея + не менее блестящее ее воплощение. А для последнего значение правильно написанной User Story вряд ли можно переоценить. Без наличия хотя бы одной из описанных характеристик теряется пользовательская ценность истории, что в итоге может привести к разногласиям в момент приемки.
Так, часто можно услышать о правиле, согласно которому история должна укладываться в рабочий день. Однако на других же пользовательской историей может считаться функция, на реализацию которой нужно несколько месяцев времени разработчика. Персонажи не могут «гулять» из продукта в продукт, но человек, который создаёт их описание, может обращаться к давно созданным образам как за вдохновением, так и за шаблоном описания. Во время написания истории для аналитика важен не только её текст, но и то содержание – ценность, проблема – которая описывается этим текстом. Чтобы написать историю, которая сможет решить проблему пользователя, аналитику надо лучше понять пользователя и задать себе следующие вопросы. Пользовательские истории — это краткое описание функциональности, детали которой должны уточняться в ходе устных обсуждений между заинтересованными лицами проекта.
Какие задачи решает user story
Если говорить про гибкие методологии, то привязка может идти к релизам функционала. Вы сами определяете, какие задачи попадут в ближайший релиз, а какие уйдут в следующий. Вот как приблизительно могут выглядеть доски с историями пользователей. Изначально user story это данный термин появился в гибких методологиях разработки. Метод ориентирован на конкретную пользу, которую принесет новый продукт или функциональность. Приоритезация задач строится по-принципу от наиболее к наименее полезным доработкам.
История должна включать в себя максимально подробное описание потребностей пользователей. Польза проявляется не только в отношении конечного потребителя, но и самого продукта. С ее помощью можно четче определить его ценность и понять, для чего нужна реализация. Непосредственно перед реализацией разработчики могут обсудить историю с заказчиком. Истории могут быть сложными для понимания, могут требовать специфические знания, или требования, возможно, могли измениться со времени написания.
МОЩНЫЕ ИНСТРУМЕНТЫ РАБОТЫ С ИСТОРИЯМИ: УПОРЯДОЧИВАНИЕ, РАЗБИЕНИЕ И ГРУППИРОВКА
Критерии или принципы для составления и использования историй мы обсудили выше, но список этих принципов — не догма. Можно вносить корректировки, использовать только часть или добавлять свои критерии. В любом случае важно, чтобы каждая история соответствовала критериям — была понятной, краткой и четкой, в ней присутствовала определенная цель, которой нужно добиться и так далее. Это привычный шаг для всех, кто создает продукты для пользователей, — составить портрет своей целевой аудитории.
Меня зовут Наталья Кобякова, я Product owner и техлид клана аналитиков в Ak Bars Digital. Таким образом, становится возможным описать даже большие системы без потери общей картины. Отзывы о User Story map, написанные пользователями, сводятся к интерактивности и веселости сего занятия, которое очень радует людей.
Чего делать не стоит при работе с User Story?
Именно так Scrum-команды совершенствуют навыки оценки и планирования спринта, повышая точность прогнозов и свою гибкость. С помощью историй команды Kanban начинают более профессионально распоряжаться незавершенной работой (WIP) и могут в дальнейшем совершенствовать рабочие процессы. Составление «хребта» пользовательской истории и её детализация — ключевой этап процесса построения карты этой истории.
Она обычно бьется на несколько пользовательских историй со временем — используя обратную связь от пользователей на ранних стадиях прототипирования и формирования продукта. Поэму можно назвать состоящей из заголовков для более детальных историй. Как видно, описанные выше истории являются более-менее автономными сущностями, и, как следствие, могут быть перечислены в другом порядке. Конечно между историями существуют связи и логические цепочки — нельзя, к примеру, удалять пользовательские записи, не умея создавать их. Но все таки можно научиться составлять истории таким образом, чтоб обеспечить некоторую свободу в выборе порядка их реализации.
Расширяем user stories
Кроме того, необходимо обоюдное участие всей команды и ее заинтересованность, а еще софт, в котором можно будет визуализировать все задачи и истории. Соответственно те пункты, в которых говорится об истории пользователей, потом и берутся за основу для карточек пользовательских историй. Когда портрет продумали, можно идти и углубляться в анализ — здесь важно выяснить, с какими проблемами может сталкиваться пользователь, чем поможет продукт для решения этой проблемы. На этом этапе хорошо работают опросы и интервью — это помогает получить реальную информацию от целевой аудитории, а также улучшить ее портрет в целом. Раскрываем секреты использования agile-оценки и очков за истории. Хорошая agile-оценка помогает владельцам продукта оптимизировать процессы для повышения эффективности и производительности.
User Story Mapping
Переделаем историю на влияние — “Как инвестиционный аналитик я получаю отчет №17 об инвестициях БЫСТРЕЕ”. Вы указываете в АС что отчет должен формироваться за 15 сек. В конце понятно выполнено ли АС, понятно какие влияние вы оказали на работу аналитика. ДА, для каких-то историй можно указать ценность истории в таком формате, но не для большинства. Наверное здесь сложно ошибиться — это суть истории, “что нужно сделать”.