Пример user story: User Story 💬 — что это такое? пользовательские истории и примеры

User Story 💬 — что это такое? пользовательские истории и примеры

Обновление от 24 мая, 2023 г.

22 отзыва, в среднем 4 из 5

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

Миша Ряженка

Founder, Executive Partner

Что такое User Story User Story (Пользовательская История)

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

Миша Ряженка

Founder, Executive Partner

Специфика User Story (v2)

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

Миша Ряженка

Founder, Executive Partner

Шаблон User Story

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

Миша Ряженка

Founder, Executive Partner

User Story

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

Миша Ряженка

Founder, Executive Partner

Что такое User Story

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

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

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

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

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

Миша Ряженка

Founder, Executive Partner

Специфика User Story

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

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

Миша Ряженка

Founder, Executive Partner

Формула User Story

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

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

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

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

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

Профессии

Продакт–менеджер

Профессия

Долгосрочная программа

Обучение с нуля профессии «Продакт–менеджер» в IT на реальных рыночных кейсах. Передадим вам практический коммерческий опыт и подготовим к трудоустройству.

Скрам–мастер & Agile–коуч

Долгосрочная программа

Профессия

Обучение с нуля профессии «Скрам–мастер & Agile–коуч» по индивидуально разработанной программе с поддержкой при трудоустройстве и еженедельным личным трекингом и менторством

Миша Ряженка

Founder, Executive Partner

Шаблон User Story (v2)

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

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

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

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

Миша Ряженка

Founder, Executive Partner

Примеры User Story

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

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

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

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

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

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

Миша Ряженка

Founder, Executive Partner

INVEST–критерии в User Story

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

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

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

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

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

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

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

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

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

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

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

Миша Ряженка

Founder, Executive Partner

Преимущества и возможные риски использования User Story

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

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

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

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

Миша Ряженка

Founder, Executive Partner

Как используются User Stories

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

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

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

Миша Ряженка

Founder, Executive Partner

User Story — кратко

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

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

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

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

Татьяна Светлова

В чем разница между пользовательской историей (User Story) и задачей?

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

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

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

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

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

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

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

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

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

Проверенный шаблон пользовательских историй / Хабр

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

В IT есть, например, паттерны проектирования или алгоритмы — математические шаблоны. Шаблоны — полезная «вещь»: позволяют меньше писать, подставляя что-то в уже сформированные рамки. 

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

Автор: Дарья Плоскодняк — опытный продуктовый аналитик в Ak Bars Digital. Занимается развитием сквозных процессов Ак Барс Банка, связанных с банковскими картами. Один из лидеров внутреннего комьюнити аналитиков компании и участник многочисленных митапов и конференций. Статья подготовлена по мотивам выступления Дарьи на одном из таких мероприятий – митапе Three Amigos Talk.

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

Сначала кратко о пользовательских историях.

Пользовательская история (или User Story, US) — это:

С точки зрения agile-разработки, пользовательская история — это задача, которая должна помещаться в спринт.

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

Я как 1_ хочу 2, чтобы 3__.

1 – тип пользователя, персонаж

2 – действие или цель

3 – результат или ценность

Разберем некоторые кейсы с реальными пользовательскими историями:

#1. «Я, как клиент банка, хочу получать сообщение об изменении статуса заявки на кредит, чтобы скорее получить деньги».

Вопрос, который возникает, глядя на эту user story, какой статус ожидает клиент? 

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

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

#2. «Я как сотрудник магазина хочу проще заходить в складскую программу».

Первое, что бросается в глаза — не сформулирована ценность данной истории. Буквально, нет ответа на вопрос «Зачем?».

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

Как улучшить: «Я как сотрудник магазина хочу иметь возможность авторизоваться в складской программе по коду из 4-х цифр, чтобы обслуживать больше клиентов за смену»

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

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

Разберем пример подробнее.

Описание

Одна из важных мелочей, которой часто не уделяют должного внимания — нумерация. Именно грамотно продуманная нумерация позволит организовать трассировку требований и поддерживать актуальность документации, связанной с требованиями. И, конечно же, эта важная деталь упростит поиск историй для вас и ваших коллег. Трекинговые системы, такие как Jira, поддерживают практически любую нумерацию.

Пример нашей нумерации: ABOL-04-113.

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

Примечание. Эпик — это сущность (крупная часть функционала или этап проекта), ценность которой для пользователя мы не можем выразить в одной истории текущего спринта. Эпик разбивается на истории и задачи. Например, в проекте «Курьерская доставка банковских карт», эпик — это «Доставка неименных банковских карт». Пример истории : «Я как клиент банка могу получить неименную карту в срок, который я указал в Заявке, чтобы сократить срок получения банковской карты»

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

Пример: ABOL-04-113. »Я как действующий клиент банка, уже зарегистрированный в личном кабинете, хочу иметь возможность сменить пароль, чтобы иметь доступ к личному кабинету, если забыл пароль»

Сценарии использования, или Use case

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

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

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

Пример нашего юзкейса.

Не стоит тратить ресурсы на описание юзкейсов, если у вас небольшие проекты — интеграционные сервисы, мало интерфейсов и пользователей, или вообще нет пользователей.

Правила бизнеса

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

Запоминаем главное — правила бизнеса могут и будут меняться!

Ограничения бизнеса

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

Ограничения бизнеса тоже могут меняться, но не так часто, как правила. 

Интеграция с внешними системами

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

Сюда отлично подойдет описание инфраструктуры, ER-диаграмма, примеры в формате JSON или XML, и все прочие детали интеграции с внешними системами. В общем, всё, что может пригодиться разработчикам.

Критерии приемки

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

Минимальные требования для пользовательской истории — формулировка и критерии приемки. Без них мы не сможем понять, выполнили историю или нет. 

Критерии приемки прописываются отдельно для каждой истории. Пример критериев приемки для нашей истории:

1. Пользователю доступна функция смены пароля на всех устройствах.

2. Функция смены пароля доступна на странице авторизации.

3. Новый пароль не может дублировать старый пароль.

4. Новый пароль имеет не меньше 8 символов.

5. Пароль не может начинаться и заканчиваться пробелом.

Есть еще один вариант описания критериев приемки, который очень любят тестировщики — модель Given-When-Then. 

• Given (дано) — состояние ситуации до начала действий пользователя.

• When (когда) — пользователь совершает какие-то действия.

• Then (тогда) — ситуация меняется и система реагирует на действия пользователя.

Подробнее про это можно почитать в статье «Как описать User stories, используя язык Gherkin».

В критериях приемки есть только два варианта — да и нет.

Критерий не может быть выполнен, например, на 90%.

Важна конкретика — если вы что-то не пропишете или упустите, то у разработчиков будет возможность додумать самостоятельно. И это не всегда хорошо. Ещё один важный момент — критерии приемки должны легко проверяться.  

Важно не путать критерии приемки и DOD (definition of done). DOD — это общий чек-лист критериев – он может быть один на все пользовательские истории в рамках процесса. 

Как отличить DOD и критериев приёмки? Очень просто. Представим доставку пиццы. DOD — пицца приготовлена, упакована, отправлена, вручена. Критерии приемки — пицца приготовлена из тех ингредиентов, которые заказал клиент.

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

Практика «три С» — card, conversation, confirmation

Ещё одна практика, которой можно пользоваться при работе с user story.

Card — фиксация истории для выполнения. Самое важное, чтобы история была доступна, и чтобы её могли найти все коллеги из команды разработки. Фиксировать истории можно в любом таск-трекере или даже на доске в офисе.

Conversation — обсуждения требований с командой. Если вы аналитик, то не используйте схему работы, в которой просто написали пользовательскую историю и передаете её разработке. Так не работает. Нужно обсудить требования с командой, в идеале выделить на это отдельную встречу.

Confirmation — прописать четкие критерии приемки.

А как на практике?

Давайте пофантазируем и представим заказчика, который передал требования на разработку и сказал «Хочу ракету». У нас есть две команды, в каждой — по одному аналитику: Соня и Степан. Они одновременно начали работать с требованиями. 

