Метод user story реферат
Обновлено: 04.05.2024
Это пять техник для нарезки больших пользовательских историй на маленькие.
Зачем делить User Story?
С большими User Story сложнее работать, не всегда команда успеваю закончить их за спринт и показать результат. С маленькими проще работать, за спринт можно успеть 6-8 пользовательских историй и сразу дать ценность клиенту и пользователям.
Почему метод деления назвали SPIDR и кто им пользуется?
SPIDR — это аббревиатура по первым буквам техник: Spikes, Paths, Interfaces, Data, Rules. Техники используют начинающие команды–разработчиков. Потому что это простой способ начать нарезку пользовательских историй. Со временем они пробуют другие техники и выбирают самые удобные для себя.
SPIDR User Story
Когда команда работает над продуктом, то делит работу над ним на User Story — пользовательские истории. Это короткие и простые описания действий пользователя в продукте. Например, перевод денег со своей карты другому человеку. Чтобы быстрее увидеть результаты работы, пользовательские истории делят на маленькие подзадачи.
В Agile–командах принято делить большие пользовательские истории на несколько маленьких. Чтобы за недельный спринт сделать 6-8 историй. Есть много методик, как делить пользовательские истории. В тексте мы расскажем про SPIDR. Это аббревиатура по первым буквам техник: Spikes, Paths, Interfaces, Data, Rules.
В SPIDR пользовательские истории разделяют по архитектурным слоям: одна история для бизнеса, другая — для пользовательского интерфейса, третья — для базы данных и так далее. Этот подход помогает разделить большие пользовательские истории. Им часто пользуются начинающие команды.
До паука SPIDR не хватает одной буквы. Но для запоминания названия техник картинка подходящая
Техника Spikes
Техника основана на исследованиях и накоплении знаний. Хотя она идет первой в списке, в жизни к ней прибегают в последнюю очередь. Если другие методы SPIDR не дают положительных результатов, то используют Spikes.
Например, пользовательская история слишком большая и в ней много технических неизвестных. Представим, что вы делаете платежную систему в облаке. Раньше таких не было. Поэтому проекте много неизвестных. Чтобы учесть риски, команда составляет довольно большую пользовательскую историю. Затем проводит исследования, ищет разные способы, как разбить ее на части. В будущем это поможет команде с похожими проектами.
Для бизнеса здесь и сейчас метод Spikes не принесет ценности. Но он делает умнее и опытнее команду разработчиков.
Как понять, что нужен Spikes: когда команда разработчиков не знает, как разбить пользовательскую историю на подзадачи. Тогда они включают ее в один спринт и проводят исследования. В следующем спринте они берут похожую пользовательскую историю. Используют свои новые знания, которые они получили в исследовании, и разбивают историю на подзадачи.
Пример нарезки User Story на мелкие задачи
Техника Paths
В этом методе команда ищет альтернативные пути для разбиения User Story, потому что пользователь может пойти по разным сценариям.
Возьмем пользовательскую историю: пользователь хочет оплачивать покупки в интернет–магазине. У него есть два возможных пути: оплата с помощью кредитной карты или оплата с помощью Paypal. Теоретически оплату кредитной картой можно разделить по типам кредиток: Visa, Mastercard, American express и так далее.
Вы думаете: имеет ли смысл для каждого типа кредитной карты иметь свою собственную историю. Ведь главная задача — оплата покупок. И она хорошо делится на две упомянутые альтернативы: Paypal и кредитная карта. В итоге вы разбиваете пользовательскую истории на небольшие задачи, из которых одна главная — оплата по кредитной карте.
Некоторые приложения, сайты и другие IT-продукты, как магнит, притягивают и крепко удерживают пользователей, что покидать их совершенно не хочется. Дело в пользовательском интерфейсе ? Продуманных текстах? Особой программистской магии? Возможно. Но часто объяснение более простое: создатели продукта хорошо проработали каждую возможную User Story и благодаря этому предугадали желания клиента. Что такое пользовательские истории, зачем они нужны и как их использовать — отвечаем на вопросы в статье.
Что такое User Stories?
Работа с аудиторией — одна из важнейших составляющих создания продуктов , потому что именно пользователи будут определять его успех. Следовательно, необходимо понимать, как пользователи будут взаимодействовать с вашим приложением или сайтом. Чтобы лучше в этом разобраться, существует User Story.
Пользовательская история , или User Story — это описание функций продукта простым языком, составленное с точки зрения пользователя. Она помогает понять, какую пользу клиенту принесет функционал приложения, еще на этапе аналитики проекта . Пользовательские истории служат неким контекстом для разработчиков: те понимают, чего хочет от продукта конечный пользователь, и работают более целенаправленно. Эти истории состоят из нескольких предложений и не углубляются в детали: они отражают суть и фокусируются на главном.
Для чего применяется User Story?
Пользовательские истории помогают сосредоточиться на потребностях пользователя : как он будет использовать приложение? Чего он ждет от продукта? Как поведет себя в той или иной ситуации? Таким образом, ответы на эти вопросы помогут создателям продукта решать настоящие проблемы клиентов. Вот несколько главных задач, для которых необходимо использовать User Stories :
- организовать работу. Когда проект разбит на части, связанные с пользовательскими историями, каждая из них представляет собой цельную и понятную задачу. Так разработчики могут фокусироваться на каждой из них и получать измеримый результат. Так, например, мы описывали пользовательские требования с помощью дискретных User Strories для разработки платформы для онлайн-обучения . Это помогло клиенту в условиях ограниченного бюджета гибко управлять приоритетами в разработке, добавляя или исключая User Story.
- сохранить фокус на пользователе. Конечно, разработка включает себя десятки сложных задач, связанных с техническими, финансовыми и другими вопросами. Однако юзер стори — это постоянное напоминание команде о тех, для кого этот продукт создается, и направляют их работу в нужное русло. Кто такой юзер вашего приложения и как вы можете быть ему полезны? Ответы на эти вопросы помогут вам составить качественную user story .
- сплотить команду. Несмотря на то, что у каждого есть свои задачи ( дизайн , тестирование , разработка ), каждый понимает конечную цель и видит себя частью целого. Только работая сообща, можно достичь нужного пользователю результата, и пользовательские истории дают четкое понимание этого аспекта работы.
- найти свежие решения. Команда старается придумать самый приятный и интересный способ решить задачу пользователя. Часто это приводит к появлению новых интересных идей и их воплощению. Результат — полезный и уникальный продукт.
Структура User Story
Ваша пользовательская история будет уникальной, поэтому вы можете создать свой особенный способ ее изложения. Однако есть стандартные элементы создания пользовательской истории, которые помогут вам лучше всего “прочитать мысли” пользователя и понять его способ мышления. Эти элементы включают в себя:
Когда вы разобрались с основными моделями поведения конечных пользователей , необходимо более подробно описать их действия. Как они будут заказывать еду в вашем приложении? Что будут искать на сайте университета? По каким критериям будут искать врача? Отталкивайтесь от того, что у вас есть, и постарайтесь как можно точнее представить поведение пользователей. Примерно так выглядит схема сценария использования вашего продукта:
сценарий : Заголовок
и [ещё немного контекста]…
тогда [результат]
и [ещё один результат]…
С помощью User Stories вы сможете приступить к созданию продукта более обдуманно. Формулировка функциональных требований станет проще, вы уже будете видеть конечный результат, и достичь его с этим пониманием будет проще.
User Story: примеры
Представим, что нужно разработать телемедицинское приложение , в котором врачи смогут проводить онлайн-консультации и отслеживать показатели пациента. Давайте для начала сформулируем несколько основных примеров User Stories для пациента, который пользуется этим приложением:
- я как пациент хочу созваниваться с врачами по видеосвязи, чтобы иметь возможность обсудить вопросы здоровья;
- я как пациент хочу иметь собственную медкарту, чтобы хранить всю информацию о своем здоровье в одном месте;
- я как пациент хочу оплачивать консультации в приложении, чтобы не искать для этого сторонние сервисы и обезопасить свои средства.
Вторая, не менее важная часть приложения — для врачей. У них есть свои потребности, поэтому и функционал будет отличаться. Вот примеры юзер стори для врачей:
- я как врач хочу созваниваться с пациентами по видеосвязи, чтобы иметь возможность работать из дома;
- я как врач хочу управлять своим расписанием, чтобы равномерно распределять нагрузку;
- я как врач хочу получать от пациентов медиафайлы, чтобы изучать результаты исследований и более качественно лечить людей.
Для написания User Stories необходимо понимать потребности клиентов. При этом количество и содержание ваших пользовательских историй зависит от разных факторов: целевая аудитория, функционал приложения и даже бюджет на разработку. Не бойтесь экспериментировать и придумывать разнообразные юзер стори . Даже неудачные варианты помогут вам сузить фокус и сосредоточиться на главных потребностях пользователя.
INVEST критерии написания User Story
Иногда бывает сложно разобраться, какие из разработанных пользовательских историй вам подходят и как писать юзер стори . Чтобы решить этот вопрос, можно воспользоваться INVEST критериями. Это аббревиатура, которая состоит из важнейших составляющих удачной user story. Давайте остановимся на этих критериях подробнее.
I — Independent. Независимая. На конкретную историю не должны влиять другие истории — или влиять минимально. Благодаря этому вы сможете проработать каждую из них, не ожидая окончания работы над какой-либо другой историей.
N — Negotiable. Договорная. Другими словами, пользовательскую историю нужно детально обсудить и прийти к оптимальному решению. При этом история должна быть емкой и краткой, отражая свою главную идею. Agile User Stories , или гибкие пользовательские истории — это хорошая возможность подстроиться под любые внешние изменения. У нас в Azoft также встречается практика, когда в рамках одного проекта может применяться несколько подходов к его ведению, что делает работу персонализированной и качественной.
V — Valuable. Ценная. Это достаточно простой и понятный пункт: пользовательская история должна быть ценной, и описанный функционал должен приносить бизнесу пользу.
E — Estimable. Доступная для оценки. У вас должна быть возможность оценить эту историю: просчитать ресурсы, необходимые для работы над ней, определить сроки реализации и установить критерии успеха.
S — Small. Маленькая. Пользовательские истории не должны описывать весь функционал продукта — сосредоточьтесь на определенной узкой задаче. Это поможет вам реализовать историю в течении короткой итерации и быстро продвигаться в работе над проектом.
T — Testable. Тестируемая. Для написания пользовательских историй у вас должна быть возможность протестировать их — понять, насколько они нужны пользователям, какие есть недостатки, как истории можно было бы изменить. Это поможет вам получить обратную связь от аудитории и довести продукт до совершенства.
Подпишитесь
Оставьте адрес, и каждый месяц мы будем высылать свежую статью
о новых трендах в разработке програмного обеспечения.
Статья будет полезная Junior-специалистам, которые так или иначе работают с документацией на проекте. В статье рассматриваются как сами пользовательские истории, так и критерии, по которым можно написать хорошую историю. Из статьи читатель сможет подчерпнуть и как писать истории, и как правильно дополнить их деталями, и какие детали важны, и как не перегрузить историю.
Содержание:
Вводная информация о User Stories
Что такое User Stories
Сейчас User Stories являются одним из главных приемов работы бизнес-аналитиков и Product Owner. Бизнес-стейкхолдеры рассказывают эти истории, чтобы показать команде разработки суть и ценность задачи, которую надо реализовать. Они короткие, написаны деловым языком и поэтому понятны всем заинтересованным лицам проекта.
Дать емкое определение этому приёму сложно. Его внешняя простота заставляет сводить его описание к внешним характеристикам. Поэтому я, как автор, хотел бы дать читателю несколько определений.
Пользовательские истории — это краткое описание функциональности, детали которой должны уточняться в ходе устных обсуждений между заинтересованными лицами проекта.
Такое определение не помогает разобраться в сути приема и его распространенности среди пользователей. Неужели главное — это записи или то, что детали должны уточняться? Думаю, нет. Поэтому я не бросил копания и начал смотреть другие источники. Множество сайтов предлагает такое определение:
User Story -- это короткая запись сути задачи в формате "As a … I want to … so that I can …".
Этот ответ тоже не удовлетворил моё любопытство. Такое определение ставит во главу угла формат. Ведь User Story может существовать и без какой-то части (As a user, I want to save data) и быть написанной без обсуждения интровертным продакт-овнером. Но самое главное — об этом будет ниже — User Story может быть написана по совершенно иному формату!
Пройдя круг обсуждений с ментором, прочитав и посмотрев много статей и видео, я понял, что главное в пользовательской истории — это ценность, которую пользователь получит от функции. Поэтому я попытался сгенерировать определение:
User Story -- это приём записи требований, который помогает команде разработки понять нужду клиента и после обсуждения выбрать, описать и утвердить то решение, которое удовлетворит эту нужду.
Чтобы понять, чем является сама нужда, давайте рассмотрим следующий пример. Человек хочет есть. Так, мы можем накормить человека рыбой. И тогда он будет сыт целый день. Но в этом ли настоящая нужда этого человека? Вряд ли, ведь завтра человек проголодается. Внимательный читатель уже догадался, что главная нужда человека -- инструмент, которым можно добыть еду (например, удочка).
Очень важно отметить, что история и ее ценность может быть направлена не только на какую-то группу пользователей. Она может быть направлена на команду разработки (обновить компонент, добавить компонент, переделать код. ), Product Owner или представителей бизнеса.
Далее в статье я использую однострочные примеры пользовательских историй: "Как Х, я хочу Y, чтобы Z". Тем не менее, многие аналитики использую другой подход, который считается даже более каноничным.
Так, истории пишутся в три строки:
Job Stories
В целом Job Stories — схожая с US техника. Можно назвать их приёмом-субститутом, ведь обычно они не используются вместе и выполняют максимально похожую функцию. Job Stories представляют требование в виде действия, которое выполняет пользователь. Они не описывают саму функцию, а лишь концентрируют внимание команды на потребности.
Job Stories концентрируются на психологической части фичи, на эмоциях, тревогах и прочем, что может возникнуть во время использования функции.
Situation: дает контекст обо всей JS, который помогает dev-команде придумать возможное решение.
Motivation: описывает невидимую руку, которая ведет юзера к использованию данной функции.
Expected Outcome: описывает, что получит юзер после использования функции.
Job Stories могут писаться по двум форматам:
В одну строку:
When X I want to Y so I can Z" или "When X, actor is Y so that Z.
В три строки:
When X
I want to Y
So I can Z.
When I want to withdraw money from my bank account, I want to know I have enough money in my account to withdraw some now so that I can go out to dinner with my friends.
Вопросы, которые следует задавать во время написания стори
Во время написания истории для аналитика важен не только её текст, но и то содержание - ценность, проблема - которая описывается этим текстом. Чтобы написать историю, которая сможет решить проблему пользователя, аналитику надо лучше понять пользователя и задать себе следующие вопросы.
Решает ли это настоящую проблему юзера?
Есть ли у такого решения какие-либо side effects? Влияет ли это на продукт в целом?
Какие последствия от такого решения?
Вопросы можно задать и стейкхолдерам. Например, первый вопрос имеет смысл адресовать Product Owner в команде которого вы работае. А второй и третий - самой команде разработки, они наверняка смогут указать на какие-то подводные камни.
Пример работы техники "5 почему".
Три С в User Story
Первое определение говорит о коммуникации и карточках, но не упоминает согласие. Эти три понятия образуют "the 3 C's of User Stories".
Card — по задумке автора метода истории пишутся на физических карточках. В реальности они пишутся в Jira и Confluence, поэтому мы не так ограничены в детальности.
Conversation — каждая стори — это множество митингов вокруг нее, которые и направлены на понимание деталей.
Confirmation — перед началом работы клиент дает согласие на данное решение, а команда полностью уверена в выполнимости решения.
User Personas
Этот метод представляет собой детализированное описание пользователя продукта. Описание пользователя должно быть конкретным и детальным, ведь по его описанию члены команды должны понять, что это целевая аудитория приложения, которое они делают.
Создавая четкого и детального персонажа, аналитик требований или Product Owner уменьшает вероятность того, что нужды пользователя будут забыты или заменены на нужды тех членов проектной команды, которые ставят себя на место пользователей.
Карточка персонажа не обязана быть полностью правильной, но она обязана содержать максимальное количество деталей.
Наиболее важными деталями персонажа являются его имя, место работы (роль в системе), место проживания. Причём имя и роль в будущем могут использоваться и при написании историй:
Как Георгий, я хочу печатать документы, чтобы я мог работать над ними вне компьютера.
Стоит также отразить маркетинговые характеристики персонажа такие как предпочитаемые бренды, блюда, увлечения и хобби. Эти характеристики важны не только, чтобы знать для кого мы создаем ПО, но и как его рекламировать и продавать. Описание должно также раскрывать и характер персонажа. Он веселый или чаще хмурится? Он делится информацией в соцсетях или вовсе не ведет их?
В описании следует отразить и задачи, которые наиболее важны для персонажа в его работе с системой. Это поможет всей команде увидеть нужды персонажа и поможет создать стимул для покупки премиум-версии или подписки.
Создав одного персонажа, можно отдохнуть и насладиться проделанной работой. Однако не стоит останавливаться, так как именно набор персонажей (от 3 до 10) поможет в будущем выстроить систему, которая поможет приоритизировать истории, благодаря пониманию того, что нужно тому или другому персонажу. А если что-то нужно двум из трех персонажей, то следует бросить все силы на эту функцию.
Что же в сухой практике использования User Personas?
На практике автор статьи убедился, что команде не важны многие вещи из описания Persona: бренды, биография, боязни. Я думаю, что наиболее актуальная информация, которую следовало бы поместить в описание Persona -- это роль в системе, цели от ее использования, а также основные кейсы.
Отрицательный персонаж
Не все персонажи должны создаваться, чтобы показать пользователей системы. Задача некоторых указать, кому в приложении нет места.
Создавая любое приложение для такси, мы вспомним, что в процессе заказа традиционно есть 3 участника: клиент, водитель, оператор. Скорее всего, задачей нашего приложения будет автоматизация работы оператора так, чтобы клиент мог связаться с водителем напрямую. В таком случае самому оператору в системе не будет места.
Ключевой персонаж
Ключевыми персонажами являются те, для кого и будет проводиться проектирование решения. Такой персонаж олицетворяет группу пользователей, которая будет либо чаще всего пользоваться приложением, либо имеет какие-то особенности, из-за которых им следует пользоваться приложением иначе. Такие персонажи заслуживают отдельных интерфейсов в системе.
Давайте вернемся к приложению для саппорта. В нем оба персонажа, которые всё-таки будут пользоваться системой, будут ключевыми. Так, тому, кто будет устранять жалобы, нужен интерфейс, который показывает жалобы и помогает выстроить маршрут. В тоже время клиенту, скорее всего, нужно посмотреть все его жалобы и оставить новую.
INVEST
По критериям INVEST мы можем судить, хорошо ли написана User Story и можно ли над ней работать.
I — Independent — Независимый
Следует избегать зависимости между историями, так как иногда это приводит к проблемам во время имплементации. (пример: задача А не может быть реализована без задачи Б, однако задача А — очень важна, а Б лишь желательно иметь в готовом продукте).
На практике это стремление не всегда достижимо. Например, в случае зависимости нескольких историй друг от друга, следует искать другой способ разбить их.
Мы хотим добавить в наш продукт поддержку банковских карт MasterCard, Visa и третьей системы. Тогда проще всего разделить эту стори на три. В первой, самой большой, разработчик должен добавить поддержку банковских карт в целом и какую-то из списка. А остальные две могут пойти в другую стори, которая зависит от первой.
N — Negotiable — Обсуждаемый
V — Valuable — Ценный
Каждая User Story должна нести пользу как пользователю, так и продукту, а описание должно создаваться так, чтобы ценность была наиболее очевидна. Так команда разработки будет понимать, зачем это нужно реализовывать.
Если ценность историй, которые несут новый функционал или улучшают старый, очевидна, то с теми, которые завязаны на технической стороне продукта, не все так очевидно. Но и истории, в рамках которой команда избавляется от легаси-кода, делает рефакторинг или переносит старый функционал на новую инфраструктуру (например, в новую базу данных) несут ценность для как для продукта, так и для пользователя. Скорее всего, пользователь ощутит их благодаря улучшению отзывчивости или скорости работы системы. Это следует отразить в описании такой задачи.
E — Estimable — Оцениваемый
История должна быть настолько ясно написана, чтобы у разработчика было достаточно понимания ведь без него он сможет выдать оценку, близкую к правде. Есть три причины, почему dev не может выдать оценку:
история слишком большая;
в описании недостаточно данных;
разработчику нужно больше опыта.
Однако подробнее об оценках поговорим в отделе “Оценка историй”.
S — Small — Компактный
Этот пункт говорит не о самом описании под историей, а о ее размере, времени на реализацию. На многих проектах команды устанавливают рамки, в которые должна уместиться история. Так, часто можно услышать о правиле, согласно которому история должна укладываться в рабочий день. Однако на других же пользовательской историей может считаться функция, на реализацию которой нужно несколько месяцев времени разработчика.
T — Testable — Тестируемый
Суть этого пункта не только в том, что команда тестировщиков должна понимать, что проверять, но и в том, что пользовательская история должна обладать чем-то, что можно посмотреть, запустить.
Однако не стоит забывать, что стоит писать истории так, чтобы QA-команда могла понять, какие кейсы и сценарии ей тестировать. Для создания этого понимания аналитику требований следует пользоваться критериями приемки и описанием сценариев по Gherkin. Подробнее об этих приемах можно прочитать в разделе “Как добавить деталей к истории”.
Как добавить деталей к истории?
Очень важно понимать, что когда работа над "телом" стори закончена, начинается работа над деталями, которые и помогут команде понять, что надо реализовать. Среди способов добавить детали самыми знаменитыми являются Acceptance Criteria и сценарии по Gherkin.
Acceptance Criteria
Что такое АС
Элемент User Stories, который дополняет их так, что команда начинает видеть историю в деталях. Этот инструмент помогает понять, что должно быть сделано, чтобы удовлетворить потребность бизнеса.
АС помогают увидеть фичу с точки зрения конечного пользователя, установить границы фичи и создать понимание того, что должно быть сделано и что будет проверяться.
Их надо понимать максимально буквально, потому что это те критерии по которым мы понимаем, выполнена история или нет.
Для чего нужны
Показывают фичу с точки зрения конечного юзера.
Для понимания задач бизнеса.
Достижения консенсуса с бизнесом относительно какой-то стори.
Служат базой для тестов.
Помогают эстимировать стори.
Правила написания
Мы пишем их не в форме should, а в настоящем времени (суть в том, что человек читает и видит, какими "способностями" обладает юзер или система).
Должны быть проверяемы. -> pass/fail result прописан четко.
Должны быть измеримы.
Пишутся ДО работы над задачей.
Включают функциональные и нефункциональные критерии.
Пользователь может выбрать цвет. Пример: есть дропдаун с цветами.
Не слишком узкие (привязаны к одному юз-кейсу-примеру) и не слишком широкие (понятно где сделано и как работает).
Не содержат технического арго.
Что делать, когда надо выбрать одно из нескольких решений?
Тогда на помощь приходит Evaluation Criteria. Используются, чтобы оценить ценность нескольких решений и выбрать нужное.
Компания хочет пообедать в итальянском веганском ресторане, где играет живая испанская гитара. Тогда ресторан, который подойдёт, должен соответствовать трем критериям:
1. Ресторан должен быть итальянским.
2. Ресторан должен быть должен подавать вегетарианские блюда.
3. В ресторане играет живая испанская гитара.
Gherkin
Gherkin - это способ описания сценариев использования систем, который понятен разработчикам, тестировщикам, бизнесу. Он строится по строгому синтаксису и потому позволяет "обходить" многие вольности естественного языка.
Эти сценарии используются чаще всего для описания критериев приёмки и могут стать отличным помощником для автоматизации тестирования. Их большим минусом является нечитабельность, ведь сценарии представляют из себя длинные тексты, в то время как АС - это чаще всего 1-2 строчки текста.
Scenario: Dr Bill posts to his own blog.
GIVEN I am logged in as Dr Bill
WHEN I try to post to my blog
THEN I should see "Your article was published"
Базовый синтаксис Gherkin
Given - это тоже самое, что Precondition в Use Case. То, что должно быть выполнено перед началом сценария.
When - то, что приводит в действие систему; главная суть этого юзкейса.
Then - то, что должно произойти в конце юзкейса.
And - для усложнения сценария вместе с given, when, then. Считается плохим тоном перегружать сценарий большим количеством and-конструкций, показывает, что в нем слишком много деталей.
But - используется с Then и указывает на то, что не должно случиться как итог юзкейса.
Feature - объединение множества сценариев в одну функцию. Включает сторю, АС и сценарии этой стори.
Background - устанавливает precondition сразу для всех сценариев, чтобы не переписывать.
1) Пишется сценарий-скелет.
Scenario Outline: Dr Bill posts to his own blog.
Given I Have published
When I try to post a new blog
Then I should see
2) Создается таблица с примерами.
Третья статья из серии инструкций по инструментам, которые помогут сделать лучше ваши продукты и жизнь клиентов.
User Story (пользовательская история) — короткая формулировка намерения пользователя и что продукт должен сделать для него.
Для чего применяется User Story?
- Для описания элементов бэклога
- Для лучшего понимания пользователей
- Для описания требований к продукту на понятном для всех языке: пользователей, разработчиков другие заинтересованных лиц
- Для вовлечения в процесс разработки пользователей и заинтересованных лиц
- Для построения User Story Mapping
Как формулировать User Story?
User Story — это ответы на 3 вопроса, связанные в одно предложение:
- Что это за пользователь?
- Какое действие он хочет выполнить в продукте или какой результат от продукта хочет получить?
- Зачем это ему?
я хочу/могу ,
чтобы
Примеры
И ещё немного примеров:
Как , хочу , чтобы
Как , я хочу , чтобы
Как видно из примеров, ценность User Story как инструмента в том, что он очень универсален — вы можете использовать для лучшего понимания пользователей в абсолютно любой сфере.
Хорошая пользовательская история
INVEST — критерий хорошей истории:
Independent — независимая от других историй, то есть истории могут быть реализованы в любом порядке
Negotiable — обсуждаемая, отражает суть, а не детали; не содержит конкретных шагов реализации
Valuable — ценная для клиентов, бизнеса и стейкхолдеров
Estimable — оцениваемая по сложности и трудозатратам
Small — компактная, может быть сделана командой за одну итерацию
Testable — тестируемая, имеет критерии приемки
Эти критерии не всегда достижимы, но чем больше историй будут им удовлетворять, тем более гибким будет ваш процесс разработки продукта.
Мы учим формулировать User Story на тренинге Владелец продукта: краткий курс выживания.
Само название – user story – указывает, что этот документ имеет формат истории и излагается в повествовательной форме.
Ключевой компонент гибкой разработки ПО – фокус на людях. Пользовательская история ставит конечных потребителей в центр всего процесса. В ней не используется технический язык, она должна лишь дать команде контекст. Прочитав user story, члены команды понимают, что именно и зачем они делают, и в чем ценность создаваемого им продукта.
Шаблон user story
Рассмотрим этот шаблон подробнее.
Отличие user story от спецификаций и сценариев использования
Текст юзер стори поясняет роль и действия пользователя в приложении. Пользовательская история в чем-то заменяет спецификации требований и сценарии использования, но все же отличается от них. Различия небольшие, но существенные:
Как писать user story?
Пользовательская история должна быть написана грамотным языком.
Когда пишете user story, следует следить за тем, чтобы не скатиться в написание техзадания. Истории пользователей фиксируют только самые важные элементы требований:
Практические советы по написанию user story
- Лучше написать побольше небольших историй, чем несколько объемных.
- Писать user story лучше всей командой, чтобы не пропустить важные для продукта, бизнеса и пользователей вещи.
- Пользовательскую историю нужно писать простым языком, без рабочего сленга (по возможности). Благодаря этому она будет понятна всем людям, занятым в проекте.
- Нужно точно описать потребности пользователя.
- Юзер стори нужно писать так, чтобы по ней можно было тестировать.
- Код пишется после тестов.
- В написании user story не стоит жестко привязываться к каким-то элементам пользовательского интерфейса.
- В каждой истории должна быть оценка сложности реализации, а также времени, которое потребуется на реализацию.
- User story должна содержать описание конечного результата.
- Хорошая user story соответствует модели INVEST.
Модель INVEST
INVEST – слово, использующееся для запоминания критериев качественной истории:
- I – independent. История должна быть независима от других историй.
- N – negotiable. История обсуждаема, в ней отражается суть, а не детали или конкретные шаги по реализации.
- V – valuable. История представляет ценность для клиентов и бизнеса.
- E – estimable. Пригодность для оценки: историю можно оценить по сложности и трудозатратам.
- S – small. Хорошая история маленькая, ее можно реализовать за одну итерацию.
- T – testable. История имеет критерии приемки и ее можно протестировать.
Итоги
User story – максимально понятное описание функционала продукта, его особенностей и пользы для конечного пользователя. Польза user story в том, что она помогает разработчику лучше понять продукт и целевую аудиторию заказчика. Для проверки качества истории используются INVEST-критерии.
Читайте также: