Что такое User Story

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

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

Что такое User Story.

История – это единица работы в Agile. Это не feature, а цель, выраженная с позиции пользователя.

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

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

Истории прекрасно укладываются в такие методологии как Scrum или Kanban. В Scrum создаются спринты с историями, которые «сжигаются» в процессе выполнения спринта. В Kanban команда проносит задачи из большого списка (backlog) через рабочий процесс. Такая работа над пользовательскими историями позволяет команде лучше прогнозировать и планировать спринты, что приводит к более точным оценкам и большей гибкости. С помощью историй, команда Kanban обучается управлению work-in-progress и может улучшить свои рабочие процессы.

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

Почему User Story, а не пошаговые задачи?

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

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

  1. User Story удерживает внимание на пользователе. Список шагов фокусирует команду только на факте выполнения задачи, в то время как истории фокусируют на решение проблемы реального пользователя.
  2. User Story запускает общение. После утверждения конечной цели команда может совместно обсудить то, как пользователь получит желаемое наилучшим и наиболее полным способом.
  3. User Story продвигает креативные решения. Истории воодушевляют команду на критическое и креативное мышление в поисках наилучшего решения конечной цели.
  4. User Story ускоряет движение. Каждая выполненная история -это маленькое испытание, радость от маленькой победы в котором движет команду всё дальше.

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

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

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

Другой типичный шаг на таких совещаниях – это оценка историй на основе их сложности или затратах времени. Обычно используются размеры футболок (XS, S, M, L, XL), баллы, покер планирования для достижения правильных оценок. История должна иметь размер, который позволит умесить её в один спринт, поэтому в процессе уточнения команда должна разбивать большие истории, если они выходят за рамки интервала планирования.

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

При написании историй необходимо понимать следующее:

  1. Критерий завершения – User Story считается завершенной, когда пользователь может достичь поставленной цели, поэтому эта цель должна быть четко обозначена.
  2. Выразить подзадачи – Решить, какие конкретные шаги должны быть выполнены и кто за их выполнимость отвечает.
  3. Личность пользователя – Для кого? Если существуют несколько конечных пользователей, нужно рассмотреть разделение на отдельные истории.
  4. Обозначенные шаги – Нужно писать историю для каждого шага сложного процесса.
  5. Обратная связь – Нужно прислушиваться к конечным пользователям и выражать проблемы их языком. Нет необходимости выдумывать формулировки, когда их можно получить от пользователя.
  6. Временные рамки – сложная тема. Некоторые команды избегают обсуждения времени полностью, полагаясь на свои оценочные рамки. Так как истории по определению должны быть выполнимыми за один спринт, то задачи длиной в недели и месяцы следует выделять в свои эпики.
  7. Видимость – после определения истории она должна быть открытой для всей команды.

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

User Story часто можно выразить одним предложением, структурированным так:

Как [лицо], я хочу [что], чтобы [то].

1)    «Как [лицо]» – Для кого всё это делается? Не должность, а конкретное лицо. Ваня. Команда должна понимать кто такой Ваня. Можно надеяться, много Вань было опрошено. Понятно как Вани устроены, что они думают, как они чувствуют. Ване можно сопереживать.

2)    «Хочу [что]» – Здесь определяется намерение, а не черты. Чего именно хотят достичь? Эта часть должна быть освобождено от реализации. Например, если в обсуждении  объясняется UI, то это не пользовательская цель и суть потеряна.

3)    «Чтобы [то]» – Как описанное желание сделать что-то воплотится в их общее понимание. Какую итоговую пользу собираются получить? Какая общая проблема нуждается в решении.

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

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

– «Как Саша, я хочу организовать работу, чтобы чувствовать больше контроля».

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

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

Как начать использовать User Story

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

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

Leave a Reply

Your email address will not be published. Required fields are marked *