• Степан решил сэкономить время и побыстрее сделать ракету. Для этого передал свои требования в виде незрелой пользовательской истории в команду разработки. 

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

Чья команда быстрее выполнит проект? Чей проект будет более качественным? Оставляйте свои мнения в опросе и пишите комментарии — давайте обсуждать.

Что такое шаблон пользовательской истории и почему он так хорошо работает?

Получите 200 реальных пользовательских историй

Примеры, написанные Майком Коном

Введите свой адрес электронной почты ниже, чтобы получить более 200 пользовательских историй из трех полных бэклогов продукта, созданных Майком Коном.

Имя

Адрес электронной почты

политика конфиденциальности

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

Как…, я… так что…..

Этот шаблон пользовательских историй по agile был разработан тренером по agile Рэйчел Дэвис из британской компании Connextra в начале 2000-х годов. С тех пор он стал признанным стандартом для выражения пользовательских историй.

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

Шаблон пользовательской истории, состоящий из трех частей

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

В User Stories Applied я описал три элемента следующим образом:

• Как (роль), я хочу (функция), чтобы (ценность для бизнеса).

Позже я стал называть эти три элемента ролью, целью и причиной .

В конце концов я решил называть их гораздо проще: кто, что и почему . Три элемента стандартного формата пользовательской истории Agile адрес:

• Кому нужна функциональность
• Чего они хотят
• Почему они этого хотят

Эти элементы отвечают на 3 из 5 вопросов хорошего журналистского рассказа: кто, что, где, когда и почему. При обсуждении требований к продукту или системе кажется разумным не упоминать «Когда» и «Где», поскольку ответы обычно будут «прямо сейчас» и «в продукте».

Давайте рассмотрим каждую из этих частей формата пользовательской истории.

Кто: Элемент формата истории пользователя #1

Кто (как роль) описывает пользователей типичного продукта или системы. Некоторые команды разработчиков создают для этого формальные образы пользователей. Другие объединяют типы пользователей в категории.

Например, я сейчас ввожу это в Google Docs. Меня можно считать случайным пользователем Документов.

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

Других, кто использует эти функции, можно назвать опытными пользователями .

Я обычно отправляю черновики своего блога редактору. И так, Редактор может быть еще одной ролью при определении различных типов пользователей Google Docs.

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

Что: Элемент формата пользовательской истории № 2

Во второй части стандартного шаблона указано, что требуется или необходимые — желаемые результаты или характеристики продукта. Обычно это формулируется как «Я хочу…». На самом деле, в течение многих лет в моих презентациях на конференциях и других тренингах по пользовательским историям был слайд, говорящий: «Как пользователь, я хочу, чтобы этот шаблон»

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

• Как участник я должен ввести надежный пароль….

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

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

Почему: элемент формата пользовательской истории #3

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

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

В качестве примера остановитесь на нашей истории с проверкой орфографии. Предположим, что это было предоставлено команде без оговорки так-что просто: Как опытный пользователь, я хочу проверку орфографии . Скорее всего, это привело бы команду к разработке того, чем были все ранние средства проверки орфографии: инструменты постфактум работают с документом после того, как он был написан.

Но нашему опытному пользователю не нужен лишний шаг после завершения написания документа. Скорее, опытный пользователь хочет того, что сегодня кажется более стандартным: исправление ошибок в реальном времени по мере их совершения. То, что пользователь действительно хочет, дается предложением так-что: пользователь не хочет беспокоиться об орфографических ошибках.

Должен ли пункт So-That быть необязательным?

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

Я не считаю это обязательным, потому что иногда это просто не добавляет никакой ценности. Рассмотрим историю о входе в систему: Как участник, я должен войти в систему . Какой так-то пункт вы можете добавить к этой истории, что добавляет ценность или проясняет цель истории? Что-то из этого действительно помогает или это просто лишний текст, добавленный для соответствия шаблону:

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

