Як визначити складні бізнес-правила, використовуючи Історії користувачів?

Швидке та брудне визначення User Story :

"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. Деталі, що передбачають тестові випадки, відокремлені від самої історії. [ Майк Кон ]

   Ви можете додати на звороті сюжетної картки, зробити невеликі примітки, якщо вони дійсно важливі, або помістити їх у документ про прийняття тестів .

Як настанову для оцінки того, чи корисні ваші історії користувачів, ви можете дотримуватися пропозиції Білла Уейка :

• Я незалежний (з інших історій)
• N договірна
• V aluable (для користувача або замовника)
• E вражаючий (до хорошого наближення)
• S mall (достатньо для оцінки)
• Т маєток

Ви можете прочитати розділ 2 "Написання історій" книги "Прикладені історії користувачів" Майка Конна.

Як правило, на широкій, що охоплює історію користувача, яка має багато аспектів, я намагаюся отримати найзагальніший приклад історії, а потім для специфіки я створюю дочірні користувацькі історії, які успадковують її. Багато інструментів управління проектами Agile, як RallyDev, дозволяють вам це зробити легко, і я вважаю, що це має сенс.

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

Крайні деталі цих речей або химерні деталі бахроми, які я зазвичай визначаю в одній або декількох завданнях у цій історії користувача. Завдання допомагають визначити розробку та проектні роботи, які слід виконати (на загальному рівні) для задоволення цієї історії користувача (Наприклад, написати валідатор, щоб забезпечити введення в поле опису менше 50 символів ...) РЕДАКТУВАТИ: Я просто хотів додати що, мабуть, краще не допускати екстремальних деталей із історій користувачів, оскільки це, ймовірно, не те, про що користувач дійсно буде хвилювати. Користувачі хочуть пояснити програмне забезпечення в загальних рисах, і вони залежать від розробників програмного забезпечення, щоб з'ясувати та приховати деталі від них.

Це саме те, як я підходжу до проблеми, але я впевнений, що існує багато різних способів.

Відповідь проста, включіть ділові правила у критерії прийняття.

Тривіальний приклад лише для ілюстрації:

Як бібліотекар я хочу зареєструвати нові книги, щоб студенти могли знайти свою доступність в Інтернеті

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

Як визначити складні бізнес-правила, використовуючи Історії користувачів?

Це не те, для чого призначені історії користувачів. Вони не є вимогами до програмного забезпечення, які охоплюють усі деталі або бізнес-правила, необхідні для написання програми. Вони - лише опис того, що програма повинна робити з точки зору користувача.

Пам'ятайте, що важливо: створення належного програмного забезпечення. Ви використовуєте все, що потрібно для цього, і історії користувачів - це просто так, щоб переконатися, що ви зібрали необхідні функції, які має мати додаток, щоб потім ви могли про них поговорити, розставити їх пріоритети, оцінити їх і т.д. Відсутня частина класичного користувача історія (як ... я хочу ... щоб так) - це про спілкування між тими, хто бере участь у створенні програмного забезпечення.

Якщо деталізація є критеріями прийняття, підрозділами, технічними завданнями, що додаються до історії користувача, у документі із специфікацією чи будь-яким іншим, виходить за рамки того, що вам допомагає історія користувача. Користувач залишається лише «предметом» розмови, коли вирішує, як створити програмне забезпечення.

У наведеному прикладі є багато деталей реєстрації книг, про які розробники не знають мало, такі як Дьюї чи інші класифікаційні системи, ISBN, номери придбання, копії / назви / автори, інші видання тощо. Для нової системи такі деталі повинен надати замовник (і бібліотекар з усіх людей обов'язково про них піклується).

Цитуючи Стіва О'Коннелла, "Страшно роздумувати над тим, скільки бізнес-політики створюється розробниками, яким бракувало необхідних деталей у технічних характеристиках, і просто вони самі це придумували".