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

Это короткое и максимально понятное описание функционала продукта или его особенностей, которые получит пользователь как итоговую ценность. Впервые описал User Story как идею Kent Beck. Этот же человек придумал Экстремальное программирование (Extreme Programming, XP).

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

Как именно должна звучать User Story: «Персона». Для кого мы это строим? «Хочу». Здесь мы описываем намерения людей. «Чтобы». Как непосредственное желание людей сделать что–то вписывается в их общую картину мира?

Впервые описал User Story как идею Kent Beck. Этот же человек придумал Экстремальное программирование (Extreme Programming, XP).

Пользовательская история — отвечает на вопрос «Что». Что именно мы будем делать для бизнеса?

Пользовательские истории часто выражаются в простом предложении, структурированном следующим образом: «Как [персона] **, я** [хочу] , [чтобы что]». Это шаблон для составления любых User Story. Это инструмент, которым вы можете создавать качественные и понятные разработчикам описания требуемого функционала.

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

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

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

Кто–то считает, что юзер стори — это что–то вроде небольшого описания задания разработчику. Но есть специфика, помимо «краткости» этого задания.

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

Пользовательскую историю можно описывать по–разному. Но наиболее продуктивным для понимания задания, а также наиболее кратким и при этом ёмким оказывается следующая формула:

Я, как X, хочу Y, чтобы Z.

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

Y — это задача, действие или свойство, которое необходимо персонажу.

Z — это конечная бизнес–ценность, которую получит персонаж.

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

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

«Хочу». Здесь мы описываем намерения людей, а не функции, которые они используют. Чего они на самом деле пытаются достичь? Каковы их «Jobs To Be Done»? Это утверждение должно быть свободным от функционального описания — если вы описываете какую–либо часть пользовательского интерфейса, а не цель пользователя, вы упускаете суть.

«Чтобы». Как непосредственное желание людей сделать что–то вписывается в их общую картину мира? Какую конечную выгоду они пытаются достичь? Зачем это нужно? Какую большую проблему нужно решить?

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

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

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

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

Когда персона получает её желаемую ценность, тогда история завершена. Если нет — то нет.

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

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

У юзер стори есть некоторые особенности.

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

I — Independent. Независимость истории означает, что на неё не влияют другие истории.

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

N — Negotiable. История должна побуждать обсуждения, и эти обсуждения должны вестись, когда создается история. Этот принцип довольно легко запомнить по самому названию — пользовательская история это именно ИСТОРИЯ. Это то, что обсуждается, о чем разговаривают.

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

V — Valuable. История должна быть ценной, функционал должен приносить бизнес–ценность. Здесь и добавить нечего.

E — Estimable. История должна быть доступна для оценки. Человек или группа, которая будет работать над реализацией истории, должна иметь возможность её оценить. Если оценку дать невозможно, то историю во–первых нельзя спланировать, а во–вторых непонятно, будет ли она реализована или нет.

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

S — Small. История должна быть достаточно небольшой, чтобы её можно было бы реализовать в течение короткой итерации, спринта. Если история большая — её есть смысл декомпозировать на более короткие, чтобы было что взять на работу в итерацию.

T — Testable. Юзер стори должна быть доступна для тестирования.

Преимущества следующие:

• Пользовательские истории, если они хорошо описаны, понятны всем.

• Они не требуют большого количества времени для составления.

• Они фокусируют на ценность, особенно важно что это ценность для клиента.

• Они вовлекают участников командной работы.

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

Риски могут быть такие:

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

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

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

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

• Составить список User Stories

• Приоритизировать составленные пользовательские истории

• Обсудить эти истории

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

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

Пользовательская история, User Story — это короткое, «минималистичное» описание задачи, которое формулируется как описание заинтересованным пользователем продукта желаемого функционала от продукта.

Формула юзер стори — Я, как X, хочу Y, чтобы Z.

Проверить юзер стори на качество можно при помощи INVEST–критериев. Если история не подходит под какой–то критерий, есть смысл пересмотреть историю, придумать новую или изменить имеющуюся, или сделать декомпозицию на более мелкие истории, или построить User Story Map (карту пользовательской истории).

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

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

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

Это было неплохо, но не многое объясняло — все равно, что сказать, что соль — это то, что насыпают в солонку, а перец -то, что кладут в мельнику для перца. Конечно же истории идут в беклог продукта, а задачи в беклог спринта. Но в чем же суть различия между ними?

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

Давайте понаблюдаем…

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

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

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

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