User story пример: User Story 💬 — Что Это Такое? Пользовательские Истории и Примеры

Пользовательские истории | Примеры и шаблон

Краткое описание: пользовательская история — это описание функциональной возможности ПО простыми, общими словами, составленное с точки зрения конечного пользователя. Она пишется с целью разъяснить, как именно функциональная возможность принесет пользу клиенту.

Есть тенденция считать, что пользовательские истории — это, говоря проще, функциональные требования к программному обеспечению. Но это не так.

Уникальная черта agile-разработки ПО — ставить во главу угла человека, и пользовательские истории как раз служат для того, чтобы в центре обсуждения всегда были фактические пользователи. Истории пишутся простым языком, без технической специфики, и служат контекстом для команды разработчиков и их деятельности. Прочитав пользовательскую историю, команда знает, почему она создает то, что создает, и какую ценность это формирует.

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

Что такое пользовательские истории в agile?

Пользовательская история — это наименьшая единица работы в методике agile. Это конечная цель, а не возможность, сформулированная с точки зрения пользователя ПО.

Пользовательская история — это описание функциональной возможности ПО простыми, общими словами, составленное с точки зрения конечного пользователя или клиента.

Пользовательская история пишется с целью разъяснить, как именно выполнение рабочей задачи приведет к созданию конкретной ценности для клиента. «Клиентами» необязательно должны быть сторонние конечные пользователи в привычном смысле слова. Эту роль могут на себя примерять внутренние клиенты или коллеги из организации, которые рассчитывают на вашу команду.

Пользовательские истории состоят из нескольких предложений, описывающих требуемый результат простым языком и в общих чертах. Они не содержат мелочей. Требования появятся позже, когда команда обсудит их и придет к согласию.

Пользовательские истории изящно вписываются в методики Agile, такие как Scrum и Kanban. В Scrum пользовательские истории добавляют в спринты и отслеживают на диаграммах Burndown в течение спринта. Команды, работающие по методике Kanban, добавляют пользовательские истории в бэклог и пропускают их через рабочий процесс. Именно так Scrum-команды совершенствуют навыки оценки и планирования спринта, повышая точность прогнозов и свою гибкость. С помощью историй команды Kanban начинают более профессионально распоряжаться незавершенной работой (WIP) и могут в дальнейшем совершенствовать рабочие процессы.

Пользовательские истории также составляют значительные элементы методик Agile, такие как эпики и инициативы. Эпики — это большие рабочие задачи, которые делятся на несколько историй. Группа эпиков образует инициативу. Благодаря этим крупным структурам каждодневные усилия команды разработчиков (в работе над историями) ведут к достижению целей организации, выраженных в эпиках и инициативах.

Подробнее об эпиках и инициативах

Зачем нужны пользовательские истории?

Для команд разработчиков, которым agile в новинку, пользовательские истории кажутся лишним шагом. Почему бы просто не разбить большой проект (эпик) на несколько шагов, а потом разбираться с ними? Но с историями команда получает необходимый контекст и связь между задачами и ценностью, которая возникает в результате выполнения этих задач.

Пользовательские истории обладают несколькими важными преимуществами.

• Истории удерживают акцент на пользователе. Список дел поможет команде сосредоточиться на актуальных задачах, в то время как с набором историй участники смогут направить усилия на решение проблем реальных пользователей.
  
• Истории создают условия для совместной работы. Когда определена конечная цель, команда может совместными усилиями найти лучшее решение для клиента и лучший способ достижения этой цели.
  
• Истории подталкивают к поиску нестандартных решений. Истории заставляют команду подходить критически и творчески к выбору наилучшего пути достижения конечной цели.
  
• Истории задают динамику. Выполнив очередную историю, команда разработчиков справляется с небольшой задачей и радуется промежуточному успеху, который помогает двигаться дальше.

Узнайте, как пользовательские истории реализованы в Jira Software

Работа с пользовательскими историями

Когда история написана, самое время встроить ее в рабочий процесс. Как правило, историю пишет владелец продукта, менеджер по продукту или руководитель группы проектов, после чего она отправляется на проверку.

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

Еще на собраниях оценивают истории на основании их сложности или времени, которое нужно потратить на выполнение. Команды высчитывают оценки в размерах футболок, баллах из последовательности Фибоначчи или с помощью покера планирования. Размер истории должен позволять выполнить ее за один спринт, поэтому в ходе оценки каждой истории команда следит, чтобы слишком трудоемкие или затратные по времени истории разбивались на меньшие части.

Как написать пользовательскую историю

При написании пользовательских историй держите в уме следующее.

• Критерии готовности работы. Как правило, история считается «выполненной», когда пользователь может сделать то, что было запрошено. Тем не менее, четко сформулируйте цель.
  
• Краткое описание задач и подзадач. Определите, какие конкретно этапы нужно пройти и кто несет ответственность за каждый из них.
  
• Типы клиентов. Для кого? При наличии нескольких типов конечных пользователей желательно написать несколько историй.
  
• Этапы как часть цепи. Напишите историю для каждого этапа, составляющего более масштабный процесс.
  
• Обратная связь. Поддерживайте связь с пользователями, чтобы увидеть проблему или потребность их глазами. Зачем гадать, если можно услышать историю из уст самих клиентов?
  
• Время. Время — очень щекотливая тема. Многие команды разработчиков боятся поднимать вопросы о времени совсем, полагаясь на свои оценки. Истории должны выполняться за один спринт, поэтому истории, которые могут занимать недели или месяцы, следует разбивать на несколько историй поменьше. Как вариант, считайте их самостоятельными эпиками.
  

Сформулировав пользовательские истории, позаботьтесь о том, чтобы они были доступны всей команде.

Шаблон и примеры пользовательских историй

Пользовательские истории часто представлены в виде простого предложения следующего вида:

«Как [тип клиента], [хочу то-то], [чтобы делать что-то]».

Давайте разберем эту формулировку.

• «Как [тип клиента]»: для кого мы выполняем эту работу? Нам не так важна должность, сколько личность, что стоит за типом клиента. Вот Макс, например. Нашей команде нужно иметь единое представление о том, что Макс за человек. К счастью, мы опросили множество Максов. Мы понимаем, как работает этот человек, как он думает и что он чувствует. Мы испытываем к Максу эмпатию.
• «Хочу то-то»: в этой части заключается намерение пользователя — не возможностей, которыми он пользуется. Чего пользователь хочет добиться? В этом утверждении не должно быть ни слова о способах реализации. Если вы описываете какую-либо деталь пользовательского интерфейса, игнорируя цель пользователя, вы упускаете суть.
• «Чтобы делать что-то»: какое место отведено этому сиюминутному желанию клиента в более широком масштабе? Какую пользу в целом хочет извлечь клиент? Какую крупную проблему нужно решить?

Пользовательские истории могут выглядеть, например, следующим образом.

• Как Макс, я хочу пригласить друзей, чтобы мы вместе могли пользоваться этим замечательным сервисом.
• Как Саша, я хочу организовать свою работу, чтобы лучше контролировать ситуацию.
• Как менеджер, я хочу видеть, как продвигается работа у моих коллег, чтобы можно было составлять более точные отчеты о наших успехах и неудачах.

Придерживаться такой структуры необязательно, но она помогает определить критерии готовности работы. История выполнена, когда упомянутый тип клиента получает требуемую ценность. В идеале, команды формулируют свою собственную структуру и придерживаются ее.

Начало работы с пользовательскими историями в agile

В пользовательских историях раскрываются суть и цели повседневной работы участников команды разработчиков. Зачастую они написаны в форме «тип клиента + потребность + цель». Чтобы процесс работал как часы, важно понимать роль историй: именно в них объясняется, что должна сделать команда и почему она должна это сделать.

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

Max Rehkopf

Я считал себя «хаотичным раздолбаем», но методики и принципы agile помогли навести порядок в моей повседневной жизни. Для меня истинная радость — делиться этими знаниями с другими людьми, публикуя многочисленные статьи, участвуя в беседах и распространяя видеоматериалы, которые я создаю для Atlassian. 

Проверенный шаблон пользовательских историй / Хабр

Самый дорогой ресурс — время. Его всегда не хватает. Один из популярных способов экономии времени — шаблон. Например, в повседневной жизни у нас есть шаблоны поведения, когда мозг, чтобы не тратить энергию, действует по привычным схемам: мы ездим по одним и тем же маршрутам до работы, пьем кофе, к которому привыкли, берем выкройки для нового платья из журнала, или готовим презентацию по корпоративному шаблону.

В IT есть, например, паттерны проектирования или алгоритмы — математические шаблоны. Шаблоны — полезная «вещь»: позволяют меньше писать, подставляя что-то в уже сформированные рамки. 

Мы в Ak Bars Digital тоже используем много собственных наработок, методологий и шаблонов, чтобы делать все быстро и качественно. В этой статье поделюсь прикладным шаблоном, который создали опытным путем для удобной работы с пользовательскими историями.

Автор: Дарья Плоскодняк — опытный продуктовый аналитик в Ak Bars Digital. Занимается развитием сквозных процессов Ак Барс Банка, связанных с банковскими картами. Один из лидеров внутреннего комьюнити аналитиков компании и участник многочисленных митапов и конференций. Статья подготовлена по мотивам выступления Дарьи на одном из таких мероприятий – митапе Three Amigos Talk.

Пользовательские истории

Сначала кратко о пользовательских историях.

Пользовательская история (или User Story, US) — это:

С точки зрения agile-разработки, пользовательская история — это задача, которая должна помещаться в спринт.

Простая структура пользовательской истории: 

Я как 1_ хочу 2, чтобы 3__.

1 – тип пользователя, персонаж

2 – действие или цель

3 – результат или ценность

Разберем некоторые кейсы с реальными пользовательскими историями:

#1. «Я, как клиент банка, хочу получать сообщение об изменении статуса заявки на кредит, чтобы скорее получить деньги».

Вопрос, который возникает, глядя на эту user story, какой статус ожидает клиент? 

Как улучшить: «Я, как клиент банка, хочу получать смс об одобрении заявки на кредит, чтобы как можно скорее получить деньги»

Такую историю хорошо бы было дополнить информацией по существующим статусам заявки.

#2. «Я как сотрудник магазина хочу проще заходить в складскую программу».

Первое, что бросается в глаза — не сформулирована ценность данной истории. Буквально, нет ответа на вопрос «Зачем?».

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

Как улучшить: «Я как сотрудник магазина хочу иметь возможность авторизоваться в складской программе по коду из 4-х цифр, чтобы обслуживать больше клиентов за смену»

Практика показывает, что простой структуры в виде фразы часто недостаточно для работы с пользовательской историей. В результате возникают вопросы со стороны команды разработки, и аналитику приходится отвлекаться на поиски ответов. 

Пример детального и максимально наполненного описания пользовательской истории.

Разберем пример подробнее.

Описание

Одна из важных мелочей, которой часто не уделяют должного внимания — нумерация. Именно грамотно продуманная нумерация позволит организовать трассировку требований и поддерживать актуальность документации, связанной с требованиями. И, конечно же, эта важная деталь упростит поиск историй для вас и ваших коллег. Трекинговые системы, такие как Jira, поддерживают практически любую нумерацию.

Пример нашей нумерации: ABOL-04-113.

Описание должно быть максимально подробным. Важно записывать все и не бояться, что напишете лишнего — документация должна быть исчерпывающей. 

Примечание. Эпик — это сущность (крупная часть функционала или этап проекта), ценность которой для пользователя мы не можем выразить в одной истории текущего спринта. Эпик разбивается на истории и задачи. Например, в проекте «Курьерская доставка банковских карт», эпик — это «Доставка неименных банковских карт». Пример истории : «Я как клиент банка могу получить неименную карту в срок, который я указал в Заявке, чтобы сократить срок получения банковской карты»

Важно исключить в описании истории технические детали и сложные термины. Пользовательская история – это общий инструмент описания для разработки и бизнеса. И важно описывать все простыми словами так, чтобы любой читатель сразу понял, о чем речь. Не мудрите.

Пример: ABOL-04-113. »Я как действующий клиент банка, уже зарегистрированный в личном кабинете, хочу иметь возможность сменить пароль, чтобы иметь доступ к личному кабинету, если забыл пароль»

Сценарии использования, или Use case

Команды, особенно в бэкенд-разработке, часто сомневаются — писать ли пользовательские истории. Причина в том, что они не взаимодействуют с пользователями и могут придумать формулировки историй только от лица системы. 

В этом случае первый шаг можно пропустить и взять за основу шаблона сценарий использования. Этот инструмент описания требования полезен для всех участников разработки.

Юзкейсы нужны не всегда, но в командах бэкенд-разработки часто пользуются только ими. Описывать их можно в виде текста – так проще исправить. Диаграммы нагляднее, но тяжелее в производстве.

Пример нашего юзкейса.

Не стоит тратить ресурсы на описание юзкейсов, если у вас небольшие проекты — интеграционные сервисы, мало интерфейсов и пользователей, или вообще нет пользователей.

Правила бизнеса

Старайтесь максимально подробно записывать бизнес-требования, фиксировать любые новые обсуждения и уточнения требований от бизнеса. Можно оставить ссылки на коллег, которые отвечают за бизнес-направление. При этом важно фиксировать источник и дату требования для истории документа и просмотра версионности.

Запоминаем главное — правила бизнеса могут и будут меняться!

Ограничения бизнеса

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

Ограничения бизнеса тоже могут меняться, но не так часто, как правила. 

Интеграция с внешними системами

Если ваш сервис взаимодействует с другими системами в рамках истории, то в этом разделе описываем все сценарии взаимодействия с внешними сервисами и системами. Скорее всего, на момент написания истории, сервис запущен и работает, у него есть архитектура, инфраструктура и какие-то артефакты, которые можно приложить в виде ссылок. 

Сюда отлично подойдет описание инфраструктуры, ER-диаграмма, примеры в формате JSON или XML, и все прочие детали интеграции с внешними системами. В общем, всё, что может пригодиться разработчикам.

