Искусство написания гибких пользовательских историй

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

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

Формат пользовательской истории

Как (n) <тип пользователя>, я хочу <функцию>, чтобы я мог <выгода>

Пример

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

Тип пользователя отвечает на вопрос «кто», функция указывает на «что» и, наконец, преимущество объясняет «почему» в пользовательской истории.

Из чего состоит отличная история пользователя?

Теперь, когда вы знаете типичный формат пользовательской истории, следующий вопрос, который приходит на ум: «Что делает пользовательскую историю отличной?»*.

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

Изображение Andre Simones из one80agiletraining

ИНВЕСТИРОВАТЬ

К счастью, [Билл Уэйк] (https://twitter.com/wwake) придумал термин «ИНВЕСТИРОВАТЬ», который служит напоминанием о характеристиках качественной пользовательской истории. ИНВЕСТ означает:

• Независимые: Пользовательские истории не должны зависеть друг от друга.

• Возможен торг: следует оставить место для обсуждения.

• Ценный: должен приносить пользу заинтересованным сторонам.

• Оцениваемый: вы должны быть в состоянии оценить размер и масштаб пользовательской истории.

• Маленький: Пользовательская история должна быть достаточно маленькой, чтобы ее можно было легко спланировать и расставить по приоритетам.

• Тестируемый: Вы должны иметь возможность протестировать результаты разработки.

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

Следуя INVEST, гораздо проще решить, какие пункты вы должны выполнить в первую очередь, а какие можно подождать.

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

Изображение Roman Pichler из romanpichler

Вот примеры плохих пользовательских историй и почему они не работают:

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

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

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

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

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

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

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

Изображение с [justinmind.com] (https://assets.justinmind.com/wp-content/uploads/2020/09/user-story-examples-backlog.png)

В отличие от предыдущих плохих примеров, вот пользовательские истории, которые работают хорошо:

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

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

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

Эти пользовательские истории хорошо работают, потому что они обладают характеристиками INVEST:

• Их функциональность не зависит от других историй.

• Они оставляют место для различных вариантов реализации.

• Они добавляют пользовательскую ценность проекту.

• Их размах и размер точно могут быть оценены разработчиками.

• Они достаточно малы, чтобы их можно было спланировать и/или перераспределить по сравнению с другими историями.

• Их можно проверить.

Завершение пользовательской истории

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

Пользовательская история завершена, когда она соответствует своим Критериям приемки и Определению готовности (DoD). Но что означают эти термины?

![Критерии приемки и определение готовности]

Изображение из agilemania

Критерии приемлемости

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

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

Определение готовности (DoD)

Определение готовности (Definition of Done, DoD) — это список требований, которым должна соответствовать пользовательская история или инкремент, чтобы команда могла считать его завершенным.

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

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

Истории пользователей в средах Agile/Scrum

Изображение [Нейта Мартинса] (https://www.notion.so/blog/kanban-vs-scrum) из Notion

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

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

В отличие от Элемента Бэклога Продукта (PBI), пользовательская история описывает больше, чем просто конкретное требование, изменение или исправление ошибки.

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

3C пользовательских историй

Пользовательская история Agile состоит из трех основных компонентов, каждый из которых начинается с буквы «C», отсюда и «3C»:

• Карта

• Беседа

• Подтверждение

Карта

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

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

Наиболее распространенный формат пользовательской истории «Карточка»:

Как (n) <тип пользователя>, я хочу <функцию>, чтобы я мог <выгода>

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

Беседа

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

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

Подтверждение

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

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

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

Изображение из heavencpa

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

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

• Следует основным принципам Agile/Scrum.

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

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

• Поощряет беседы, а не просто раздает детали документа.

• Простота расстановки приоритетов и изменения порядка, особенно для элементов невыполненной работы.

• Легко понимается как клиентами, так и разработчиками.

Недостатки пользовательских историй:

• Не объясняет "как?"

• Не включает нефункциональные требования (например, отказоустойчивость, производительность, удобство использования, модифицируемость)

• Пользовательские истории не заменяют бизнес-требования.

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

• Может быть неправильно понят и неправильно использован.

• Может утратить свою первоначальную суть/цель (особенно в компаниях и командах, которые используют Agile только для целей соответствия).

Часто задаваемые вопросы (FAQ)

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

Каждый может писать пользовательские истории. В среде Agile/Scrum владелец продукта несет ответственность за невыполненные работы по всем пользовательским историям.

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

Когда следует писать пользовательские истории?

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

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

Когда пользовательская история завершена или завершена?

Пользовательская история завершена, когда она соответствует критериям приемлемости и определению готовности (DoD).

Заменяют ли пользовательские истории документ с требованиями?

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

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

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

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

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

Похожи ли пользовательские истории на псевдокод?

Они используются по-разному.

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

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

Заключительные замечания

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

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

• Определите пользователя, функцию и выгоду (или ответьте "кто, что и почему?").

• Иметь характеристики INVEST.

• Не слишком ограничительный с точки зрения реализации.

• Иметь критерии приемки и определение готовности (DoD).

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

Пользовательская история — это наименьшая функциональная единица в Бэклоге Продукта Agile/Scrum. Большинство современных команд разработчиков программного обеспечения потребуют от вас его использования, поэтому его определенно стоит изучить.

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

Попробуйте написать пользовательские истории, прежде чем создавать свой следующий проект, и посмотрите, как это поможет!

Ресурсы/рекомендуемая литература:

• [Руководство по пользовательским историям Майка Кона] (https://www.mountaingoatsoftware.com/agile/user-stories#:\~:text=User%20stories%20are%20short%2C%20simple,so%20that%20)

• [Как создать идеальную историю пользователя — пошаговое руководство] (https://blog.anvileight.com/posts/how-to-create-a-perfect-user-story-step-by-step-guide/ )

• Новичок в Agile? ИНВЕСТИРУЙТЕ в хорошие пользовательские истории

• [Определение готовности и критериев приемлемости] (https://www.visual-paradigm.com/scrum/definition-of-done-vs-acceptance-criteria/)

• [Эффективные пользовательские истории] (https://www.visual-paradigm.com/scrum/3c-and-invest-guide/)

ОТКАЗ ОТ ОТВЕТСТВЕННОСТИ:

***Это руководство для начинающих, предназначенное для ознакомления новичков с пользовательскими историями. ***

Это руководство выражает только мои мысли и мнения (основанные на моих ограниченных знаниях) и никоим образом не заменяет реальных ссылок.

Если я когда-нибудь ошибусь или вы не согласитесь, буду признателен за исправления и обсуждения в комментариях!

• Впервые опубликовано [здесь] (https://www.rammina.com/blog/posts/the-art-of-writing-agile-user-stories)*