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

• 1997: Кент Бек вводит концепцию пользовательских историй в проекте Chrysler C3 в Детройте.
• 1998: Алистэр Кокбёрн, посетив проект C3, формулирует фразу: «Пользовательская история — это обещание поговорить»^[3].
• 1999: Кент Бек публикует первую редакцию книги «Extreme Programming Explained», описывая экстремальное программирование (XP)^[4] и применение пользовательских историй в игре по планированию.
• 2001: Рон Джеффрис предлагает «формулу трёх C» для создания пользовательской истории:^[5]
  • Карта — физический носитель идеи (карточка или стикер);
  • Беседа — обсуждение между стейкхолдерами (клиенты, пользователи, разработчики, тестировщики);
  • Подтверждение — удостоверение того, что цели обсуждения достигнуты.
• 2001: Команда XP в Connextra^[6] в Лондоне разрабатывает собственный формат пользовательских историй.
• 2004: Майк Коэн (распространяет принципы пользовательских историй за пределы карточек в своей книге User Stories Applied: For Agile Software Development^[7], которая стала стандартным источником по теме согласно мнению Мартин Фаулер^[8]. Коэн считает Рэйчел Дэвис изобретательницей формата, хотя Дэвис подчёркивает, что это была командная работа^[9].
• 2014: После публикаций в 2005^[10] и блоге в 2008^[11], Джефф Пэттон публикует технику мэппинга пользовательских историй для систематизации и визуализации их взаимосвязей^[12].

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

Скрининговый опрос (эпик)

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

Просмотр викторин

Как менеджер я хочу просматривать свои квизы, чтобы вспомнить, что у меня уже есть, и решить, стоит ли их обновить или создать новые^[17].

Частичный бэкап

Как пользователь, я могу указать папки, которые не следует копировать в резервную копию, чтобы на диске не хранилось лишнего^[18].

Пользовательские истории — центральный элемент многих гибких методик разработки программного обеспечения (например, в экстремальном программировании — часть игры по планированию). Приоритезацию историй производит заказчик (или владелец продукта в Scrum), отмечая, какие из них наиболее важны для системы; затем истории разбивают на задачи и оценивают (например, в очках Фибоначчи: 1, 2, 3, 5, 8, 13 — простейшим задачам даётся 1 балл).

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

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

Научных данных о том, что использование пользовательских историй повышает успех разработки или продуктивность команды, нет. Однако истории облегчают осмысление требований при отсутствии жёсткой структуры задачи, что связано с успехом проектов^[20].

К ограничениям пользовательских историй относят:

• Проблема масштабирования: карточки сложно поддерживать для крупных проектов либо распределённых команд, они плохо масштабируются.
• Нечёткость и неполнота: карточки служат началом беседы; в силу краткости и неформальности они неоднозначны и не всегда содержат все технические детали. Истории не подходят для формальных соглашений и контрактов^[21].
• Отсутствие нефункциональных требований: редко фиксируются требования производительности, времени отклика, и другие нефункциональные параметры.
• Не определяют техническую реализацию: истории формулируются с бизнес-точки зрения, но при реализации могут выявиться ограничивающие технические детали, выходящие за рамки одной истории. Иногда помогает декомпозиция; иногда пишутся специальные «технические» истории, которые неочевидны для бизнеса.

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

Например, в Jira используется иерархия: первый уровень — «пользовательские истории», второй — «эпики» (группы историй), третий — «инициативы» (группы эпиков). В Jira «темы» позволяют объединять объекты разного уровня^[22][23].

Термин «тема» при этом может означать как организационную единицу (сколько времени потрачено на определённую тему), так и набор задач для отдельного пользователя, объединённых общей целью. Жёсткого стандарта нет, подходы различаются^{[24][25][26][27][28][29]}.

Мэппинг пользовательских историй^[31] — техника структурирования историй по «нарративной линии», которая помогает увидеть продукт целиком. Её разработал Джефф Пэттон в 2005—2014, чтобы избежать потери фокуса из-за детализации отдельных историй.

В мэппинге историй^[32] сначала на воркшопах с пользователями выделяются основные бизнес-активности. Каждая из них может включать разные типы пользователей или персон.

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

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

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

Мэппинг удобно даёт двумерную визуализацию бэклога: сверху — эпики/темы/активности (связанные с этапами рабочего процесса пользователя), снизу — приоритизированные истории. Первый горизонтальный слой — «walking skeleton» (основа), ниже — детализация^[33][34].

Карта пользовательского пути^[35] строится для одного типа пользователя; её нарратив лежит в хронологии выполнения задач для достижения цели.

Это позволяет визуально отобразить пользовательский опыт в развитии. По отзывам пользователей можно определить узкие места, негатив или удовлетворённые/неудовлетворённые потребности. Техника применяется для проектирования интерфейса с опорой на пользовательский опыт^[36] и вовлечения пользователей в совместное проектирование^[37].

Вариант использования описывается как «обобщённое описание множества взаимодействий между системой и одним или несколькими акторами, где актор — это пользователь или другая система»^[38]. Несмотря на схожесть, между пользовательскими историями и вариантами использования есть различия и в детализации, и в назначении.

Кент Бек, Алистэр Кокбёрн, Мартин Фаулер и др. разбирали это различие на wiki c2.com (сообщество экстремального программирования)^[40].