Критерии приемки

Обязательное условие для работы с историей. Даже для тех команд, которые пользуются короткими формулировками пользовательской истории безо всяких шаблонов.

Минимальные требования для пользовательской истории — формулировка и критерии приемки. Без них мы не сможем понять, выполнили историю или нет. 

Критерии приемки прописываются отдельно для каждой истории. Пример критериев приемки для нашей истории:

1. Пользователю доступна функция смены пароля на всех устройствах.

2. Функция смены пароля доступна на странице авторизации.

3. Новый пароль не может дублировать старый пароль.

4. Новый пароль имеет не меньше 8 символов.

5. Пароль не может начинаться и заканчиваться пробелом.

Есть еще один вариант описания критериев приемки, который очень любят тестировщики — модель Given-When-Then. 

• Given (дано) — состояние ситуации до начала действий пользователя.

• When (когда) — пользователь совершает какие-то действия.

• Then (тогда) — ситуация меняется и система реагирует на действия пользователя.

Подробнее про это можно почитать в статье «Как описать User stories, используя язык Gherkin».

В критериях приемки есть только два варианта — да и нет.

Критерий не может быть выполнен, например, на 90%.

Важна конкретика — если вы что-то не пропишете или упустите, то у разработчиков будет возможность додумать самостоятельно. И это не всегда хорошо. Ещё один важный момент — критерии приемки должны легко проверяться.  

Важно не путать критерии приемки и DOD (definition of done). DOD — это общий чек-лист критериев – он может быть один на все пользовательские истории в рамках процесса. 

Как отличить DOD и критериев приёмки? Очень просто. Представим доставку пиццы. DOD — пицца приготовлена, упакована, отправлена, вручена. Критерии приемки — пицца приготовлена из тех ингредиентов, которые заказал клиент.

На этом всё. Вы можете пользоваться шаблоном как есть или модернизировать его. Главное — формулировать понятно для всех участников и понимать ценность пользовательской истории для бизнеса.

Практика «три С» — card, conversation, confirmation

Ещё одна практика, которой можно пользоваться при работе с user story.

Card — фиксация истории для выполнения. Самое важное, чтобы история была доступна, и чтобы её могли найти все коллеги из команды разработки. Фиксировать истории можно в любом таск-трекере или даже на доске в офисе.

Conversation — обсуждения требований с командой. Если вы аналитик, то не используйте схему работы, в которой просто написали пользовательскую историю и передаете её разработке. Так не работает. Нужно обсудить требования с командой, в идеале выделить на это отдельную встречу.

Confirmation — прописать четкие критерии приемки.

А как на практике?

Давайте пофантазируем и представим заказчика, который передал требования на разработку и сказал «Хочу ракету». У нас есть две команды, в каждой — по одному аналитику: Соня и Степан. Они одновременно начали работать с требованиями. 

• Степан решил сэкономить время и побыстрее сделать ракету. Для этого передал свои требования в виде незрелой пользовательской истории в команду разработки. 

• Соня потратила больше времени на проработку требований, описала все истории, расписала по шаблону, ссылки добавила и передала упорядоченные требования в разработку.

Чья команда быстрее выполнит проект? Чей проект будет более качественным? Оставляйте свои мнения в опросе и пишите комментарии — давайте обсуждать.

User story — что это, структура и 7 примеров

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

---

Что такое пользовательские истории и их значение для разработки

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

Прежде чем рассказать о структуре юзер стори, важно понять, для чего они вообще нужны и по каким правилам работают. Отвечаем — многие топовые компании по разработке ПО, игр или приложений работают по методике Scrum, которая основывается на образе мышления Agile.

Scrum — это что-то из мира практики, то есть метод помогает усовершенствовать работу в отделе. Сама методика подразумевает, что нужно постоянно обучаться и подстраиваться под изменчивые процессы — причина в том, что задачи в мире разработчика постоянно меняются, порой на полностью противоположные. И нужно быть к этому готовым — методика Scrum и обучает, как к этому быть готовым.

Agile — это образ мышления, один из принципов которого и базируется на идее совершенствования и умения подстраиваться под изменения. По сути, чтобы понять принципы Agile наглядно и внедрить их в работу, можно начинать с внедрения Scrum в работу и в жизнь — это будет первым шагом перестроить свое мышление.

Agile-разработка в целом — это все этапы разработки по порядку. Каждый этап перетекает в другой, и так по кругу. Наглядно это выглядит так:

Scrum предполагает эмпирический подход к работе, когда с помощью определенных примеров человек обучается всему практическим путем. Поэтому у метода есть своя структура — она состоит из трех артефактов: бэклог продукта, бэклог спринта и инкремент.

Бэклог продукта — это по сути список задач, которые нужно выполнить за все время. Обычно такой список составляют менеджеры проектов или продуктов и включает в него буквально все актуальные задачи отдела.

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

Инкремент — это уже готовый продукт по итогам каждого спринта, обычно он демонстрируется на митапах внутри команды.

По итогу можно сказать, что юзер стори — это по сути единица в большой системе работы над созданием, тестированием и подготовкой продукта. Хоть это всего лишь крошечная часть процесса, она имеет важное значение, так как помогает выяснять желания и цели целевой аудитории. То есть в перспективе — делать продукт совершенным.

---

Зачем нужны юзер стори

Пользовательские истории, как уже сказали, много значат для отдела разработки и выпуска удачного продукта. Поэтому их нужно создавать вдумчиво и кропотливо, но при этом понятно и просто. Разберем, насколько вообще важны юзер стори — для этого рассмотрим их преимущества.

Помогают сосредоточиться на пользователях — несмотря на наличие списков, которые включают все актуальные задачи команды, пользовательские истории помогают их уточнять и сосредотачивать именно на пользователях.

Улучшают сотрудничество и взаимодействие внутри команды — во время составления юзер стори, а также в процессе спринтов команда прилагает все свои общие усилия, что прийти к общей цели.

Побуждают творческое мышление — чтобы добиться цели пользователя, нужно применять различные методы работы. В этом плане себя может проявить каждый сотрудник — это серьезно развивает творческое и критическое мышление.

Увеличивают мотивацию — если команда все делает правильно и в итоге добивается хорошего результата, это мотивирует работать еще лучше и усерднее.

---

Структура пользовательской истории

Ценность юзер стори разобрали — теперь можно подробнее изучить, как они пишутся, и что собой представляет их структура.

Структура юзер стори едина для каждой — она состоит из трех частей:

• пользователь — каждая юзер стори составляется на основе мнений и пожеланий целевой аудитории, поэтому важно отметить, что именно это за пользователь;
• действие — здесь прописывают, что хочет сделать пользователь с помощью продукта или его функции;
• выгода/результат/цель — в этой точке отмечают, какая конечная цель у пользователя, то есть зачем ему совершать определенное действие.

Таким образом, структура приобретает следующий вид:

Как пользователь, я хочу действие, чтобы выгода/цель

Например, как покупатель, я хочу использовать на сайте магазина корзину, чтобы товары, которые я хочу купить, хранились в одном месте.

Или — как пассажир, я хочу видеть всех таксистов поблизости в приложении, чтобы выбрать более подходящий вариант.

Хватает пары фраз, чтобы написать такую карточку — в ней обозначают, кто целевой клиент, чего он хочет, и какую выгоду получает.

---

Принципы и шаги написания пользовательской истории

Чтобы написать хорошую историю, важно руководствоваться принципами и использовать основные шаги, которые чаще применяют в большинстве компаний.

Принципы написания юзер стори называют INVEST — их разработал опытный программист Билл Уэйк. Давайте изучим их — всего принципов шесть:

• I означает Independent (независимость) — истории должны быть осуществимы, вне зависимости от обстоятельств;
• N означает Negotiable (открытость) — история должна быть открытой для обсуждения, то есть простой и понятной каждому;
• V означает Valuable (ценность) — все заинтересованные люди должны получить ценность от выполнения истории — пользователи, разработчики, владельцы проекта;
• E означает Estimable (оценочность) — история должна подходить для обсуждения и ее оценки в дальнейшем;
• S означает Small (лаконичность) — история должна иметь небольшой размер, в идеале не превышать одного сложноподчиненного предложения с простыми составными частями;
• T означает Testable (тестируемость) — чтобы завершить историю, ее нужно сначала протестировать, и она должна подходить для тестирования.

Если руководствоваться этими принципами, получится учесть мелкие детали при написании стори. Но это не все, что используют при подготовке истории руководители проектов, — для ее написания мы собрали

последовательность четких шагов. Давайте с ними ознакомимся.

---

Шаг №1: проверьте пользовательские потребности

PBN-сети и дроп-домены по выгодной цене! Все включено на 12 месяцев: хостинг, домен, CDN и Private Person.

Это привычный шаг для всех, кто создает продукты для пользователей, — составить портрет своей целевой аудитории. Обычно он включает серьезный анализ потребностей, места работы, целей в жизни. Но это потом — сначала нужно подготовить портрет целевого клиента. Портрет клиента — это частично вымышленный персонаж, который и является идеальным пользователем продукта. На этом этапе обычно выясняется, кто клиент, чем он занимается, сколько зарабатывает, его пол, наличие семьи и так далее.

Овнеры магазинов ФБ акков про свой бизнес и тренды в арбитраже. ФБ аккаунты для арбитража трафика

Например, если магазину детских игрушек нужно выяснить, кто их целевая аудитория. Один сегмент — это стопроцентно мамы, у которых не так давно появился ребенок, они замужем, сидят в декрете и не имеют дохода. Список можно продолжать, чтобы сузить аудиторию, а также продумывать и другие сегменты — скажем, покупать игрушки могут и беременные девушки, которые только ждут рождения ребенка. И ситуация внутри семьи, как и потребности, будут несколько другими, чем у мамы с детьми.

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

---

Шаг №2: создайте эпики

Эпики — это по сути те же истории пользователей, но они включают несколько и содержат описание функционала приложения и его задач. Обычно эпики используют, чтобы не перегружать список с общими задачами. Когда приходит время создания юзер стори, то эпики дробят на эти истории.

Это может выглядеть как обычный список из историй пользователей:

«— как пользователь, я хочу яркую обложку приложения, чтобы не терять его из виду на рабочем столе;

— как пользователь, я хочу автоматический скроллинг видео, чтобы не тратить время на перелистывание;

— как пользователь, я хочу поделиться своим профилем через QR-код, чтобы не тратить свое и чужое время на ручной поиск профиля».

Впоследствии эпики разделяют на несколько карточек, чтобы работать над ними. Если бы это делали сразу, список задач бы увеличивался из-за большого количества актуальных историй. Это может сбивать с толку сотрудников.

---

Шаг №3: создавайте пользовательские истории на основе эпиков

Как уже сказали, на основе эпиков можно писать юзер стори, но это нужно делать правильно, с учетом потребностей отдельных пользователей. Это значит, что нужно выбрать определенный эпик, который соответствует цели спринта — например, это обновление в приложении и добавление в него новых фичей. Получается, нужно выбрать тот эпик, который включает все пользовательские пожелания относительно нововведений. Потом выбранный эпик дробится на юзер стори. Скажем, основная цель эпика была упростить способ загрузки и установки приложения на ПК в грядущем обновлении. Тогда стори будет включать мини-запросы пользователей по части загрузки — упростить процесс регистрации в приложении через авторизацию в Google или Facebook*, например.

Система составления стори наглядно будет выглядеть так:

---

Шаг №4: визуализация пользовательской истории

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

Проще всего визуализировать через такие инструменты, где предусмотрено создание досок и карточек. Например, это может быть привычный всем Trello, за рубежом нередко используют Kanban.

---

Шаг №5: проверьте все истории по критериям приемлемости

Критерии или принципы для составления и использования историй мы обсудили выше, но список этих принципов — не догма. Можно вносить корректировки, использовать только часть или добавлять свои критерии. В любом случае важно, чтобы каждая история соответствовала критериям — была понятной, краткой и четкой, в ней присутствовала определенная цель, которой нужно добиться и так далее.

---

Рекомендации по написанию юзер стори

Чтобы быстрее пройти по всем этапам написания, можно использовать несколько рекомендаций — они касаются определения пользователя, а также его запроса.

Определяем, «кто» будет вашим пользователем: 

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

Определяем, «что» нужно пользователю:

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

Напоследок: все этапы работы важно обсуждать в коллективе, поэтому после написания пользовательских историй нужен серьезный мозговой штурм — так каждый из отдела сможет высказать свои мысли по поводу истории.

Интересуешься SEO-продвижением? — Вступай в закрытый VIP-клуб! Мастермайнды, общение с единомышленниками и приватный контент.

---

7 примеров юзер стори и эпиков

Без примеров сложно разобраться в тонкостях, поэтому давайте разберем семь примеров эпиков и вытекающих из них пользовательских историй.

Пример №1: авторизация в кабинете сайта

Сначала начнем с составления эпика, его основная тема — как быстро авторизоваться в кабинете.

После уточнения темы можно накидывать варианты того, с чем возникли или могут возникнуть проблемы у пользователя:

• кто — как покупатель;
• что хочет — я хочу быстро зарегистрироваться через Google;
• зачем — чтобы быстрее перейти к покупкам.

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

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

• данные с сайта показывают, что большинство пользователей покидают его после открытия формы регистрации;
• опросы показали, что многие клиенты хотят сохранить свою конфиденциальность даже от владельцев магазина;
• судя по трафику конкурентов, у которых упрощенная форма регистрации без указания личных данных, их конверсия гораздо выше нашей.

К пояснениям можно приложить ссылки или скрины с ответами пользователей в опросе, например. И после этого можно переходить к финальному шагу — обозначить границы эпика. Обозначение границ помогает задать путь к решению проблемы для разработчиков и отдела в целом.

То есть в этом пункте нужно прямо и описать действия для решения проблемы:

