Гайд по User Stories для Junior BA / PO / PM / Хабр
Статья будет полезная Junior-специалистам, которые так или иначе работают с документацией на проекте. В статье рассматриваются как сами пользовательские истории, так и критерии, по которым можно написать хорошую историю. Из статьи читатель сможет подчерпнуть и как писать истории, и как правильно дополнить их деталями, и какие детали важны, и как не перегрузить историю.
Содержание:
Вводная информация о User Stories
— Что такое User Stories
— Job Stories
— Вопросы, которые следует задавать во время написания стори
— Три С в User Story
— User Personas
— Отрицательный персонаж
— Ключевой персонаж
— INVEST
— Как добавить деталей к истории?
— Acceptance Criteria
— Что такое АС
— Что делать, когда надо выбрать одно из нескольких решений?
— Gherkin
Болезни плохих пользовательских историй
— Слишком много информации про функционал в “So that …”
— “Исторический” роман
— Слишком конкретные
— “Хочу делать, чтобы делать”
Вывод
Источники
Вводная информация о 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«. Тем не менее, многие аналитики использую другой подход, который считается даже более каноничным.
Так, истории пишутся в три строки:
Как Х,
Я хочу Y,
Чтобы Z.
Job Stories
В целом Job Stories — схожая с US техника. Можно назвать их приёмом-субститутом, ведь обычно они не используются вместе и выполняют максимально похожую функцию. Job Stories представляют требование в виде действия, которое выполняет пользователь. Они не описывают саму функцию, а лишь концентрируют внимание команды на потребности.
Job Stories концентрируются на психологической части фичи, на эмоциях, тревогах и прочем, что может возникнуть во время использования функции.
«Тело» JS делится на три части:
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 почему?».
Пример работы техники «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 сразу для всех сценариев, чтобы не переписывать.
Scenario Outline / Examples — используются вместе, чтобы скомбинировать несколько сценариев, где попадаются разные сообщения.
Пример:
1) Пишется сценарий-скелет.
Scenario Outline: Dr Bill posts to his own blog.
Given I Have published <number of blogs>
When I try to post a new blog
Then I should see <message>
2) Создается таблица с примерами.
В данном примере мы должны показать связь между количеством постов в блоге и тем, какое сообщение увидит пользователь.Например:
Number of blogs | Message |
>5 | Your article was published. |
5 or <5 | Please, pay for posting. |
Tags — средство для группировки сценариев (в тегах можно указывать тикеты, особенности системы, группы пользователей и пр.)
Steps — это Given, When, Then в виде нумерованных шагов.
Короткий отзыв об использовании Gherkin
Сложно сделать однозначный вывод относительно полезности Gherkin. Я много раз пытался начать постоянно использовать его на проекте. Gherkin отлично подходит для описания сложных сценариев с ветвлением, вариантами. Тем не менее, этот способ не вызвал положительные отзывы со стороны (вообще не вызвал) команды разработки или тестирования. Получается так, что балом в «деталях» к историям правят критерии приёмки — именно на них команда смотрит чаще всего во время оценки и изучения задач.
Болезни плохих пользовательских историй
Как не все фломастеры красные, так и не все пользовательские истории хорошие. Существует несколько типичных черт, которые характерны плохим историям.
Давайте рассмотрим наиболее распространенные из них.
Слишком много информации про функционал в “So that …”
“So that” — это часть про ценность истории, а не функции, которые будут в её рамках реализованы.
Антипример.
Как посетитель кафе, я хочу, чтобы мой заказ сохранялся где-то, чтобы я мог смотреть историю заказов, распечатать чеки, отправить чеки по email.
Потенциальная проблема из этой истории в том, что команда видит “заказ сохранялся где-то”, то на этом и заканчивает рассмотрение истории, эстимацию, так как думает, что задача-то и не очень сложная, а ведь тут так много функционала!
Пример возможного решения.
Как посетитель кафе, я хочу смотреть историю заказов, видеть чеки, печатать чеки, чтобы я мог изменять чеки, сравнивать их, отправлять новые заказы в ресторан.
Мы расширили часть “I want…”, чтобы каждая “хотелка” из третьей части истории была соотнесена с функцией из второй части.
Так команда точно увидит, что задача не такая простая и там есть над чем подумать.Но даже такая история не становится хорошей, ведь кто угодно замучается читать такой длинный “исторический роман”.
“Исторический” роман
Истории должны быть короткими. В идеале они должны помещаться на канцелярский стикер, который должен клеиться на реальную доску.
Антипример.
Как посетитель кафе, я хочу смотреть историю заказов, видеть чеки, печатать чеки, чтобы я мог пересматривать их, сравнивать их, отправлять такие же заказы в ресторан.
Как поступить с такой большой историей? Её следует разделить на несколько!
Пример.
Как посетитель кафе, я хочу смотреть историю заказов, чтобы я мог сделать такой же заказ в будущем.
Как посетитель кафе, я хочу видеть чеки, чтобы я сравнивать их.
Слишком конкретные
История — не место для деталей. Переполненность истории негативно скажется на нескольких аспектах.
Во-первых, она не оставляет места для творчества разработчику — он становится просто руками, которые делают, что сказали; во-вторых, детали превращают историю в исторический роман.
Антипример.
Как посетитель ресторана, я хочу, чтобы разные виды продуктов были обозначены разными цветами (мясо — #FF0000, крупы — #A52AFA, овощи — #808000), чтобы я мог легко различать их.
Лучший способ улучшить такую историю — убрать конкретные примеры. Если в самих цветах есть какая-то важность, их можно поместить в критерии приемки.
Пример.
Как посетитель ресторана, я хочу, чтобы разные виды продуктов были обозначены разными цветами, чтобы я мог легко различать их.
1. Для мяса используется цвет #FF0000.
2. Для круп используется цвет #A52AFA.
3. Для овощей используется цвет #808000.
“Хочу делать, чтобы делать”
Одной из распространенных хворей историй является главной болезнью плохой пользовательской истории автор считает истории “хочу Х чтобы Х”.
Антипример:
Как человек, гуляющий в жару, я хочу мороженое, чтобы съесть мороженое.
История из примера не отражает ценность, только средство ее достижения. Предполагаю, что человек хочет мороженое, чтобы палящее июльское солнце не довело его солнечного удара.
Вывод
Пользовательские истории — это очень полезный формат описания требований. Он позволяет команде разработки придумать именно то решение, которое удовлетворит потребность конечного пользователя.
Но не стоит забывать, что сами истории — это верхушка задачи. Очень важно аккуратно дополнить историю примерами и деталями, которые будут направлять команду во время имплементации решения.
Источники
When Is a Story Done? Three Criteria to Decide, — Atomic Object. URL: https://medium.com/@atomicobject/when-is-a-story-done-three-criteria-to-decide-1979c7edd1fe
What is Acceptance and Evaluation Criteria in the context of Business Analysis?, — Business Analysis Excellence.
URL: https://business-analysis-excellence.com/acceptance-evaluation-criteria-context-business-analysis/#:~:text=In%20the%20case%20of%20a,’%20or%20’a%20failGherkin for Business Analysts, — Hewitt, Ryan. URL: https://www.modernanalyst.com/Resources/Articles/tabid/115/ID/3810/Gherkin-for-Business-Analysts.aspx
Agile Extension to BABOK, — IIBA.
Business Analysis Body Of Knowledge, — IIBA.
10.1 Acceptance and Evaluation Criteria. URL: https://www.slideshare.net/maddyiscrazy/101-acceptance-and-evaluation-criteria
7 Tips for Writing Acceptance Criteria with Examples, — Prasad, Durga. URL: https://agileforgrowth.com/blog/acceptance-criteria-checklist/
Identifying and Improving Bad User Stories, — Suscheck, Charles; Fuqua, Andrew. URL: https://www.agileconnection.com/article/identifying-and-improving-bad-user-stories
Разработка требований к программному обеспечению, — Вигерс, Карл.
Пользовательские истории гибкая разработка программного обеспечения, — Кон, М.
Пользовательские истории. Искусство гибкой разработки ПО, — Паттон, Дж.
Психбольница в руках пациентов, — Купер, А.
URL: https://business-analysis-excellence.com/acceptance-evaluation-criteria-context-business-analysis/#:~:text=In%20the%20case%20of%20a,’%20or%20’a%20fail
User story mapping на практике. Общая картина проекта одна из самых… | by Andrey Gurov
Цели и действия это верхнеуровневые сущности, они образуют сам продукт. У нас в студии, действия по уровню декомпозиции равны эпикам, а шаги пользовательским историям, которые разработчик может раскладывать на задачи и брать в работу.
Шаг может быть задачей технического плана, когда система совершает какое-то действие. Но не стоит углубляться на карте в технические детали, расписывая пошагово интеграцию с каким-нибудь сервисом. Если что-то вызывает много обсуждений, скорее всего, оно требует дополнительной декомпозиции. Еще бывает, что-то отмечается, как шаг, но позже оказывается самостоятельным действием пользователя со своими шагами.
Очень важна взаимосвязь и последовательность всех сущностей на карте. Они должны образовывать единое повествование.
Если нет, значит у продукта есть пробелы, которые в будущем приведут к плохому пользовательскому опыту.
- Определитесь с тем, где будете строить карту: онлайн сервис или обычные клеящиеся стикеры и стена.
- Хотите единого понимания? Соберите представителей бизнеса и разработки: менеджер продукта, менеджер проекта со стороны разработки, аналитик, технический и дизайн лиды, возможно кто-то из разработчиков и т.д.
- Заранее тяжело зафиксировать длительность воркшопа, но если на составление первой версии карты вам требуется больше двух рабочих дней, то это признак того, что концептуальный уровень продукта плохо проработан на стороне бизнеса.
- Подготовьтесь к фасилитации воркшопа, чтобы остальным участникам было проще фокусироваться на работе.
- Предложите менеджеру продукта поделиться пониманием, как бизнес представляет будущий продукт, еще раз пройдитесь по бизнес-целям, существующим ограничениям в реализации и т. д.
- Если у UX специалистов уже есть инсайты ЦА на основе результатов аналитики, пусть они поделятся ими.
д.Начинайте с вопроса: Что бы пользователь сделал с продуктом? Выделите время, чтобы каждый самостоятельно ответил и записал результат.
- Подумайте о действиях, которые пользователь может совершать в продукте (в идеале, это действия, которые можно совершать без переключения).
- Старайтесь использовать глаголы при описании этих действий.
- Подумайте, как изменится флоу использования продукта для пользователей с другими ролями (например, администрация).
Спустя минут 10 начните совместное обсуждение результатов. Необходимо прийти к единому флоу, действия которого понятны всем участникам.
Будет классно, если на этом шаге будет как можно больше обсуждений, чтобы все не только пришли к единому флоу, но и прониклись им, разделяли его.
- Первым делом, скомпонуйте похожие заметки. Какие-то из них потребуется переформулировать,
- Сгруппируйте их так, чтобы действия соответствовали конкретным ролям пользователей,
- Каждое полученное действие должно преследовать конкретную цель. Расположите цели над действиями,
- Полученные цели и действия есть наш вероятный флоу продукта. Проверьте, чтобы расположение действий соответствовало логической последовательности использования продукта,
- При чтении слева-направо, у вас должна получится единая история использования. Расскажите её вслух, чтобы понять, не упустили ли вы чего.
Расположите цели над действиями,Иногда, действия могут приводить сразу к нескольким целям. Это нормально, размещайте их в той группе, где у них наибольшее влияние.
Самая длительная часть. Каждое действие нужно декомпозировать до шагов, которые вместе приведут пользователя к выполнению желаемой активности.
Прежде, чем обсуждать каждое действие совместно, выделите время для самостоятельной проработки. Этот процесс может занять много времени, поэтому контролируйте тайминг. Именно декомпозиция действий способствует генерированию идей по возможностям достижения целей и помогает всем прийти к единому видению.
Как записывать шаги на карту? Готово шаблона нет.
- Использование глаголов при написании помогает концентрироваться на пользовательском действии (а не на конкретных функциях, что исключает возможность поиска лучших решений).
- Уровень декомпозиции примерно, что и у пользовательской истории, которую можно разработать в течении 1 спринта (если длина спринта не менее 2 календарных недель).
На этом этапе карта становится все больше и больше, причем иногда в неожиданной для вас части. Это не значит, что растут размеры самого продукта, растет ваше понимание его.
Кажется, что сделать это просто, но обычно эта часть вызывает множество споров 🙂 Расставьте стикеры с шагами по вертикальной оси в порядке приоритета для бизнес-целей.
Теперь на карте есть цели, действия, шаги и приоритетность. Определите этапность реализации, что попадет в первый релиз, будет ли у вас MVP и т.д. Важно, чтобы каждый релиз помогал достигать определенных бизнес-целей.
Используйте горизонтальную линию, чтобы отделять релизы.
Над линией, что сделаете в этом релизе. Под, что пойдет в следующий.
Скорее всего, к этому моменту команда будет утомлена, подбодрите всех участников и объективно взгляните на полученный результат. Например, проверьте все действия на соответствие поставленным перед продуктом бизнес-целям и вообще на реализуемость (в разумных пределах, поскольку это не полноценный технический анализ).
Вместе еще раз проверьте весь флоу: каждый шаг соотнесен с действием, которое соответствует конкретной пользовательской цели. Все это имеет последовательное повествование.
В идеале, распечатать карту и повесить на стене, чтобы команда всегда могла увидеть результат совместного обсуждения. Есть классный Agile термин — «информационный излучатель» (придуманный Alistair Cockburn). Так вот карта как раз им и является, распределяет знания, укрепляя общее понимание продукта командой.
Шаблоны декомпозиции Пользовательских Историй (User Stories)
Автор: Richard LawrenceПереведено с английского проектом Agile Translations
Хорошие Пользовательские Истории следуют INVEST модели, предложенной Биллом Вейком (Bill Wake).
Они независимые (Independent), обсуждаемые (Negotiable), ценные (Valuable), поддающиеся оценке (Estimable), небольшие (Small) и тестируемые (Testable). Именно требование к размеру приводит нас к необходимости делить большие Пользовательские Истории, однако, даже после разбиения, они все еще должны следовать этой модели.
Многие начинающие agile-команды пытаются разделять Пользовательские Истории по архитектурным слоям: одна история для пользовательского интерфейса, другая — для базы данных, и так далее. Такой подход может удовлетворять критерию “небольшая”, однако, не сможет похвастаться тем же в случае с “независимая” и “ценная”
(Примечание автора: Как в случае с шаблонами любого языка, я не придумывал их, я только наблюдал и объединил их. Например, Ласс Коскела (Lasse Koskela) на сайте radio.
javaranch.com дает имена некоторым шаблонам, которые я заметил, но не назвал, в частности, “Весомое усилие.”) Насколько маленькая?
Насколько мелкой должна быть история? Я рекомендую 6-10 историй за итерацию, так что насколько большими они должны быть зависит от скорости разработки (velocity) вашей команды. Перед следующем планированием Спринта, подсчитайте, какая оценка должна сигнализировать,что историю нужно разделить. Для большинства команд это будет 8 или 13. Но на своем последнем проекте мне было необходимо разделять истории и в 5 стори-поинтов. Когда вы во время планирования попадаете в оценку, сигнализирующую о необходимости разделения историй, возьмите список подсказок, находящийся в конце этой статьи, и попробуйте применить несколько шаблонов, пока не подберете хорошее разделение. Какой шаблон использовать
Вы часто будете замечать, что можете разделить истории, используя несколько шаблонов. Какое разделение стоит выбрать? Я использую два правила :- Выбирайте разделение, которое позволит понизить приоритет или отбросить историю.
- Выбирайте разделение, которое даст вам наиболее равные по размеру истории.
Шаблон #1: Шаги рабочего процесса (Workflow Steps)
Приведу пример истории системы управления контентом (content management system), которую делал один из моих клиентов:Как контент менеджер, я могу публиковать новость на корпоративном сайте.Она не выглядела слишком большой — до тех пор, пока вы не углубились в шаги, необходимые для публикации новости. Оказалось, что для публикации нескольких строк новостей на корпоративном сайте требовалось разрешение редакторов и юристов, а также финальная проверка на отладочном (staging) сайте. Невозможно поместить в одну итерацию 6-10 историй такого типа.
Новая история включала:
… я могу публиковать новость напрямую на корпоративном сайте.
… я могу публиковать новость с рецензией редактора.
… я могу публиковать новость с рецензией юриста.
… я могу просмотреть новость на отладочном сайте.
… я могу опубликовать новость с отладочного сайта на основном сервере.
Шаблон #2: Варианты бизнес-правил
Следующая история имеет несколько скрытых историй, которые позволяют достичь одного и того же, используя разные бизнес-правила:Как пользователь, я могу искать рейсы с гибкими датами.Углубление в понятие “гибкие даты” выявит несколько разных бизнес-правил, каждое из которых само по себе может быть хорошей Пользовательской Историей:
… “N дней между X и Y”
… “выходные в декабре”
… “± N дней от X и Y”.
Шаблон #3: Основное усилие
Порой истории можно разделить на несколько частей таким образом, что основные усилия будут направлены на разработку первой истории. Например, история обработки кредитных карт вроде:Как пользователь, я могу оплатить мой билет картами VISA, MasterCard, Diners Club или American Expressможет быть разделена на 4 истории, по одной для каждого типа карты.
… я могу оплатить одной из карт (VISA, MC, DC, AMEX).Две созданные истории по-прежнему не являются независимыми, но их зависимость гораздо прозрачнее, чем если бы мы создали по одной истории для каждого типа карт.
… я могу оплатить всеми четырьмя картами (VISA, MC, DC, AMEX) (предполагается, что оплата одной из карт уже релизована).
Шаблон #4: Простые/Сложные
Во время обсуждения истории на планировании, история становится все больше и больше (“а как насчет Х?”; “ты учел Y?”). Остановитесь и спросите “Как сделать это максимально просто?”.
Запишите этот простой способ как отдельную историю. Вероятно, вам также на месте придется определить ее критерии завершенности, чтобы она оставалась простой. А потом разделите все вариации и сложности на отельные истории. Вот, к примеру, история: будет оставаться простой, если вынести в отдельные вариации историйКак пользователь, я могу искать рейсы между двумя пунктами назначения.
… определяя максимальное количество пересадок.
… включая ближайшие аэропорты.
… используя гибкие промежутки дат.
… и т.д.
Шаблон #5: Вариации данных
Сложность историй может обусловливаться вариантами данных. Например, системе, над которой я сейчас работаю, необходимо смоделировать георафические области, которые обслуживаются поставщиками транспортных услуг (перевозчиками). Мы могли бы потратить весь бюджет только на то,чтобы предоставить системе географические данные; да, потенциально это настолько сложно.
Как пользователь, я могу искать перевозчиков по месту отправляения и месту назначения.с нашим Владельцем Продукта, я понял, что пока мы не создадим развитую географическую информационную систему (Geographic Information System, GIS), моделирование географии будет оставаться достаточно сложным. Мы остановились и спросили: “Как мы можем построить минимально удовлетворяющую нас географическую модель, чтобы сконцентрироваться на другой ценной функциональности?” Мы сошлись во мнениях на варианте
Как пользователь, я могу искать перевозчиков по стране отправления и стране назначения.Это помогло на некоторое время, пока мы не собрали больше данных и не выяснили, что некоторые перевозчики обсуживают определенные города или даже районы. Новая история выглядела так:
Как пользователь, я могу искать перевозчиков по странам, городам или районам отправления и назначения.Это привело нас к следующей формулировке:
Перевозчики могут обслуживать разные георгафические области в качестве пунктов отправления и назначения.
Все три истории были созданы путем разбиения первоначальной истории. Отличие здесь состоит в том, что мы добавляли историю сразу после создания наиболее простого ее варианта. Но иногда вариации данных лежат на поверхности. Классические истории локализаций: Как контент менеджер, я могу добавлять новые новости
… на английском.
… на японском.
… на арабском.
… и так далее.
Шаблон #6: Методы введения данных
Зачастую сложность заключается в пользовательском интерфейсе, а не в самой функциональности. В таком случае разделите историю таким образом,чтобы сначала построить максимально простой интерфейс, а потом делать его более более привлекательным и удобным. Такие истории, конечно, не являются независимыми, так как вторая часть может быть сделана только после первой, но этот факт не уменьшает эффективности такого разделения.Как пользователь, я могу искать рейсы между пунктами отправления и назначения.
… используя простой ввод даты.
… используя календарь.
Шаблон #7: Отложите производительность
Иногда значительная часть усилий тратится на то, чтобы сделать функционал быстрым, при этом основная разработка не является такой сложной. Но вы можете выиграть больше, разработав медленную функциональность, которая уже будет иметь некую ценность для пользователя и позволять ему делать то, что иначе было бы еще невозможно. В таком случае разбейте историю на “заставить работать” и “сделать быстрой”:Как пользователь, я могу искать рейсы между пунктами отправления и назначения.
… (медленно — просто сделать поиск, показывать анимацию “в процессе”)
… (меньше чем за 5 секунд).
Шаблон #8: Операции (например, CRUD)
Слово “управлять” в истории использования показывает, что история покрывает несколько операций. Таким образом, нам предлагается очевидный путь разделения истории, например:Как пользователь,я могу управлять моим аккаунтом.
… я могу войти в систему, используя мой аккаунт.
… я могу редактировать настройки моего аккаунта.
… я могу удалить мой аккаунт.
Шаблон #9: Отделение Спайка (Spike)
Пользовательская История может быть большой не только из-за высокой сложности, но и по причине неточного понимания ее реализации. В этом случае никакой из подходов не позволит вам ее разбить. Поэтому сначала сделайте ограниченный во времени спайк, который позволит разрешить все неопределенности разработки. После этого вы сможете приступить к разработке или придумать, как можно разделить историю. Не знаете, как сделать следующую историю?Как пользователь, я могу оплатить заказ с помощью кредитной карты.Тогда разделите ее на:
Исследовать обработку кредитных карт.В “исследовательской” истории критерием завершенности должен быть вопрос, на который вы пытаетесь ответить.
Реализовать обработку кредитных карт.
Сделайте минимально необходимое исследование, которое позволит ответить на вопрос, и остановитесь; во время исследования очень легко отклониться от первоначальной цели.Шаблон отделения спайка описан последним в этой статье, потому что к этому подходу следует прибегать лишь в крайнем случае. Вероятней всего, вы знаете достаточно для того, чтобы хоть что-то разработать. Сделайте это — и вы узнаете больше. Так что постарайтесь применить какие-то из предыдущих восьми шаблонов, прежде чем отделять спайк.
Заключение
Не поддавайтесь искушению разделить Пользовательские Истории по архитектурным слоям. Вместо этого попробуйте приведенные выше шаблоны, чтобы разделить вашу историю на более мелкие, которые будут следовать INVEST модели. Дайте мне знать, помогли ли вам мои шаблоны или если вам встретились неделимые истории (я люблю трудности!).Здесь можно скачать подсказки по разделению историй: Story Splitting in Russian (or, Как Разделять Истории Пользователей)
Переведено с английского проектом Agile Translations
Дарья Ершова, Светлана Каща, Сергей Гердов
Оригинальная статья: «Patterns for Splitting User Stories» by Richard Lawrence
10 советов — CMS Magazine
User Story [пользовательские истории] — это, пожалуй, самая популярная техника для определения рамок функциональности продукта.
Работать с историями легко. Но рассказать хорошую историю может быть сложно. Эти 10 советов помогут вам создавать хорошие истории.
Создайте конкурс на workspace.ru – получите предложения от участников CMS Magazine по цене и срокам. Это бесплатно и займет 5 минут. В каталоге 15 617 диджитал-агентств, готовых вам помочь – выберите и сэкономьте до 30%.
Создать конкурс →
Пользователи на первом месте
Как следует из названия, пользовательская история описывает как покупатель или пользователь применяет продукт; он строится с точки зрения пользователя. Кроме того, истории особенно помогает понять специфическую функциональность, например, поиск по товарам или бронирование. Картинка ниже иллюстрирует отношения между пользователем, историей и функциональностью продукта (символически изображено как круг).
Если вы не знаете, кто ваши пользователи и покупатели, и как она хотят использовать ваш продукт, не следует писать истории вообще.
Вы рискуете создать теоретические истории, основанные на ваших убеждениях и идеях, а не на данных и эмпирических доказательствах.
Используйте Персонажей для поиска правильных историй
Прекрасная техника понять инсайты пользователей и покупателей — это работа с персонажами. Персонажи — это вымышленные герои, основанные на полученных из первых рук данных о целевой аудитории. Обычно персонаж имеет фотографию и имя, соответствующие ему характеристики, черты поведения и убеждения; и цель. Цель — это выгода, которую Персонаж хочет получить, или проблема, которую он надеется, решить с использованием продукта.
Создавайте истории командой
Пользовательские истории — это простая методика, которая позволяет двигаться быстро. Это не спецификация, а скорее инструмент совместной работы. Истории никогда не должны отдаваться на откуп команде разработчиков. Напротив, они должны рождаться в процессе обсуждения: Менеджер по продукту (The Product Owner) и команда должны обсуждать истории вместе.
Это позволяет фиксировать минимальную необходимую информацию, уменьшать издержки и ускорять процесс.
Вы можете использовать такой подход даже шире и писать истории в рамках разбора бэклога проекта. Это способствует более творческому подходу и погружению команды, что в результате приводит к лучшим пользовательским историям.
Если вовлечь команду разработки нельзя, подумайте над использованием другой техники для определения функциональности продукта — Use Cases (кейсы использования продукта).
Составляйте короткие и простые истории
Пишите истории, которые легко понять. Составляйте их простыми и краткими. Избегайте сбивающих с толку и двусмысленных понятий, используйте действительный залог. Фокусируйтесь на том, что важно и убирайте все остальное. Шаблон ниже превращает пользователя или покупателя в персонажа истории и позволяет объяснить его выгоды. Он основан на популярном шаблоне Рейчел Дейви, но я заменил «роль пользователя» на «имя персонажа», чтобы связать историю с релевантным персонажем.
Как <персонаж>,
Я хочу <что?>,
Для того, чтобы <зачем>.
Используйте этот шаблон, если он вам помогает, но помните, что использовать его не обязательно. Экспериментируйте с разными способами написания историй, чтобы понять, какой из них лучше всего работает в вашей команде.
Начните с поэмы
Поэма — это большая, поверхностная история, написанная крупными мазками. Она обычно бьется на несколько пользовательских историй со временем — используя обратную связь от пользователей на ранних стадиях прототипирования и формирования продукта. Поэму можно назвать состоящей из заголовков для более детальных историй.
Начав с поэмы, вы сможете быстро набросать требуемый функционал без детализации. Это особенно полезно для описания составных частей продукта: поэма помогает вам грубо прикинуть объем задач, хотя часто это может сыграть злую шутку и отнять кучу времени, если прикидка оказалась слишком грубой.
Совершенствуйте истории, пока они не будут готовы
Делите ваши поэмы на более мелкие, детализированные истории, пока они не будут готовы: пока не станут ясными, выполнимыми и измеримыми. Вся команда разработки должна понимать значение истории. История не должна быть слишком большой, должна комфортно помещаться в спринт, должен быть эффективный способ определить и проверить критерий успешного выполнения истории.
Добавьте критерии успеха
По мере того, как вы делите поэму на мелкие истории, помните, что к каждому из них должен быть добавлен критерий успешности. Он дополняет рассказ: позволяет описать условия, которые должны быть выполнены для того, чтобы история завершилась. Этот критерий дополняет историю, делает её измеримой, а также позволяет продемонстрировать историю, выпустить её для пользователей или инвесторов. Как правило, я использую от 3 до 5 критериев для каждой детальной истории.
Используйте бумажные карточки
Пользовательские истории возникли из Экстремального Программирования.
А в Экстремальном Программировании говориться о «пользовательских карточках», а не об «историях». Тому есть простая причина: пользовательские истории записывались на бумажных карточках. У этого подхода есть три преимущества. Во-первых, бумажные карточки дешевы и их легко использовать. Во-вторых, это упрощает командную работу: каждый может взять карточку и записать идею. В-третьих, карточки можно легко сгруппировать на столе или стене, чтобы проверить полноту и целостность визуализации зависимостей. Даже если ваши истории хранятся в электронном виде, стоит использовать бумажные карточки, когда вы придумываете новые истории.
Держите сценарии на видном месте
Истории хотят сообщить вам информацию. Поэтому не прячьте их на сетевой диск, джунгли корпоративного интранета или в другие дебри. Определите их на видное место. Например, на стену. Это способствует командной работе, создает прозрачность процесса, делает очевидным, если вы добавляете слишком много историй слишком быстро (у вас просто начнет заканчиваться место).
Удобный инструмент для поиска, визуализации и организации ваших сценариев — это доска продукта, показанная ниже.
Не полагайтесь только на истории
Создание отличного UX (пользовательского опыта) требует больше, чем только истории. Истории помогают определить функциональность продукта, но не подходят для изображения пути пользователя (User Journey) и подготовки визуального дизайна. Поэтому дополняйте истории другими техниками: картами историй, диаграммами, сторибордами, скетчами, макетами.
Кроме того, истории плохо определяют технические требования. Если необходимо объяснить, что архитектурный элемент должен делать как компонент или сервис, опишите техническую историю, используя язык моделирования (например, UML).
Наконец, написание историй имеет смысл, когда вы разрабатываете платформу, которая будет использоваться не один раз. Но если вы хотите быстро создать одноразовый прототип или макет для проверки идеи, написание историй излишне.
Помните: пользовательские истории — не обязательная документация. Они нужны для того, чтобы дать вам возможность двигаться быстро и разрабатывать продукты в максимально короткие сроки, а не для увеличения накладных расходов.
Переводчик: Екатерина Герасименко
Оригинал: https://www.romanpichler.com/blog/10-tips-writing-good-user-stories/
Зачем нужны User Story Mapping и Roadmap продукта?
Всем привет!
23 марта мы провели вебинар “Как перейти от создания MVP к планомерному развитию продукта при Agile-подходе”.
И в данной статье мы расскажем подробнее об одной из затронутых тем — зачем нужны User Story Mapping и Roadmap продукта.
Зачем нужен User Story Mapping?
User Story Mapping (USM / Карта пользовательского пути) — это самый простой способ показать команде, зачем мы работаем и какую потребность пользователей закрываем. Он отвечает на самый главный вопрос — что сделать в первую очередь, чтобы показать продукт, потому что у нас появляется понимание:
- какие функции продукта нужно закрыть
- что минимально можно сделать
- что нам нужно сделать прямо сейчас, а что позднее (приоритизация задач)
User Story Mapping сильно помогает именно на старте, т.
к. идет от потребностей пользователей. Сложности возникают, когда продукт уже готов, когда мы уже закрыли те потребности, на которые рассчитывали, и нам нужно расти.
При использовании User Story Mapping нет ответа на важный вопрос — КОГДА:
- когда мы увидим ту или иную вещь в продакшене
- когда пользователи увидят наш продукт
- когда нужно запускать другие активности в компании
- когда готовиться к маркетингу
В этих вопросах User Story Mapping не может помочь, т.к. у USM другая задача — определить, что нам нужно сделать сейчас.
Т.к. USM не закрывает нашу потребность в сроках, нам нужно сделать переход к Roadmap (Дорожная карта продукта).
Зачем нужен Roadmap?
С помощью Roadmap мы можем определить более значимые изменения и собрать задачи, которые должны закрывать ключевые метрики продукта. Важный принцип использования Roadmap — задачи должны закрывать основные бизнес-потребности.
Например, наша основная бизнес-потребность — вырасти на рынке в 3 раза с точки зрения той аудитории, с которой мы работаем. Значит, что основные наши планы и действия должны быть направлены на реализацию конкретно этой задачи (потребности).
Чтобы включить задачи в Roadmap, нам нужно использовать EPIC-и. Чтобы узнать подробнее о том, как это сделать, вы можете посмотреть запись нашего вебинара.
Также, если вы хотите овладеть Agile-навыками или сделать свою команду гибкой, то с 30 марта по 2 апреля мы проведем онлайн-тренинг Agile Certified Professional.
Тренеры: Сергей Шарпак и привлеченный эксперт Олег Афанасьев.
Программа тренинга:
- Гибкое мышление: инструменты управления изменениями; обучение на опыте; командная работа; связь мышления и практик
- Agile-трансформация: роль корпоративной культуры; подходы к трансформации организации; понимание путей трансформации подразделения или компании
- Kanban: сервисная парадигма, визуализация, ограничения; управление потоком, определение правил, обратная связь; масштабирование Kanban
- SCRUM: команда, планирование в Scrum, события; формирование бэклога продукта, покер-планироание; ценности Scrum
Вы сможете изучить теорию Agile, поучаствовать в практикумах и играх, узнать о реальном опыте тренеров, а также получить международный сертификат ICP.
Мы проводит корпоративные и открытые тренинги Agile Certified Professional как в онлайн, так и в офлайн. Поэтому, если вы готовы стать Agile, тогда регистрируйтесь на наш тренинг в удобном для вас формате!
Как составлять бэклог: краткое руководство | GeekBrains
При чём здесь Product Roadmap, User Stories и Customer Journey Map (CJM)
https://gbcdn.mrgcdn.ru/uploads/post/2340/og_image/7aa222f2e9d93e5b3aca04b7504c2e2d.png
Бэклог — это список требований к продукту. Чем подробнее он заполнен, тем эффективнее будет организована работа команды. Разумеется, при работе с ним сразу появляются вопросы: как правильно собрать и структурировать все требования и пожелания, а также чем может навредить беспорядок в бэклоге.
Работу с бэклогом стоит начинать со «скелета» — базовых функций, которые должны присутствовать в продукте. Здесь будет полезен план развития — Product Roadmap. Детализировать задачи можно с помощью User Stories, на основе которых строится Customer Journey Map.
Разберёмся, что скрывается за этими английскими словами и как к ним подступиться.
Что это такое?
Product Roadmap (дорожная карта) — верхнеуровневый стратегический план, в котором отражено направление разработки вашего продукта. В идеале — со сроками реализации. Roadmap не даёт конкретных пояснений по каждой задаче — это общее видение проекта. Но при этом он содержит основные цели, миссию и объясняет предпосылки того, что вы делаете.
Пример дорожной карты
User Story (пользовательская история) — это упрощённый список требований клиента в виде истории, рассказанной на языке пользователя. По сути, это доходчивое описание, которому должны соответствовать новые фичи продукта, в противовес объёмной и сложной документации. В основе требований — удобство и ценность для пользователей.
Например, User Story может звучать так: «Я хотел бы видеть всплывающие подсказки при входе в приложение, если прихожу сюда впервые».
Пример с knowledgehut.
com
Customer Journey Map (карта путешествия клиента) — это визуализированный опыт пользователя продукта с учётом его целей, эмоций, барьеров, мотивов. Карта составляется под определённую User Story, отражает путь клиента к продукту, показывает «узкие места», даёт понять, над какими этапами и метриками нужно работать в первую очередь.
Очень важно всегда быть в контексте пользователя, поэтому CJM нужно регулярно обновлять.
Пример CJM онлайн-магазина
Как на основании этих документов собрать бэклог?
- Составляем список функций. Если есть возможность, сразу задаём их приоритет согласно Roadmap.
- Прописываем User Story для каждого предложения и анализируем, насколько эта функциональность ценна пользователю.
- Расставляем фичи, прошедшие отбор, по приоритету и записываем в бэклог.
- Обсуждаем задачи с командой, определяем сроки и ответственных.
- Обновляем список задач по мере их завершения или поступления новых вводных.
Нужно регулярно возвращаться к бэклогу, чтобы актуализировать его. По мере развития продукта часть задач будет терять актуальность, трансформироваться или менять приоритет. А отслеживание бэклога позволит команде быть в контексте происходящего и не тратить время на долгое обсуждение плана действий.
Каждая задача должна быть конкретной, конечной и достижимой — например, исправление конкретной ошибки или внедрение определённой фичи. Именно поэтому в бэклоге собирают только те задачи, которые закрывают среднесрочные и краткосрочные цели проекта. Долгосрочные цели обычно не так хорошо формализованы, чтобы легко разложить задачу на спринты и передать команде.
Пример бэклога:
Название задачи всегда должно быть ёмким и понятным, отражать её суть и не вводить в заблуждение.
В графе «Важность» проставляется значимость фичи для проекта. Оценку могут дать менеджер или команда, но она будет субъективна. Также можно сделать выводы о важности задачи на основе накопленных знаний о пользователях: сколько из них будет охвачено новыми функциями и как фичи повлияют на пользовательскую историю.
Трудозатраты оценивает команда. Scrum Poker или метод KJ помогут упростить этот процесс.
В графе «Демонстрация» фиксируется способ, который поможет понять, успешно ли реализована функциональность.
В поле «Тип задачи» мы указываем направление, с которым работаем:
- Новая функция — фича, видимая пользователю и улучшающая его опыт.
- Невидимая функция — незаметная фича, улучшающая пользовательский опыт за счёт повышения качества продукта, снижения затрат и т. п.
- Дефект — ошибка, заметная пользователям и требующая внимания.
- Технический долг — неоптимальные решения, которые со временем потребуют доработки.
Пропорции задач разных типов в бэклоге зависят от этапа жизненного цикла продукта. На старте в приоритет ставятся новые функции, а технический долг откладывается на потом. На этапе зрелости и масштабирования куда важнее поддерживать уровень сервиса и качество продукта.
Всё это позволяет расставить приоритеты и понять, что будет взято в первые два спринта, а что — отложено на более долгий срок.
Влиять на появление новых задач в бэклоге может не только менеджер продукта, но и команда, инвесторы, конкуренты и даже клиенты. Важно внимательно собирать информацию из разных источников, оценивать её и на основе данных фильтровать задачи и брать их в работу.
Научиться вести работу над проектами в разных сферах вы сможете на факультете проджект-менеджмента GeekUniversity.
Как и какое техническое задание писать при работе по Agile
1. Техническое задание при работе по Agile
Манифест гибкой разработки ПО ставит во главу угла достижение бизнес-ценности, отбрасывая и уменьшая значимость всего, что к бизнес-ценности не приближает. В этом смысле традиционное детальное техническое задание, подписанное заказчиком и исполнителем, часто является причиной потерь.
Об этом я подробно писал в статье 12 проблем при работе по техническому заданию в IT-продукте.
ТЗ, как любой другой юридический документ, накладывает обязательства с двух сторон по формальному соблюдению всех пунктов документа.
Это дает побочные эффекты:
- Заказчик, хоть и стремиться к бизнес-цели, при этом вынужден принимать результаты работ по формальному ТЗ;
- Исполнитель, который видит как сделать работу более оптимально, предпочтет следовать ТЗ и не залезать в пересогласование плана, даже если окажется, что план не эффективный.
2. Метафора для инструмента планирования
Программное обеспечение абстрактное и легко меняется. Этим свойством софт отличается от производства вещей в реальном мире. Например, после постройки дома никому не придет в голову сказать: «Теперь давайте раздвинем 5-й и 6-й этажи и вставим между ними огромный аквариум с акулой». В мире материального производства так не бывает, а в разработке ПО такие изменения — норма. Поэтому подход к планированию работ должен соответствовать природе софта.
На мой взгляд, хорошо подходит метафора навигатора в автомобиле:
- Навигатор знает где мы сейчас и куда хотим приехать.
- Если по дороге домой, мы решили свернуть в магазин, то он перестроит первоначальный путь с учетом изменений.
- Если мы передумали ехать домой, то ставим новую точку и нам сразу показывается новый оптимальный путь до новой цели.
- Если на дороге случилось ДТП и путь закрыт, то навигатор перестраивает маршрут.
Хорошо было бы иметь такие навигаторы при работе над IT-продуктами. Наше планирование превратилось бы в постоянное прокладывание оптимальных маршрутов до бизнес-ценности с быстрой реакцией на изменение внешних факторов, таких как отзывы пользователей, действия конкурентов, желания инвесторов и т.п.
3. Реализация адаптивного плана работ
Чтобы создать «навигатор» для IT-продукта, я рекомендую использовать подходящие инструменты планирования, периодически возвращаться к началу планирования и пересматривать планы, прекратить фиксировать объем работ надолго в будущее и строить коммуникацию вокруг бизнес-целей.
3.1. Визуальное и «многомерное» техническое задание
Люди хорошо работают с визуальными образами, mind map’ами и схемами. Поэтому в своей практике мы мало пишем «плоского» текста, зато активно используем карты и образы.
Рисунки и карты легко перестроить в отличие от 300-страничного документа. К тому же эти карты быстро считываются и помогают людям на проекте эффективно коммуницировать.
Для построение карты целей и нахождения кратчайшего пути до цели мы рисуем Impact Map:
Взаимодействие всех частей IT-продукта, пользовательский опыт и сценарии работы пользователя описываются в Customer Journey Map и User Story Map.
После создания этих трех карт нужно отрезать самые важные для бизнеса задачи на ближайший релиз и проложить самые короткий путь до цели. Здесь опять помогает то, что все карты визуальные, они помогают отрезать части и рисовать пути.
Все три инструмента подробно описаны в Аналитике IT-продукта.
3.2. Циклы и пересмотры
Гибкость создается за счет цикличности процесса разработки IT-продукта и легкости внесения изменений в планы. Т.к. все планы описаны в схемах и стикерах, внесение в них изменений не составляет труда.
После каждого релиза надо обязательно вернуться в начало и посмотреть в верном ли направлении был сделан шаг.
За каждый цикл мы учимся чему-то новому о рынке и о своих возможностях, делаем выводы и идем на новый круг:
Описание этого процесса с примером проекта из практики нашей компании в статье Пять самых важных составляющих процесса выпуска успешных проектов.
3.3. Объем работ — не фиксированная величина
Для обеспечения гибкости в классическом проектном треугольнике нужно поменять две вещи: перестать фиксировать объем работ и начать фиксировать качество.
- Фиксация качества — т.к. направление разработки ПО всё время меняется, то архитектура и код не должны ломаться при внесении изменений. Код не должен быть хрупким. Для повышения качества кода используют практики Экстремального программирования и следят за уровнем технического долга.
- Плавающий объем работ — обычно для заказчика важны срок и цена, эти величины остаются зафиксированными. Но что конкретно мы сделаем в указанный срок? Сделаем то, что максимально приблизит заказчика к бизнес-цели, а это будет видно по картам и схемам, которые используются при планировании.
Разработчикам хорошо известно, что одну и ту же задачу можно сделать бесконечным количеством способов. Например, если вывести красивый индикатор, то это займет два дня работы дизайнера, верстальщика и программиста, а если вместо него показать цифру, то это делается в пять раз быстрее. Поэтому мы часто «флексим», т.е. делаем меньше, но не ухудшаем достигаемость бизнес-цели.
Чтобы сделать объем работ плавающим, между исполнителем и заказчиком надо выстроить высокий уровень доверия. Как это сделать в статье Customer satisfaction для программистов: Доверие и прозрачность.
3.4. Ориентация на бизнес-цель
Заказчик и исполнитель вместе ориентируются на бизнес-цель при прокладывании пути без формального технического задания:
При таком подходе нет формального списка работ, который надо выполнить вопреки здравому смыслу и потери эффективности.
4. Я бухгалтер, я так вижу
Наши схемы и стикеры на стене, к сожалению, не подходят для формальной документации и юридического оформления работ.
Бухгалтера и юристы требуют сроки и описание объема работ. Они не противодействуют «гибкому» подходу, они только пытаются соблюдать законы и правила отчетности, принятые в стране. Поэтому обычно в жизни схема работы выглядит так:
В этом случае ТЗ остается, но является только лишь юридическим сопровождением к проекту. Часто оно пишется довольно абстрактно, чтобы оставить достаточно пространства для творчества и реакции на возникшие риски. Еще чаще список работ заполняется уже после реализации IT-продукта и подписывается датой начала проекта. При этом все нормы закона соблюдены и ТЗ не портит ход работ своей негибкостью.
5. Повышаем качество работы
Основные тезисы:
- Планирование работ — цикличный и постоянный процесс, поэтому нужно использовать гибкие инструменты;
- Не заменяйте живую коммуникацию на ТЗ. Если ТЗ начинает занимать ведущую роль, то стоит насторожиться и проверить как устроена коммуникация в проекте между всеми участниками;
- Пишите ТЗ, когда это необходимо. Делайте его как можно более полезным;
- Контроль процесса разработки достигается за счет визуализации текущего состояния проекта и понимание дальнейших шагов.
Делайте его как можно более полезным;Эта статья входит в цикл статей о техническом задании:
- Когда надо прекратить писать Техническое задание и начать делать проект? Дана схема как балансировать между чрезмерно подробным, а значит дорогим, ТЗ и слишком абстрактным, что ведет к рискам и ошибкам.
- 5 причин написать ТЗ, где перечислены причины, которые подталкивают подробно описывать весь план работ до начала проекта.
- 12 проблем при работе по техническому заданию в IT-продукте. Описаны проблемы, которые превращают написание ТЗ в потери для бизнеса.
- Откровенное общение с заказчиком, где решился спор о том, на сколько подробным должно быть ТЗ.
- Техническое задание как база знаний о проекте, где описано, что написание ТЗ — это потери для бизнеса.
- Как и какое техническое задание писать при работе по Agile, где описывается, как использовать подходящие инструменты планирования, прекратить фиксировать объем работ надолго в будущее и строить коммуникацию вокруг бизнес-целей.
пользовательских историй | Примеры и шаблон
Резюме: История пользователя — это неформальное общее объяснение функции программного обеспечения, написанное с точки зрения конечного пользователя. Его цель состоит в том, чтобы сформулировать, как функция программного обеспечения будет представлять ценность для клиента.
Заманчиво думать, что пользовательские истории — это, проще говоря, системные требования к программному обеспечению. Но это не так.
Ключевой компонент гибкой разработки программного обеспечения — ставить людей на первое место, а история пользователя ставит конечных пользователей в центр разговора.Эти истории используют нетехнический язык, чтобы предоставить контекст для команды разработчиков и их усилий. После прочтения пользовательской истории команда знает, почему они создают, что они создают и какую ценность они создают.
Пользовательские истории — один из основных компонентов гибкой программы. Они помогают обеспечить ориентированную на пользователя структуру для повседневной работы, которая способствует совместной работе, творчеству и улучшению продукта в целом.
Что такое гибкие пользовательские истории?
Пользовательская история — это наименьшая единица работы в гибкой структуре.Это конечная цель, а не функция, выраженная с точки зрения пользователя программного обеспечения.
Пользовательская история — это неформальное общее объяснение функции программного обеспечения, написанное с точки зрения конечного пользователя или заказчика.
Цель пользовательской истории — показать, как часть работы принесет клиенту определенную ценность. Обратите внимание, что «клиенты» не обязательно должны быть внешними конечными пользователями в традиционном смысле, они также могут быть внутренними клиентами или коллегами в вашей организации, которые зависят от вашей команды.
Пользовательские истории — это несколько предложений на простом языке, описывающих желаемый результат. Они не вдаются в подробности. Требования добавляются позже, после согласования с командой.
Истории прекрасно вписываются в agile-структуры, такие как scrum и kanban.
В скраме пользовательские истории добавляются в спринты и «сгорают» в течение всего спринта. Канбан-команды собирают пользовательские истории в свой бэклог и запускают их в своем рабочем процессе. Именно эта работа над пользовательскими историями помогает скрам-командам лучше оценивать и планировать спринты, что приводит к более точным прогнозам и большей гибкости.Благодаря историям канбан-команды узнают, как управлять незавершенным производством (WIP), и могут дополнительно совершенствовать свои рабочие процессы.
Пользовательские истории также являются строительными блоками более крупных agile-фреймворков, таких как эпики и инициативы. Эпики — это большие рабочие элементы, разбитые на набор историй, а несколько эпиков составляют инициативу. Эти более крупные структуры гарантируют, что повседневная работа команды разработчиков (в магазинах) способствует достижению организационных целей, встроенных в эпики и инициативы.
Узнайте больше об эпиках и инициативах
Зачем создавать пользовательские истории?
Для команд разработчиков, плохо знакомых с Agile, пользовательские истории иногда кажутся дополнительным шагом.
Почему бы просто не разбить большой проект (эпопею) на серию шагов и не приступить к делу? Но истории дают команде важный контекст и связывают задачи с ценностью, которую эти задачи приносят.
Истории пользователей имеют ряд ключевых преимуществ:
- Истории фокусируют внимание на пользователе. Список дел позволяет команде сосредоточиться на задачах, которые необходимо отметить, а набор историй позволяет команде сосредоточиться на решении проблем реальных пользователей.
- Истории позволяют сотрудничать. Определив конечную цель, команда может работать вместе, чтобы решить, как лучше всего обслуживать пользователя и достигать этой цели.
- Истории стимулируют творческие решения. Истории побуждают команду к критическому и творческому мышлению о том, как лучше всего решить конечную цель.
- Истории создают импульс. С каждой новой историей команда разработчиков получает удовольствие от небольшого испытания и маленькой победы, что придает импульс.
Посмотрите, как пользовательские истории работают в Jira Software
Работа с пользовательскими историями
После написания истории пришло время интегрировать ее в ваш рабочий процесс.Обычно история пишется владельцем продукта, менеджером продукта или менеджером программы и отправляется на рассмотрение.
Во время совещания по планированию спринта или итерации команда решает, какими историями они займутся в этом спринте. Теперь команды обсуждают требования и функциональные возможности, необходимые для каждой пользовательской истории. Это возможность проявить техническую и творческую изобретательность в реализации истории командой. После согласования эти требования добавляются в историю.
Другим распространенным шагом на этом собрании является оценка историй в зависимости от их сложности или времени до завершения.Команды используют размеры футболок, последовательность Фибоначчи или планирование покера, чтобы сделать правильные оценки.
История должна быть рассчитана на завершение за один спринт, поэтому, когда команда определяет каждую историю, они обязательно разбивают истории, которые преодолеют этот горизонт завершения.
Как писать пользовательские истории
При написании пользовательских историй учитывайте следующее:
- Определение «готово» определить, что это такое.
- Составление подзадач или задач — Определите, какие конкретные шаги необходимо выполнить и кто отвечает за каждую из них.
- Персонажи пользователей — Для кого? Если есть несколько конечных пользователей, рассмотрите возможность создания нескольких историй.
- Упорядоченные шаги — Напишите историю для каждого шага в более крупном процессе.
- Прислушивайтесь к отзывам — Поговорите со своими пользователями и сформулируйте проблему или потребность в их словах.Не нужно угадывать истории, когда вы можете получить их от своих клиентов.
- Время — Время — деликатная тема. Многие команды разработчиков вообще избегают обсуждения времени, полагаясь вместо этого на свои оценки. Поскольку истории должны быть завершены за один спринт, истории, на завершение которых могут уйти недели или месяцы, должны быть разбиты на более мелкие истории или должны рассматриваться как отдельная эпопея.
После четкого определения пользовательских историй убедитесь, что они видны всей команде.
Шаблон истории пользователя и примеры
Истории пользователей часто выражаются простым предложением, структурированным следующим образом:
«Как [персонаж], я [хочу], [чтобы]».
Разбивка этого:
- «Как [персона]»: для кого мы это создаем? Нам нужна не просто должность, нам нужна личность человека. Максимум. У нашей команды должно быть общее понимание того, кто такой Макс. Мы надеемся, что взяли интервью у многих Максов.Мы понимаем, как этот человек работает, как он думает и что чувствует. Мы сочувствуем Максу.
- «Хочет»: здесь мы описываем их намерения, а не функции, которые они используют. Чего они на самом деле пытаются достичь? Это утверждение должно быть свободным от реализации — если вы описываете какую-либо часть пользовательского интерфейса, а не то, какова цель пользователя, вы упускаете суть.
- «Так что»: как их непосредственное желание сделать что-то это вписывается в их общую картину? Какую общую выгоду они пытаются достичь? Какая большая проблема требует решения?
Мы сочувствуем Максу.Например, пользовательские истории могут выглядеть так:
- Как Макс, я хочу пригласить своих друзей, чтобы мы могли вместе пользоваться этой услугой.
- Как Саша, я хочу организовать свою работу, чтобы лучше контролировать ситуацию.
- Как руководитель я хочу иметь возможность понимать успехи моих коллег, чтобы я мог лучше сообщать о наших успехах и неудачах.
Эта структура не обязательна, но полезна для определения готовности.
Когда эта персона может уловить желаемую ценность, тогда история завершена. Мы призываем команды определить свою собственную структуру, а затем придерживаться ее.
Начало работы с гибкими пользовательскими историями
Пользовательские истории описывают, почему и что стоит за повседневной работой членов команды разработчиков, часто выражаясь как персонаж + потребность + цель .Понимание их роли как источника правды о том, что делает ваша команда, а также почему, является ключом к гладкому процессу.
Начните с оценки следующего или наиболее важного крупного проекта (например, эпоса). Разбейте его на более мелкие пользовательские истории и работайте с командой разработчиков над уточнением. Как только ваши истории появятся в открытом доступе, где их сможет увидеть вся команда, вы готовы приступить к работе.
Макс Рекопф
Как самопровозглашенная «кукла хаоса» я обращаюсь к agile-методикам и принципам бережливого производства, чтобы навести порядок в своей повседневной жизни.
Мне очень приятно делиться этими уроками с другими через множество статей, выступлений и видеороликов, которые я делаю для Atlassian
17 Полезные примеры пользовательских историй для начала работы
Нужна небольшая помощь в написании пользовательских историй? Направьте свою команду на правильный путь с помощью этих замечательных примеров пользовательских историй!
С чего начать разработку успешного приложения или веб-сайта, который станет хитом среди ваших пользователей? Пользовательские истории — ваш лучший друг в сочетании с инструментом каркаса!
Пользовательские истории помогают нам вписать наши пользовательские образы в контекст продукта, который мы разрабатываем.В то время как биография пользователя описывает его жизнь и беды, история пользователя описывает, как он использует функцию вашего продукта — с точки зрения непрофессионала!
В agile-среде владельцы продукта вместе с UX-дизайнерами, как правило, пишут пользовательские истории на каталожных карточках, чтобы передать их команде дизайнеров и вызвать обсуждение.
Мы также можем записать их в цифровом виде, используя Office или Google Docs, чтобы включить их в бэклог Scrum.
Тот факт, что они написаны простым языком и лишены технического жаргона, означает, что команда дизайнеров не чувствует себя ограниченной техническими аспектами.У них больше возможностей проявить творческий подход к своим дизайнерским идеям. Прочтите несколько замечательных примеров пользовательских историй!
17 практических примеров пользовательских историй
Мы собрали несколько примеров того, как пользовательские истории могут выглядеть в реальной жизни. примеры цифровых пользовательских историй, которыми можно легко поделиться на онлайн-платформе.
Некоторые даже поставляются в виде загружаемых шаблонов, таких как файлы Word и Excel! Давайте углубимся в:
1.Пример пользовательской истории Product Plan
Этот пример пользовательской истории Product Plan состоит из пяти важных разделов. Во-первых, это название рассказа.
Для этого вы можете указать название функции, о которой будет рассказ, например, «рецензии на книги».
В разделе Приоритет можно назначить приоритет от низкого до среднего или высокого. Важно назначить приоритеты элементам невыполненной работы, поскольку некоторые функции будут более востребованы в соответствии с вашей матрицей прослеживаемости требований.Рядом с приоритетом находится раздел «Оценка». Здесь вы можете указать время, которое, по вашему мнению, потребуется команде для реализации этой функции. Здесь вы можете назначить соответствующее количество очков схватки.
Далее в этом примере пользовательской истории у вас есть сам раздел пользовательской истории и, наконец, критерии приемлемости. Критерии приемки часто пишутся на обратной стороне индексной копии, но, поскольку это двухмерная цифровая копия, критерии приемки четко написаны прямо под ней в качестве своего рода заключения.Некоторым может показаться очень полезным, чтобы все было включено на одну страницу.
2. Пример пользовательской истории в Word Doc
Этот загружаемый пример пользовательской истории представляет собой документ Word, который вы можете редактировать. На наш взгляд, инструкции, которые следуют после каждого пункта в пользовательской истории, а также инструкции по критериям приемлемости, довольно просты для выполнения.
Почему важно иметь эти инструкции в шаблоне пользовательской истории? Потому что, если ваша команда какое-то время не писала пользовательские истории или вам нужно работать над многими историями, полезно иметь такие инструкции в качестве подсказки.Они служат полезным напоминанием о качестве информации, которая должна содержаться в каждом пункте.
3. Пример пользовательской истории Excel
Какой лучший способ сгруппировать информацию в таблицах, чем Excel? Этот пример пользовательской истории excel также немного отличается тем, что, помимо обычных полей, он также дает вам возможность заполнить другую важную информацию.
Дополнительные поля, которые вы можете найти в этом примере пользовательской истории, включают в себя ценность бизнеса пользователя, расчет риска, стоимость задержки и взвешенную самую короткую работу в первую очередь.Эта дополнительная информация также может быть полезна в зависимости от типа функций продукта, над которыми вы работаете, или типов клиентов или компании, на которую вы работаете.
4. Пример тематической истории пользователя
В этом примере тематической истории на основе Excel вы получаете столбец для оценки приоритета, критериев приемлемости, а также столбец «Выпуск» для даты выпуска.
Столбцы в этом примере пользовательской истории упорядочены: темы расположены вертикально, а типы столбцов — горизонтально.Это был бы отличный шаблон для эпической истории, состоящей из нескольких под-историй.
5. Пример эпической пользовательской истории
Говоря об эпических примерах пользовательской истории, вы можете взглянуть на этот шаблон эпической пользовательской истории.
Это отличный способ сгруппировать подистории по их эпическим историям.
Каждая особенность эпической истории указана вертикально, а столбцы предназначены для пользователя, действия или желания и выгоды. Последний столбец состоит из вертикального расположения пользовательских историй в подстроках, заключенных в каждую ячейку.
То, как организована эта эпическая пользовательская история, позволяет показать четкую иерархию между эпиками и их многочисленными подробными пользовательскими историями. Это позволяет очень легко просматривать и получать быстрый обзор всех функций, которые необходимо применить или разработать, чтобы удовлетворить пользователя.
6. Пример пользовательской истории PowerPoint
Этот загружаемый пример пользовательской истории из Powerslides показывает нам еще один изящный способ организации наших пользовательских историй. Эти карточки можно показать в презентации Powerpoint, а также распечатать и раздать.
Нам также нравится четкое разделение наиболее важных разделов: история пользователя и идентификатор пользователя, а также несколько разделов, которые отличают его от других примеров.
В разделе истории мы можем увидеть пользовательскую историю и критерии приемлемости. Тем не менее, в разделе идентификатора пользователя есть область, в которую вы можете прикрепить изображение своего пользователя, а также несколько флажков для типа функции, на которую он ориентирован, и поля для приоритета и оценки времени.
7.Пример пользовательской истории каталожной карточки
Что нам нравится в этой старой доброй пользовательской каталожной карточке, так это простота и то, как она возвращает вещи к основам. Иногда вам может понадобиться быстро набросать историю для функции продукта или краткий обзор функций, таких как эпопея.
Этот простой и традиционный пример пользовательской истории показывает нам, насколько простым это может быть. Самое замечательное в каталожных карточках то, что вы также можете написать критерии приемлемости на обороте, а затем карточку пользовательской истории можно передать команде.
8. Пример пользовательской истории спереди и сзади
Здесь у нас есть традиционный пример пользовательской истории спереди и сзади, который отражает то, как можно написать историю пользователя на каталожной карточке.
История наглядно показывает, чего хочет добиться пользователь и почему он этого хочет.
В этом случае они хотят отменить бронирование, чтобы не потерять все свои деньги в случае возникновения ситуации.
На обратной стороне карты перечислены все критерии приемлемости.Он показывает все функции приложения, о которых необходимо позаботиться, чтобы преимущества пользователя и преимущества бизнес-целей были удовлетворительно достигнуты.
9. Пример пользовательской истории банковского приложения
Этот пример пользовательской истории банковского приложения — отличный способ кратко объяснить необходимую функцию и зачем она нужна пользователю.
Сразу становится понятно, кто такой пользователь и что ему нужно сделать. На самом деле, одна из его замечательных особенностей заключается в том, что он даже намекает на одну из проблем, которые обычно может испытывать пользователь банковского приложения (в данном случае владелец кредитной карты), например, беспокойство о непогашенном остатке на кредитной карте, сохраняя хороший кредитный рейтинг и не попадая в минус.
Пользователь в этом примере пользовательской истории хочет оплатить свой баланс, поэтому первое, что может сделать команда разработчиков, — это начать работу над решением, которое даст им более или менее мгновенный доступ к балансу их кредитной карты. Либо это должно быть первое, что они увидят, когда откроют приложение, либо должна быть четкая возможность увидеть баланс этой карты одним касанием.
10. Гибкий шаблон написания пользовательской истории
Наш следующий пример пользовательской истории от Whizible также является шаблоном, который вы можете загрузить, чтобы дать вам и вашей команде фору.
Этот шаблон позволяет написать список нескольких пользовательских историй на одной карточке. Горизонтальные столбцы вверху отображают шаблонное предложение типичной пользовательской истории, а это означает, что нужно просто заполнить пробелы.
Это определенно сэкономит время при написании нескольких пользовательских историй и поможет сразу перейти к делу.
Например, из этого примера истории пользователя мы можем с первого взгляда понять, что у менеджера контента есть следующая история:
«Как контент-менеджер, я хочу получать еженедельный отчет об аналитике контента, чтобы отслеживать эффективность автора контента.
11. Пример истории пользователя Amazon
Мы выбрали этот пример истории пользователя Amazon, потому что он дает нам представление о типе истории, ожидаемой в гибкой среде в крупной многонациональной технологической компании. Самое интересное, что это действительно просто. Здесь нет технического жаргона, и его может понять любой человек из любой дисциплины, в чем и заключаются пользовательские истории.
В этом примере пользователь зарегистрирован у них и хочет купить Kindle для своего друга.Один из способов, которым команда может отреагировать на эту историю, в зависимости от того, кто их пользователь, может состоять в том, чтобы включить раздел подарков на главный экран. Это может быть что-то вроде «Идеальный подарок на день рождения».
С другой стороны, они могут отображать сообщение, которое сообщает пользователю, что он может мгновенно отправлять подарки, когда просматривает такие элементы, как Kindle.
Еще одно действие, за которым они могут захотеть следить, — убедиться, что клиент может быстро и легко добавлять новые адреса или выбирать текущий список адресов.Если вы используете Amazon, вы увидите, что это действительно так!
12. Пример невыполненных пользовательских историй
Как мы видим здесь, элементы невыполненной работы сгруппированы в порядке приоритета, а задачи представлены пользовательскими историями. В каждой пользовательской истории мы можем отметить различные очки схватки, присуждаемые, чтобы указать, сколько работы потребуется, когда речь идет о каждой функции.
13. Пример пользовательской истории BBC Sport
Нам нравится этот простой пример пользовательской истории от BBC Sport.Что нам нравится в нем, так это то, что он на самом деле передает много информации всего в нескольких словах, а это именно то, что должна делать хорошая пользовательская история.
В этом примере BBC планировала добавить кнопку «Поделиться» в свои спортивные статьи, чтобы читатели могли делиться новостями, связанными со спортом, а также узнавать мнение своих друзей. Он завершен, передает много информации, а логика проста. Это определенно оправдывает необходимость кнопки «Поделиться» и указывает на то, что кто-то провел довольно много исследований своей пользовательской базы, прежде чем писать эту пользовательскую историю.
14. Пример пользовательской истории Easy Agile Workshop
Этот пример пользовательской истории из Easy Agile немного отличается. Во-первых, мы заметили, что это удивительно приятно для глаз.
Во-первых, в каждом ряду чередуются цвет и белый цвет, чтобы упростить разделение концепций и упростить сканирование. Левая и правая части карты, то есть инструкции и формула предложения, имеют зеленый и синий цвета.
Далее, инструкции слева от этого примера пользовательской истории помогают служить полезной подсказкой с категориями «Кто», «Что» и «Почему».
Они помогают нам думать об истории с точки зрения бизнеса, например, «Для кого мы это создаем?», «Кто пользователь?» и «Каково намерение?» Если бы этот пример был продублирован, он был бы невероятно полезен и послужил бы простой подсказкой для начала написания пользовательских историй.
15. Примеры пользовательских историй на туристическом веб-сайте
Вот несколько примеров пользовательских историй с туристического веб-сайта. Мы рассматриваем четыре разные истории, которые дают нам представление о различных функциях, которые они могут разработать, чтобы помочь своим пользователям достичь своих целей.
Однако мы видим одну проблему, заключающуюся в том, что три из четырех неверны. Ну, не столько неправильный, сколько неполный. Почему? Потому что пользовательские истории всегда должны указывать причину, «почему» они хотят совершить действие.
Функция всегда должна приносить пользу пользователю. Это поможет вашей команде отдать приоритет конкретным функциям, которые будут иметь реальную ценность и значение для ваших пользователей.
А счастливые пользователи — это успешный продукт и счастливый бизнес.
В первом примере речь идет о бронировании отелей. В более полной версии может быть указано:
.Как пользователь, я хочу забронировать номер в гостинице недалеко от центра города, чтобы мне не приходилось каждый день далеко ездить.
Маловероятно, что пользователь не имеет в виду конкретное место для отеля, осознает он это или нет. Добавление части «почему» поможет вам придумать более креативные решения, которые могут помочь пользователю, например, показать ему отели, в зависимости от его бюджета, которые находятся ближе к центру города или к аэропорту.Это может помешать пользователю покинуть страницу и искать адреса отелей на картах Google и проверять расстояния. В противном случае это может быть просто любой другой туристический веб-сайт, который не предоставляет пользователю явно полезной функции.
Однако последний пример пользовательской истории завершен и полезен для группы разработчиков; он показывает именно то, что хочет пользователь — иметь возможность сохранять прошлые бронирования и предотвращать дополнительные усилия по вводу данных.
Это также может помочь придумать лучшие и более жесткие критерии приемлемости.
16. Пример пользовательской истории Agile USA
Agile USA с их примером пользовательской истории на заметках для менеджера по работе с клиентами кратко описывает, что должно быть в этом типе результатов.
Это довольно простой пример, показывающий, как жизненно важную информацию для руководства проектной группой и командой разработчиков можно легко обобщить на простом стикере. Что нам нравится в этом виде примера, так это то, что он не пугает и легко понятен любому.
Это позволяет вам следовать простой формуле их написания, которая необходима, когда дело доходит до творчества, особенно когда вам нужно прокручивать историю за историей о характеристиках продукта в день написания истории.
17. Пример интроспективной пользовательской истории
Мы решили включить этот пример пользовательской истории от Александра Коуэна, потому что он четко отражает уровень мысли, который требуется при создании даже самой простой пользовательской истории.
Написание пользовательской истории — это не просто придумывание гипотетической ситуации с участием гипотетического пользователя. Вместо этого информация должна быть основана на реальных исследованиях и личностях пользователей. Этот пример пользовательской истории помогает нам использовать эту информацию, напоминая нам об основах того, почему мы пишем эту историю в первую очередь.
Подсказки в этом примере отлично подходят для того, чтобы помочь вам придумать пользовательскую историю, отражающую личность пользователя, в создание которой вы и ваша команда вложили усилия. Что нам также нравится в этом примере с персоной пользователя, так это тот факт, что подсказки также помогают ввести критерии приемлемости, спрашивая: «Как мы узнаем, работает ли это?».
Вывод — примеры пользовательской истории
Правильный носитель для вашей пользовательской истории и правильная информация для включения в нее будут зависеть от вашей организации, размера и масштаба вашего проекта и сложности разрабатываемых вами функций.
.
Какой бы способ вы ни выбрали для передачи своей пользовательской истории, самое важное, о чем следует помнить, — это исследования. После того, как вы провели адекватное исследование пользователей и определили профили своих персонажей, вы готовы написать свои пользовательские истории.
Следуя лучшим практикам, изложенным в этом посте, и черпая вдохновение (или даже скачивая) показанные примеры и шаблоны, вы должны быть на пути к написанию отличной пользовательской истории.
пользовательских историй и примеров пользовательских историй Майка Кона
Что такое история пользователя?
Истории пользователей — это краткие простые описания функции, рассказанные с точки зрения человека, которому нужны новые возможности, обычно пользователя или клиента системы.Обычно они следуют простому шаблону:
.Как , я так хочу .
Истории пользователей часто пишутся на каталожных карточках или стикерах, хранятся в коробках из-под обуви и раскладываются на стенах или столах для облегчения планирования и обсуждения.
Таким образом, они сильно смещают акцент с описания функций на их обсуждение. На самом деле, эти обсуждения важнее любого написанного текста.
Можете показать примеры пользовательских историй?
Одним из преимуществ гибких пользовательских историй является то, что они могут быть написаны с разным уровнем детализации.Мы можем написать пользовательскую историю, чтобы охватить большое количество функций. Эти большие пользовательские истории обычно известны как эпики. Вот эпический пример гибкой пользовательской истории из продукта для резервного копирования настольных компьютеров:
.- Как пользователь, я могу сделать резервную копию всего моего жесткого диска.
Поскольку эпик, как правило, слишком велик, чтобы agile-команда могла его завершить за одну итерацию, перед началом работы над ним разбивают на несколько более мелких пользовательских историй. Эпопею выше можно разделить на десятки (или, возможно, сотни), включая эти два:
- Как опытный пользователь, я могу указать файлы или папки для резервного копирования в зависимости от размера файла, даты создания и даты изменения.
- Как пользователь, я могу указать папки, которые не нужно резервировать, чтобы мой резервный диск не был заполнен тем, что мне не нужно сохранять.
Как добавляются подробности в пользовательские истории?
Детали могут быть добавлены в пользовательские истории двумя способами:
- Путем разделения пользовательской истории на несколько более мелких пользовательских историй.
- Путем добавления «условий удовлетворения».
Когда относительно большая история разбивается на несколько меньших гибких пользовательских историй, естественно предположить, что детали были добавлены.Ведь написано больше.
Условия удовлетворения — это просто высокоуровневый приемочный тест, который будет верным после того, как гибкая пользовательская история будет завершена. Рассмотрим следующий пример в качестве другого примера гибкой пользовательской истории:
. Как вице-президент по маркетингу, я хочу выбрать праздничный сезон, который будет использоваться при анализе эффективности прошлых рекламных кампаний, чтобы я мог определить прибыльные.
Подробности можно добавить к этому примеру пользовательской истории, добавив следующие условия удовлетворения:
- Убедитесь, что он работает с крупными розничными праздниками: Рождеством, Пасхой, Днем президента, Днем матери, Днем отца, Днем труда, Новым годом.
- Поддержка праздников, которые охватывают два календарных года (ни один год не длится три).
- Праздничные сезоны могут быть установлены от одного праздника к другому (например, от Дня Благодарения до Рождества).
- Праздничные сезоны могут быть установлены за несколько дней до праздника.
Кто пишет пользовательские истории?
Любой может писать пользовательские истории. Владелец продукта несет ответственность за то, чтобы существовал бэклог гибких пользовательских историй, но это не значит, что владелец продукта — это тот, кто их пишет.В ходе хорошего гибкого проекта вы должны ожидать, что каждый член команды напишет примеры пользовательских историй.
Также обратите внимание, что то, кто пишет пользовательскую историю, гораздо менее важно, чем то, кто участвует в ее обсуждении.
Когда пишутся пользовательские истории?
Пользовательские истории пишутся на протяжении всего agile-проекта. Обычно мастер-класс по написанию историй проводится в начале Agile-проекта. Каждый в команде участвует с целью создания бэклога продукта, который полностью описывает функциональность, которая будет добавлена в ходе проекта или трех-шестимесячного цикла его выпуска.
Некоторые из этих гибких пользовательских историй, несомненно, станут эпическими. Эпосы позже будут разложены на более мелкие истории, которые легче впишутся в одну итерацию. Кроме того, новые истории могут быть написаны и добавлены в бэклог продукта в любое время и кем угодно.
Заменяют ли пользовательские истории документ с требованиями?
Agile-проекты, особенно Scrum, используют бэклог продукта, который представляет собой приоритетный список функций, которые должны быть разработаны в продукте или услуге.
Хотя элементы бэклога продукта могут быть любыми, какие пожелает команда, пользовательские истории стали лучшей и самой популярной формой элементов бэклога продукта.
Хотя бэклог продукта можно рассматривать как замену документу с требованиями традиционного проекта, важно помнить, что письменная часть гибкой пользовательской истории («Как пользователь, я хочу…») является неполной до тех пор, пока не будет дискуссии об этой истории происходят.
Часто лучше думать о письменной части как об указателе на реальное требование.Пользовательские истории могут указывать на диаграмму, изображающую рабочий процесс, электронную таблицу, показывающую, как выполнять вычисления, или любой другой артефакт, который нужен владельцу продукта или команде.
Рекомендуемые ресурсы, связанные с пользовательскими историями
Курсы, связанные с пользовательскими историями
Преимущества шаблона User Story
Бесплатная загрузка: 200 примеров пользовательских историй
В моей книге пользовательских историй и на всех моих тренингах и конференциях по пользовательским историям я выступаю за написание пользовательских историй в форме:
«Как , я хочу, чтобы .
» Хотя я считаю пункт так-то необязательным, мне очень нравится этот шаблон. На конференции кто-то спросил меня, почему. Поскольку мне довольно часто задают этот вопрос, я хочу привести здесь три причины, почему:
Причина 1
Что-то важное, и я склонен сказать, что происходит волшебство, когда требования предъявляются от первого лица. Очевидно, сказав: «Как такой-то и такой-то, я хочу…» вы можете увидеть, как ум человека мгновенно начинает воображать, что он или она является таким-то и таким-то. Что касается волшебства, у Пола Маккартни взяли интервью и спросили, почему песни «Битлз» так удивительно популярны.Одним из его ответов было то, что их песни были одними из первых, в которых использовалось много местоимений. Подумайте об этом: She Loves You, I Wanna Hold Your Hand, I Saw Her Standing There, I Am The Walrus, Baby You Can Drive My Car и т. д. Он считал, что это помогает людям более тесно идентифицировать себя с песнями.
Подробнее об использовании местоимений Битлз можно прочитать в этой статье.
Причина 2
Наличие структуры историй действительно помогает владельцу продукта расставлять приоритеты.Если бэклог продукта состоит из таких вещей, как:
- Исправить обработку исключений
- Разрешить пользователям делать заказы
- Пользователи хотят видеть фото
- Показать варианты размера комнаты
… и так далее, владелец продукта должен усердно работать, чтобы понять, что это за фича, кому она выгодна и в чем ее ценность.
Причина 3
Я слышал аргумент, что написание рассказов с использованием этого шаблона на самом деле подавляет информационное содержание рассказа, потому что в тексте слишком много шаблонов.Если вы обнаружите, что это правда, то исправьте это в том, как вы представляете историю. Я видел невыполненные работы в Word, в которых стандартный текст представлен серым цветом, а уникальные части — черным. Я создал невыполненные работы по продукту в Excel, в которых используются заголовки столбцов для фильтрации общего текста.
Посмотрите сюда, и вы поймете, что я имею в виду:
Серьезно взгляните на таблицу выше, прежде чем продолжить… Я подожду… Пожалуйста, внимательно посмотрите на нее, прежде чем читать дальше.
Хорошо, вот как я могу поспорить, что вы читали электронную таблицу.Бьюсь об заклад, что, когда вы читаете большинство строк, которые вы добавили в текст «Как …», «Я хочу …» и «Чтобы …», возможно, даже просматривая заголовок, когда вы читаете через каждый ряд. Я экспериментировал, спрашивая людей, и это то, что делает большинство людей. Если этот текст не нужен, почему мы мысленно произносим слова или даже смотрим на заголовок, читая строку? Возможно, это не так уж и несущественно, в конце концов.
На данный момент и, возможно, еще долго, я буду придерживаться шаблона «Как я хочу так» по этим и другим причинам.
Примеры пользовательских историй в разработке продукта
Определение: Пользовательская история — это небольшая автономная единица разработки, предназначенная для достижения определенной цели в рамках продукта.
Пользовательская история обычно пишется с точки зрения пользователя и следует формату: «Как [персонаж пользователя], я хочу [выполнить это действие], чтобы [я мог достичь этой цели]».
Что такое история пользователя?
В гибкой разработке программного обеспечения пользовательская история представляет собой краткое, простым языком объяснение функции или функциональности, написанное с точки зрения пользователя.Многие agile-эксперты также описывают пользовательскую историю как наименьшую единицу работы по разработке продукта, которая может привести к полному элементу пользовательской функциональности.
Команды разработчиков предпочитают разбивать работу по разработке на пользовательские истории, а не на характеристики продукта или требования к продукту по нескольким причинам.
Истории пользователей:
- Простые для понимания
- Представляют небольшие результаты, которые могут уместиться в спринтах, в то время как не все полные функции могут.
- Помогите команде сосредоточиться на реальных людях, а не на абстрактных функциях
- Придайте импульс, дав командам разработчиков ощущение прогресса
Как выглядит история пользователя?
Большинство продуктовых команд используют аналогичный шаблон пользовательской истории, обычно всего одно или два предложения, написанные в соответствии со следующей формулой: ].
Примеры пользовательских историй
На практике пользовательские истории могут выглядеть следующим образом:
- Как администратор базы данных, я хочу автоматически объединять наборы данных из разных источников, чтобы мне было легче создавать отчеты для своих внутренних клиентов.
- Как бренд-менеджер, я хочу получать оповещения всякий раз, когда торговый посредник рекламирует наши продукты по ценам ниже согласованных, чтобы я мог быстро принять меры для защиты нашего бренда.
- Как руководитель удаленной команды я хочу, чтобы наше приложение для обмена командными сообщениями включало общий доступ к файлам и аннотации, чтобы моя команда могла сотрудничать в режиме реального времени и хранить архив своей работы в одном месте.
Как видно из третьего примера выше, персона в вашей пользовательской истории не обязательно должна ограничиваться должностью человека. « руководитель удаленной команды » может быть менеджером отдела, вице-президентом компании, генеральным директором небольшого стартапа или любой другой должностью в организации.
Но для объяснения этой истории — позволяя пользователям загружать файл в ваше приложение для обмена сообщениями, а затем делать собственные аннотации к этому файлу — имеет смысл описать пользователя для этой функции как человека, который наблюдает за командой коллег. работающие в разных местах.Различные пользователи, описанные в историях, которые пишет ваша команда, в некоторых случаях могут быть одним и тем же человеком, которому нужны разные функции для разных задач.
Кто должен писать пользовательские истории?
Во многих agile-организациях владелец продукта берет на себя основную ответственность за написание пользовательских историй и организацию их в бэклоге продукта.
Однако на самом деле это общая ответственность всей кросс-функциональной команды разработчиков.
На самом деле, одна из причин, по которой они написаны простым языком — без какого-либо профессионального жаргона или технических подробностей, — заключается в том, что это позволяет любому представителю деловой или технической части команды внести свою пользовательскую историю для рассмотрения.Этому члену команды (менеджеру по продукту, UX-дизайнеру и т. д.) нужно только иметь представление о конкретной проблеме пользователя, которую он надеется решить. Им не нужно знать, как команда разработчиков на самом деле будет кодировать это решение.
История пользователя и вариант использования: в чем разница?
Как и пользовательские истории, вариант использования описывает, как пользователь может взаимодействовать с продуктом для решения конкретной проблемы. Но они не взаимозаменяемы; это разные инструменты, используемые при разработке продукта.
Ивар Якобсон, которому приписывают разработку концепции вариантов использования, объясняет, что варианты использования документируют как цель пользователя, так и функциональные требования системы.
Другими словами, варианты использования предназначены для захвата гораздо большего количества деталей, чем пользовательская история, о процессе, через который проходит пользователь, чтобы достичь желаемого результата от взаимодействия с продуктом.
В то время как пользовательская история записывается как очень краткое изложение, описывающее только конечную цель пользователя, вариант использования часто описывает несколько дополнительных шагов, в том числе:
- Предварительные условия, необходимые для начала варианта использования (также называемый основным потоком), описывающий пошаговый путь пользователя к выполнению действия с продуктом
- Альтернативные потоки и потоки исключений, означающие варианты путей, которые пользователь может использовать с продуктом для достижения той же или похожей цели
- Возможно наглядная диаграмма, изображающая весь рабочий процесс
Как написать историю пользователя?
Вот простой шестиэтапный процесс создания пользовательских историй:
Шаг 1: Решите, как будет выглядеть «готово».
В большинстве случаев пользовательская история описывает конечное состояние: когда пользователь может выполнить задачу или достичь описанной цели. Вам нужно помнить об этом конечном состоянии, когда вы пишете свой, чтобы остальная часть вашей команды знала, когда они могут отметить завершенную работу по разработке. (Подробнее об определении «готово».)
Шаг 2. Задокументируйте задачи и подзадачи.
Хотя ваша фактическая история пользователя будет включать только стандартное утверждение, описанное выше — «Как [персонаж], я хочу [функцию], чтобы [причина]» — вам также необходимо будет задокументировать детали, необходимые для завершения работы по разработке. описано в рассказе.Это означает определение задач и подзадач и назначение их нужным людям.
Шаг 3: Определите свои пользовательские профили.
Кого обслуживают в этой истории? Какой тип пользователя или клиента? Вы должны задокументировать это заранее. Если вы имеете в виду несколько разных пользователей, вы можете разбить это на более чем одну пользовательскую историю.
Таким образом, ваша команда сможет сосредоточиться на том, чтобы помочь конкретному персонажу достичь определенной цели для каждой истории.
Шаг 4. Создавайте истории в виде упорядоченных шагов.
Концепция отображения пользовательских историй предполагает, что вы можете думать о своем продукте в целом как о серии задач или работ, которые продукт помогает выполнять вашим пользователям. Имея это в виду, если вы пытаетесь структурировать работу над более крупным процессом или более полным набором функций продукта, напишите каждый отдельный шаг в виде истории.
Шаг 5: Получите отзывы пользователей.
Чтобы повысить свои шансы на выделение ресурсов для разработки, которая будет резонировать с вашим рынком, поговорите с пользователями и клиентами об их приоритетах и узнайте, чего еще они хотят от ваших продуктов.Только после сбора и анализа этой обратной связи вы можете приступать к созданию пользовательских историй.
Шаг 6. Набросайте истории, которые можно выполнить за один спринт.
Истории пользователей, которые занимают больше одного спринта (обычно две недели), должны быть разбиты на более мелкие истории. Таким образом, ваша команда получает ощущение завершения в каждом спринте, потому что каждый раз они могут выполнять какую-то новую функциональность. Это также позволяет вашей команде чаще выводить на рынок новые функции.
Команды по продуктам, почему бы вам не написать, думая о своих пользователях?
Помимо того, что они предназначены для размещения на каталожных карточках и могут быть легко поняты любым, одно из самых больших преимуществ пользовательских историй заключается в том, что они могут помочь вам не потеряться в технических деталях серверной части вашего продукта или от увлечения UX, который вы считаете элегантным, но который на самом деле не структурирован так, как ваши пользователи предпочитают работать.
Истории пользователей помогают вашей команде достичь всего этого — и создавать более качественные продукты — заставляя вас внести одно простое изменение в свой подход к планированию разработки.
Вместо того, чтобы описывать свои планы с точки зрения продукта (какие функции создавать), пользовательские истории заставляют вас разрабатывать каждую предложенную идею для новой функциональности с точки зрения реальных людей, которые будут использовать эту функциональность.
Шаблон пользовательских историй — формула для пользовательских историй | Ага! software
Записывайте пользовательские истории на основе облачных технологий в Aha! с бесплатной 30-дневной пробной версией .
Пользовательская история — это термин гибкой разработки, описывающий функцию продукта с точки зрения конечного пользователя.Пользовательские истории помогают менеджерам по продуктам четко определять требования к программному обеспечению, чтобы команда разработчиков понимала желаемый результат новой функциональности.
Что такое шаблон пользовательской истории?
Шаблон пользовательской истории описывает «кто», «что» и «почему» функции простым и кратким образом.
Это предложение часто пишется повседневным или деловым языком конечного пользователя, чтобы передать то, что он хочет или должен сделать.
Структура для определения пользовательских историй представлена ниже:
Как [тип пользователя] я хочу [выполнить некоторую задачу], чтобы я мог [достичь некоторой цели].
Давайте используем пример компании под названием Fredwin Cycling, чтобы определить пользовательскую историю на основе приведенной выше структуры. Fredwin Cycling предлагает социальное фитнес-приложение, которое объединяет спортсменов и способствует дружеским соревнованиям. Вот пример пользовательской истории для функциональности, которая показывает велосипедистам местоположение их друзей на карте:
Как велосипедист, я хочу отслеживать местоположение своих друзей, чтобы я мог присоединиться к ним в поездках.
Важно проверять пользовательские истории посредством общения с конечными пользователями.Беседы обеспечивают более богатую форму сбора информации, чтобы гарантировать, что требования правильно поняты и доведены до более широкой команды.
Шаблон пользовательской истории также должен включать условия удовлетворения — или критерии приемлемости — которые уточняют желаемый результат. Эта информация помогает команде разработчиков понять, как создать новую функциональность и протестировать ее на соответствие требованиям конечного пользователя.
Многие группы используют структурированный подход для определения критериев приемлемости.Вот простой шаблон, которым можно руководствоваться при написании приемочных тестов:
Учитывая, что [некоторый контекст], когда [выполняется какое-то действие], должен произойти [набор наблюдаемых результатов].
Использование этой формулы уменьшает количество недоразумений с командой разработчиков, обеспечивая правильную реализацию пользовательских историй. Давайте воспользуемся пользовательской историей Fredwin Cycling, которую мы создали ранее, чтобы показать пример критериев приемлемости, написанных с точки зрения конечного пользователя:
Учитывая, что велосипедист хочет кататься с друзьями, когда они проверяют вид карты, то показывают им местоположение других велосипедистов в их социальной сети.
Шаблоны, представленные в этом руководстве, предлагают быстрый способ регистрации требований клиентов без необходимости создания формализованного документа с требованиями. Вы должны постоянно собирать пользовательские истории от конечных пользователей и расставлять приоритеты в своем бэклоге продукта. Это поможет вам быстрее реагировать на потребности клиентов и свести к минимуму административные издержки, связанные с ведением объемных документов. По мере роста вашего бэклога продукта вам, вероятно, потребуются различные типы шаблонов для организации ваших пользовательских историй.
Вы можете использовать приведенные ниже шаблоны для записи своих пользовательских историй и критериев приемлемости:
Простой шаблон пользовательской истории
Что такое пользовательские истории — примеры пользовательских историй от Inflectra
Пользовательская история — это форма требования к программной системе, которая стала довольно популярной в гибких методологиях, таких как экстремальное программирование и Scrum.
В отличие от более традиционных методов, таких как спецификация системных требований или диаграммы вариантов использования, упор в этих методологиях делается на простоту и изменчивость.Поэтому пользовательские истории разработаны таким образом, чтобы их было легко описать и понять, и, что более важно, конечный пользователь может легко изменить их в ходе проекта.
Атрибуты хорошей пользовательской истории:
- Написано с использованием языка, понятного заказчику и конечному пользователю
- Достаточно короткий, чтобы состоять из нескольких предложений и поместиться на небольшую карточку (для чтения или в электронном виде)
- Достаточно сфокусированы, чтобы описывать небольшие приращения функциональности, которые можно выполнить за несколько дней или недель
- Часто изменяется на основе обсуждений с заказчиком по мере лучшего понимания функциональности
Чтобы избежать ненужной сложности, их часто записывают на небольших каталожных карточках (реальных или виртуальных), называемых «карточками историй», которые описывают функциональность с использованием формы — «Как (роль) я хочу (что-то), чтобы (польза)» .
Например, в системе бронирования авиабилетов карточка-история может выглядеть так:
Создание пользовательских историй
В соответствии с совместным, относительно информационным характером гибких методологий пользовательские истории обычно создаются разработчиками и представителями заказчика либо на бумаге, либо с использованием гибкой системы управления проектами для фиксации истории. Заказчик несет ответственность за описание того, что он хочет от системы, а разработчик отвечает за сбор информации и задает вопросы, помогающие прояснить важные моменты.
В отличие от других методологий, в которых у вас есть специальные бизнес-аналитики, собирающие требования, в идеале разработчики должны работать напрямую с клиентом, чтобы убедиться, что история пользователя реалистична и технически осуществима. Кроме того, поскольку разработчик будет понимать, что нужно для фактической реализации функции, он будет знать, какие детали необходимо включить в определение истории.
по сравнению с вариантами использования
Во многих отношениях пользовательские истории служат той же цели, что и формальный вариант использования, а именно для сбора системных требований с точки зрения пользователя системы.Оба описывают взаимодействия, происходящие между внешним объектом (пользователем или действующим лицом) и системой. Однако, несмотря на эти сходства, есть и весьма характерные различия:
- Истории пользователей пишутся довольно неформально на языке пользователя, имеют свободную организацию и обычно пишутся клиентами совместно с разработчиками. Из-за их неформального характера они могут быть интерпретированы и, следовательно, требуют, чтобы клиент был на месте или был доступен для уточнения, когда это необходимо.
- Варианты использования написаны в соответствии с довольно строгим стандартом, состоящим из отдельных шагов, описывающих бизнес-процесс и точное взаимодействие между пользователем и системой. Обычно они пишутся бизнес-аналитиками совместно с заказчиком, но носят достаточно предписывающий характер, чтобы разработчик мог их понять, не обращаясь к заказчику за разъяснениями.
Важность приемочных испытаний
Как упоминалось выше, пользовательские истории сами по себе являются высокоуровневыми описаниями предполагаемой функциональности и открыты для интерпретации.Поэтому они сами по себе не определяют требование достаточно подробно, чтобы сформировать основу обязывающего контракта или формальную спецификацию требований. Таким образом, пользовательские истории обычно сопровождаются приемочными тестами, написанными заказчиком (или, по крайней мере, согласованными с заказчиком) и формирующими основу для реализации пользовательской истории разработчиком.
Поскольку формальная спецификация воплощена в приемочных тестах, а не в пользовательских историях, одним из ключевых аспектов гибких методологий (по сравнению с традиционной каскадной разработкой) является то, что разработка определяется результатами приемочных тестов, а не наоборот. .В результате разработчики сначала пишут тесты, а затем разрабатывают программное обеспечение для их прохождения.
Этот подход известен как разработка на основе тестирования и отличается от альтернативы, разработки на основе модели или разработки на основе дизайна, в которых модель проектирования, основанная на «бумажной» спецификации требований, управляет разработкой.
Почему я должен использовать SpiraTeam для своих пользовательских историй?
SpiraTeam® предоставляет информационные панели с ключевыми показателями качества и прогресса проекта — охват тестами требований, ход выполнения задач, скорость проекта, а также основные риски и проблемы — в одном консолидированном представлении, которое специально создано для гибких методологий разработки программного обеспечения, а также поддерживает ваши унаследованные/гибридные водопадные проекты.Основные причины, по которым наши клиенты выбирают SpiraTeam® среди других решений:
- Интуитивно понятное веб-приложение, которое дает полную картину состояния и работоспособности проекта, но требует только веб-браузера.
