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

Проверка 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

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

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

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

В 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 — прописать четкие критерии приемки.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Истории прекрасно вписываются в 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. Интроспективный пример пользовательской истории

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

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

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

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

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

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

No related posts.