Хотя я не считаю пункт так-то обязательным, я пишу его почти постоянно. Я просмотрел недавний бэклог, который написал, и 62 из 64 историй (97%) имели т. е. статей. Небольшое количество случаев не позволяет мне считать его обязательным.

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

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

1. Элементы представлены в правильном порядке

Я думаю, что элементы — кто, что и почему — представлены в правильном порядке. Подумайте о любой истории, не пользовательской, а о фильме, романе, анекдоте или шутке, которую вы хотите рассказать другу. Самое главное в этой истории почти всегда — кто это делает. Мы называем этого человека главный герой .

Когда мы смотрим фильм, нам нужно больше думать о главном герое, чем о сюжете. Меня не волнует, так или иначе, что Звезда Смерти взорвется, пока я не увижу частичку себя в Люке, Хане или Лее и не смогу соотнести с ними .

Только после того, как я узнаю кто , я забочусь о что и почему . Стандартный шаблон пользовательской истории размещает их в таком порядке.

2. История рассказывается от первого лица

Нам нравятся истории о себе. (Ну, если только мы не подростки и наши родители не рассказывают истории о не очень милых вещах, которые мы делали, когда были младенцами.) Следующим по значимости после истории обо мне является история о тебе. Наименее интересна история о парне на другом конце города, которого я никогда не встречал.

Истории про я и ты и мы и она и он интересны.

The Beatles знали об этом. Они намеренно впихнули в названия своих песен как можно больше личных местоимений. И если они не могли вставить личное местоимение в название песни, они вставляли столько, сколько могли, в текст песни.

Первый британский альбом The Beatles содержал местоимения в 8 из 14 названий песен (57%). За 19 минут и 30 секунд этих восьми песен The Beatles использовали 325 личных местоимений, по одному местоимению каждые 3,6 секунды.

Это сработало так хорошо, что их второй альбом имел местоимения в 64% названий. Затем The Beatles увеличили его до 79% на своем третьем альбоме.

В интервью журналу Billboard битл Пол Маккартни сказал, что это было очень преднамеренно: «Все наши ранние песни содержали «я» или «ты». Мы были совершенно прямолинейны и бесстыдны с фанатами: Люби меня, делай, пожалуйста, доставляй мне удовольствие, я хочу держать тебя за руку. »

Стандартный шаблон пользовательской истории начинается с I , самого личного из личных местоимений. У меня нет никаких оснований для этого утверждения — я не специалист по изучению мозга, — но я клянусь, что что-то происходит, когда у нас есть история пользователя, начинающаяся с I . Мы относимся к этой истории более близко, чем если бы то же самое было написано в виде традиционного утверждения Система должна… .

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

3. Заинтересованным сторонам сразу становится комфортно Заполнять пробелы

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

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

У меня никогда не было такой проблемы с пользовательскими историями. Я могу провести семинар по написанию историй с заинтересованными сторонами, просто написав Как _____, я ______ так, чтобы _______ на доске и сказав им, что мы собрались, чтобы заполнить пробелы столько раз, сколько сможем.

Заинтересованные стороны понимают. Для них это естественный способ говорить.

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

Например, Behavior-Driven Development — отличный способ для выражения тестов или указания на примере. Мартин Фаулер описывает синтаксис данного алгоритма как «стиль представления тестов». Он отлично подходит для написания тестовых спецификаций, но не так хорош для общения с клиентами, отчасти потому, что его шаблон менее естественен.

Я разговариваю с 2 или 3 лет. Не знаю, начинал ли я когда-нибудь предложение с на . Я определенно никогда не использовал дано, когда и , а затем в таком порядке в предложении. Я бесчисленное количество раз говорил: «Я хочу , , , ».

4. Структура пользовательских историй помогает владельцам продуктов расставлять приоритеты

Структура хороших пользовательских историй на самом деле помогает владельцам продуктов расставлять приоритеты. Если бэклог продукта состоит из таких вещей, как:

• Исправить обработку исключений
• Разрешить пользователям делать заказы
• Пользователи хотят видеть фотографии
• Показать варианты размеров комнаты

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

