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

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

Пользовательская история (User story) описывает тип пользователей, чего они хотят и почему. Этот инструмент помогает создать упрощенное описание требований, но при этом таковым не является. Требования — это другой инструмент, с более сложной структурой и описанием.

Обычно User story используют при разработке по методологии Agile. Ранее мы писали, как происходит работа при гибком подходе. На этапе дискавери-фазы обычно разбивают разработку продукта на пользовательские истории, а не на характеристики или требования.

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

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

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

Как [описание пользователя ], я хочу [ функциональность ], чтобы [ выгода ].

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

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

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

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

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

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

Источник

User Story: как писать качественные пользовательские истории

#Дизайн и аналитика

Время чтения: 8 минут

Отправим вам статью на:

Что такое User Stories?

Для чего применяется User Story?

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

Структура User Story

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

и [ещё немного контекста]…

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

User Story: примеры

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

INVEST критерии написания User Story

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

V — Valuable. Ценная. Это достаточно простой и понятный пункт: пользовательская история должна быть ценной, и описанный функционал должен приносить бизнесу пользу.

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

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

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

Подпишитесь

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

Источник

Основы пользовательских историй. Часть 1. Введение

Перевод: Александр Якима (www.enter-agile.com)
Независимый консультант, agile-тренер. В IT-индустрии с 2002 года. Работал менеджером проектов, программ, а также присейл-менеджером в аутсорсинговых компаниях и директором по разработке в стартапах Силиконовой долины. В 2007-2008 сотрудничал с тренинг-центром Luxoft.

Аннотация:
В этой статье мы предлагаем обзор происхождения и приложений пользовательских историй, являющихся ключевым механизмом в гибких методах разработки и служащих проводником требований заказчика сквозь поток ценностей. В свою очередь, пользовательские истории являются критическим элементом в статьях «Бережливая и масштабируемая информационная модель требований для гибких компаний» и «Общая картина гибкости компании», обе статьи можно найти в блоге. Текущая же статья извлечена из будущей книги «Гибкие требования: бережливые практики управления требованиями для команд, программ и предприятий», издание которой запланировано на 2010 год. Отдельная благодарность Дженнифер Фосетт (Jennifer Fawcett) и Дону Видригу (Don Widrig) за их вклад в работу над книгой.

О терминологии (примечания автора перевода):
Центральным объектом статьи, как читатель уже мог догадаться, является пользовательская история, в оригинале звучащая как user story. Существует несколько различных, в том числе и довольно экстравагантных переводов этого термина (напр., «пожелание»). Однако при переводе я решил пользоваться исключительно практическими мотивами, именно поэтому мы используем термин «пользовательская история» в несколько официальном ключе и для непосредственных выкладок — «стори». Дело в том, что именно этот термин преобладает в быту большинства гибких команд при работе с англоязычными заказчиками и поэтому вполне оправдан.

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

Они были на великом пиру языков, но довольствовались крохами.
— паж Моль к Костарду, «Напрасный труд любви», Уильям Шекспир

Введение

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

Стори служит также метафорой всему нашему подходу, базирующемуся на инкрементальной доставке ценностей, а именно:

Определить полезную стори — реализовать и оттестировать в рамках короткой итерации — продемонстрировать и/или доставить ее пользователю — получить фидбек — усвоить информацию — повторить в цикле!

Я уже вкратце приводил обсуждение пользовательских историй в контексте моих более широких статей: «Бережливая и масштабируемая информационная модель требований для гибких компаний» и «Общая картина гибкости компании»(1), в которых наряду с темами, эпосами и фичами, стори являются первостепенными артефактами требований, используемых гибкими командами.

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

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

В вышеупомянутых статьях и связанных с ними публикациях в блоге я подчеркивал существенность вклада Скрам-модели в гибкие практики для компаний, отмечая, к примеру, само определение роли продакт оунера (product owner), являющейся неотьемлимой по отношению к работе с требованиями. Но самим изобретением пользовательской истории мы обязаны XP и именно сторонники XP и разработали всю широту и глубину этого артефакта. Хотя это значительно менее значимое «методологическое распутье», чем это может показаться, так как пользовательские истории сейчас обычно входят в рамки Скрам-курсов как средство построения бэклога и определения состава Спринта. Наверняка мы должны благодарить Майка Кона (Mike Cohn) за большую часть этой интеграции, так как он обстоятельно проработал пользовательские истории в своей книге User Stories Applied [см. Cohn 2004], и был очень активным в сообществе Scrum Alliance.

Для наших целей мы определим пользовательскую историю так:

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

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

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

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

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

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

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

Билл Вейк (Bill Wake), один из создателей XP, описывает это следующим образом(2):
Пиджин (pidgin) — упрощенный язык, обычно используемый в торговле, позволяет людям, которые не могут общаться на своем родном языке, тем не менее работать вместе. Пользовательские истории действуют подобным образом. Мы не ждем от заказчика или пользователей точно такого же видения системы, как у разработчиков; стори действуют как пиджин, где обе стороны всегда могут договориться, чтобы эффективно вместе работать.

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

Пользовательские истории — это не требования

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

Литература
Cohn, Mike. 2004. User Stories Applied: For Agile Software Development. Boston, MA: Addison-Wesley.

Источник

10 советов для написания хороших пользовательских историй

Также приглашаем всех желающих участвовать в открытом вебинаре на тему «Как спроектировать REST API и не умереть?». Участники вместе с экспертом на занятии рассмотрят следующие моменты:

• Основные плюсы и фичи REST API;
• Правильное разделение ресурсов в REST API;
• Наследование ресурсов и абстрактные ресурсы.

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

Скачать аудиоверсию можно здесь.

1. Пользователи прежде всего

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

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

2. Используйте персонажей, чтобы найти правильные истории

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

Но это еще не все: цели персонажей помогают вам выявлять правильные истории: спросите себя, какую функциональность должен обеспечивать продукт для достижения целей персонажей (я объясняю это в своей статье «От персонажей к пользовательским историям». Вы можете скачать удобный шаблон для описания своих персонажей с romanpichler.com/tools/persona-template.

3. Совместное создание историй

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

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

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

4. Делайте истории простыми и лаконичными

Пишите истории так, чтобы их было легко понять. Старайтесь делать их простыми и лаконичными. Избегайте путаницы и двусмысленных терминов, используйте активную речь. Сосредоточьтесь только на том, что важно, и не отбросьте все остальное. Приведенный ниже шаблон помещает пользователя или покупателя, смоделированного как персонажа, в историю и ясно показывает ее преимущества. Он основан на широко известном шаблоне Рейчел Дэвис, но я заменил роль пользователя (user role) на имя персонажа, чтобы соединить историю с соответствующим персонажем.

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

5. Начните с эпиков

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

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

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

6. Уточняйте истории, пока они не будут готовы

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

7. Добавьте критерии приемлемости

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

8. Используйте бумажные карточки

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

9. Делайте ваши истории видимыми и доступными

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

10. Не полагайтесь исключительно на пользовательские истории

Для создания хорошего пользовательского опыта (user experience, UX) требуется нечто большее, чем пользовательские истории. Пользовательские истории полезны для отражения функциональности продукта, но они не подходят для описания пользовательского пути и визуального дизайна. Поэтому дополняйте пользовательские истории другими методами, такими как карты историй (story maps), диаграммы рабочих процессов, сториборды (storyboards), скетчи и макеты.

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

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

Источник

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

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

Просмотр тем

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник