Как определить сложные бизнес-правила с помощью пользовательских историй?

Быстрое и грязное определение истории пользователя :

"As a <role>, I want <goal/desire> so that <benefit>"

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

Тривиальный пример просто для иллюстрации:

"As a <librarian>, I want to <register new books> so that
<students can find their availability online>"

В этом глупом примере, где можно определить поля, необходимые при регистрации книги? Должно ли это быть написано где-нибудь? Или владелец продукта должен передать необходимые бизнес-правила в устной форме?

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

История пользователя - Обещание поговорить - это запись в блоге об этом.

У вашего тривиального примера есть пара моментов, которые я не знаю, насколько хорошо вы заметите это. Что значит «регистрировать новые книги»? Что такое «Найти их онлайн?» Именно здесь начинается разговор, и после того, как история закончена, могут появиться новые истории, поскольку, возможно, эти регистрации должны храниться в файле или отчеты должны периодически создаваться.

Предыдущие ответы дают действительные аргументы, особенно в отношении того, что пользовательская история является напоминанием для разговора . Другие вещи для рассмотрения:

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

2. Детали, которые подразумевают контрольные примеры, отделены от самой истории. [ Майк Кон ]

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

В качестве ориентира, чтобы оценить, насколько хороши ваши пользовательские истории, вы можете последовать предложению Билла Уэйка :

• Я независим (от других историй)
• По договоренности
• V доступно (для пользователя или клиента)
• E stimable (в хорошем приближении)
• S торговый центр (достаточно, чтобы быть оцененным)
• T ESTABLE

Возможно, вы захотите прочитать главу 2 «Написание историй» книги «Прикладные пользовательские истории» Майка Кона.

Обычно в широкой охватывающей пользовательской истории, которая имеет много аспектов, я пытаюсь получить наиболее общий пример истории, а затем для деталей я создаю дочерние пользовательские истории, которые наследуются от нее. Многие инструменты Agile для управления проектами, такие как RallyDev, позволяют вам легко это делать, и я считаю, что это имеет смысл.

Регистрация новых книг обширна, поэтому, возможно, есть еще 10 детских историй о том, как <role>бы книги были зарегистрированы.

Чрезвычайные подробности этих вещей или причудливые незначительные детали, которые я обычно определяю в одной или нескольких задачах в этой пользовательской истории. Задачи помогают определить работу по разработке и дизайну, которая должна быть выполнена (на общем уровне), чтобы соответствовать этой пользовательской истории (например, написать валидатор, чтобы обеспечить ввод в поле описания менее 50 символов ...) РЕДАКТИРОВАТЬ: я просто хотел добавить что, вероятно, лучше избегать экстремальных подробностей из пользовательских историй, потому что это, вероятно, не то, что пользователь действительно будет сильно волновать. Пользователи хотят объяснять программное обеспечение в общих чертах, и они зависят от разработчиков программного обеспечения, чтобы выяснить и скрыть детали от них.

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

Ответ прост, включить бизнес-правила в критерии приемлемости.

Тривиальный пример просто для иллюстрации:

Как библиотекарь, я хочу зарегистрировать новые книги, чтобы студенты могли найти их в Интернете

Я буду удовлетворен, когда: * Я могу зарегистрировать следующие поля: - ISDN - Автор - Дьюи Десятичный бла-бла * Я вижу подтверждение, что книга была зарегистрирована системой * Я могу просмотреть книгу в системе

Как определить сложные бизнес-правила с помощью пользовательских историй?

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

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

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

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

По словам Стива О'Коннелла: «Страшно созерцать, сколько бизнес-политики создают разработчики, которым не хватало необходимой детализации в спецификациях, поэтому просто придумал это для себя».