Як боротися з історіями, які поділяють функціональність

У мене дві історії (я знаю, що у них відсутня пільгова частина)

1. Як користувач з управління кредитами, я можу переглянути поточні та попередні відмінності в оплаті праці для офісів.
2. Як користувач з управління кредитами, я можу отримати електронний лист, що містить PDF поточної та попередньої різниці в оплаті праці для офісів.

Вони пов'язані між собою тим, що вони мали б однакові критерії запиту / фільтра. Єдина відмінність полягає в тому, що в історії «Перегляд» результати відображаються Користувачеві, а в історії «Електронна пошта» результати записуються у PDF, який надсилається електронною поштою Користувачеві.

Я борюся з відокремленням спільних аспектів цих двох історій або якщо я навіть повинен це зробити.

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

Чи слід відокремлювати запит на іншу історію, суто технічну?

Створення PDF-файлу та надсилання електронного листа слід здійснювати в режимі офлайн, чи це має стати технічною історією?

Я міг бачити розбиття цих двох історій на 2 функціональні історії та 2 технічні історії.

1. Як Система, я можу розрахувати різниці в поточній та попередній заробітній платі для Офісів.

2. Як користувач з управління кредитними даними, я можу бачити відмінності в поточній та попередній заробітній платі для офісів.

3. Як Система, я можу створити документ PDF про відмінності в поточній та попередній заробітній платі для Офісів.

4. Як користувач Кредитного управління, я можу подати запит на отримання електронного листа, що містить PDF-файл про відмінності в поточній та попередній заробітній платі для офісів.

Проблема, до якої я все-таки повертаюся, полягає в тому, що 4 історії не є незалежними і не "нарізають торт".

Тож я не зовсім впевнений, як боротися з цими двома.

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

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

Не: Спробуйте і розділіть історії, зробіть одну історію, а потім іншу.

Зробіть: Переконайтесь, що команда розробників знає другу історію.

Проблема з спробою спланувати детальні завдання та скласти загальну модель, яка може впоратися з обома елегантно, полягає в тому, що це важко.

Метою розповідей користувачів є завершення роботи. Елегантність є вторинною метою і її слід залишити на рефакторинг.

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

За жорстокою згодою з Робертом Харві, мета розповіді користувачів полягає в тому, щоб зрозуміти, що потрібно робити користувачеві. Під час догляду за покупцем клієнт розуміє і піклується про історію користувача, але розробники піклуються про трохи більше. Після того, як ви задасте достатньо питань, щоб зрозуміти та оцінити роботу, ви можете створити завдання для їх підтримки.

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

Важливі речі, які слід додати до історії користувача, це:

• Критерії приймання
• Припущення

Строго кажучи, Історії користувачів - це обіцянка бесіди, щоб зрозуміти необхідний результат.

Наприклад, взяти другу історію користувача

Як користувач з управління кредитами, я можу отримати електронний лист, що містить PDF поточної та попередньої різниці в оплаті праці для офісів.

Подумайте про наступне:

• Що таке "потреба" користувача, яка визначає цю вимогу? (Чи надходить PDF-лист в електронному листі як рішення від них? Це може не відповідати потребам, і ваша команда може придумати краще рішення)
• Який мінімальний фрагмент може вирішити "потребу" користувача та підтвердити ваше рішення? Короткі петлі зворотного зв'язку є цінними.

Підходячи до розбиття історії, пам’ятайте про свої критерії ІНВЕСТу, де це можливо.

1. Я не залежний
2. N договірний
3. V aluable
4. E вражаючий
5. S mall
6. Т маєток

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

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

TL; DR

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

Історії повинні бути відкладені до ітераційних завдань

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

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

Завдання Реалізація розповідей

Ось ще один спосіб продумати планування залежності для розповідей користувачів. Загалом:

1. Епопея / тема використовується для довгострокового планування чи групування за відстані.
2. Історія користувача використовується для передачі цілей, контексту та сфери застосування.
3. Своєчасне планування використовується для розробки реалізації, що відповідає одній ітерації.
4. Завдання реалізують заздалегідь заданий план, який відповідає Визначенню виконано для однієї або декількох історій користувача.

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