В гибком dev, как Вы организуете пользовательские истории? [закрытый]

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

Каждая задача теперь написана таким образом, чтобы ее можно было напрямую преобразовать в тест «спецификации» в стиле BDD, который устанавливает контекст, выполняет вызывающее беспокойство действие и проверяет соответствие наблюдения. (Прекрасный пример того, как это работает с xUnit.NET, см. На этом сайте .)

При создании пользовательских историй важно не мыслить слишком технически. На самом деле вы не хотите разбивать свои истории на высокотехнологичные и низкоуровневые вещи, такие как «Создайте веб-страницу с заголовком 'xyz'. Покажите на этой странице магазины a, b и c». Это супертехнологично и на самом деле не отображает никаких полезных бизнес-требований. История должна быть более плавной и динамичной и отражать реальные бизнес-требования: " Миниатюра должна перенаправить меня на страницу веб-сайта магазина, содержащую продукт, который искал пользователь

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

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

Разделение пользовательских историй по «веб-страницам» кажется мне неоптимальным - вы должны выбирать набор своих страниц на основе пользовательских историй, а не наоборот. Я бы классифицировал по «роли» пользователя - фактически, в ориентированном на пользователя дизайне, по « персона » в игре.

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

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

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

это вполне предсказуемо. Пользователь входит на сайт с определенной задачей в голове и хочет выполнить эту задачу.

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

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

это вполне предсказуемо. Пользователь входит на сайт с определенной задачей в голове и хочет выполнить эту задачу.

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

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

пользователь проверяет, конец.

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

пользователь проверяет, конец.

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

В нашем магазине мы пишем сценарии использования . Примеры использования:

Create New Customer Account
Assign User Rights
Receive Order
Accept Payment

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

Затем на основе вариантов использования мы начинаем набрасывать веб-страницы.

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

We group them by feature - or better - Minimum Marketable Feature (MMF) so that there add value to the product. Indeed, for instance, there is no way to show something that cannot be created, or to create something that cannot be seen yet. So we group the creation/display so that there are delivered together. Updates and deletions can come later, YMMV.