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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Max Rehkopf

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

User Story — инструкция по применению — статья в блоге ScrumTrek

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

User Story (пользовательская история) — короткая формулировка намерения пользователя и что продукт должен сделать для него.

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

• Для описания элементов бэклога
• Для лучшего понимания пользователей
• Для описания требований к продукту на понятном для всех языке: пользователей, разработчиков другие заинтересованных лиц
• Для вовлечения в процесс разработки пользователей и заинтересованных лиц
• Для построения User Story Mapping

Как формулировать User Story?

User Story — это ответы на 3 вопроса, связанные в одно предложение:

• Что это за пользователь?
• Какое действие он хочет выполнить в продукте или какой результат от продукта хочет получить?
• Зачем это ему?

Как <роль или тип пользователя>,

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

чтобы <получить ценность>

Примеры

И ещё немного примеров:

Как <пользователь фейсбука>, хочу <видеть в ленте только позитивные посты>, чтобы <не портить себе настроение>

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

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

Хорошая пользовательская история

INVEST — критерий хорошей истории:

Independent — независимая от других историй, то есть истории могут быть реализованы в любом порядке
Negotiable — обсуждаемая, отражает суть, а не детали; не содержит конкретных шагов реализации
Valuable — ценная для клиентов, бизнеса и стейкхолдеров
Estimable — оцениваемая по сложности и трудозатратам
Small — компактная, может быть сделана командой за одну итерацию
Testable — тестируемая, имеет критерии приемки

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

Мы учим формулировать User Story на тренинге Владелец продукта: краткий курс выживания.

P.S.: серию статей про продуктовые инструменты пишут Роман Баранов и Дмитрий Кустов используя технику pair writing.

Основы пользовательских историй. Часть 1. Введение / Блог компании Luxoft / Хабр

Перевод: Александр Якима (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), сценариям использования и т. п., они все же ощутимо отличаются рядом тонких, но критических нюансов:

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

[ПРОДОЛЖЕНИЕ СЛЕДУЕТ]

Литература

Cohn, Mike. 2004. User Stories Applied: For Agile Software Development. Boston, MA: Addison-Wesley.

Cсылки:

1. www.scalingsoftwareagility.wordpress.com
2. xp123.com/xplor/xp0308/index.shtml
3. Это задача разработки и поддержки приемочных тестов, определяющих поведение системы в деталях, необходимых для регрессионного тестирования.

Шаблон сценария (user story) — популярный подход к описанию задач в SCRUM/Agile

Одна из ключевых проблем в разработке продуктов — взаимопониманием стейкхолдеров и команды, а также всех участников внутри команды. Один из классных подходов с решением проблемы — формат user story.

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

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

Определение из Вики

Пользовательские истории (англ. User Story, вариант перевода Сценарии) — способ описания требований к разрабатываемой системе, сформулированных как одно или более предложений на повседневном или деловом языке пользователя. Пользовательские истории используются гибкими методологиями разработки программного обеспечения для спецификации требований (вместе с приёмочными испытаниямиruen). Каждая пользовательская история ограничена в размере и сложности. Часто история пишется на маленькой бумажной карточке. Это гарантирует, что она не станет слишком большой. В Экстремальном программировании пользовательские истории пишутся пользователями (заказчиками) системы. В методологии SCRUM — пишутся либо одобряются ролью владельца продукта (англ. Product Owner). Для заказчиков (пользователей) пользовательские истории являются основным инструментом влияния на разработку программного обеспечения.

Формат

Хорошо подходит формат user story: «Как <роль>, я хочу делать <это>, чтобы <достигать цели>».

Примеры User Story

• Как Посетитель сайта, я хочу подписаться на интересные для меня продукты, чтобы получать по ним новости и статьи
• Как Владелец Интернет-магазина, я хочу видеть панель управления, чтобы понимать текущее состояние дел и динамику дохода/прибыли

Декомпозиция User Story

Чтобы реализовать задачу типа US, бывает нужно ее декомпозировать.

Можно прописать и структурировать аспекты по задаче. Отлично подходит практика ВИСИ.

