Пользовательская история или 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»:
- Independent (Независимость). Пользовательская история должна быть независимой от других историй. Она должна описывать только одну функцию или задачу.
- Negotiable (Открытость). Пользовательская история должна быть понятной всем участников проекта, включая разработчиков, тестировщиков, дизайнеров и менеджеров проекта.
- Valuable (Ценность). Пользовательская история должна быть связана с потребностями пользователей и целями продукта. Она должна описывать, какая ценность будет получена в результате её выполнения.
- Estimable (Оценочность). Пользовательская история должна быть конкретной и измеримой, т.е. может быть оценена.
- Small (Лаконичность). Пользовательская история не должна быть слишком длинной или содержать несвязанные детали. Она должна быть короткой и содержать только необходимую информацию.
- Testable (Тестопригодность). Пользовательская история должна быть сформулирована таким образом, чтобы можно было легко проверить, выполнена ли задача.
Кроме того, хорошая User story должна быть актуальной и регулярно обновляться в соответствии с изменением требований пользователей и бизнес-целей.
Какие могут быть ошибки?
При написании User story следует избегать следующих ошибок:
- Недостаточная ясность и понятность. User story должна быть ясной и понятной для всех участников проекта. Избегайте использования технических терминов и сложных конструкций языка.
- Неудачное формулирование. Избегайте формулирования историй в стиле «как пользователь, я должен сделать что-то, чтобы достичь чего-то еще». История должна быть более конкретной и описывать задачу пользователя.
- Неправильный уровень детализации. История не должна быть слишком детальной или слишком общей. Она должна описывать только одну задачу пользователя.
- Несоответствие бизнес-целям. Избегайте написания пользовательских историй, которые не соответствуют бизнес-целям или потребностям пользователей.
- Неопределенность. Избегайте использования неопределенных понятий в истории, например, «некоторые пользователи». Определите конкретных пользователей и их потребности.
- Неправильный формат. Избегайте использования формата, не соответствующего стандартам. Используйте стандартный формат User Story — «Как [тип пользователя], я хочу [описание задачи], чтобы [цель]».
- Несоответствие реальности. Избегайте написания историй, которые не могут быть реализованы в рамках текущего проекта или технических возможностей.
- Неучтенные ограничения. Учитывайте ограничения, например бюджет, сроки, доступность ресурсов и другие факторы, которые могут повлиять на историю.
- Недостаточное тестирование. Избегайте написания пользовательских историй, которые не могут быть протестированы. История должна быть тестопригодной и измеримой, чтобы можно было проверить, выполнена ли задача.
Избегая этих ошибок, вы сможете написать эффективные User story, которые помогут достичь бизнес-целей и удовлетворить потребности пользователей.
Как оценивать?
Оценка User story может помочь команде определить, сколько времени и ресурсов необходимо для выполнения истории. Вот несколько способов оценки пользовательских историй:
- Оценка в единицах времени. Это самый распространенный способ оценки пользовательских историй. Команда разработки оценивает каждую историю в единицах времени, например, в часах или днях, необходимых для ее выполнения.
- Оценка сложности (Story point). Команда разработки может оценить User story по ее сложности, используя шкалу от 1 до 10, где 1 — это простая история, а 10 — очень сложная.
- Оценка по критериям. Команда разработки может оценить каждую User story по определенным критериям, таким как техническая сложность, степень взаимодействия с другими функциями ПО, уровень удовлетворения потребностей пользователя и т. д.
- Оценка по приоритету. Команда разработки может оценить User story по приоритету, определяя, какие истории имеют более высокий приоритет и необходимы для достижения бизнес-целей проекта.
- Оценка по опыту. Команда разработки может использовать свой опыт для оценки User story, учитывая сложности и риски, связанные с выполнением каждой истории.
Каждый из этих методов может быть полезен при оценке User story. Однако команда разработки должна выбрать тот метод, который лучше всего подходит для конкретного проекта и учитывает особенности его разработки.
User Story пример
Ошибочная формулировка | Ошибка | Правильная формулировка |
Как пользователь, я хочу, чтобы мое приложение было красивым, чтобы мне было приятно им пользоваться. | Неопределенный критерий готовности. Нет конкретики о том, что такое «красивое приложение» и как это достигается. | Как пользователь, я хочу, чтобы мое приложение имело привлекательный и легко воспринимаемый дизайн, соответствующий современным трендам дизайна, чтобы я мог эффективно использовать его. |
Как пользователь, я хочу, чтобы мой профиль был виден другим пользователям, чтобы они могли узнать обо мне больше. | Не указано, какая информация должна быть видна и как пользователь может контролировать видимость. | Как пользователь, я хочу иметь возможность выбирать, какая информация в моем профиле должна быть видна другим пользователям, и какая информация должна быть скрыта, чтобы я мог контролировать свою конфиденциальность. |
Как менеджер, я хочу иметь возможность добавлять новые задачи, чтобы я мог назначать их нашим сотрудникам. | Недостаточно точное определение роли. Не указано, какие задачи должны быть добавлены и как они будут использоваться. | Как менеджер, я хочу иметь возможность добавлять новые задачи с конкретными параметрами (название, описание, сроки, ответственный сотрудник), чтобы я мог назначать их нашим сотрудникам и контролировать выполнение работ. |
Как пользователь, я хочу, чтобы мое приложение было быстрее, чтобы я мог сократить время ожидания. | Цель сократить время ожидания не является измеримой | Как пользователь, я хочу, чтобы мое приложение загружалось за 3 секунды или меньше, чтобы я мог быстро получать доступ к информации и эффективно использовать приложение. |
Как менеджер, я хочу, чтобы мои сотрудники работали более эффективно, чтобы мы могли увеличить нашу производительность. | Не содержит определенных действий, которые должны быть выполнены. Цель увеличения производительности не является измеримой. | Как менеджер, я хочу, чтобы сотрудники заводили в CRM всех потенциальных клиентов, чтобы мы могли легко отслеживать весь процесс продаж, повышать эффективность работы и улучшать наш сервис для клиентов. Критерии выполнения: все потенциальные клиенты внесены в CRM, эффективность работы повышена на 20%. |