• убрать из формы регистрации все поля, где требуется указывать личные данные — за исключением раздела с вариантами оплаты товаров, а также номера телефона и почты пользователя;
• добавить возможность авторизации через Google или Facebook;
• добавить к кнопке регистрации ссылку с текстом на политику конфиденциальности.

Так, эпик приобретет такой вид:

Тема: как быстро авторизоваться в кабинете   История 1: как покупатель, я хочу быстро зарегистрироваться через Google, чтобы быстрее перейти к покупкам.   История 2: как клиент магазина для взрослых, я хочу не указывать личные данные при регистрации, чтобы сохранить свою конфиденциальность.   Примечания:   данные с сайта показывают, что большинство пользователей покидают его после открытия формы регистрации; опросы показали, что многие клиенты хотят сохранить свою конфиденциальность даже от владельцев магазина; судя по трафику конкурентов, у которых упрощенная форма регистрации без указания личных данных, их конверсия гораздо выше нашей. Задачи, за которые выходить не нужно:   убрать из формы регистрации все поля, где требуется указывать личные данные — за исключением раздела с вариантами оплаты товаров, а также номера телефона и почты пользователя; добавить возможность авторизации через Google или Facebook*; добавить к кнопке регистрации ссылку с текстом на политику конфиденциальности.

 

Соответственно те пункты, в которых говорится об истории пользователей, потом и берутся за основу для карточек пользовательских историй.

---

Пример №2: как сделать меню ресторана в приложении более интересным

Подробный пример с описанием всех шагов был выше — надеемся, что логика ясна.

Поэтому далее будем показывать только то, как выглядит финальный вариант эпика и историй:

Тема: как сделать меню ресторана N в приложении живым и цепляющим   История 1: как менеджер ресторана, я хочу видеть больше фотографий блюд в меню, чтобы привлечь больше клиентов.   История 2: как покупатель, я хочу видеть, что я заказываю, чтобы не ошибиться с выбором.   История 3: как постоянный клиент, я хочу видеть все скидочные предложения, которые мне положены, чтобы не пропускать дни акций.   Примечания:   после созвона с менеджером ресторана выяснилось, что визуально меню не впечатляет — нужны фотографии. Это подтверждают и отзывы на сайте; отзывы от клиентов показали, что в функционале не хватает описания всех скидочных предложений на напитки и блюда. Задачи, за которые не нужно выходить:   добавить на каждую страницу меню блок с описанием скидочного предложения, к нему добавить фото и автоматизировать отсчет времени до окончания скидки; к каждому блюду и напитку в меню добавить фотографии — ссылка на них прилагается к карточке.

---

Пример №3: создание приложения под интернет-магазин косметики

Тема: оснастить приложение дополнительными фичами, которые облегчат выбор косметики клиентам   История 1: как покупатель косметики, я хочу видеть, как она будет выглядеть на мне, чтобы правильно подобрать тон или текстуру.   История 2: как частый покупатель, я хочу видеть все варианты актуальных скидок на товары, чтобы не пропустить их.   История 3: как оптовый покупатель, я хочу получать все предложения на почту, чтобы вовремя заказать товары по сниженной цене.   Примечания:   данные получены с помощью опросов пользователей, которые успели опробовать демо-версию приложения. Задачи, за которые не нужно выходить:   добавить в предложении функции и инструменты дополненной реальности, чтобы каждый пользователь мог использовать нужную ему косметику на аватаре и проверить, как она выглядит в деле; добавить возможность регистрации покупателей и настроить рассылку всех актуальных предложений на почту; добавить возможность отменить рассылку, если пользователь не хочет ее получать; добавить раздел со скидками и как отдельный блок на странице с товарами.

---

Пример №4: как повысить лояльность клиентов через раздел с отзывами

Тема: добавить на сайт компании-поставщика продуктов для кафе и ресторанов раздел с отзывами   История 1: как владелец кафе, я хочу знать, как отзываются о поставщике продуктов коллеги, чтобы оценить качество продуктов и сроки доставки.   История 2: как сотрудник санитарной службы, я хочу знать реальные отзывы покупателей, чтобы дать начальную оценку их качеству.   История 3: как розничный покупатель, я хочу понимать, что за продукты я покупаю, чтобы знать, стоит заказывать или нет.   Примечания:   информация получена через опросники на самом сайте, а также анализ трафика и сравнение с трафиком конкурентов. Задачи, за которые не нужно выходить:   создать полноценную страницу с отзывами в интерактивной форме; собрать базу отзывов с помощью владельцев или опросов клиентов — нужны реальные данные, фотографии людей, а также способы связи с ними; добавить отдельный раздел с видео-отзывами.

---

Пример №5: улучшить пользовательский интерфейс приложения

Тема: улучшить пользовательский интерфейс приложения: работа с текстом, плашками, формами и шрифтами   История 1: как пенсионер, который занимается с помощью этого приложения, я хочу без проблем читать текст, чтобы не приближать постоянно телефон к глазам и не надевать очки.   История 2: как человек без медицинского образования, я хочу понимать эффективность программы и иметь возможность связаться с экспертом, чтобы задать ему все вопросы.   История 3: как человек, который следит за своим питанием и водным балансом, я бы хотел видеть, сколько я пью воды регулярно и сколько вешу, чтобы следить за своим здоровьем полноценно.   Примечания:   все данные получили после запуска демо-версии в узком кругу лиц. Задачи, за которые не стоит выходить:   добавить на основной экран интерактивную таблицу, в которой будет указан вес и рост, количество потребленной еды и выпитой воды; добавить возможность указывать все эти данные при регистрации в приложении; добавить окошко для связи с врачом клиники, который проконсультирует по вопросу; увеличить все шрифты и уникализировать их, поработать над читаемостью текста и соразмерно увеличить все плашки.

---

Пример №6: добавить плейлист в приложение, который можно пополнять через поиск

Тема: добавить возможность поиска музыки, создать плейлист и возможность добавлять в него музыку   История 1: как любитель слушать музыку постоянно, я хочу иметь возможность создавать и пополнять свой плейлист любимыми песнями, чтобы слушать их в любое время.   История 2: как пользователь, я хочу интерфейс попроще, чтобы сразу находить свои плейлисты и искать новую музыку в этом же разделе.   Примечания:   после запуска приложения посыпались отзывы о неудобстве интерфейса — в основном, на Google Play; об отсутствии плейлистов писали в поддержку приложения — этого не хватает, чтобы слушать бесплатную музыку онлайн. Задачи, за которые не нужно выходить:   добавить плейлисты в приложение; настроить возможность слушать только онлайн; объединить разделы поиска и плейлистов в один; поработать над пользовательским интерфейсом — плейлисты пользователей добавить на главную страницу, перенести меню с разделами вниз, чтобы оно было перед глазами; актуализировать библиотеку с песнями и настроить ее пополнение.

---

Пример №7: улучшить безопасность приложения банка

Тема: улучшить настройки безопасности в приложении банка N   История 1: как клиент банка, я хочу видеть проверку личности по отпечатку пальца, чтобы точно знать, что никто не залезет в это приложение.   История 2: как представитель банка N, я хочу убрать возможность восстановления пароля по почте или номеру телефона, чтобы клиенты лично на сайте банка или в офисе меняли эти данные.   Примечания:   информация получена от представителей банка после выпуска демо-версии приложения; данные также взяли через прямой опрос людей, которые использовали демо-версию. Задачи, за которые не нужно выходить:   добавить возможность входа по отпечатку пальца, код-паролю или логину и паролю владельца карты; убрать возможность восстановления через почту и добавить кнопку для перехода на сайт банка; улучшить скорость приложения за счет оптимизации всей системы и отдельных инструментов.

Вывод

User story — это эффективный инструмент для организации работы внутри IT-отдела. Но система может подойти для команд из любых сфер, в которых требуется решать много сложных задач быстро.

Главное не только выучить всю механику, — как составлять эпики, а потом истории —  но и войти в контекст вместе с командой: устраивать регулярные собрания по обсуждения всех историй, эпиков, целей и задач.

Для внедрения такой методики нужно хорошо освоить навык анализа аудитории, а также запомнить структуру историй и эпиков. Кроме того, необходимо обоюдное участие всей команды и ее заинтересованность, а еще софт, в котором можно будет визуализировать все задачи и истории.

Качественные PBN-сети под ключ! Команда с опытом более 7 лет. Для продвижения, тестов или получения трафика.

Как вы считаете, помогает ли оптимизировать процесс разработки юзер стори?

1 голос

Судя по всему, да — 100% Не, что-то непонятное — 0%

*запрещенная в РФ организация

User Story: пора применять правильно

Мария Родина,
Консультант проектов в М. Видео-Эльдорадо

User story (пользовательская история) считается одним из самых простых способов описания бизнес-требований. Многие считают именно user story главным инструментом для продакт-менеджера: это помогает ему простыми словами объяснить разработчикам, что и зачем должно быть сделано.

Обманчивая простота


На курсах продуктового менеджмента про user story обычно рассказывают так: «это очень просто – пишите, кто вы, что вы хотите и как вы будете это использовать». И начинающие продуктовые менеджеры начинают думать, что это действительно так легко и не требует более глубокого погружения в детали.

Шаблон для пользовательской истории выглядит так:


Пример примитивный, но сразу понятно, что охотнику и молодому человеку нужны разные квадроциклы. И продавец-консультант в магазине вряд ли порекомендует таким клиентам одну и ту же модель.

На этом этапе начинающие продакты устраивают праздник. Для них обучение закончено, они идут ставить первые задачи команде. Команда в шоке.

Примеры таких историй:


Пример 1:
Как оператор колл-центра, я хочу, чтобы по отмененным заказам в CRM передавался признак declined по интерфейсу 139.


Разберем ошибки:
а) Оператору колл-центра не важно, какой признак передаётся в системе. Ему важно отображение статуса заказа на карточке клиента или карточке заказа, потому что он будет использовать в работе пользовательские интерфейсы, а не технические логи.

б) По такой истории разработчик будет пытаться передать статус именно по 139 интерфейсу. Правильно ли это с точки зрения архитектуры? Нет ли другого интерфейса, который уже передает нужную информацию? Этого продуктовый менеджер не знает. Оставьте технические детали на усмотрение специалистов, они могут предложить решение лучше.


Пример 2:
Как владелец сайта, я хочу добавить на карточку товара красную кнопку «Купить», чтобы повысить конверсию.


Ошибки:
а) Что должно происходить при нажатии кнопки? Куда она ведёт?

б) «Чтобы повысить конверсию» — это не описание ожидаемого результата. Тем более, повышать конверсию можно разными способами. Лучше написать «чтобы при нажатии пользователь попадал на экран оформления заказа». История должна отражать сценарий использования.

в) Добавить кнопку вместо имеющейся? Или на карточке должно быть две кнопки? Это уже придирка, но об этом тоже было бы неплохо подумать при формулировке user story.

Пример 3:
Как маркетолог, я хочу добавлять к каждой покупке подарок, чтобы повысить лояльность клиентов.


К этой истории есть один комментарий, но он очень важный:
А не проще ли передать это требование складу в виде инструкции или распоряжения и отправить им подарки, предназначенные для вложения в заказ? История выглядит так, будто разработка не нужна совсем.

Смысл и назначение user story


Ещё Майк Кон, известный во всём мире agile-коуч, говорил, что «пользовательские истории не являются конечными требованиями к системе, и не предназначены быть полезными в конце итерации» (в книге «User stories applied»). В первую очередь, пользовательские истории нужны для того, чтобы выяснить, что нужно клиенту. Так ищутся основные боли пользователя и возможные способы их исправления.

Следующий этап – обсуждение каждой истории с заказчиком. На этом этапе каждая история детализируется до уровня, который позволит описать верхнеуровневые требования к системе. И после этого этапа для каждой истории появляется Definition of Done – критерии готовности, по которым можно понять, что требование выполнено.

Итак, три этапа:


1. Пишем истории
   
2. Обсуждаем и детализируем истории
   
3. Определяем критерии готовности
   
4. При необходимости, повторяем пункты 2-3 еще несколько раз.



Проверка user story


И даже после нескольких таких итераций пользовательские истории могут нуждаться в улучшении. Проверить это можно с помощью метода INVEST:

• I (Independent) – ваша история не зависит от выполнения других историй
• N (Negotiable) – вы уже несколько раз обсудили историю
• V (Valuable) – реализованная история принесет реальную бизнес-ценность
• E (Estimable) – возможно оценить трудозатраты, необходимые для выполнения истории
• S (Small) – историю можно реализовать за одну итерацию
• T (Testable) – есть понятные критерии приемки и тестовые сценарии для проверки реализации

Пример хороших user stories:

Пример 1:
Как куратор онлайн-курса, я хочу знать имя и контакты заинтересовавшихся курсом посетителей сайта, чтобы направить им по e-mail информацию о старте курса.

Пример 2:
Как пользователь мобильного приложения, я хочу на листинге видеть шильдики акций, в которых участвует товар, чтобы понимать, какие бонусы получу за покупку.

Что может пойти не так?


