Введение

Неформальное описание одной или нескольких характеристик программной системы.

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

Принцип

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

Примеры

Проверочный тест (эпическая история) Как менеджер по персоналу, я хочу создать проверочный тест, чтобы понять, стоит ли направлять потенциальных кандидатов функциональному менеджеру. Поиск тестов Как менеджер, я хочу просматривать мои существующие тесты, чтобы вспомнить, какие у меня уже есть, и понять, могу ли я повторно использовать или обновить существующий тест для текущей вакансии. Они определяют границы пользовательской истории и используются для подтверждения завершения истории и ее корректной работы. Объем информации, включаемой в критерии приемки, зависит от команды, программы и проекта. Некоторые могут включать "предварительные критерии", например, "Пользователь уже вошел в систему и ранее один раз редактировал свои данные". Другие могут формулировать критерии приемки в типичном Agile-формате Given-When-Then. А некоторые могут просто использовать маркированный список, основанный на исходных требованиях, собранных у клиентов или заинтересованных сторон.

Связь с эпосами, темами и инициативами/программами

Во многих контекстах пользовательские истории используются и обобщаются в группы по онтологическим, семантическим и организационным причинам. Инициатива также может называться программой в некоторых масштабируемых гибких фреймворках. Различные варианты использования зависят от точки зрения, например, с позиции пользователя как владельца продукта по отношению к функциям, или с позиции компании по отношению к организации задач. В то время как некоторые предлагают использовать термины "эпик" и "тема" для обозначения любого вида группировки пользовательских историй, руководство организации склонно использовать их для чёткой структуризации и объединения рабочих нагрузок. Например, Jira, похоже, использует иерархически организованный список задач, где первый уровень – "пользовательская история", второй – "эпики" (группировка пользовательских историй), а третий – "инициативы" (группировка эпиков). Однако инициативы не всегда присутствуют в процессе разработки продукта и лишь добавляют дополнительный уровень детализации. В Jira также существуют "темы" (для отслеживания), позволяющие связывать и группировать элементы из разных частей фиксированной иерархии. В этом случае Jira меняет значение термина "тема" с точки зрения организации: например, сколько времени было затрачено на разработку темы "xyz". Но другое определение темы – это набор историй, эпиков, функций и т.д., предназначенных для пользователя и формирующих единую семантическую единицу или цель. Вероятно, единого определения не существует, поскольку существуют различные подходы к разным стилям проектирования и разработки продукта. В связи с этим некоторые предлагают вообще не использовать жёсткие группы и иерархии.

Тема

Несколько эпопей или множество очень крупных историй, тесно связанных между собой, объединяются в темы. Распространенное объяснение эпопей также: объем работы, требующий множества спринтов, или, в масштабируемых фреймворках, Release Train (Поезд релизов) или Solution Train (Поезд решений).

Инициатива

Множественные темы, эпопеи или истории, объединенные иерархически.

Эпическая

Множество тем или сюжетов, объединенных онтологией и/или семантическими связями.

Карта сюжета

Карта историй организует пользовательские истории в соответствии с повествовательным потоком, представляющим общую картину продукта. Метод был разработан Джеффом Паттоном в период с 2005 по 2014 год для снижения риска возникновения проектов, перегруженных чрезмерно детализированными пользовательскими историями, которые отвлекают от достижения основных целей продукта. Картографирование пользовательских историй использует воркшопы с пользователями для начала с определения основных бизнес-действий. Каждое из этих основных действий может вовлекать несколько типов пользователей или персон. Затем, путем определения основных задач конкретного пользователя, участвующего в этих бизнес-действиях, проводится горизонтальная сквозная повествовательная линия. Эта линия сохраняется на протяжении всего проекта. Более детальные пользовательские истории собираются и добавляются, как обычно в практике работы с пользовательскими историями. Но каждая новая пользовательская история либо встраивается в повествовательный поток, либо связывается вертикально с основной задачей. Горизонтальная ось соответствует охвату целей продукта, а вертикальная – потребностям отдельных пользователей. Таким образом, становится возможным описать даже большие системы, не теряя общей картины. Карты историй могут легко предоставить двумерную графическую визуализацию бэклога продукта: в верхней части карты располагаются заголовки, под которыми группируются истории, обычно называемые «эпиками» (крупнозернистыми пользовательскими историями), «темами» (коллекциями связанных пользовательских историй) или «действиями». Они определяются, ориентируясь на рабочий процесс пользователя или «порядок, в котором вы объяснили бы поведение системы». Вертикально, под эпиками, размещаются и упорядочиваются по приоритету фактические карточки историй. Первый горизонтальный ряд представляет собой «ходячий скелет», а ниже располагаются элементы, демонстрирующие возрастающую сложность.

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

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