Иногда есть смысл сделать ToDo-список по реализации.

А во многих трекерах US можно разбить на подзадачи и отслеживать прогресс выполнения.

1

оцените контент и участвуйте в выборе трендов

Насколько детальной должна быть User Story? / Хабр

В agile-командах часто возникает спор, насколько детально должна быть проработана User Story, прежде чем ее следует передавать разработчикам.

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

Рассмотрим Agile-подход к решению этой проблемы.

Для начала разберемся с концепцией CCC, которая расшифровывается как Card, Conversation, Confirmation.

Card (Карточка)

Идея состоит в том, что вся User Story должна поместиться на небольшую бумажную карточку или стикер. Много на ней не напишешь, да это и не нужно.

Главное предназначение карточки – служить напоминанием, приглашением к обсуждению (placeholder for conversation).

Цель – сместить фокус с написания требований на их обсуждение. Ибо живое обсуждение более важно, чем написанный текст.

Карточка должна коротко, но емко отражать суть задачи. Предлагаемый формат:

Мне как {роль} нужна {функциональность}, чтобы достичь {цели}.

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

При написании User Story рекомендуется сосредоточиться на пользователе нашего приложения (focus on user needs and benefits).

Функциональность лучше описывать не абстрактно, а с использованием живых примеров (by example).

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

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

Карточка User Story служит также для отслеживания статуса задачи, например, на канбан-доске.

Conversation (Обсуждение)

Обсуждение – наиболее важная часть.

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

Общение, в идеале, происходит лицом к лицу (face to face), так как это наиболее эффективный (high bandwidth) способ передачи информации. Важные аспекты живого общения – это его интерактивность (возможность уточнить и удостовериться), а также обратная связь (один из фундаментальных принципов Agile).

Живое обсуждение позволяет преодолеть или свести к минимуму недостатки, присущие документации:

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

Confirmation (Подтверждение)

Третий важный аспект User Story – это подтверждение того, что задача выполнена.

Условия приемки (acceptance criteria), а также Definition of Done, оговоренные заранее, позволят вовремя прекратить работу, оценить, достигнута ли преследуемая бизнес-цель.

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

Насколько же детальной должна быть User Story?

Вернемся к исходному вопросу и рассмотрим две крайности:

1. User Story непроработаны совсем. В этом случае в начале спринта могут возникнуть такие вопросы, получение ответов на которые сильно задержит начало разработки. Задержит ее настолько, что задача не будет выполнена в рамках запланированного спринта. Простой и ожидание снизят нашу эффективность.
2. User Story проработаны максимально, т.е. Product Owner заранее подготовил ответы на все возможные вопросы. В этом случае мы не сможем взять в спринт задачи до тех пор, пока PO их не проработает. Это увеличит нагрузку на PO (стремление предвидеть все возможные вопросы, повторная проработка меняющихся требований, проработка требований по задачам, которые будут отложены или отменены), замедлит его работу, отодвинет разработку важных и срочных требований заказчика, например, полученных в рамках обратной связи.

Очевидно, что мы не хотим впадать ни в одну из этих крайностей. Значит оптимум где-то посередине. Чтобы нащупать его, будем использовать концепции “точно вовремя” (just in time) и “ровно столько, сколько нужно” (just enough).

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

Можно ли достичь такого баланса для каждой User Story? Разумеется нет, но надо постоянно подстраиваться.

Поделитесь, пожалуйста, в комментариях, как вы работаете с User Stories. Актуальна ли для вас описанная проблема? Какие другие проблемы, связанные с User Stories, возникают в вашей команде?

Об авторе: более 15 лет занимаюсь разработкой ПО, работаю в крупном банке в качестве тимлида. Более пяти лет практикую Agile в роли скрам-мастера.

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

История пользователя. Что, зачем и почему она нужна?

Что такое история пользователя? Для чего она нужна? И как “рассказать” правильную историю?

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

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

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

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

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

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

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

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

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

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

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

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

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

По существу, чтобы заполнить форму, вам необходимо:

• определить тот тип пользователей, который вас интересует (как правило, это ваша целевая аудитория)
• понять те действия, которые нужны пользователям
• выяснить почему именно эти действия нужны

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

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

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