1. Вы написали лучшую пользовательскую историю за всю вашу карьеру, она отвечает принципам INVEST, уже готовы сценарии тестирования. И в этот момент у заказчика меняются требования. Если вы оставите историю без изменений, она может не принести пользы. Не бойтесь вносить корректировки даже в идеальную user story.
2. Ваша история написана хорошо, но понятна только вам и заказчику из-за использований специфических терминов, аббревиатур и сокращений. Или наоборот, после обсуждения с командой разработки появилось слишком много технической информации, которую уже не понимает заказчик. Помните, что история должна быть понятна всем.
3. После детализации истории она занимает лист А4. Вы уверены, что вся информация необходима? История не должна занимать всю вашу доску с требованиями к продукту.
4. Все истории понятны и достаточно детализированы, но описывают сценарии использования только для одного типа пользователей. Вспомните всех, кто будет пользоваться продуктом и на кого повлияет ваш продукт.
5. Ваших историй слишком много в бэклоге, в них уже сложно ориентироваться. Старайтесь поддерживать бэклог в актуальном состоянии, вычеркивайте ненужные истории (и удаляйте их из jira/trello/etc.). Поставьте свое ограничение на общее количество пользовательских историй и соблюдайте его. Идеального числа нет, экспериментируйте.
6. Вы переносите ваши истории из бэклога продукта в бэклог спринта без изменений. Помните, что для бэклога спринта каждую user story необходимо разбить на подзадачи, понятные для разработчиков. Это зона ответственности scrum-мастера, IT проджекта, архитектора или кросс-системного аналитика, в зависимости от распределения ролей в вашей компании. Подзадачи должны быть максимально чёткими и понятными для исполнителя.
7. Ваш спринт целиком состоит из задач по реализации пользовательских историй. Оставляйте время для устранения багов и технического долга, чтобы не копить проблемы.
8. Команда уже реализовала половину историй, а владелец продукта не провел приемку ни одной. Прогресс спринта зависит от приемки задач, не затягивайте с этим этапом. Поздняя приемка не оставляет времени на исправление ошибок, из-за этого будет расти список задач на следующие спринты, а общее количество выполненных задач при этом не изменится.

Выводы:


1. Поймите, чего хочет пользователь. Обсудите и детализируйте каждое требование.
2. Опишите сценарий использования в формате user story с соблюдением принципа INVEST.
3. Удостоверьтесь, что история понятна и заказчику, и исполнителям.
4. Самые приоритетные истории разбейте на подзадачи и включите в ближайший спринт.
5. Наименее ценные истории удалите из бэклога продукта.
6. Организуйте приемку выполненных историй на протяжении всего спринта.

Автор: Мария Родина, Консультант проектов в М.Видео-Эльдорадо

Больше интересного в Telegram-канале @pmclub


Понравилась статья?

понятие, преимущества использования, процесс написания

О чем речь? User Story в переводе с английского означает «пользовательская история». Ее задача – как можно более понятно описать особенности конкретного продукта, его функциональные возможности и ценность для конечного потребителя.

На что обратить внимание? Есть определенные правила составления User Story, а также критерии оценки получившегося в итоге материала. И только изучив их досконально, можно рассчитывать, что описание продукта будет сформулировано грамотно.

В статье рассказывается: 

1. Понятие User Story
2. Задачи, решаемые User Story
3. Преимущества пользовательских историй
4. Простой шаблон user story
5. Критерии INVEST для User Story
6. 6 полезных советов по написанию пользовательской истории
7. 7 распространенных ошибок при составлении User Story

8. Пройди тест и узнай, какая сфера тебе подходит:
   айти, дизайн или маркетинг.

   Бесплатно от Geekbrains

Суть User Story

User Story – термин, который обозначает общее описание возможностей программы. Текст воспринимается читателем так, как будто его создавал другой пользователь. В нем говорится о ценности каждой функции ресурса. Примечательно, что User Story – это некий обзор, который представлен в формате повествования.

Суть User Story

Важно, что любое программное обеспечение нужно разрабатывать максимально гибко, поэтому внимание разработчика должно быть сфокусировано непосредственно на человеке, который будет им пользоваться. Таким образом, пользовательский опыт – это центральная часть всего процесса. Повествование пишется не техническим языком, его задача заключается в предоставлении команде специалистов контекста. Когда последние прочитают user story, они смогут ответить на следующие вопросы:

• Что они делают?
• Зачем?
• В чем заключается ценность разработки?

В какой-то мере User Story следует воспринимать как альтернативу спецификации требований и сценария использования. Но, тем не менее, они имеют ряд существенных отличий друг от друга:

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

Задачи, решаемые User Story

Сразу отметим, что создание User Story имеет огромную важность, так как решает большое количество задач:

• Рассказывает о потребностях целевой аудитории.
• Оказывает содействие в группировке потребностей на задачи для разработчиков проекта.
• Принимает участие в оценке ресурсов, которые пригодятся в работе.
• Делает контекст задачи максимально понятным для всех участников команды.
• Является базой, на основании которой будет проводиться тестирование с настоящими пользователями.
• Дает возможность правильно расставить приоритеты среди поставленных разработчиками задач.
Задачи, решаемые User Story

Этот перечень не окончательный. На самом деле список задач гораздо шире. Кроме того, User Story применяется не только для разработки приложений. Историю следует воспринимать как представление себя в контексте некоторой ситуации. С ее помощью появляется возможность четче понять потребности целевой аудитории.

Преимущества пользовательских историй

Отметим, что некоторые разработчики приложений не видят необходимости в создании User Story. Они склонны считать, что для создания нового ресурса достаточно разбить одну большую задачу (эпик) на несколько маленьких и последовательно решать их. Главное достоинство пользовательской истории заключается не в пошаговом руководстве, а в определении взаимосвязи между задачами и ценностью, которая становится актуальной после их выполнения.

На этом преимущества не заканчиваются. Остальные приведем ниже:

Простой шаблон User Story

Есть определенный шаблон, на основании которого пишется User Story. Его использует подавляющее большинство разработчиков. Чаще всего он состоит из одного или двух предложений, для их написания используется следующая формула:

как <роль или тип пользователя>, я хочу/могу <выполнить действие или получить результат>, чтобы <получить ценность>.

Есть смысл детального рассмотрения шаблона:

• Описание пользователя, того, кто находится по другую сторону монитора. Здесь следует нарисовать максимально подробный портрет, профессии и характеристики занимаемой должности, скорее всего, будет недостаточно. Важно понять, как размышляет человек, в чем заключается его работа, какие цели он ставит перед собой при выполнении служебных обязанностей. Будет идеально, если получится взять интервью у пользователя.
Простой шаблон User Story
• Функциональность будущего приложения. Важно, чтобы описание функционала включало в себя не только саму фичу, но и цель, которую ставит перед собой пользователь разработки.
• Выгода. Осваивая новое приложение, пользователь знает, какие проблемы ему необходимо решить. В результате он должен получить некоторую выгоду. Какую? Это стоит описать в UserStory.

Топ-30 самых востребованных и высокооплачиваемых профессий 2023

Поможет разобраться в актуальной ситуации на рынке труда

Подборка 50+ ресурсов об IT-сфере

Только лучшие телеграм-каналы, каналы Youtube, подкасты, форумы и многое другое для того, чтобы узнавать новое про IT

ТОП 50+ сервисов и приложений от Geekbrains

Безопасные и надежные программы для работы в наши дни

pdf 3,7mb

doc 1,7mb

Уже скачали 19885

Если говорить простым языком, то пользовательская история – это ответ на 3 вопроса, которые укомплектованы в одно предложение:

• Кто является пользователем приложения?
• Что он будет с ним делать и какой результат получит?
• В чем заключается цель использования?

Чтобы стало понятнее, рассмотрим конкретные примеры:

• Как <пользователь социальной сети>, хочу <видеть в новостях исключительно веселые публикации>, чтобы <не чувствовать апатию>.
• Как <гипотоник>, я хочу <поддерживать артериальное давление на нормальном уровне постоянно>, чтобы <не пользоваться тонометром несколько раз в день>.
• Как <бармен>, я хочу <научить наливать стакан пива максимально быстро>, чтобы <оперативнее обслуживать посетителей>.
• Как <новый работник организации> хочу <понять, что такое Scrum> чтобы <работа в компании была более продуктивной>.
• Как <бренд-менеджер> хочу <чтобы мне приходили уведомления о рекламе продукции моей компании от торговых представителей по стоимости, ниже той, о которой мы договорились >, чтобы <у меня была возможность оперативной защиты своего бренда>.
• Как <директор отдела, работающего удаленно >, я хочу, <чтобы в наш общий чат был добавлен функционал по общему использованию файлов, аннотаций и различных документов>, чтобы <сотрудники имели возможность работать в коллективе в режиме реального времени и иметь доступ к архивным файлам>.

Отметим, что пользователи в разных User Story могут быть одними и теми же людьми, история формируется исходя из их потребностей. Поэтому для каждой задачи необходимо написать отдельную историю.

На основании вышеприведенных примеров можно сделать очевидный вывод, что User Story имеет огромную ценность, так как позволяет понять пользователя в любой сфере деятельности.

Критерии INVEST для User Story

INVEST — термин, который используют для их запоминания. По ним можно провести аналитику User Story и сделать вывод, насколько качественно выполнена работа.

• Independent (Независимый)

Истории между собой не должны быть зависимыми, чтобы впоследствии не столкнуться с проблемами во время имплементации. К примеру, одна из задач не может быть решена без решения последующей, но при этом первая из них является обязательной, а вторая лишь желательной. Увы, в реальности добиться независимости не всегда возможно, поэтому специалистам периодически приходится разбивать одну User Story на несколько более мелких задач.

• Negotiable (Обсуждаемый)

После того, как будет готов черновик пользовательской истории, необходимо обсудить заготовку с заинтересованными лицами. При необходимости вносятся изменения.

Критерии INVEST для User Story

Во время переговоров еще не обсуждается, как будет происходить реализация User Story. На этом этапе идет речь о том, каким способом будут удовлетворяться потребности пользователей.

• Valuable (Ценный)

Каждая User Story имеет полезное значение. Польза проявляется не только в отношении конечного потребителя, но и самого продукта. С ее помощью можно четче определить его ценность и понять, для чего нужна реализация.

Точный инструмент «Колесо компетенций»

Для детального самоанализа по выбору IT-профессии

Список грубых ошибок в IT, из-за которых сразу увольняют

Об этом мало кто рассказывает, но это должен знать каждый

Мини-тест из 11 вопросов от нашего личного психолога

Вы сразу поймете, что в данный момент тормозит ваш успех

Регистрируйтесь на бесплатный интенсив, чтобы за 3 часа начать разбираться в IT лучше 90% новичков.

Только до 9 марта

Осталось 17 мест

• Estimable (Оцениваемый)

Пользовательской истории должна быть присуща предельная ясность. Таким образом, разработчики смогут заранее определить, насколько сложная перед ними стоит задача, сколько сил придется вложить. Именно так проводится оценка задачи, невозможность ее выполнения можно объяснить тремя причинами: история слишком длинная, в документе не хватает сведений, у разработчика недостаточно опыта для выполнения задания.

• Small (Компактный)

Многие разработчики считают, что для пользовательской истории есть смысл установить определенные рамки, за пределы которых она не должна выходить. Речь идет о размерах и времени, отведенном на реализацию. К примеру, есть правило, которое гласит о том, что пользовательская история должна быть выполнена за один день. Конечно, из правила бывают исключения, и на выполнение задачи уходит даже несколько месяцев, но этот срок, как правило, устанавливается заранее.

• Testable (Тестируемый)

Любая User Story нуждается в тестировании. Необходимо убедиться, что она действительно имеет что-то такое, что можно реализовать.

7 полезных советов по написанию пользовательской истории

7 полезных советов по написанию пользовательской истории

История должна включать в себя максимально подробное описание потребностей пользователей.

• В написании User Story не должно быть привязки к различным составляющим пользовательского интерфейса.
• User Story – это документ, важной составляющей которого является описание конечного результата, необходимого компании.

7 распространенных ошибок при составлении User Story

• Предположим, что вы написали качественную UserStory, которая полностью отвечает критериям INVEST и успешно прошла тестирование. Вы считаете, что работа по созданию истории выполнена. Но в один момент ваш клиент решил изменить требования. Если вы не внесете изменения, пользы будет мало. Поэтому, даже если результат превзошел все ожидания, корректировки все же нужно сделать.
• Как бы хорошо не была написана история, старайтесь, чтобы она была понятна не только для вас и заказчика. Использование специфических и профессиональных терминов является нежелательным. Также следует избегать аббревиатур и сокращений.
• Полный лист формата А4 – это много для пользовательской истории. Перечитайте ее и подумайте, какие данные лишние?
• Если у продукта несколько типов пользователей, это нужно отразить в истории. Многие разработчики пишут UserStory лишь для одного типа, тем самым не раскрывают полностью ценность продукта.
• Вы перегружаете свой бэклог историями, вследствие чего вам самим тяжело в них разобраться. Есть смысл навести порядок, убрать то, что уже утратило свою актуальность.
• У вас уже реализовано большое количество Story, а вот заказчики не торопятся принимать их. Но ваш успех зависит именно от последних. Поторопите владельцев продукта, если работы будут приняты слишком поздно, у вас не останется времени на редактирование.
7 распространенных ошибок при составлении User Story
• Многие разработчики пренебрегают обсуждениями, а зря. Обратная связь дает возможность прояснить непонятные моменты, вовремя найти и устранить ошибки. Помните, что вы команда, и ваши действия должны быть слажены.

Итак, User Story – это мощный инструмент, который позволяет создать нужный продукт. При использовании методики обязательно поддерживайте связь со своей командой и клиентами, а также своевременно вносите изменения.

Рейтинг: 5

( голосов 1 )

Поделиться статьей

Как правильно написать user stories оценить стоимость разработки, доработки CRM Bitrix24

Расти семимильными шагами, помогая другим. Как мы создавали маркетплейс для INTERTOP Прочитать кейс

Начать проект

Как правильно написать user stories для Bitrix24 CRM

Как получать быструю, адекватную оценку стоимости проекта одновременно с готовой документацией

Знакомо ли вам это: вы обращаетесь в IT компанию с просьбой оценить стоимость разработки, а в ответ получаете отговорки в ключе: пришлите «нормальное» ТЗ и тогда мы посчитаем. Или завуалированное предложение щедро оплатить составление подробнейшей спецификации, а затем, на основании её уже сделать расчет стоимости?

При этом никто не может толком объяснить что такое «нормальное» ТЗ. А также никто не гарантирует, что стоимость разработки после составления такового, может оставаться приемлемой.

Так уже давно никто не делает.


“

После того как был описан метод представления требований бизнес уровня через user stories все остальное безнадежно устарело.

User Story — это короткая формулировка намерения, описывающая что-то, что система должна делать для пользователя.