Недостатки трехчастного шаблона пользовательской истории

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

1. Слишком много историй пишутся просто как «Как пользователь…»

Слишком часто члены команды имеют привычку начинать каждую пользовательскую историю со слов «Как пользователь…» Иногда это результат ленивого мышления и истории. Писатели должны лучше понять пользователей продукта, прежде чем писать так много историй «как пользователь…». Важно иметь в виду определенный тип пользователя.

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

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

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

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

В подобных случаях командам необходимо использовать альтернативные способы выражения того, что должен делать продукт. Синтаксис, используемый в описаниях вакансий или функциях Feature-Driven Development, может быть лучшим выбором.

2. Шаблону слишком часто рабски следуют

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

Ранее сегодня я написал элемент невыполненной работы по продукту: «Изменить способ отправки напоминаний о повторах веб-семинаров в последний день, как мы обсуждали на пятничной телеконференции».

В качестве элемента невыполненной работы по продукту это отстой. Если ее не исправят в ближайшее время, никто даже не вспомнит, о какой ошибке говорили в каком-то забытом телефонном звонке.

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

Что вы думаете?

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

Преимущества пользовательских историй перед требованиями и вариантами использования

Получите 200 реальных пользовательских историй

Примеры, написанные Майком Коном

Введите свой адрес электронной почты ниже, чтобы получить более 200 пользовательских историй из трех полных бэклогов продукта, созданных Майком Коном.

Имя

Адрес электронной почты

Мы ненавидим спам и обещаем обеспечить безопасность вашего адреса электронной почты. Отписаться в любое время. политика конфиденциальности

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

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

Требования обычно представляют собой список утверждений «Система должна…», например:

• Система должна позволять компании оплачивать объявления о вакансиях с помощью кредитной карты.
• Система должна принимать карты Visa, MasterCard и American Express.
• Система спишет средства с кредитной карты до того, как объявление о вакансии будет размещено на сайте.
• Система должна предоставить пользователю уникальный номер подтверждения.

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

Преимущества пользовательских историй.

.

Преимущество 1: пользовательские истории требуют диалогов

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

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

Преимущество 2: Истории пользователей вербальны, а значит более точны

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

Мы действуем так, как будто написанные слова точны, но часто это не так. Например, недавно за обедом я прочитал это в своем меню: «Закуски идут с выбором супа или салата и хлеба».

Это не должно было быть трудным для понимания предложением, но это было так. Что из этого означало, что я мог выбрать?

• Суп или (салат и хлеб)
• (Суп или салат) и хлеб

Сравните слова, написанные в этом меню, со словами, произнесенными официанткой: «Вы хотите суп или салат?» Более того, она устранила всю двусмысленность, поставив на стол корзину с хлебом, прежде чем принять мой заказ.

Преимущество 3: Пользовательские истории относительно легко оценивать и расставлять приоритеты

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

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

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

Преимущество 4: пользовательские истории поощряют команды откладывать сбор деталей

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

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

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

Преимущество 5: пользовательские истории дают общее представление о продукте

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

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

Например, рассмотрим следующие требования, адаптированные из книги Алана Купера Заключенные управляют приютом: почему высокотехнологичные продукты сводят нас с ума и как восстановить здравомыслие .

• Изделие должно иметь бензиновый двигатель.
• Изделие должно иметь четыре колеса.
• На каждом колесе изделия должна быть установлена ​​резиновая шина.
• Изделие должно иметь руль.
• Изделие должно иметь стальной корпус.

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

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

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

Глядя на цели, мы получаем совершенно иное представление о продукте: покупатель действительно хочет газонокосилку, а не автомобиль!

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

Преимущество 6: пользовательские истории предполагают стоимость

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

Типичный сценарий: один или несколько аналитиков тратят два-три месяца (часто дольше) на написание длинного документа с требованиями. Затем этот документ передается программистам, которые сообщают аналитикам (которые передают сообщение заказчику), что проект займет 24 месяца, а не шесть месяцев, на которые они рассчитывали.

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