Давайте перейдем к конкретным примерам и поймем как же это работает.

–

Простите, что прерываю чтение. Присоединяйтесь к моему telegram канал. Свежие анонсы статей, развитие digital продуктов и growth hack, там все. Жду вас! Продолжаем…

–

Пример истории пользователя: эмоджи

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

Понимаю, как тяжело это представить…

И вот все бы ничего, да видите вы, что время, которое проводят пользователя а вашей платформе, начинает сокращаться. Если раньше в среднем за день человек проводил у вас час, то сейчас это уже 52 минуты. “В чем дело?”, – подумаете вы. Проведете опрос, поговорите с пользователями, в конце концов спросите совет у друзей и тут станет понятно, что пользователям стало скучно, хочется чего-то новенького.

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

Я как пользователь социальных сетей, хочу чего-то новенького, так как мне скучно.

Поштурмили немного с командой и придумали эмоджи (смайлы или эмоциональные реакции). Докрутили немного user story:

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

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

Если историй много

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

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

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

Не забудьте про измерения

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

Критерии приемки – показатели, которые будут подтверждать результат ваших трудов.

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

Два основных вопроса для критериев приемки:

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

Маленький секрет

Будь то разработка на гибких методологиях или же маркетинговое исследование, в результате которого появились истории пользователя, вам обязательно потребуется тесный контакт с реальными пользователями. Команда, которая делает что-то для определенных людей, должна периодически общаться с этими людьми. Узнавайте у своих пользователей, правильно ли вы поняли их боль, делайте customer development и оттачивайте свой функционал до блеска. В противном случае, вы просто один раз снимите данные с пользователей, “запилите” что-то, а в итоге это будет никому не нужно.

Закругляемся

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

Алексей А.

Читайте также:

Интересный ролик от компании Under Armor, атмосферное и заряженное видео.

Вконтакте

Facebook

Twitter

Google+

Загрузка…

User Story Mapping – инструкция по применению — статья в блоге ScrumTrek

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

User Story Mapping (USM, карта пользовательских историй) – инструмент целостного проектирования продукта на основе пользовательского пути.

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

• Для проектирования пользовательского опыта в продукте
• Для определения границ MVP (минимальной работоспособной версии продукта) и планирования релизов на базе пользовательского сценария
• Для формирования единого понимания пользователя у команды разработки и заинтересованных лиц

Как построить User Story Mapping?

Для построения USM вам потребуется:

• Инструмент визуализации: стикеры или электронный инструмент вроде Miro или Mural
• Владелец продукта и команда разработки
• Представление о пользовательском сценарии (если у вас уже есть построенный CJM – берите его за основу)
• 1-2 часа

Ваша задача — спроектировать по шагам действия пользователя в продукте на основе его реального сценария.

Рассмотрим USM на примере

Магазин цветов решил запустить сайт. Визуализируем опыт клиентов с помощью техники USM.

1. Расскажите историю клиента по шагам

2. Сгруппируйте действия клиента в этапы

3. Заполнение пробелов в истории (User Story)

4. Приоритезируйте истории внутри каждого этапа пути

5. Выделите релизы

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

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

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

Мы учим строить USM на тренинге Владелец продукта: краткий курс выживания.

P.S.: серию статей про продуктовые инструменты пишут Роман Баранов и Дмитрий Кустов используя технику pair writing.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Разбивка на части:

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

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

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

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

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

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

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

Max Rehkopf

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

.

Что такое история пользователя и критерии приемлемости (примеры)

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

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

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

Термин «требование» имеет разные названия в разных методологиях проекта.

В Waterfall он называется «Документ с требованиями / спецификацией», в Agile или SCRUM он называется «Epic», «Пользовательская история».

В модели Waterfall документы с требованиями представляют собой огромные документы объемом 200 или более страниц, поскольку весь продукт реализуется за один этап. Но это не относится к Agile / SCRUM, потому что в этих методологиях требования предъявляются к небольшим функциям или функциям, поскольку продукт готовится поэтапно.

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

Давайте сначала вернемся к основам.

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

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

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

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

Пример:

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

Что такое критерии приемки?

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

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

Его формат выглядит следующим образом:

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

Пример (по приведенной выше истории пользователя):

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

Следовательно, пользовательская история определяет требования к любой функциональности или функции, в то время как критерии приемлемости определяют «определение готового» для пользовательской истории или требования.

Для QA очень важно глубоко понимать историю пользователя и его критерии приемлемости, не оставляя ни единого сомнения в «начале тестирования». Двигаясь вперед, давайте разберемся, почему так важно «глубоко» копаться в пользовательских историях и критериях приемлемости.

Углубляясь в истории пользователей

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

Следующие случаи являются моим собственным опытом.

Дело № 1:

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

Вы бы видели, как к вам приезжает доставщик для доставки.И у них есть мобильный телефон, на котором они просят вас поставить свою подпись после доставки. Эта подпись отражается на порталах поставщиков курьерских услуг, таких как DTDC, FedEx и т. Д.

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

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

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

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

Конечно, нет, с этим нужно обращаться любезно.

Решение: Когда соответствующие таблицы БД обновляются для добавления нового столбца для местоположения подписи, старые данные должны иметь значение NULL или 0, которое следует проверить, и должно появиться сообщение «Нет подписи».

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

Дело № 2

6 лет назад я работал над Финансовым приложением для пенсионного планирования (без BA), которое было глобальным приложением, в котором финансовые специалисты, такие как CA, Finance Advisors, могли использовать его для разных валют для прогнозирования инвестиций. планы, сбережения и т. д. в течение длительного периода для своих клиентов.

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

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

a] В отчетах должен учитываться ежедневный курс конвертации валюты, а не исторический, как в последнем просмотренном отчете и

b] Если валюта была изменена после предоставления финансовых данных клиента, отчеты должны отображаться в измененной валюте.

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

Take Away: Их поймали, потому что мы все очень хорошо знали продукты, их дизайн, структуру и т. Д. Такое знание может быть достигнуто только путем полного понимания продукта, понимания взаимодействия модулей и изучения история пользователя основательно, даже если это 2 лайнера.

Делайте заметки, чтобы упростить задачу, и обсуждайте их мнение с БА и разработчиками.

Подробный анализ критериев приемки

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

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

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

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

При следующих критериях приемки:

• Учитывая, что я нахожусь на странице загрузки исторического отчета, я должен выбрать период, за который я хочу загрузить отчет.
• Учитывая, что я нахожусь на странице загрузки исторической выписки, я должен выбрать учетную запись, для которой я хочу загрузить выписку.
• Учитывая, что я нахожусь на странице «Загрузить историческое заявление», мне не должно быть разрешено загружать отчет для будущей даты «До».
• Учитывая, что я нахожусь на странице «Загрузить историческое заявление», мне не должно быть разрешено выбирать дату «С» на 10 лет позже в прошлом.
• Учитывая, что я скачал выписку, я смогу просмотреть загруженный файл.
• Учитывая, что я нахожусь на странице «Загрузить историческое заявление», я должен иметь возможность загрузить свое заявление в форматах doc, excel и pdf.

Если вы пройдете это принятие, здесь не хватит трех вещей:

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

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

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

Важность поиска расхождений в пользовательской истории / критериях приемлемости

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

Потому что это включает:

# 1) Потеря времени:

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

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

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

# 2) Потеря усилий:

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

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

Заключение

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

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

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

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

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

.

Руководство по составлению карт пользовательских историй: шаблоны и примеры (как составить карты пользовательских историй)

Джори МакКей

Джори — писатель, контент-стратег и отмеченный наградами редактор книги Unsplash. Он вносит свой вклад в Inc., Fast Company, Quartz и другие.

14 января 2019 г. · 12 мин чтения

🎁 Бонусный материал: бесплатные шаблоны и карточки

Бэклоги — это интересно. Увидеть все эти потенциальные функции, обновления и исправления ошибок в одном месте, просто полно потенциала… Да, конечно.Прямо сейчас вы, вероятно, думаете, что Я полон чего-то другого, кроме потенциала.

Дело в том, что отставание может сбивать с толку.

Сделайте свой семинар по построению историй для пользователей успешным!

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

Это обычное дело, когда ваша подборка «что можно сделать» превращается в препятствие. Когда вариантов слишком много, с чего начать?

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

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

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

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

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

Давайте начнем с основ: что такое пользовательские истории? А примеры пользовательских историй?

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

Итак: Видение → Цели → Действия → Задачи → Истории пользователей

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Сопоставление пользовательских историй 101: что это такое, кто это делает и когда это происходит

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

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

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

Такой подход дает ряд преимуществ:

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

Кто участвует в картировании пользовательских историй?

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

1. Специалисты в предметной области, тестировщики и UX-дизайнеры: Люди, знакомые с пользователями и функциями
2. Заинтересованные стороны: Люди, имеющие представление о том, как работает программное обеспечение заработает деньги вашей компании
3. Разработчики: Люди, которые знают, сколько времени потребуется на сборку

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

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

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

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

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

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

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

Сделайте свой семинар по построению историй для пользователей успешным!

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

Что вам понадобится: Карты-истории пользователей — это физические предметы (для начала). Важно иметь отдельную комнату и некоторые основные принадлежности, такие как стикеры, карточки 3×5 (загрузите и распечатайте наши шаблоны карточек), ручки и огромный лист бумаги, чтобы разместить все это.

Шаг 1. Сфокусируйте путь

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

Один из самых простых способов сделать это — просто спросить: Что делает наш продукт?

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

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

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

Шаг 2. Создайте основу своей истории

Хорошо, с видением и некоторыми ограничениями (или нет!) Пора определить вашу «основу». Это весь путь пользователя, описанный в задачах высокого уровня или этапах от начала до конца. Не вдавайтесь в подробности. На этом этапе вы хотите пойти широко, а не глубоко.

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

1. Зарегистрируйте аккаунт
2. Поиск домов для отпуска по городу / цене / местоположению / доступности
3. Просмотр домашней страницы профиля
4. Введите информацию об оплате
5. Забронировать дом
6. Написать отзыв для домовладельца

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

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

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

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

Шаг 3. Определите и сгруппируйте действия

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

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

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

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

• Если у вас есть группы задач, которые можно выполнять в разное время (например, на этом этапе я мог бы выполнить X, Y или Z), вы бы организовали эти вертикально в столбец как набор задачи или варианты .
• Если у вас есть группа задач, которые выполняются вместе (например, я выполняю A, затем B, затем C), это пользовательских шагов , которые, скорее всего, будут размещены горизонтально .

Шаг 4. Разбейте большие задачи на подзадачи

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

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

Вот пара предложений о том, как помочь вашей группе двигаться вперед от отца картографирования пользовательских историй, Джеффа Паттона:

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

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

Шаг 5: Заполните пустые поля

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

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

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

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

Шаг 6. Расставьте приоритеты для задач и подзадач (но оставьте свою основу как есть)

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

В каждом разделе вы можете расставить приоритеты по важности задач, переместив их вверх и завершив. Держите высокоприоритетные наверху, а менее важные переместите вниз.

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

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

Шаг 7: «Разделите» группы задач на итерации

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

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

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

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

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

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

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

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

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

Карта пользовательских историй приведет вас туда, куда вы (и ваши пользователи) хотите пойти.

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

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

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

Сделайте свой семинар по построению историй для пользователей успешным!

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

.История

— масштабируемая гибкая структура

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

— Билл Уэйк, соавтор экстремального программирования

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

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

Истории

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

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

Модель требований

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

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

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

• «Вау, посмотрите на все эти истории, на которые мы собираемся подписаться» (объем)
• «Посмотрите на все истории, которых мы достигли в этой итерации» (прогресс)

Хотя каждый может писать истории, их утверждение в бэклог команды и принятие их в базовый план системы является обязанностью Владельца продукта.Конечно, стикеры плохо масштабируются на предприятии, поэтому истории часто быстро переходят в инструменты Agile Lifecycle Management (ALM).

В SAFe есть два типа историй: истории пользователей и истории поддержки, как описано ниже.

Источники рассказов

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

Рисунок 1. Пример бизнес-функции, разделенной на истории

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

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

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

Как (роль пользователя) я хочу (активность), чтобы (бизнес-ценность)

Используя этот формат, команды помогают понять, кто использует систему, что они делают с ней и почему они это делают.Применение формата «голос пользователя» обычно увеличивает компетенцию команды; они начинают лучше понимать реальные бизнес-потребности своего пользователя. Рисунок 2 представляет собой пример.

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

«Персонажи» описывают конкретные характеристики типичных пользователей, которые помогают командам лучше понять своего конечного пользователя. Примерами персонажей наездника на Рисунке 2 могут быть искатель острых ощущений «Джейн» и робкий наездник «Боб». Затем описания историй ссылаются на этих персонажей («Как Джейн, я хочу…»).

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

Рис. 3. Пример пользовательской истории с «системой» в качестве пользователя

Enabler Stories

Командам

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

Рисунок 4. Пример истории фактора влияния

Существует много других типов историй фактора влияния, в том числе:

• Рефакторинг и всплески (как обычно определяется в XP)
• Создание или улучшение инфраструктуры разработки / развертывания
• Выполняемые работы, требующие человеческого взаимодействия (например,g., индексировать 1 миллион веб-страниц)
• Создание необходимых конфигураций продукта или компонентов для различных целей
• Проверка качества системы (например, тестирование производительности и уязвимости)

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

Написание хороших историй

Хорошие истории требуют множества точек зрения. В Agile вся команда — владелец продукта, разработчики и тестировщики — формируют общее понимание того, что нужно создавать, чтобы уменьшить количество переделок и увеличить пропускную способность.Команды совместно используют разработку на основе поведения (BDD), чтобы определить подробные приемочные тесты, которые окончательно описывают каждую историю. Хорошие истории требуют разных точек зрения:

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

Тестировщики

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

Совместное написание историй гарантирует, что все точки зрения будут учтены, и все согласны в поведении рассказа с результатами, представленными в описании истории, критериях приемлемости и приемочных тестах.Приемочные тесты написаны на языке предметной области системы с помощью Behavior-Driven Development (BDD). Затем тесты BDD автоматизируются и проводятся непрерывно, чтобы поддерживать встроенное качество. Тесты BDD написаны в соответствии с системными требованиями (историями) и поэтому могут использоваться в качестве окончательного определения поведения системы, заменяя спецификации на основе документов.

3C: карта, разговор, подтверждение

Рону Джеффрису, одному из изобретателей XP, приписывают описание трех составляющих истории:

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

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

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

Рис. 5. Критерии приемки историй с помощью BDD

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

Инвестируйте в хорошие истории

Модель INVEST, разработанная Биллом Уэйком [1], описывает характеристики хороших пользовательских историй:

• I — Независимый (среди прочего)
• N — По договоренности (гибкое заявление о намерениях, а не договор)
• V — ценный (предоставление клиенту ценного вертикального среза)
• E — Предполагаемая (малая и оборотная)
• S — Маленький (подходит для одной итерации)
• T — Тестируемый (достаточно понятный, чтобы знать, как это проверить)

Оценочные истории

Agile-команды используют очки истории и «оценку покера» для оценки своей работы [1, 2].Сюжетная точка — это единственное число, которое представляет собой комбинацию качеств:

• Объем — Сколько там?
• Сложность — Насколько это сложно?
• Знание — Что известно?
• Неопределенность — Что неизвестного?

Сюжетные точки являются относительными и не связаны с какой-либо конкретной единицей измерения. Размер (усилие) каждого рассказа оценивается относительно самого маленького рассказа, которому присваивается размер «один».’Применяется модифицированная последовательность Фибоначчи (1, 2, 3, 5, 8, 13, 20, 40, 100), которая отражает неотъемлемую неопределенность в оценке, особенно больших чисел (например, 20, 40, 100) [2].

Оценка покера

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

(Обратите внимание, что существует также ряд других методов.) Правила оценки в покере:

• Участники включают всех членов команды.
• Каждому оценщику дается колода карт с числами 1, 2, 3, 5, 8, 13, 20, 40, 100, ∞ и,?
• ЗП участвует, но не оценивает.
• Скрам-мастер участвует, но не оценивает, если только он не занимается реальной разработкой.
• Для каждого оцениваемого элемента невыполненной работы заказчик на закупку читает описание истории.
• Вопросы и ответы.
• Каждый оценщик в частном порядке выбирает оценочную карту, представляющую его или ее оценку.
• Все карточки переворачиваются одновременно, чтобы избежать предвзятости и сделать все оценки видимыми.
• Высокие и низкие оценки объясняют свои оценки.
• После обсуждения каждый оценщик переоценивает, выбирая карту.
• Оценки, скорее всего, сойдутся. Если нет, процесс повторяется.

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

Скорость

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

Вместимость

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

Начальная база для оценки

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

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

• Дайте каждому разработчику-тестировщику в команде восемь баллов за двухнедельную итерацию (по одному баллу за каждый идеальный рабочий день, вычитая 2 дня на общие накладные расходы).
• Вычтите по одному баллу за каждый выходной и праздничный день члена команды.
• Найдите небольшую историю, на код которой уйдет полдня, а на ее тестирование и валидацию — полдня. Назовите это «единицей».
• Оцените каждую вторую историю относительно этой.

Пример : Предположим, что команда из шести человек, состоящая из трех разработчиков, двух тестировщиков и одного PO, без отпусков или праздников, тогда предполагаемая начальная скорость = 5 × 8 баллов = 40 баллов за итерацию.(Примечание: настройка немного ниже может потребоваться, если один из разработчиков и тестировщиков также является Scrum Master.)

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

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

Разделение историй

Ячейки меньшего размера обеспечивают более быстрое и надежное внедрение, поскольку мелкие элементы проходят через любую систему быстрее, с меньшей изменчивостью и меньшим риском. Следовательно, разделение больших историй на более мелкие — обязательный навык для каждой Agile-команды. Это и искусство, и наука постепенного развития. Десять способов разделения историй описаны в Leffingwell Agile Software Requirements [1]. Ниже приводится краткое описание этих методов:

• Шаги рабочего процесса
• Варианты бизнес-правил
• Основное усилие
• Простой / сложный
• Отклонения в данных
• Способы ввода данных
• Качество отсроченной системы
• Операции (напр., Создать, прочитать, обновить, удалить [CRUD])
• Сценарии использования
• Шип выламываемый

На рисунке 6 показан пример разделения по сценариям использования.

Рисунок 6. Пример разделения большой истории на более мелкие истории.

Истории в модели требований SAFe

.

Как описано в статье о модели требований SAFe, Framework применяет обширный набор артефактов и взаимосвязей для управления определением и тестированием сложных систем в стиле Lean и Agile.Рисунок 7 иллюстрирует роль историй в этой более широкой картине.

Рисунок 7. Истории в модели требований SAFe

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

Примечание. На рисунке 7 используется нотация Unified Modeling Language (UML) для представления отношений между объектами: от нуля до многих (0 .. *), от одного до многих (1 .. *), от одного до одного (1) и т. Д. на.

Узнать больше

[1] Леффингуэлл, декан. Требования к гибкому программному обеспечению: методы бережливого производства требований для команд, программ и предприятия. Аддисон-Уэсли, 2011.
[2] Кон, Майк. Пользовательские истории, примененные: для гибкой разработки программного обеспечения. Аддисон-Уэсли, 2004.

Последнее обновление: 17 декабря 2019 г.

Информация на этой странице принадлежит © 2010-2020 Scaled Agile, Inc.и защищен американскими и международными законами об авторских правах. Ни изображения, ни текст не могут быть скопированы с этого сайта без письменного разрешения правообладателя. Scaled Agile Framework и SAFe являются зарегистрированными товарными знаками Scaled Agile, Inc. Посетите раздел часто задаваемых вопросов о разрешениях и свяжитесь с нами для получения разрешений.

.