Гибкая разработка — это методология, ориентированная на итеративную и поэтапную разработку программных продуктов. Она акцентирует внимание на сотрудничестве между межфункциональными командами, постоянной обратной связи и гибкости при изменении требований на протяжении всего процесса разработки. Две популярные техники, используемые в гибкой разработке, — это истории пользователей и пользовательские сценарии. В этом всестороннем руководстве мы рассмотрим обе техники и утверждаем, что они обе подходят для гибкой разработки, если используются должным образом.
Истории пользователей
Истории пользователей — это краткие, простые описания функции, изложенные с точки зрения конечного пользователя.
Обычно они следуют определенному шаблону:
«Как [тип пользователя], я хочу [некоторая цель] чтобы [некоторая причина].”
Истории пользователей — это мощный инструмент в гибкой разработке, поскольку они помогают командам сосредоточиться на потребностях конечного пользователя и способствуют коммуникации и сотрудничеству между заинтересованными сторонами.
Пример: Допустим, наша команда разрабатывает новую платформу электронной коммерции.
История пользователя может выглядеть следующим образом:
«Как покупатель, я хочу мочь фильтровать результаты поиска по диапазону цен чтобы я мог найти товары в пределах моего бюджета.”
Почему это хороший выбор для гибкой разработки?
Истории пользователей — отличный выбор для гибкой разработки, поскольку они легкие, легко записываются и обеспечивают общее понимание того, что необходимо создать. Они также гибкие и могут легко изменяться на протяжении всего процесса разработки. Это делает их идеальным выбором для команд, ценящих сотрудничество, постоянную обратную связь и адаптивность.
Пользовательские сценарии
Пользовательские сценарии — это подробные описания поведения системы с точки зрения актора (обычно пользователя или другой системы). Обычно они состоят из серии шагов, которые пользователь выполняет для достижения конкретной цели, и описывают взаимодействие между пользователем и системой. Пользовательские сценарии являются важным инструментом в гибкой разработке, поскольку они помогают командам понять поведение системы и выявить потенциальные проблемы на ранних этапах разработки.
Пример: Давайте продолжим на примере нашей платформы электронной коммерции.
Пользовательский сценарий может выглядеть следующим образом:
«Покупатель ищет товар на платформе. Он применяет фильтр по цене и сортирует результаты по рейтингу клиентов. Он добавляет товар в корзину и переходит к оформлению заказа. После проверки деталей заказа он отправляет информацию о платеже и завершает покупку.»
Почему это хороший выбор для гибкой разработки?
Кейсы пользователей также являются отличным выбором для гибкой разработки, поскольку они обеспечивают детальное понимание того, как должна работать система. Они помогают командам выявлять потенциальные проблемы на ранних этапах разработки и обеспечивать соответствие системы потребностям конечного пользователя. Они также полезны для тестирования и проверки, что является важным аспектом гибкой разработки.
Сравнение пользовательских историй и кейсов пользователей
Хотя и пользовательские истории, и кейсы пользователей подходят для гибкой разработки, они различаются по нескольким аспектам. Пользовательские истории легкие и ориентированы на потребности конечного пользователя, в то время как кейсы пользователей более подробны и описывают поведение системы. Пользовательские истории обычно используются для фиксации высокого уровня требований, а кейсы пользователей — для описания конкретных взаимодействий между пользователем и системой.
В конечном счете выбор между пользовательскими историями и кейсами пользователей зависит от конкретных потребностей проекта. Пользовательские истории более подходят для проектов, где требования неясны или, скорее всего, будут меняться, тогда как кейсы пользователей более подходят для проектов, где требования четко определены и конкретны. На практике многие команды используют оба подхода, чтобы обеспечить полное понимание поведения системы и потребностей конечного пользователя.
Пример — интернет-магазин продуктов
Пример пользовательской истории: «Я — занятая мама, хочу иметь возможность создавать список покупок в приложении, чтобы легко отслеживать товары, которые мне нужно купить. Я также хочу иметь возможность добавлять и удалять товары из списка и отмечать товары как купленные, когда закончу покупки.”
В этой пользовательской истории мы описали конкретную функцию, которая отвечает потребностям конечного пользователя (занятых мам) и приносит им пользу (легко отслеживать свой список покупок). Пользовательская история написана с позиции конечного пользователя и использует конкретный шаблон для обеспечения ясности и согласованности.
Пример кейса пользователя: пользователь хочет создать новый список покупок в приложении. Он открывает приложение и переходит к функции списка покупок. Он нажимает кнопку «Создать новый список» и вводит название списка. Затем он начинает добавлять товары в список, нажимая кнопку «Добавить товар» и вводя название товара. Он также может указать количество или дополнительные заметки. Когда пользователь добавит все необходимые товары, он может сохранить список и вернуться к нему позже. Он также может отмечать товары как купленные, когда они уже приобретены.
В этом кейсе пользователя мы описали конкретную ситуацию, в которой пользователь взаимодействует с функцией списка покупок приложения. Мы описали шаги, которые предпринимает пользователь для достижения своей цели, а также взаимодействие между пользователем и системой. Кейс пользователя более подробный, чем пользовательская история, и обеспечивает полное понимание того, как должна работать функция.
Оба подхода — пользовательская история и кейс пользователя — полезны для гибкой разработки. Пользовательская история предоставляет обзор функции на высоком уровне и фокусируется на потребностях конечного пользователя, в то время как кейс пользователя предлагает более подробное описание поведения функции. Использование обоих подходов обеспечивает полное понимание командой разработки функции и потребностей конечного пользователя, что является ключевым для успешной гибкой разработки.
Детализация пользовательской истории с помощью 3C
вот возможный анализ 3C для примера пользовательской истории:
- Карточка: «Я — занятая мама, хочу иметь возможность создавать список покупок в приложении, чтобы легко отслеживать товары, которые мне нужно купить. Я также хочу иметь возможность добавлять и удалять товары из списка и отмечать товары как купленные, когда закончу покупки.»
- Разговор:
- Продуктовый владелец: «Можете рассказать подробнее, почему вам нужно отслеживать свой список покупок?»
- Занятая мама: «Конечно, как мама с загруженным графиком, мне нужно убедиться, что я ничего не забуду, когда пойду в магазин. Было бы очень полезно, если бы я мог легко создавать список покупок на своем телефоне и добавлять или удалять товары по мере необходимости.»
- Продуктовый владелец: «Понял. А насколько важно для вас отмечать товары как купленные?»
- Занятая мама: «Это важно, потому что тогда я быстро могу увидеть, что уже купил, и что еще нужно приобрести.»
- Подтверждение: «Как занятая мама, я могу создавать список покупок в приложении, добавлять и удалять товары из списка, а также отмечать товары как купленные, когда закончу покупки.»
Детализация кейса пользователя с описанием кейса
вот пример описания кейса пользователя, основанный на описании проблемы и пользовательской истории:
Название кейса: Создание и управление списком покупок
Участники:
- Пользователь: человек, который хочет создавать и управлять списком покупок в приложении.
Предусловия:
- Пользователь загрузил и установил приложение на свое мобильное устройство.
- У пользователя есть стабильное интернет-соединение.
Постусловия:
- Пользователь успешно создал и управлял списком покупок в приложении.
Последовательность событий:
- Пользователь открывает приложение и переходит к функции списка покупок.
- Приложение отображает список существующих списков покупок или предлагает пользователю создать новый список.
- Пользователь нажимает кнопку «Создать новый список».
- Приложение предлагает пользователю ввести название нового списка.
- Пользователь вводит название нового списка и нажимает «Сохранить».
- Приложение отображает пустой список покупок с названием, которое ввёл пользователь.
- Пользователь нажимает кнопку «Добавить элемент».
- Приложение предлагает пользователю ввести название элемента, который нужно добавить в список.
- Пользователь вводит название элемента и нажимает «Добавить».
- Приложение отображает новый элемент в списке покупок.
- Пользователь повторяет шаги 7–10, пока не добавит все необходимые элементы в список.
- Пользователь может удалить элемент из списка, нажав кнопку «Удалить элемент» рядом с элементом.
- Пользователь может отметить элемент как купленный, нажав кнопку «Отметить как купленный» рядом с элементом.
- Приложение обновляет список покупок, чтобы отразить все изменения, внесённые пользователем.
- Пользователь может в любой момент просмотреть список покупок, перейдя обратно к функции списка покупок в приложении.
Альтернативные потоки:
- Если пользователь отменяет создание нового списка на шаге 5, приложение возвращает пользователя к списку существующих списков покупок или предлагает создать новый список снова.
- Если пользователь отменяет добавление нового элемента на шаге 9, приложение возвращает пользователя к списку покупок без добавления элемента.
Различия между пользовательскими историями и сценариями использования
В таблице приведено краткое описание различий между пользовательскими историями и сценариями использования. Пользовательские истории — это краткие, простые описания, ориентированные на цели и потребности пользователя, в то время как сценарии использования содержат подробные пошаговые описания поведения системы и её функциональности.
| Пользовательские истории | Сценарии использования |
|---|---|
| Краткое, простое описание функции с точки зрения пользователя. | Подробные пошаговые описания взаимодействия пользователя с системой. |
| Ориентированы на цели и потребности пользователя. | Ориентированы на поведение и функциональность системы. |
| Подчёркивают диалог и взаимодействие между заинтересованными сторонами. | Акцентируйте более формализованный, структурированный подход. |
| Часто пишется в более неформальном, разговорном стиле. | Часто пишется в более формализованном, техническом стиле. |
| Обычно используется для фиксации высокого уровня требований и функций. | Обычно используется для фиксации детальных функциональных требований. |
| Обычно проще и быстрее писать и проверять. | Обычно требует больше времени на написание и проверку. |
Краткое содержание
В статье рассматривается использование пользовательских сценариев и случаев использования в гибкой разработке, утверждая, что оба подхода подходят при правильном применении. Пользовательские сценарии — это краткие, простые описания функции с точки зрения пользователя, тогда как случаи использования предоставляют подробное пошаговое описание того, как пользователь взаимодействует с системой.
В качестве примера используется задача создания и управления списком покупок, чтобы проиллюстрировать, как можно использовать оба подхода. В статье подчеркивается важность 3Cs (карточка, разговор, подтверждение) при создании эффективных пользовательских сценариев и важность участников, предусловий и постусловий при создании эффективных случаев использования. В целом, статья представляет всестороннее руководство для разработчиков программного обеспечения по эффективному использованию пользовательских сценариев и случаев использования в гибкой разработке.
В заключение, пользовательские сценарии и случаи использования являются ценными инструментами в гибкой разработке при правильном применении. Пользовательские сценарии легкие, простые в написании и гибкие, что делает их идеальными для проектов с изменяющимися требованиями. Случаи использования подробны и обеспечивают полное понимание поведения системы, что делает их идеальными для проектов с четко определенными требованиями. Используя оба метода, команды гибкой разработки могут обеспечить полное понимание поведения и целей системы.