User Story не являются детальным описанием требований (то-есть детального описания интерфейса, реакций на действие), а представляет собой обсуждаемое представление намерения

Является короткой и легко читаемой, понятной разработчикам, стейкхолдерам и пользователям

Самое главное: каждая user story легко поддаётся эстимированию, таким образом, усилия, необходимые для реализации, могут быть быстро определены

Ваша идеальная user story должна выглядеть так:

Как, РОЛЬ пользователя>, я ДЕЙСТВИЕ>, ЦЕННОСТЬ>

Критерии приемки:

Обработка ошибок:

Технические заметки:


Роль


Это пользователи или группы пользователей
Например у вас в Системе их не очень много — Пользователь, Гость, Оператор и Админпстратор


Действие


Это суть истории, «что нужно сделать». Что можно улучшить. Действие должно быть одно — основное. Нет смысла описывать «авторизуется и выполняется поиск» или «указывает параметры поиска и выполняет поиск». Укажите то действие, что вам действительно нужно.
Важно описывать историю на уровне «ЧТО?» делает, а не «КАК?» Это главное в истории. Опишите проблему, а не ее решение.


Ценность


Ваша история обязательно должна иметь ценность (результат), обязательно должна оказывать влияние на кого-то. Это влияние ведет в конечном итоге к цели, которая имеет для вас ценность.
Возможно заменять понятия ценности (value) на влияние (impact).


Выкладываем примеры, как выглядят пользовательские истории из реальных проектов

Пример описания user story #1

Пример описания user story #2

Пример описания user story #3

Подготовив user story вы сформулировали бизнес-ценность для конечного пользователя. Но прелесть пользовательской истории еще в том, что она формулирует не только бизнес-ценность, но и требования для разработки и тестирования, служит прекрасной business level документацией для быстрого понимания что делает ваша система.


Советы по написанию пользовательских историй

• Лучше написать много историй поменьше, чем несколько громоздких
• Каждая история в идеале должна быть написана избегая технического жаргона
• Истории должны быть написаны таким образом, чтобы их можно было протестировать Тесты должны быть написаны до кода.
• Как можно дольше стоит избегать UI. История должна выполняться без привязки к конкретным элементам.
• Каждая история должна содержать оценку.
• История должна иметь конечную ценность — т.е. приводить к конкретному результату. Или оказывать влияние
• История должна вмещаться в итерацию

Scrum guide

Критерии «INVEST» для оценки качества user story

Scrum guide:

Independent. Reduced dependencies = easier to plan

Aniart:

Независимая. Максимально уменьшены взаимозависимости с другими историями. Историю легко выделить и реализовать

SCRUM guide:

Negotiable. Details added via collaboration;

Aniart:

Обсуждаемая. Описание достаточное для понимания всеми участниками, после прочтения все готовы вносить дополнения

Scrum guide:

Valuable

Aniart:

Несет понятную ценность

Scrum guide:

Estimable. Too big or too vague = not estimable

Aniart:

Пригодна к оценке. Слишком большие или нечетко сформулированные истории сложно оценить конкретно

Scrum guide:

Small. Can be done in less than a week by the team;

Aniart:

Достаточно компактная чтобы быть сделанной менее чем за неделю при работе всей командой.

Scrum guide:

Testable. Good acceptance criteria;

Aniart:

Тестируемая. Достаточные критерии приемки, чтобы проверить историю на соответствие им

Что интересное мы делаем еще

Понравилась статья? Поставьте свою оценку, чтоб мы понимали о чем писать еще.

user stories для Bitrix24

Голосов: 7 , Рейтинг: 4. 87

У Вас есть проект?

Давайте обсудим его. Придумаем. И сделаем!

Оставить заявку

• ЛІЦЕНЗІЙНА УГОДА НА ВИКОРИСТАННЯ ПО Банкінформ
• Как автоматизация всего одного основного процесса влияет на бизнес
• 5 стадий интеграции CRM-системы
• Когда нужен редизайн сайта?
• Купить Битрикс 24 — Bitrix24. Тариф Задачи+
• Как легально получить скидку 50% на Битрикс24
• Купить Битрикс 24 — Bitrix24. Тариф CRM+
• В декабре лицензию можно купить значительно дешевле на Битрикс и Битрикс24
• Купить Битрикс 24 — Bitrix24. Тариф Команда
• Купить Битрикс 24 — Bitrix24. Тариф Компания

пользовательских историй | Примеры и шаблон

Резюме:  История пользователя — это неформальное общее объяснение функции программного обеспечения, написанное с точки зрения конечного пользователя. Его цель состоит в том, чтобы сформулировать, как функция программного обеспечения будет представлять ценность для клиента.

Заманчиво думать, что пользовательские истории — это, проще говоря, системные требования к программному обеспечению. Но это не так.

Ключевой компонент гибкой разработки программного обеспечения — ставить людей на первое место, а история пользователя ставит конечных пользователей в центр разговора. Эти истории используют нетехнический язык, чтобы предоставить контекст для команды разработчиков и их усилий. После прочтения пользовательской истории команда знает, почему они создают, что они создают и какую ценность они создают.

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

Что такое гибкие пользовательские истории?

Пользовательская история — это наименьшая единица работы в гибкой структуре. Это конечная цель, а не функция, выраженная с точки зрения пользователя программного обеспечения.

Пользовательская история — это неформальное общее объяснение функции программного обеспечения, написанное с точки зрения конечного пользователя или заказчика.

Цель пользовательской истории — сформулировать, как часть работы принесет клиенту определенную ценность. Обратите внимание, что «клиенты» не обязательно должны быть внешними конечными пользователями в традиционном смысле, они также могут быть внутренними клиентами или коллегами в вашей организации, которые зависят от вашей команды.

Пользовательские истории — это несколько предложений на простом языке, описывающих желаемый результат. Они не вдаются в подробности. Требования добавляются позже, после согласования с командой.

Истории прекрасно вписываются в agile-структуры, такие как scrum и kanban. В скраме пользовательские истории добавляются в спринты и «сгорают» в течение всего спринта. Канбан-команды собирают пользовательские истории в свой бэклог и запускают их в своем рабочем процессе. Именно эта работа над пользовательскими историями помогает скрам-командам лучше оценивать и планировать спринты, что приводит к более точным прогнозам и большей гибкости. Благодаря историям канбан-команды узнают, как управлять незавершенным производством (WIP), и могут дополнительно совершенствовать свои рабочие процессы.

Истории пользователей также являются строительными блоками более крупных гибких структур, таких как эпики и инициативы. Эпики — это большие рабочие элементы, разбитые на набор историй, а несколько эпиков составляют инициативу. Эти более крупные структуры гарантируют, что повседневная работа команды разработчиков (в магазинах) способствует достижению организационных целей, встроенных в эпики и инициативы.

Узнайте больше об эпиках и инициативах

Зачем создавать пользовательские истории?

Для команд разработчиков, плохо знакомых с Agile, пользовательские истории иногда кажутся дополнительным шагом. Почему бы просто не разбить большой проект (эпопею) на серию шагов и не приступить к делу? Но истории дают команде важный контекст и связывают задачи с ценностью, которую эти задачи приносят.

Истории пользователей имеют ряд ключевых преимуществ:

• Истории фокусируют внимание на пользователе. Список дел позволяет команде сосредоточиться на задачах, которые необходимо отметить, а набор историй помогает команде сосредоточиться на решении проблем реальных пользователей.
   
• Истории позволяют сотрудничать. Определив конечную цель, команда может работать вместе, чтобы решить, как лучше всего обслуживать пользователя и достигать этой цели.
   
• Истории стимулируют творческие решения. Истории побуждают команду к критическому и творческому мышлению о том, как лучше всего решить конечную цель.
   
• Истории создают импульс.  С каждой новой историей команда разработчиков получает удовольствие от небольшого испытания и маленькой победы, что придает импульс.

Посмотрите, как пользовательские истории работают в Jira Software

Работа с пользовательскими историями

После написания истории пришло время интегрировать ее в ваш рабочий процесс. Обычно история пишется владельцем продукта, менеджером продукта или менеджером программы и отправляется на рассмотрение.

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

Другим распространенным шагом на этом собрании является оценка историй в зависимости от их сложности или времени до завершения. Команды используют размеры футболок, последовательность Фибоначчи или планирование покера, чтобы сделать правильные оценки. История должна быть рассчитана на завершение за один спринт, поэтому, когда команда определяет каждую историю, они обязательно разбивают истории, которые преодолеют этот горизонт завершения.

Как писать пользовательские истории

При написании пользовательских историй учитывайте следующее:

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

После четкого определения пользовательских историй убедитесь, что они видны всей команде.

Шаблон истории пользователя и примеры

Истории пользователей часто выражаются простым предложением, структурированным следующим образом:

«Как [персонаж], я [хочу], [чтобы]».

Разбивка этого: 

• «Как [персона]»: для кого мы это создаем? Нам нужна не просто должность, нам нужна личность человека. Макс. У нашей команды должно быть общее понимание того, кто такой Макс. Мы надеемся, что взяли интервью у многих Максов. Мы понимаем, как этот человек работает, как он думает и что чувствует. Мы сочувствуем Максу.
• «Хочет»: здесь мы описываем их намерения, а не функции, которые они используют. Чего они на самом деле пытаются достичь? Это утверждение должно быть свободным от реализации — если вы описываете какую-либо часть пользовательского интерфейса, а не то, какова цель пользователя, вы упускаете суть.
• «Так что»: как их непосредственное желание сделать что-то это вписывается в их общую картину? Какую общую выгоду они пытаются достичь? Какая большая проблема требует решения?

Например, пользовательские истории могут выглядеть так:

• Как Макс, я хочу пригласить своих друзей, чтобы мы могли вместе пользоваться этой услугой.
• Как Саша, я хочу организовать свою работу, чтобы лучше контролировать ситуацию.
• Как руководитель я хочу иметь возможность понимать успехи моих коллег, чтобы я мог лучше сообщать о наших успехах и неудачах.

Эта структура не обязательна, но полезна для определения готовности. Когда эта персона может уловить желаемую ценность, тогда история завершена. Мы призываем команды определить свою собственную структуру, а затем придерживаться ее.

Начало работы с гибкими пользовательскими историями

Пользовательские истории описывают, почему и что стоит за повседневной работой членов команды разработчиков, часто выражаясь как персонаж + потребность + цель . Понимание их роли как источника правды о том, что делает ваша команда, а также почему, является ключом к гладкому процессу.

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

Макс Рекопф

Как самопровозглашенная «кукла хаоса» я обращаюсь к agile-практикам и принципам бережливого производства, чтобы навести порядок в своей повседневной жизни. Я с удовольствием делюсь этими уроками с другими в многочисленных статьях, выступлениях и видео, которые я делаю для Atlassian 

17 Полезные примеры пользовательских историй, которые помогут вам начать работу

Мы используем файлы cookie, чтобы обеспечить вам наилучшие впечатления от наш сайт. Для получения дополнительной информации нажмите здесь. Понятно

Нужна помощь в написании пользовательских историй? Направьте свою команду на правильный путь с помощью этих замечательных примеров пользовательских историй!

С чего начать разработку успешного приложения или веб-сайта, который станет хитом среди ваших пользователей? Пользовательские истории — ваш лучший друг в сочетании с инструментом каркаса!

Начните создавать прототипы для своих пользователей уже сегодня с Justinmind.

Это бесплатно. Неограниченное количество проектов!

Истории пользователей помогают нам вписать образы наших пользователей в контекст разрабатываемого нами продукта. В то время как биография пользователя описывает его жизнь и беды, история пользователя описывает, как он использует функцию вашего продукта — с точки зрения непрофессионала!

В agile-среде владельцы продукта вместе с UX-дизайнерами, как правило, пишут пользовательские истории на каталожных карточках, чтобы передать их команде дизайнеров и вызвать обсуждение. Мы также можем записать их в цифровом виде, используя Office или Google Docs, чтобы включить их в бэклог Scrum.

Тот факт, что они написаны простым языком и лишены технического жаргона, означает, что команда дизайнеров не чувствует себя ограниченной техническими аспектами. У них больше возможностей проявить творческий подход к своим дизайнерским идеям. Прочтите несколько замечательных примеров пользовательских историй!

17 практических примеров пользовательских историй

Мы собрали несколько примеров того, как пользовательские истории могут выглядеть в реальной жизни. в качестве примеров цифровых пользовательских историй, которыми можно легко поделиться на онлайн-платформе.

Некоторые даже поставляются в виде загружаемых шаблонов, таких как файлы Word и Excel! Давайте углубимся:

1. Пример пользовательской истории Product Plan

Этот пример истории пользователя План продукта состоит из пяти важных разделов. Во-первых, это название рассказа. Для этого вы можете указать название функции, о которой будет рассказ, например, «рецензии на книги».

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

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

2. Пример пользовательской истории в Word Doc

Этот загружаемый пример пользовательской истории представляет собой документ Word, который вы можете редактировать. На наш взгляд, инструкции, которые следуют после каждого пункта в пользовательской истории, а также инструкции по критериям приемлемости, довольно просты для выполнения.

Почему важно иметь эти инструкции в шаблоне пользовательской истории? Потому что, если ваша команда какое-то время не писала пользовательские истории или вам нужно работать над многими историями, полезно иметь такие инструкции в качестве подсказки. Они служат полезным напоминанием о качестве информации, которая должна содержаться в каждом пункте.

3. Пример пользовательской истории Excel

Какой лучший способ сгруппировать информацию в таблицах, чем Excel? Этот пример пользовательской истории excel также немного отличается тем, что, помимо обычных полей, он также дает вам возможность заполнить другую важную информацию.

Дополнительные поля, которые вы можете найти в этом примере пользовательской истории, включают бизнес-ценность пользователя, расчет риска, стоимость задержки и взвешенную самую короткую работу в первую очередь. Эта дополнительная информация также может быть полезна в зависимости от типа функций продукта, над которыми вы работаете, или типов клиентов или компании, на которую вы работаете.

4. Пример тематической истории пользователя

В этом примере тематической истории на основе Excel вы получаете столбец для оценки приоритета, критериев приемлемости, а также столбец «Выпуск» для даты выпуска.

Столбцы в этом примере пользовательской истории упорядочены: темы расположены вертикально, а типы столбцов — горизонтально. Это был бы отличный шаблон для эпической истории, состоящей из нескольких под-историй.

Начните создавать прототипы для своих пользователей уже сегодня с Justinmind. Это бесплатно. Неограниченное количество проектов!

5. Пример эпической пользовательской истории

Говоря об эпических примерах пользовательской истории, вы можете взглянуть на этот шаблон эпической пользовательской истории. Это отличный способ сгруппировать подистории по их эпическим историям.

Каждый элемент эпической истории расположен вертикально, столбцы предназначены для пользователя, действия или желания и выгоды. Последний столбец состоит из вертикального расположения пользовательских историй в подстроках, заключенных в каждую ячейку.

То, как организована эта эпическая пользовательская история, позволяет показать четкую иерархию между эпиками и их многочисленными подробными пользовательскими историями. Это позволяет очень легко сканировать и быстро просматривать все функции, которые необходимо применить или разработать, чтобы удовлетворить пользователя.

6. Пример пользовательской истории PowerPoint

Этот загружаемый пример пользовательской истории от Powerslides показывает нам еще один изящный способ организации наших пользовательских историй. Эти карточки можно показать в презентации Powerpoint, а также распечатать и раздать.

Нам также нравится четкое разделение наиболее важных разделов: история пользователя и идентификатор пользователя, а также несколько разделов, которые отличают его от других примеров.

В разделе истории мы можем увидеть историю пользователя и критерии приемлемости. Тем не менее, в разделе идентификатора пользователя есть область, куда вы можете прикрепить изображение своего пользователя, а также несколько флажков для типа функции, на которую он ориентирован, и поля для приоритета и оценки времени.

7. Пример пользовательской истории каталожных карточек

Что нам нравится в этой старой доброй пользовательской каталожной карточке, так это простота и то, как она возвращает вещи к основам. Иногда вам может понадобиться быстро набросать историю для функции продукта или краткий обзор функций, таких как эпопея.

Этот простой и традиционный пример пользовательской истории показывает нам, насколько простым это может быть. Самое замечательное в каталожных карточках то, что вы также можете написать критерии приемлемости на обратной стороне, а затем карточку пользовательской истории можно передать команде.

8. Пример пользовательской истории спереди и сзади

Здесь у нас есть традиционный пример пользовательской истории спереди и сзади, который отражает, как можно написать историю пользователя на каталожной карточке. История наглядно показывает, чего хочет добиться пользователь и почему он этого хочет.

В этом случае они хотят отменить бронирование, чтобы не потерять все свои деньги в случае возникновения ситуации.

На обратной стороне карты перечислены все критерии приемлемости. Он показывает все функции приложения, о которых необходимо позаботиться, чтобы преимущества пользователя и преимущества бизнес-целей были удовлетворительно достигнуты.

9. Пример пользовательской истории банковского приложения

Этот пример пользовательской истории банковского приложения — отличный способ кратко объяснить необходимую функцию и зачем она нужна пользователю.

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

Пользователь в этом примере пользовательской истории хочет погасить свой баланс, поэтому первое, что может сделать команда дизайнеров, — это начать работу над решением, которое даст им более или менее мгновенный доступ к балансу их кредитной карты. Либо это должно быть первое, что они увидят, когда откроют приложение, либо должна быть четкая возможность увидеть баланс этой карты одним касанием.

10. Гибкий шаблон написания пользовательской истории

Наш следующий пример пользовательской истории от Whizible также является шаблоном, который вы можете загрузить, чтобы дать вам и вашей команде фору.

Этот шаблон позволяет написать список нескольких пользовательских историй на одной карточке. Горизонтальные столбцы вверху отображают шаблонное предложение типичной пользовательской истории, а это означает, что пробелы нужно просто заполнить. Например, из этого примера пользовательской истории с первого взгляда можно понять, что у контент-менеджера есть следующая история:

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

11. Пример истории пользователя Amazon

Мы выбрали этот пример истории пользователя Amazon, потому что он дает нам представление о типе истории, ожидаемой в гибкой среде в крупной многонациональной технологической компании. Самое интересное, что это действительно просто. Здесь нет технического жаргона, и его может понять любой человек из любой дисциплины, в чем и заключаются пользовательские истории.

В этом примере пользователь зарегистрирован у них и хочет купить Kindle для своего друга. Один из способов, которым команда может отреагировать на эту историю, в зависимости от того, кто их пользователь, может состоять в том, чтобы включить раздел подарков на главный экран. Это может быть что-то вроде «Идеальный подарок на день рождения». С другой стороны, они могут отображать сообщение, которое сообщает пользователю, что он может мгновенно отправлять подарки, когда просматривает такие элементы, как Kindle.

Еще одно действие, за которым они могут захотеть следить, — убедиться, что клиент может быстро и легко добавлять новые адреса или выбирать свой текущий список адресов. Если вы используете Amazon, вы увидите, что это действительно так!

Начните создавать прототипы для своих пользователей уже сегодня с Justinmind.

Это бесплатно. Неограниченное количество проектов!

12. Пример невыполненных пользовательских историй

В этом примере мы получаем представление о том, как выглядит список пользовательских историй в невыполненной работе в гибкой среде разработки продукта.

Как мы видим здесь, элементы невыполненной работы сгруппированы в порядке приоритета, а задачи представлены пользовательскими историями. В каждой пользовательской истории мы можем отметить различные очки схватки, присуждаемые, чтобы указать, сколько работы потребуется, когда речь идет о каждой функции.

13. Пример пользовательской истории BBC Sport

Нам нравится этот простой пример пользовательской истории от BBC Sport. Что нам нравится в нем, так это то, что он на самом деле передает много информации всего в нескольких словах, а это именно то, что должна делать хорошая пользовательская история.

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

14. Пример пользовательской истории Easy Agile Workshop

Этот пример пользовательской истории из Easy Agile немного отличается. Во-первых, мы заметили, что это удивительно приятно для глаз.

Во-первых, в каждом ряду цвет чередуется с белым, чтобы упростить разделение концепций и облегчить сканирование. Левая и правая части карты, то есть инструкции и формула предложения, имеют зеленый и синий цвета.

Далее, инструкции слева от этого примера пользовательской истории помогают служить полезной подсказкой с категориями «Кто», «Что» и «Почему». Они помогают нам думать об истории с точки зрения бизнеса, например, «Для кого мы это создаем?», «Кто пользователь?» и «Каково намерение?» Если бы этот пример был продублирован, он был бы невероятно полезен и послужил бы простой подсказкой для начала написания пользовательских историй.

15. Примеры пользовательских историй на веб-сайте о путешествиях

Вот несколько примеров пользовательских историй на туристическом веб-сайте. Мы рассматриваем четыре разные истории, которые дают нам представление о различных функциях, которые они могут разработать, чтобы помочь своим пользователям достичь своих целей.

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

Функция всегда должна приносить пользу пользователю. Это поможет вашей команде отдать приоритет конкретным функциям, которые будут иметь реальную ценность и значение для ваших пользователей. А счастливые пользователи — это успешный продукт и счастливый бизнес.

В первом примере речь идет о бронировании отелей. Более полная версия могла бы звучать так:

Как пользователь, я хочу забронировать номер в гостинице недалеко от центра города, чтобы мне не приходилось каждый день далеко ездить.

Маловероятно, что пользователь не имеет в виду конкретное место для отеля, осознает он это или нет. Добавление части «почему» поможет вам придумать более творческие решения, которые могут помочь пользователю, например, показать ему отели, в зависимости от его бюджета, которые находятся ближе к центру города или к аэропорту. Это может помешать пользователю покинуть страницу и искать адреса отелей на картах Google и проверять расстояния. В противном случае это может быть просто любой другой туристический веб-сайт, который не предоставляет пользователю явно полезной функции.

Однако последний пример пользовательской истории завершен и полезен для группы разработчиков; он показывает именно то, что хочет пользователь — иметь возможность сохранять прошлые бронирования и предотвращать дополнительные усилия по вводу данных. Это также может помочь придумать лучшие и более жесткие критерии приемлемости.

16. Пример пользовательской истории Agile USA

Agile USA с их примером пользовательской истории для заметок для менеджера по работе с клиентами кратко описывает, что должно быть в этом типе результатов.

Это довольно простой пример, показывающий, как жизненно важную информацию для руководства проектной группой и командой разработчиков можно легко обобщить на простом стикере. Что нам нравится в этом виде примера, так это то, что он не пугает и легко понятен любому.

Это позволяет вам следовать простой формуле для их написания, что необходимо, когда дело доходит до творчества, особенно когда вам нужно прокручивать историю за историей о функциях продукта в день написания истории.

Начните создавать прототипы для своих пользователей сегодня с Justinmind. Это бесплатно. Неограниченное количество проектов!

17. Интроспективный пример пользовательской истории

Мы решили включить этот пример пользовательской истории от Александра Коуэна, потому что он ясно отражает уровень мысли, который требуется при создании даже самой простой пользовательской истории.

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

Подсказки в этом примере прекрасно помогают вам придумать пользовательскую историю, отражающую образ пользователя, над созданием которого вы и ваша команда потрудились. Что нам также нравится в этом примере с персоной пользователя, так это тот факт, что подсказки также помогают перейти к критериям приемлемости, спрашивая: «Как мы узнаем, работает ли это?».

Вывод — примеры пользовательской истории

Правильный носитель для вашей пользовательской истории и правильная информация для включения в нее будут зависеть от вашей организации, размера и масштаба вашего проекта и сложности функций, которые вы используете. проектирование.

Какой бы способ вы ни выбрали для передачи своей пользовательской истории, самое важное, о чем следует помнить, — это исследования. После того, как вы провели адекватное исследование пользователей и определили профили своих персонажей, вы готовы написать свои пользовательские истории.

Следуя лучшим практикам, изложенным в этом посте, и черпая вдохновение (или даже скачивая) показанные примеры и шаблоны, вы должны быть на пути к написанию отличной пользовательской истории.

ПРОТОТИП · СВЯЗЬ · ПРОВЕРКА

УНИВЕРСАЛЬНЫЙ ИНСТРУМЕНТ ПРОТОТИПИРОВАНИЯ ДЛЯ ВЕБ И МОБИЛЬНЫХ ПРИЛОЖЕНИЙ

Скачать бесплатно

Джозеф Даунс

Штатный копирайтер UX, гурман и любитель классических автомобилей

пользовательских историй и примеров пользовательских историй Майк Кон

Что такое пользовательские истории?

Пользовательская история — это короткое простое описание функции, рассказанное с точки зрения человека, которому нужны новые возможности, обычно пользователя или клиента системы. Пользовательские истории обычно строятся по простому шаблону: 9. 0005

Как , я так хочу .

Исторически сложилось так, что пользовательские истории намеренно сохранялись неформальными, записывались на каталожных карточках или стикерах, хранились в коробках из-под обуви и размещались на стенах или столах для облегчения планирования и обсуждения. Их непостоянство позволяло легко разорвать их, выбросить и заменить новыми историями по мере того, как все больше узнавалось о разрабатываемом продукте.

В настоящее время пользовательские истории можно легко хранить в задаче Jira или на доске Trello. Не позволяйте тому факту, что история пользователя существует в инструменте, сделать вас менее склонным отказываться от историй, когда они больше не нужны!

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

Что такое хорошая история пользователя?

Пользовательские истории Agile состоят из трех аспектов, которые Рон Джеффрис назвал в 2001 году прекрасным сочетанием слов «карточка», «разговор» и «подтверждение»:

1. Карточка : письменное описание истории, используемое для планирования и в качестве напоминания 9. 0043
2. Разговор : Разговоры об истории, которые служат для уточнения деталей истории
3. Подтверждение : Тесты, которые передают и документируют детали, которые можно использовать для определения завершения истории.

Пользовательские истории имеют много преимуществ, но самым важным может быть то, что каждая пользовательская история является заполнителем для будущего разговора.

Как написать пользовательскую историю

Написание хороших пользовательских историй в Scrum требует понимания основного шаблона пользовательской истории, сосредоточения внимания на пользователе или клиенте и четкого представления о желаемой функциональности.

Шаблон пользовательской истории

При написании пользовательской истории помните, что пользовательские истории следуют стандартному шаблону:

Как , я хочу, чтобы .

Примеры пользовательских историй

Один из лучших способов научиться писать пользовательские истории в Agile — это увидеть примеры. Ниже приведен пример пользовательской истории. Это несколько реальных примеров пользовательских историй, описывающих желаемую функциональность в ранней версии веб-сайта Scrum Alliance.

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


Обратите внимание, что вы не видите никаких пользовательских историй: «Как владелец продукта, я хочу список сертификационных курсов, чтобы. ..» Владелец продукта является важной заинтересованной стороной, но не конечным пользователем/покупателем. При создании пользовательских историй лучше всего указать тип пользователя как можно точнее.

 

200 примеров пользовательских историй

Кто пишет пользовательские истории?

Кто пишет пользовательские истории? Любой может писать пользовательские истории.

Пишет ли пользовательские истории владелец продукта?

Владелец продукта должен убедиться, что существует бэклог гибких пользовательских историй, но это не означает, что именно он их пишет. В ходе хорошего agile-проекта вы должны ожидать, что каждый член команды напишет пользовательские истории.

Также обратите внимание, что то, кто пишет пользовательскую историю, гораздо менее важно, чем то, кто участвует в ее обсуждении.

Когда пишутся пользовательские истории?

Истории пользователей пишутся на протяжении всего agile-проекта. Обычно мастер-класс по написанию историй проводится в начале Agile-проекта. Каждый в команде участвует с целью создания бэклога продукта, который полностью описывает функциональность, которая будет добавлена ​​в ходе проекта или трех-шестимесячного цикла его выпуска.

Некоторые из этих гибких пользовательских историй, несомненно, станут эпическими. Эпосы позже будут разложены на более мелкие истории, которые легче впишутся в одну итерацию. Кроме того, новые истории могут быть написаны и добавлены в бэклог продукта в любое время и кем угодно.

Можете ли вы показать другие примеры пользовательских историй?

В качестве более общего примера написания пользовательских историй в Scrum, вот несколько типичных пользовательских историй для сайта объявлений о вакансиях и поиска:

• Пользователь может разместить свое резюме на веб-сайте.
• Пользователь может искать работу.
• Компания может размещать новые вакансии.
• Пользователь может ограничить доступ к своему резюме.

Примеры эпиков 

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

Большие пользовательские истории менее детализированы и обычно называются эпиками.

Вот эпический пример гибкой пользовательской истории из продукта для резервного копирования настольных компьютеров:

• Как пользователь, я могу сделать резервную копию всего моего жесткого диска.

Поскольку эпик, как правило, слишком велик, чтобы agile-команда могла завершить его за одну итерацию, перед началом работы над ним разбивают на несколько более мелких пользовательских историй. Приведенный выше эпос можно разделить на десятки (или, возможно, сотни), включая эти два примера пользовательских историй:

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

Как добавляются подробности в пользовательские истории?

Детали могут быть добавлены к пользовательским историям двумя способами:

• Путем разделения пользовательской истории на несколько более мелких пользовательских историй.
• Путем добавления условий удовлетворения (критериев приемлемости).

Когда относительно большая история разбивается на несколько меньших гибких пользовательских историй, естественно предположить, что детали были добавлены. Ведь написано больше.

Условия удовлетворения — это просто высокоуровневый приемочный тест, который будет верным после завершения гибкой пользовательской истории. Рассмотрим следующий пример в качестве еще одного примера пользовательской истории:

Как вице-президент по маркетингу, я хочу выбрать праздничный сезон для анализа эффективности прошлых рекламных кампаний, чтобы определить прибыльные.

Подробности можно добавить к этому примеру пользовательской истории, добавив следующие условия выполнения:

• Убедитесь, что он работает с крупными розничными праздниками: Рождеством, Пасхой, Днем президента, Днем матери, Днем отца, Днем труда, Новым годом. .
• Поддержка праздников, которые охватывают два календарных года (ни один год не длится три).
• Праздничные сезоны могут быть установлены от одного праздника к другому (например, от Дня Благодарения до Рождества).
• Праздничные сезоны могут быть установлены за несколько дней до праздника.

Заменяют ли пользовательские истории документ с требованиями?

Agile-проекты, особенно Scrum-проекты, используют бэклог продукта, который представляет собой приоритетный список функций, которые должны быть разработаны в продукте или услуге. Хотя элементы бэклога продукта могут быть любыми, какие пожелает команда, пользовательские истории стали лучшей и самой популярной формой элементов бэклога продукта.

Хотя бэклог продукта можно рассматривать как замену документу с требованиями традиционного проекта, важно помнить, что письменная часть гибкой пользовательской истории («Как пользователь, я хочу…») является неполной до тех пор, пока дискуссии об этой истории происходят.

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

Рекомендуемые ресурсы

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

Связанные курсы

Сертифицированный владелец продукта Scrum®

Лучшие пользовательские истории

Примеры пользовательских историй в разработке продукта

Определение: Пользовательская история — это небольшая автономная единица разработки, предназначенная для достижения определенной цели в рамках продукта. Пользовательская история обычно пишется с точки зрения пользователя и следует формату: «Как [персонаж пользователя], я хочу [выполнить это действие], чтобы [я мог достичь этой цели]».

Что такое история пользователя?

В гибкой разработке программного обеспечения пользовательская история представляет собой краткое, простым языком объяснение функции или функциональности, написанное с точки зрения пользователя. Многие agile-эксперты также описывают пользовательскую историю как наименьшую единицу работы по разработке продукта, которая может привести к полному элементу пользовательской функциональности.

Команды разработчиков предпочитают разбивать разработку на пользовательские истории, а не на характеристики продукта или требования к продукту по нескольким причинам.

Истории пользователей:

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

Как выглядит история пользователя?

Большинство продуктовых команд используют аналогичный шаблон пользовательской истории, обычно всего одно или два предложения, написанные в соответствии со следующей формулой: ].

Примеры пользовательских историй

На практике пользовательские истории могут выглядеть следующим образом:

• Как администратор базы данных, я хочу автоматически объединять наборы данных из разных источников, чтобы мне было легче создавать отчеты для своих внутренних клиентов.
• Как бренд-менеджер, я хочу получать оповещения всякий раз, когда торговый посредник рекламирует наши продукты по ценам ниже согласованных, чтобы я мог быстро принять меры для защиты нашего бренда.
• Как руководитель удаленной команды я хочу, чтобы наше приложение для обмена сообщениями включало общий доступ к файлам и аннотации, чтобы моя команда могла сотрудничать в режиме реального времени и хранить архив своей работы в одном месте.

Как видно из третьего примера выше, персона в вашей пользовательской истории не обязательно должна ограничиваться должностью человека. А “ руководитель удаленной команды » может быть менеджером отдела, вице-президентом компании, генеральным директором небольшого стартапа или любой другой должностью в организации.

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

Кто должен писать пользовательские истории?

Во многих agile-организациях владелец продукта берет на себя основную ответственность за написание пользовательских историй и организацию их в бэклоге продукта. Однако на самом деле это общая ответственность всей кросс-функциональной команды разработчиков.

На самом деле, одна из причин, по которой они написаны простым языком — без какого-либо профессионального жаргона или технических подробностей, — заключается в том, что это позволяет любому представителю бизнес- или технической стороны команды внести свою пользовательскую историю для рассмотрения. Этому члену команды (менеджеру по продукту, UX-дизайнеру и т. д.) нужно только иметь представление о конкретной проблеме пользователя, которую он надеется решить. Им не нужно знать, как команда разработчиков на самом деле будет кодировать это решение.

История пользователя и вариант использования: в чем разница?

Как и пользовательские истории, вариант использования описывает, как пользователь может взаимодействовать с продуктом для решения конкретной проблемы. Но они не взаимозаменяемы; это разные инструменты, используемые при разработке продукта.

Ивар Якобсон, которому приписывают разработку концепции вариантов использования, объясняет, что варианты использования документируют как цель пользователя, так и функциональные требования системы. Другими словами, варианты использования предназначены для сбора гораздо большего количества деталей, чем пользовательская история, о процессе, через который проходит пользователь, чтобы достичь желаемого результата от взаимодействия с продуктом.

В то время как пользовательская история записывается как очень краткое изложение, описывающее только конечную цель пользователя, вариант использования часто описывает несколько дополнительных шагов, в том числе:

• Предварительные условия, необходимые для начала варианта использования
• Основной поток событий (также называемый базовым потоком), пошагово описывающий путь пользователя к выполнению действия с продуктом
• Альтернативные потоки и потоки исключений, означающие различные пути, по которым пользователь может пойти с продуктом для достижения той же или похожей цели
• Возможно, наглядная схема, изображающая весь рабочий процесс

Как написать историю пользователя?

Вот простой шестиэтапный процесс создания пользовательских историй:

Шаг 1: Решите, как будет выглядеть «готово».

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

Шаг 2: Задокументируйте задачи и подзадачи.

Хотя ваша реальная история пользователя будет включать только стандартное утверждение, описанное выше — «Как [персонаж], я хочу [функцию], чтобы [причина]» — вам также необходимо будет задокументировать детали, необходимые для завершения работы по разработке. описано в рассказе. Это означает определение задач и подзадач и назначение их нужным людям.

Шаг 3: Определите свои пользовательские профили.

Кого обслуживают в этой истории? Какой тип пользователя или клиента? Вы должны задокументировать это заранее. Если вы имеете в виду несколько разных пользователей, вы можете разбить это на более чем одну пользовательскую историю. Таким образом, ваша команда сможет сосредоточиться на том, чтобы помочь конкретному персонажу достичь определенной цели для каждой истории.

Шаг 4: Создавайте истории в виде упорядоченных шагов.

Концепция отображения пользовательской истории предполагает, что вы можете думать о своем продукте в целом как о серии задач или работ, которые продукт помогает выполнять вашим пользователям. Имея это в виду, если вы пытаетесь структурировать работу над более крупным процессом или более полным набором функций продукта, напишите каждый отдельный шаг в виде истории.

Шаг 5. Получите отзывы пользователей.

Чтобы повысить свои шансы на выделение ресурсов для разработки, которая будет резонировать с вашим рынком, поговорите с пользователями и клиентами об их приоритетах и ​​узнайте, чего еще они хотят от ваших продуктов. Только после сбора и анализа этой обратной связи вы можете приступать к созданию пользовательских историй.

Шаг 6: Набросайте истории, которые можно выполнить за один спринт.

Истории пользователей, которые занимают больше времени, чем один спринт (обычно две недели), должны быть разбиты на более мелкие истории. Таким образом, ваша команда получает ощущение завершения в каждом спринте, потому что каждый раз они могут выполнять какую-то новую функциональность. Это также позволяет вашей команде чаще выводить на рынок новые функции.

Команды по продуктам, почему бы вам не написать, думая о своих пользователях?

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

Истории пользователей помогают вашей команде достичь всего этого — и создавать более качественные продукты — заставляя вас внести одно простое изменение в свой подход к планированию разработки. Вместо того, чтобы писать свои планы с точки зрения продукта (какие функции создавать), пользовательские истории заставляют вас разрабатывать каждую предложенную идею для новой функциональности с точки зрения реальных людей, которые будут использовать эту функциональность.

Примеры историй пользователей — Технический отдел GSA

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

Эпический	История пользователя	Критерии приемки
Как пользователю Acquisition Gateway, мне нужен для доступа к платформе заказов Acquisition за безопасный вход , чтобы я мог покупать продукты.	Как пользователю шлюза приобретения , мне нужно , чтобы выбрать продукт аукциона в окне приобретения. заказываю платформу , чтобы я мог делать ставки на нее. 907:10	Убедитесь, что пользователь шлюза сбора данных может: войти в шлюз сбора данных перейти на страницу аукциона возможность выбрать продукт(ы) для участия в торгах
	Как пользователь Acquisition Gateway, мне нужно , чтобы просмотреть мои предыдущие ставки в Acquisition Gateway. платформа заказа , чтобы я мог удалить просроченные ставки.	Убедитесь, что пользователь шлюза сбора данных может: войти в шлюз сбора данных перейти на страницу, чтобы просмотреть товары, ранее сделанные ставки на выберите одну или несколько предложений с истекшим сроком действия удалить просроченные ставки
В качестве руководителя отдела маркетинга я хочу, чтобы в была система управления контентом , чтобы я мог управлять и предоставлять качественный контент и опыт моим читателям. Источник: Как использовать пользовательские истории для создания вашего веб-сайта	Как владелец контента , я хочу, чтобы мог создавать контент продукта , чтобы я мог предоставлять информацию и рынок для клиентов.	Убедитесь, что владелец контента может: войти в систему управления контентом создать страницу контента изменить/обновить существующую страницу контента сохранить изменения назначить страницу содержимого редактору для проверки
	Как редактор , я хочу, чтобы просматривал контент перед его публикацией , чтобы я мог заверить он оптимизирован с правильной грамматикой и тоном.	Убедитесь, что редактор может: войти в систему управления контентом просмотреть существующую страницу содержимого редактировать/обновлять страницу контента добавить комментарии к разметке — сохранить изменения сохранить изменения переназначить владельца контента для внесения обновлений запланировать публикацию содержимого
Как инициатор запроса EBC , я хочу, чтобы создал бизнес-обоснование для руководителей , чтобы я мог запросить финансирование проекта.	Как заявитель EBC, я хочу, чтобы знал, какой каталог услуг предлагает GSA IT , чтобы я может определить, может ли существующая платформа поддерживать мой предложенный проект. 907:10	Убедитесь, что запрашивающий EBC может: получать / получать доступ к каталогу ИТ-услуг GSA возможность легко сравнивать платформенные технологии и определять сопутствующие расходы
	Как запросчик EBC, я хочу, чтобы у был контрольный список результатов , чтобы я мог отправить завершить запрос EBC.	Убедитесь, что запрашивающий EBC может: получать/доступ к контрольному списку EBC имеет доступ для отправки EBC в Salesforce может создавать/просматривать/редактировать все применимые разделы и материалы, необходимые для отправки EBC
Как менеджер по персоналу , я хочу виртуальную доску вакансий , чтобы я мог просматривать статус работы и управлять потребностями персонала компании. Источник: Как работает Agile Маркетинговая работа?	Мне как менеджеру по персоналу нужно для просмотра статуса кандидата чтобы я мог управлять их процесс подачи заявки на всех этапах набора.	Убедитесь, что менеджер по персоналу может: войти в виртуальную систему доски объявлений о вакансиях просмотр/редактирование/добавление статуса кандидатов на работу Обновление для каждого этапа (например, проверка телефона завершена, запланировано личное собеседование, проверка биографических данных в процессе и т. д.) отправить персоналу электронное сообщение о кандидате
Как аналитик маркетинговых данных, я хочу, чтобы создавал прогнозы и отчеты о тенденциях , чтобы я может поддерживать усилия по продажам торговых представителей региона 9. Источник: Как работает Agile Маркетинговая работа?	Как аналитик маркетинговых данных , мне нужен для запуска аналитических отчетов Salesforce и Google. , чтобы я мог составлять ежемесячные планы кампаний в СМИ.	Убедитесь, что аналитик маркетинговых данных может: получать доступ к отчетам Salesforce и Google Analytics создать ежемесячный план кампании в СМИ для указанного региона (например, региона 9) доступ к списку контактов отправить по электронной почте подготовленную ежемесячную медиа-кампанию одному или нескольким выбранным контактам

Пример и шаблоны пользовательских историй Agile

В этой статье вы узнаете о пользовательских историях, 3 элементах пользовательской истории, кто ее пишет, как ее писать, как ИНВЕСТИРОВАТЬ в пользовательские истории, различные типы пользовательских историй с примерами и критерии приемлемости.

Кроме того, узнайте больше о будущем разработчиков Power BI.

Что такое история пользователя?

User Story – это инструмент, с помощью которого требования излагаются простым и понятным языком и с точки зрения конечного пользователя.

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

В Agile-разработке программного обеспечения пользовательские истории используются для выражения требований с точки зрения конечного пользователя. Формат пользовательской истории: 

 Как <пользователь>
Я хочу <выполнить действие>
Так что < я ожидаю…. >  

• <Пользователь> – это конечный пользователь или роль пользователя в прикладном программном обеспечении – «Как клиент интернет-банка» 
• <выполнить действие> – действие, которое пользователь выполняет в прикладном программном обеспечении – “ Я хочу добавить получателя в свой аккаунт» 
• <Я ожидаю. .> — результат, желаемое значение, ожидаемое пользователем от выполненного действия – «чтобы я мог перевести деньги добавленному получателю»
• Более крупный истории называются «эпиками», которые затем разлагаются на «функции», а затем разлагаются на «пользовательские истории».
• Эпический пример: Как банк я хочу предоставлять клиентам интернет-банкинг, чтобы они могли выполнять различные транзакции.
• Приведенный выше Epic можно разложить на несколько функций: несколько примеров: 
• Как банк, я хочу предоставить клиентам функцию перевода средств, чтобы они могли переводить средства с одного счета на другой 
• Как банк , я хочу предоставить сводную информацию по всем типам учетных записей клиентов.
• Как банк, я хочу предоставить клиентам данные кредитной карты.
• Теперь каждую функцию можно разбить на несколько пользовательских историй.

Пользовательские истории, исходя из предполагаемого размера, берутся для реализации в итерации. Пользовательские истории должны быть достаточно детализированы, чтобы их можно было завершить в рамках одной итерации и нельзя было продолжить в следующей итерации. Если история не может быть завершена за одну итерацию, она должна быть логически разделена. Пользовательские истории расставляются владельцем продукта по приоритету в зависимости от бизнес-приоритета и доступны в верхней части списка невыполненных работ по продукту. Команда разработчиков собирает истории в журнал итерации и реализует их. Определение готовности (DOD) для пользовательских историй определяется командой, которая включает в себя критерии приемлемости и процессы, которым необходимо следовать, такие как модульное тестирование, регрессионное тестирование, проверка кода и т. д. История считается «готовой» только тогда, когда он соответствует заданному определению готовности.

Узнайте больше о гибком и традиционном управлении проектами.

Кто пишет пользовательские истории?

Итак, кто отвечает за написание пользовательских историй в agile-команде?

Обычно считается, что только владельцы продукта должны писать пользовательские истории, поскольку именно они выявляют требования от заинтересованных сторон. Однако на практике любой член Agile-команды может писать пользовательские истории, хотя общая ответственность лежит на владельце продукта. Владелец продукта должен просмотреть истории и расставить приоритеты в бэклоге продукта. В ходе agile-проекта каждый член команды поощряется и должен писать пользовательские истории.

Подготовьтесь к собеседованию, ответив на эти популярные вопросы о микросервисах.

Когда пишутся пользовательские истории?

Написаны ли истории пользователей в начале проекта традиционным способом?

Пользовательские истории пишутся на протяжении всего жизненного цикла проекта. В начале проекта пользовательские истории пишутся в спринте «0», также называемом предварительным спринтом. Первоначально владелец продукта получает требования от заинтересованной стороны, и они сохраняются как EPICS, Features и User Stories в невыполненной работе продукта. Требования к гибкой разработке программного обеспечения постоянно уточняются, и, следовательно, необходимость написания пользовательских историй будет возникать на протяжении всего проекта. Они пишутся в основном во время сеанса подготовки бэклога, когда владелец продукта разбивает эпики/фичи на детализированные истории. Команда разработчиков пишет истории вместе с владельцем продукта во время этой сессии, а также участвует в 3 C (это описано в следующем разделе).

подтверждение в 3C пользовательских историй 

• «Карточка», «Разговор» и «Подтверждение» — это модель, которая фиксирует компоненты пользовательской истории. Эта модель широко известна как модель 3C, которая помогает Agile-команде планировать и оценивать пользовательские истории.
• Карточка — обозначает заметку Post-It или физическую карточку, обычно размером 3 x 5 дюймов, на которой фиксируется важная информация пользовательской истории. Карточка должна содержать достаточно информации (не слишком мало и не слишком много), которую команда может понять, чтобы спланировать и оценить историю.
• «Беседа» — это разговор, который происходит между владельцем продукта и командой разработчиков для обсуждения истории и деталей. Это может быть и беседа с пользователями системы. Этот разговор также выявляет творческий потенциал команды разработчиков и раскрывает любые невыявленные потребности пользователей.
• «Подтверждение» — здесь выявляются критерии приемлемости истории, основанной на приведенном выше разговоре. Этот критерий будет использоваться для оценки истории заинтересованными сторонами, когда пользовательская история реализуется командой разработчиков.

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

Затем команда разработчиков оценивает пользовательскую историю с помощью доступной информации. Разговор между командой разработчиков и владельцем продукта продолжается до тех пор, пока не будет достигнут консенсус в отношении деталей и критериев приемлемости, а также до тех пор, пока команда не сможет определить тот же размер. Этот раунд разговора может повториться во время сеанса планирования итерации/спринта. Затем команда разработчиков реализует историю в итерации, которая проверяется владельцем продукта или заинтересованными сторонами в конце итерации. Затем они примут историю на основе критериев приемлемости, определенных для истории.

Вы также можете ознакомиться с записью в блоге о том, как Agile-команды могут использовать процесс анализа основных причин «5 почему», чтобы определить основную причину проблемы.

Зачем создавать пользовательские истории?

Какие преимущества получит команда, документируя потребности заинтересованных сторон в виде пользовательских историй?

• Позволяет команде понять требования с точки зрения пользователя.
• Основное внимание уделяется тому, чтобы пользователь приносил ему пользу; пользовательская история четко описывает ожидаемый результат каждого выполненного действия.
• Такой способ сбора требований дает команде возможность больше сотрудничать с владельцем продукта и бизнес-пользователями.
• Проводя беседы (в 3 C), команда может выявить скрытые требования, а также предложить творческие решения.
• Обеспечивает общее понимание требований к команде, чтобы все знали об исходе/цели истории и находились на одной волне.
• Истории пользователей помогают команде достигать небольших приращений продукта.
• Пользовательские истории более понятны всем заинтересованным сторонам (техническим/нетехническим/деловым/операционным).
• Истории пользователей помогают команде внедрять функции небольшими итерациями продолжительностью от одной недели до одного месяца.
• Истории пользователей позволяют команде постепенно прорабатывать ее, когда они могут отложить историю до тех пор, пока не будет получено больше ясности.
• Пользовательские истории помогают создать прозрачность приоритетов, определенных владельцем продукта и клиентом.
• Пользовательские истории помогают разработчикам, владельцам продукта и владельцам бизнеса прийти к общему мнению в процессе обсуждения деталей и согласования критериев приемлемости. С помощью инструмента пользовательских историй и курса CSM или PMP профессионалы могут улучшить свои карьерные навыки в гибком управлении проектами.
• Это помогает заинтересованным сторонам определить приоритеты функций продукта, а также помогает принимать правильные решения в нужное время.

ИНВЕСТИРОВАТЬ в истории пользователей




Это аббревиатура для набора атрибутов или критериев, которые помогают нам оценить качество пользовательской истории. Если какой-либо из атрибутов в истории не соответствует требованиям, это означает, что команда может подумать о том, чтобы переписать пользовательскую историю.

• Независимый  – Пользовательские истории не должны зависеть от других историй. Между ними не должно быть пересечений. Однако они могут следовать друг за другом в такой последовательности, что их легко запланировать и внедрить.

Это одна из проблем, с которой сталкивается команда, особенно когда они только начали адаптировать гибкие методы работы. У них может быть история, которая зависит от чего-то еще, что может быть сделано другой командой. Команды могут надеяться, что смогут запустить две истории параллельно, и к тому времени, когда первая команда закончит, зависимая команда также завершит свою часть истории. Это неправильный способ запуска пользовательских историй, так как это может привести к путанице и обвинениям.

Преимущество независимых историй заключается в том, что между командами не возникает игра в вину. Это также позволяет учитывать зависимости и придумывать инновационные способы их устранения, чтобы стать независимыми.

• По договоренности  – История не должна быть настолько подробной, чтобы стать обязательным документом. Если это слишком подробно, это не дает команде разработчиков возможности поговорить с владельцем продукта или бизнесом. История должна быть написана с достаточным количеством деталей, чтобы она проложила путь к открытым дискуссиям с владельцем продукта или компанией и помогла выявить детали или найти креативные решения. Обсуждая историю с соответствующими заинтересованными сторонами, команды могут прийти к общему пониманию.
• Ценный  –  История должна быть ценной для покупателя. В нем должно быть четко указано, почему мы это делаем? Как это будет создавать ценность для клиента? Какую ценность получит клиент, реализовав эту историю?

Единственная причина, по которой пользовательские истории должны быть частью бэклога продукта, заключается в том, что они повышают ценность для клиента, верно?

• Приблизительно  – Пользовательские истории должны быть достаточно подробными, чтобы команда разработчиков могла их понять и оценить. Разговор в формате 3 C помогает команде раскрыть детали с владельцем продукта и заинтересованными сторонами, чтобы они могли оценить историю. Если история слишком большая и недостаточная, тогда ее следует уточнить или разложить на части. Любая информация, которая может потребоваться команде, должна быть доступна в истории, чтобы они могли ее оценить. В случае, если есть часть истории, где команда должна провести исследование, тогда может быть создана «спайковая» история, в то время как остальная часть истории может быть оценена и принята для реализации.
• Маленький  – Хорошие пользовательские истории должны быть небольшими. Это не относится к размеру или количеству слов, написанных в истории. Небольшая история имеет правильную длину, чтобы команда реализации могла завершить историю за одну итерацию. Он должен быть достаточно маленьким, чтобы история была «полностью доставлена» во время итерации.

Небольшая история пользователя помогает команде разрабатывать и тестировать быстро и легко.

• Тестируемая — Хорошая пользовательская история должна быть тестируемой, чтобы быть «Готовой». Это подтверждается «Подтверждением» в 3 C, где команда выдвигает критерии приемлемости для каждой истории после подробного разговора с заинтересованными сторонами.
  Клиент должен четко понимать, что он должен тестировать во время проверки. Если он не ясен, то история недостаточно хороша для реализации.
  Команда работает вместе, чтобы ИНВЕСТИРОВАТЬ в хорошие истории. Команда учится писать хорошие пользовательские истории, работая вместе, а также активно обдумывая ценности и критерии, изложенные в INVEST.

Типы пользовательских историй  

Пользовательские истории можно разделить на функциональные и технические типы: 

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

Технические. Технические истории пишутся для поддержки функциональных историй. Технические истории можно классифицировать как

• Истории инфраструктуры — любые дополнения/модификации инфраструктуры, которые могут потребоваться для поддержки функциональной истории
• Рефакторинг — истории такого типа пишутся для поддержки кода и решения технических проблем. Это также можно использовать для нужд проектирования и автоматизации 
• Spikes — истории, требующие исследования архитектуры и дизайна, которые, в свою очередь, могут помочь удовлетворить функциональные потребности клиента.
Примеры пользовательских историй  

В этом разделе рассмотрим несколько примеров пользовательских историй (Epics, Features и User Story).

. на предстоящий квартал

ID	EPICS
e1	1104 E19.	11104 e1	11104 e1
E2	As a Banking Customer, I want to access net banking, so that I can access my account and make transactions
E3	As an Administrator of программного обеспечения, я хочу получить доступ к основным записям, чтобы иметь возможность вносить изменения в данные клиента0041
E2F1	As a Banking Customer, I want to access Savings account so that I can view/make transactions
E2F2	As a Banking Customer , Я хочу получить доступ к странице кредитной карты, чтобы просматривать и совершать транзакции
E2F3	Как клиент банка, я хочу получить доступ к странице кредитов, чтобы просматривать свои кредиты
E2F4	As a Banking Customer, I want to transfer funds, so that I can move my funds to different accounts within my bank and other banks

9071 собственные счета, чтобы я мог перемещать часть остатка между своими счетами

ID	Истории пользователей
E2F1U1	Как клиент банка, я хочу получить доступ/просмотреть сводку своего сберегательного счета, чтобы знать свой баланс и другие данные
E2F2U1	Как клиент банка, я хочу войти в систему интернет-банкинга, чтобы просмотреть данные кредитной карты
E2F4U1
E2F4U2	Как клиент банка, я хочу перевести средства со своего счета на другой счет в другом банке, чтобы я мог отправить деньги своей семье и друзья, у которых есть счета в других банках
E2F4U3	.	Как администратор Net Banking, я хочу иметь резервную копию данных клиента, чтобы иметь возможность восстановить их в любое время в случае возникновения проблем
E2TU2	другой банк, использующий специальный форматированный XML, чтобы можно было переводить средства в зависимости от потребностей клиентов

Заключение

Преобразование документации по требованиям пользователей в Документ функциональных требований (FRD) или Спецификацию требований к программному обеспечению (SRS) в традиционном управлении проектами в сторону пользовательских историй в Agile-управлении проектами — это масштабный шаг. Это помогает изменить представление о том, как команды могут лучше понять клиента и сотрудничать с ним, сместив фокус реализации на ценность, которую клиент может понять из истории. Это изменение сработало очень хорошо с точки зрения удовлетворения требований и ожиданий заказчика.

No related posts.