Для чего используются варианты использования и пользовательские истории

В мире разработки программного обеспечения 💻 важно не просто создавать код, а создавать ценность для пользователей. Чтобы достичь этой цели, разработчики и заказчики должны говорить на одном языке, понимать потребности пользователей и четко представлять, как будет функционировать конечный продукт. Именно здесь на помощь приходят пользовательские истории и варианты использования (Use Cases) — мощные инструменты, которые помогают командам сфокусироваться на ценности, синхронизировать усилия и создать действительно полезный продукт.

1. Пользовательские истории: голоса пользователей, ведущие к успеху 🗣️
2. Варианты использования (Use Cases): детализация взаимодействия 🔍
3. Взаимосвязь и различия: пользовательские истории и Use Cases 🤝
4. Карта пользовательских историй: визуальное представление ценности 🗺️
5. Критерии приёмки (Acceptance Criteria, AC): чёткое определение успеха ✅
6. Формула пользовательской истории: простая структура 📝
7. Заключение: пользовательские истории и варианты использования — неотъемлемая часть успешной разработки 🌟
8. Советы по использованию пользовательских историй и вариантов использования
9. FAQ: часто задаваемые вопросы

Пользовательские истории: голоса пользователей, ведущие к успеху 🗣️

Пользовательская история — это краткое описание функциональности с точки зрения конечного пользователя. Она отвечает на вопрос: «Что пользователь хочет сделать?». Представьте, что вы разговариваете с пользователем и он рассказывает вам, что ему нужно, чтобы сделать свою работу или решить свою проблему. Вот так и пишется пользовательская история — простым, понятным языком, без технических подробностей.

Например, пользовательская история для приложения онлайн-заказа такси может выглядеть так:

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

Пользовательские истории обладают рядом преимуществ:

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

Варианты использования (Use Cases): детализация взаимодействия 🔍

Варианты использования (Use Cases) — это более детальные описания сценариев взаимодействия пользователей с системой. Они отвечают на вопрос: «Как пользователь взаимодействует с системой?». Use Cases описывают каждый шаг взаимодействия, начиная с входа пользователя в систему и заканчивая получением желаемого результата.

Пример Use Case для приложения онлайн-заказа такси:

1. Пользователь открывает приложение.
2. Вводит начальный и конечный адрес.
3. Выбирает тип автомобиля.
4. Подтверждает заказ.
5. Приложение находит ближайшее свободное такси.
6. Пользователь получает информацию о такси (номер, модель, время прибытия).
7. Пользователь отслеживает движение такси на карте.
8. Такси прибывает к пользователю.
9. Пользователь совершает поездку.
10. Пользователь оплачивает поездку.

Use Cases помогают:

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

Взаимосвязь и различия: пользовательские истории и Use Cases 🤝

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

Пользовательские истории:

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

Use Cases:

• Фокусируются на деталях взаимодействия.
• Описывают последовательность действий.
• Используют формальный язык.
• Используются для проектирования и тестирования системы.

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

А Use Case может быть: «Пользователь открывает приложение, вводит начальный и конечный адрес, выбирает тип автомобиля, подтверждает заказ, приложение находит ближайшее свободное такси, пользователь получает информацию о такси, отслеживает движение такси на карте, такси прибывает к пользователю, пользователь совершает поездку, пользователь оплачивает поездку.»

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

Карта пользовательских историй: визуальное представление ценности 🗺️

Карта пользовательских историй (User Story Map) — это визуальное представление продукта, которое помогает командам увидеть, как отдельные функции продукта сочетаются друг с другом. Она позволяет выделить ключевые функции, определить приоритеты и построить roadmap.

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

Карта пользовательских историй помогает:

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

Критерии приёмки (Acceptance Criteria, AC): чёткое определение успеха ✅

Критерии приёмки (Acceptance Criteria, AC) — это набор требований, которые должны быть выполнены, чтобы пользовательская история считалась завершённой. Они являются неотъемлемой частью создания качественных пользовательских историй в Agile-проектах.

Например, для пользовательской истории «Как пользователь, я хочу заказать такси через приложение, чтобы добраться из пункта А в пункт Б в кратчайшие сроки и по доступной цене» критерии приёмки могут включать в себя:

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

Критерии приёмки помогают:

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

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

Пользовательские истории часто записываются с помощью специальной формулы:

> "Как [X], я хочу [Y], чтобы [Z]"

• X — это персонаж, от имени которого ведётся повествование. Это пользователь продукта. Это тот, для кого будет строиться функциональность.
• Y — это задача, действие или свойство, которое необходимо персонажу. Это то, что пользователь хочет сделать.
• Z — это причина, по которой пользователю необходимо выполнить задачу. Это то, что пользователь хочет получить в результате.

Например, пользовательская история «Как водитель, я хочу получить уведомление о заказе, чтобы быстро добраться до клиента» имеет следующую структуру:

• X — водитель.
• Y — получить уведомление о заказе.
• Z — быстро добраться до клиента.

Эта формула помогает создать чёткую и лаконичную пользовательскую историю.

Заключение: пользовательские истории и варианты использования — неотъемлемая часть успешной разработки 🌟

Пользовательские истории и варианты использования (Use Cases) — это мощные инструменты, которые помогают командам разработчиков создать действительно ценный продукт. Они помогают синхронизировать усилия, выделить ключевую функциональность и построить roadmap. Используя эти инструменты в комплексе, команда может создать продукт, который будет удобным, функциональным и полезным для пользователей.

Советы по использованию пользовательских историй и вариантов использования

• Пишите пользовательские истории простым и понятным языком.
• Используйте формулу "Как [X], я хочу [Y], чтобы [Z]"
• Добавляйте критерии приёмки (Acceptance Criteria) к каждой пользовательской истории.
• Создавайте карту пользовательских историй (User Story Map), чтобы визуализировать ценность продукта.
• Используйте Use Cases для детализации взаимодействия пользователя с системой.
• Регулярно пересматривайте и обновляйте пользовательские истории и Use Cases.

FAQ: часто задаваемые вопросы

• В чем разница между пользовательской историей и Use Case?
• Пользовательская история описывает ценность для пользователя, а Use Case — детали взаимодействия с системой.
• Как выбрать правильные критерии приёмки (Acceptance Criteria)?
• Критерии приёмки должны быть конкретными, измеримыми, достижимыми, релевантными и ограниченными во времени (SMART).
• Как использовать карту пользовательских историй (User Story Map)?
• Карту пользовательских историй можно использовать для планирования спринтов, приоритизации задач и визуализации дорожной карты продукта.
• Как создать Use Case?
• Use Case состоит из актёра, целей и шагов взаимодействия.
• Какие инструменты можно использовать для работы с пользовательскими историями и Use Cases?
• Существует много инструментов для работы с пользовательскими историями и Use Cases, например, Jira, Trello, Asana и др.

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