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

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

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

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

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

Что такое пользовательская история

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

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

Пользовательские истории — это списки дел, которые помогают определить шаги, которым нужно следовать при работе над проектом. Пользовательская история должна отражать «кто», «что» и «почему» требования к продукту. Такие рассказы короткие, где каждый элемент содержит 10-15 слов. Эти шаги помогут обеспечить соответствие продукта и процесса желаемым требованиям.

По словам Рона Джеффриса, каждая пользовательская история должна иметь 3C, обозначающие «карточка, разговор и подтверждение». Давайте теперь опишем 3C, на которые следует обратить внимание при написании пользовательских историй в Jira.

Открытка

Пользовательские истории изначально были написаны на физических карточках или стикерах Post-it. Теперь у нас есть современные карточки, которые мы можем легко настроить при написании пользовательских историй в Jira. Однако в карточке будет содержаться лишь некоторая информация о требовании. На карточке будет достаточно информации, чтобы помочь вам понять потребность.

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

Беседа

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

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

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

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

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

Цель написания пользовательской истории

• Помогает дизайнерам, владельцам продуктов и разработчикам думать о конечных пользователях . Современные продукты всегда должны учитывать, как конечные пользователи будут взаимодействовать с продуктом. Пользовательская история — это отличный подход, который подчеркивает путь конечных пользователей при проектировании и разработке продукта.
• Имеет простой и гибкий формат . Пользовательские истории в Jira не должны быть сложными. Простой формат гарантирует, что вы зафиксируете все детали, используя минимум слов. Потребности также меняются по мере роста системы/программного приложения, и именно поэтому User Story является гибкой, чтобы приспосабливаться к таким изменениям.
• Команда говорит на одном языке . Типичная команда разработчиков может иметь владельца продукта, дизайнеров и разработчиков. Пользовательская история — это хороший инструмент, который гарантирует, что каждый в команде понимает необходимость и конечные цели.
• Пользовательские истории позволяют сотрудничать . Пользовательские истории определяют конечные цели. Таким образом, команда может работать вместе и решать, как лучше всего обслуживать конечного пользователя и достигать поставленных целей.

Лучшие практики, которым следует следовать при написании пользовательских историй

№1. Пользователь должен быть четко определен

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

Пользователь представлен как:

«Как [имя пользователя]……»

Например, «Как арендатор…….» или «Как арендодатель…».

№ 2. Пользовательские истории должны отражать потребность

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

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

Потребность представлена ​​следующим образом: «Как [ИМЯ ПОЛЬЗОВАТЕЛЯ]: Я могу [ДОСТИГНУТЬ ЧЕГО-ТО]…».

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

№3. Должно быть уточняющее заявление

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

Вы можете представить уточняющее утверждение как;

«Как [ИМЯ ПОЛЬЗОВАТЕЛЯ] я могу [ДОСТИГНУТЬ ЧЕГО-ТО], так что [ЗАЯВЛЕНИЕ ЦЕННОСТИ]…»

Например;

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

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

№ 4. Пользовательская история должна быть независимой

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

№ 5. Сделайте пользовательскую историю доступной для обсуждения

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

№ 6. Должен быть простым и маленьким

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

Пошаговый процесс создания пользовательской истории в Jira

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

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

№1. Войти/создать учетную запись Jira

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

№ 2. Создать задачу

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

№3. Сформулируйте свою пользовательскую историю

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

№ 4. Прикрепить связанные файлы

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

№ 5. добавить описание

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

№ 6. Назначить задачу

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

№ 7. Установить приоритет задачи

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

№8. Опубликуйте историю пользователя

Поскольку вы создаете User Story впервые, у вас не будет много функций. Вы можете нажать кнопку «Создать», и ваша история пользователя будет готова для просмотра.

Подведение итогов

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

Вас также может заинтересовать это Руководство по методологии Agile.