В разработке программного обеспечения и управлении продуктом пользовательская история - это неформальное описание на естественном языке одной или нескольких функций программной системы. Примеры User Story часто пишутся с точки зрения конечного пользователя или пользователя системы. Они часто записываются на учетных карточках, в заметках Post-it или в программном обеспечении для управления проектами. В зависимости от проекта пользовательские истории могут быть написаны различными заинтересованными сторонами, включая клиентов, менеджеров или членов команды разработчиков.
Пояснение
Пользовательские истории - это тип пограничного объекта. Они способствуют выработке смысла и общению, то есть помогают командам разработчиков систематизировать свое понимание системы и ее контекста.
Примеры User Story часто путают с системными требованиями. Требование - это формальное описание потребности; пользовательская история - это неформальное описание функции.
Создания
В 1998 году Алистер Кокберн посетил проект Chrysler C3 в Детройте и придумал фразу «История пользователя - это обещание для разговора».
С Extreme Programming (XP) пользовательские истории стали частью игры планирования.
Требования
Как составлять хорошие User Story? В 2001 году Рон Джеффрис предложил формулу «Три C» для создания пользовательских историй:
- Карта (или часто записка) - это материальный прочный физический жетон для хранения понятий.
- Разговор ведется между заинтересованными сторонами (клиентами, пользователями, разработчиками, тестировщиками и т. д.). Он устный и часто дополняется документацией.
- Подтверждение гарантирует, что цели разговора были достигнуты. Так написано в англоязычном мануале User Story map examples and templates.
В некоторых командах менеджер по продукту (или владелец продукта в Scrum) несет основную ответственность за формулирование пользовательских историй и организацию их в портфель продуктов. В других командах любой может написать историю пользователя. Примеры User Story написаны или для пользователей, для или клиентов, чтобы влиять на функциональность разрабатываемой системы. Пользовательские истории могут быть разработаны путем обсуждения с заинтересованными сторонами, на основе персон или просто составлены. Так написано в официальном руководстве How to do User Story mapping.
Методы
В качестве центральной части многих методологий гибкой разработки, таких как игра в планирование XP, пользовательские истории определяют, что должно быть встроено в программный проект. Пользовательские истории располагаются по приоритетам клиента (или владельца продукта в Scrum), чтобы указать, какие из них наиболее важны для системы и будут разбиты на задачи и оценены разработчиками. Один из способов оценки - по шкале Фибоначчи. Это будет воистину пример хорошей "юзер стори"!
Когда будут реализованы пользовательские истории, разработчики должны иметь возможность поговорить об этом с заказчиком. Короткие истории могут быть трудно интерпретировать, могут потребовать некоторых базовых знаний, или требования могли измениться с момента написания истории.
К каждой пользовательской истории в какой-то момент должен быть прикреплен один или несколько приемочных тестов, позволяющих разработчику проверить, когда она готова, а также позволяющих заказчику ее проверить. Без точной формулировки требований могут возникнуть длительные неконструктивные аргументы, когда продукт должен быть доставлен.
Спорный статус
Нет убедительных доказательств того, что использование пользовательских историй увеличивает успех программного обеспечения или продуктивность разработчиков. Тем не менее, пользовательские истории облегчают поиск смысла без чрезмерного структурирования проблем, что связано с успехом.
Ограничения пользовательских историй включают в себя:
- Проблема масштабирования.
- Пользовательские истории, написанные на маленьких физических картах, трудно поддерживать, трудно масштабировать для больших проектов и проблематично для географически распределенных команд.
- Неясный, неформальный и неполный свод правил.
Коммуникативное значение
Пользовательские истории рассматриваются как начало разговора. Будучи неформальными, они открыты для многих толкований. Вкратце, они не содержат всех деталей, необходимых для реализации функции. Поэтому истории не подходят для заключения официальных соглашений или написания юридических контрактов.
Отсутствие нефункциональных требований
Пользовательские истории редко включают в себя сведения о производительности или нефункциональных требованиях, поэтому нефункциональные тесты (например, время отклика) могут быть пропущены.
Во многих контекстах используются пользовательские истории, которые также объединяются в группы по смысловым и организационным причинам. Различное использование зависит от точки зрения, например, либо с точки зрения пользователя как владельца продукта по отношению к функциям, либо с точки зрения компании по отношению к организации задач.
Метки
В то время, как некоторые предлагают использовать epic и theme в качестве меток для любого мыслимого типа группировки пользовательских историй, руководство организации стремится использовать их для сильного структурирования и объединения рабочих нагрузок. Например, Jira, кажется, использует иерархически организованный список дел, в котором они назвали первый уровень задач user-story, второй уровень epics (группирование пользовательских историй) и «инициативы» третьего уровня (группировка эпопей). Тем не менее, инициативы не всегда присутствуют в разработке управления продуктами и просто добавляют еще один уровень детализации. В Jira существуют «темы» (для целей отслеживания), которые позволяют перекрестно связывать и группировать элементы разных частей фиксированной иерархии. В этом использовании "Джира" меняет значение темы с точки зрения организации: например, сколько времени мы потратили на разработку темы xyz. Но другое определение тем - это набор историй, эпосов, функций и т. д. Для пользователя, который формирует общую семантическую единицу или цель, вероятно, нет общего определения, потому что существуют разные подходы для разных стилей дизайна и разработки продукта. В этом смысле некоторые также предлагают не использовать какие-либо жесткие группы и иерархии.
Эпики
Большие истории или истории нескольких пользователей, которые очень тесно связаны, суммируются как эпические. Общее объяснение эпопеи такое - пользовательская история, которая слишком велика для спринта.
Множество эпосов или историй, сгруппированных по иерархическому принципу, в основном известны из Jira.
User Story map: описание
Карта истории представляет собой графическую двумерную визуализацию отставания продукта. В верхней части карты находятся заголовки, под которыми сгруппированы истории, обычно называемые «эпосами» (большие грубые пользовательские истории), «темами» (сборниками связанных пользовательских историй) или «действиями». Они определяются путем ориентации на рабочий процесс пользователя или «в порядке, в котором вы бы объяснили поведение системы». Вертикально, ниже эпопей, фактические примеры User Story map расположены и упорядочены по приоритету. Первый горизонтальный ряд представляет собой «ходячий скелет» и ниже, что представляет растущую изощренность.
Таким образом, становится возможным описать даже большие системы без потери общей картины. Отзывы о User Story map, написанные пользователями, сводятся к интерактивности и веселости сего занятия, которое очень радует людей. Они заявляют о преимуществах такого программного обеспечения. Это, прежде всего, то, что они облегчают оценку заданий.
Примеры User Story являются частью гибкого подхода, который помогает сместить акцент с написания требований на обсуждение их. Все гибкие пользовательские истории включают одно или два письменных предложения и, что более важно, серию бесед о желаемой функциональности.
Шаблон
Что можно сказать о примерах User Story map? Пользовательские истории - это короткие, простые описания функций, рассказанные с точки зрения человека, который желает получить новую возможность. Обычно это пользователь или клиент системы. Они обычно следуют простому шаблону:
Как <тип пользователя>, я хочу <некоторую цель>, потому что <причина>.
Это и есть ответ на вопрос, как построить карту историй User Story mapping. Пользовательские истории часто пишутся на карточках или записках, хранятся в обувной коробке и располагаются на стенах или столах для облегчения планирования и обсуждения. Как таковые они сильно смещают акцент с написания функций на обсуждение их. На самом деле эти дискуссии важнее любого написанного текста. А для последнего вы можете воспользоваться написанным выше образцом user stories.
Преимущества
Одним из преимуществ гибких пользовательских историй является то, что они могут быть написаны с различной степенью детализации. Мы можем написать пользовательскую историю, чтобы охватить большое количество функциональных возможностей. Эти большие пользовательские истории обычно известны как эпопея. Вот пример эпической гибкой пользовательской истории из продукта для резервного копирования на компьютере.
Как пользователь, вы можете сделать резервную копию всего моего жесткого диска. Поскольку эпос обычно слишком велик для гибкой команды, чтобы завершить его за одну итерацию, он разбивается на несколько небольших пользовательских историй, прежде чем он будет продолжен. Эпопея, приведенная выше, может быть разбита на десятки (или, возможно, сотни).
Как опытный пользователь, вы можете указать файлы или папки для резервного копирования на основе размера файла, даты создания и даты изменения. Как пользователь, человек может указать папки, которые не подлежат резервному копированию, чтобы резервный диск не был заполнен вещами, которые ему не нужно сохранять. Как детализация добавляется в пользовательские истории? Детали могут быть добавлены двумя способами:
- Разделив пользовательскую историю на несколько небольших.
- Добавляя "условия удовлетворения".
Когда относительно большая история разбивается на несколько маленьких, гибких пользовательских историй, естественно предположить, что детали были добавлены. В конце концов, больше было написано.
Условия удовлетворения
Это просто приемочный тест высокого уровня, который будет действительным после завершения гибкой пользовательской истории. Рассмотрим следующее, как еще один пример гибкой пользовательской истории:
- Как вице-президент по маркетингу, я хочу выбрать сезон отпусков, который будет использоваться при оценке эффективности прошлых рекламных кампаний, чтобы я мог определить прибыльные.
В этот пример пользовательской истории можно добавить подробности, добавив следующие условия удовлетворения:
- Убедитесь, что он работает с основными розничными праздниками: Рождество, Пасха, День президента, День матери, День отца, День труда, Новый год.
- Поддержка праздников, которые охватывают два календарных года (ни один не охватывает три).
- Праздничные сезоны могут быть установлены от одного праздника к другому (например, День благодарения к Рождеству).
- Курортные сезоны могут быть установлены за несколько дней до праздника.
Любой может писать истории пользователей. Владелец продукта обязан убедиться, что существует множество незавершенных пользовательских историй, но это не означает, что их автором является владелец продукта. В течение хорошего гибкого проекта вы должны ожидать, что каждый пользователь будет иметь примеры пользовательских историй.
Также обратите внимание, что тот, кто пишет историю пользователя, гораздо менее важен, чем тот, кто участвует в ее обсуждении.
Значение для проектов
Пользовательские истории написаны на протяжении всего гибкого проекта. Обычно семинар по написанию историй проводится в начале. Все в команде участвуют с целью создания журнала ожидания продукта, который полностью описывает функциональные возможности, которые будут добавлены в ходе проекта или в течение трех-шести месяцев выпуска в нем. Примеры этого есть в большом сборнике Example User Story map.
Некоторые из этих гибких пользовательских историй, несомненно, будут эпическими. Позднее эпосы будут разложены на более мелкие истории, которые с большей готовностью поместятся в одну итерацию. Кроме того, новые истории могут быть написаны и добавлены в портфель продуктов в любое время и кем угодно.
Agile-проекты, особенно Scrum, используют бэклог продукта, который является приоритетным списком функциональности, которая будет разработана в продукте или услуге. Несмотря на то, что элементы незавершенного производства могут быть такими, какие пожелает команда, пользовательские истории стали лучшей и наиболее популярной формой незавершенного производства.
В то время как отставание по продукту можно рассматривать как замену документа требований традиционного проекта, важно помнить, что письменная часть гибкой пользовательской истории («Как пользователь, я хочу…») является неполной до обсуждения об этой истории происходят. Так написано в американском мануале User Story mapping and how to use it.
Часто лучше рассматривать письменную часть как указатель на реальное требование. Пользовательские истории могут указывать на диаграмму, изображающую рабочий процесс, электронную таблицу, показывающую, как выполнять вычисления, или любой другой артефакт, который желает владелец продукта или команда.
