User story — что это и как их использовать

User story - что это и как их использовать

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

User story обычно используются в Agile-методологиях разработки ПО, где их задача — помочь разработчикам лучше понимать нужды и потребности пользователей, а также ориентироваться на конечный результат при создании программного продукта. Они позволяют определить цели и задачи конечного пользователя, а также описать требования, которые должны быть выполнены, чтобы удовлетворить потребности пользователя. Таким образом, user story помогают команде разработки программного обеспечения создавать продукты, которые будут успешно решать проблемы и удовлетворять потребности пользователей.

Как писать User story правильно

Чтобы успешно сформулировать User story, следует учитывать следующие рекомендации:

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

Использовать формат User Story — As a… I want… So that…. Этот формат позволяет формулировать пользовательские истории в ясном и лаконичном формате. В нем вы указываете, кто пользователь (As a…), что он хочет (I want…) и зачем ему это нужно (So that…).

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

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

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

Критерии User story

Хорошая User story должна соответствовать критериям «INVEST»:

  1. Independent (Независимость). Пользовательская история должна быть независимой от других историй. Она должна описывать только одну функцию или задачу.
  2. Negotiable (Открытость). Пользовательская история должна быть понятной всем участников проекта, включая разработчиков, тестировщиков, дизайнеров и менеджеров проекта.
  3. Valuable (Ценность). Пользовательская история должна быть связана с потребностями пользователей и целями продукта. Она должна описывать, какая ценность будет получена в результате её выполнения.
  4. Estimable (Оценочность). Пользовательская история должна быть конкретной и измеримой, т.е. может быть оценена.
  5. Small (Лаконичность). Пользовательская история не должна быть слишком длинной или содержать несвязанные детали. Она должна быть короткой и содержать только необходимую информацию.
  6. Testable (Тестопригодность). Пользовательская история должна быть сформулирована таким образом, чтобы можно было легко проверить, выполнена ли задача.

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

Какие могут быть ошибки?

При написании User story следует избегать следующих ошибок:

  1. Недостаточная ясность и понятность. User story должна быть ясной и понятной для всех участников проекта. Избегайте использования технических терминов и сложных конструкций языка.
  2. Неудачное формулирование. Избегайте формулирования историй в стиле «как пользователь, я должен сделать что-то, чтобы достичь чего-то еще». История должна быть более конкретной и описывать задачу пользователя.
  3. Неправильный уровень детализации. История не должна быть слишком детальной или слишком общей. Она должна описывать только одну задачу пользователя.
  4. Несоответствие бизнес-целям. Избегайте написания пользовательских историй, которые не соответствуют бизнес-целям или потребностям пользователей.
  5. Неопределенность. Избегайте использования неопределенных понятий в истории, например, «некоторые пользователи». Определите конкретных пользователей и их потребности.
  6. Неправильный формат. Избегайте использования формата, не соответствующего стандартам. Используйте стандартный формат User Story —  «Как [тип пользователя], я хочу [описание задачи], чтобы [цель]».
  7. Несоответствие реальности. Избегайте написания историй, которые не могут быть реализованы в рамках текущего проекта или технических возможностей.
  8. Неучтенные ограничения. Учитывайте ограничения, например бюджет, сроки, доступность ресурсов и другие факторы, которые могут повлиять на историю.
  9. Недостаточное тестирование. Избегайте написания пользовательских историй, которые не могут быть протестированы. История должна быть тестопригодной и измеримой, чтобы можно было проверить, выполнена ли задача.

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

Как оценивать?

Оценка User story может помочь команде определить, сколько времени и ресурсов необходимо для выполнения истории. Вот несколько способов оценки пользовательских историй:

  1. Оценка в единицах времени. Это самый распространенный способ оценки пользовательских историй. Команда разработки оценивает каждую историю в единицах времени, например, в часах или днях, необходимых для ее выполнения.
  2. Оценка сложности (Story point). Команда разработки может оценить User story по ее сложности, используя шкалу от 1 до 10, где 1 — это простая история, а 10 — очень сложная.
  3. Оценка по критериям. Команда разработки может оценить каждую User story по определенным критериям, таким как техническая сложность, степень взаимодействия с другими функциями ПО, уровень удовлетворения потребностей пользователя и т. д.
  4. Оценка по приоритету. Команда разработки может оценить User story по приоритету, определяя, какие истории имеют более высокий приоритет и необходимы для достижения бизнес-целей проекта.
  5. Оценка по опыту. Команда разработки может использовать свой опыт для оценки User story, учитывая сложности и риски, связанные с выполнением каждой истории.

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

User Story пример

Ошибочная формулировка Ошибка Правильная формулировка
Как пользователь, я хочу, чтобы мое приложение было красивым, чтобы мне было приятно им пользоваться. Неопределенный критерий готовности. Нет конкретики о том, что такое «красивое приложение» и как это достигается. Как пользователь, я хочу, чтобы мое приложение имело привлекательный и легко воспринимаемый дизайн, соответствующий современным трендам дизайна, чтобы я мог эффективно использовать его.
Как пользователь, я хочу, чтобы мой профиль был виден другим пользователям, чтобы они могли узнать обо мне больше. Не указано, какая информация должна быть видна и как пользователь может контролировать видимость. Как пользователь, я хочу иметь возможность выбирать, какая информация в моем профиле должна быть видна другим пользователям, и какая информация должна быть скрыта, чтобы я мог контролировать свою конфиденциальность.
Как менеджер, я хочу иметь возможность добавлять новые задачи, чтобы я мог назначать их нашим сотрудникам. Недостаточно точное определение роли. Не указано, какие задачи должны быть добавлены и как они будут использоваться. Как менеджер, я хочу иметь возможность добавлять новые задачи с конкретными параметрами (название, описание, сроки, ответственный сотрудник), чтобы я мог назначать их нашим сотрудникам и контролировать выполнение работ.
Как пользователь, я хочу, чтобы мое приложение было быстрее, чтобы я мог сократить время ожидания. Цель сократить время ожидания не является измеримой Как пользователь, я хочу, чтобы мое приложение загружалось за 3 секунды или меньше, чтобы я мог быстро получать доступ к информации и эффективно использовать приложение.
Как менеджер, я хочу, чтобы мои сотрудники работали более эффективно, чтобы мы могли увеличить нашу производительность. Не содержит определенных действий, которые должны быть выполнены. Цель увеличения производительности не является измеримой. Как менеджер, я хочу, чтобы сотрудники заводили в CRM всех потенциальных клиентов, чтобы мы могли легко отслеживать весь процесс продаж, повышать эффективность работы и улучшать наш сервис для клиентов. Критерии выполнения: все потенциальные клиенты внесены в CRM, эффективность работы повышена на 20%.

 

Техноблог
Добавить комментарий