• DoD, DoR та AC

    DoD, DoR та AC

DoD, DoR та AC

Як часто Ви говорили клієнту, що користувацька історія готова, а він не погоджувався з вами?

Ми з такими випадками зіштовхувались досить часто. А все тому, що бізнес та команда розробки мали різні поняття “Зробленого”. Щоб уникнути таких ситуацій радимо обговорити з командою що таке:

  • DoR (Definition of Ready) — визначення “Готової” користувацької історії
  • DoD (Definition of Done) — визначення “Виконаної” роботи
  • AC (Acceptance Criteria) — критерії прийняття користувацької історії чи задачі.

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

DEFINITION OF READY

Це список вимог до КОЖНОЇ користувацької історії перед її реалізацією у наступному спринті. Часто ним слугує абревіатура «INVEST» (independent, negotiable, valuable, estimable, small and testable):

  • Independent (Незалежна) — відсутність залежностей між цією вимогою та іншими, які беруться в один спрінт. Це допомагає уникнути “ефекту доміно”: через невиконання однієї вимоги не виконуються й інші з цього спрінта, оскільки було багато залежностей між ними. На практиці це буває складно виконати, тому часто намагаються хоча б зменшити кількість залежностей між вимогами.
  • Negotiable (Є предметом переговорів). Історія повинна спонукати обговорення, а не слугувати певним контрактом, де все зафіксовано. Ці обговорення зазвичай  ведуться під час командних сесій (PBR — Product Backlog Refinement).
  • Valuable (Цінна). Кожна вимога має нести цінність для бізнесу та кінцевого користувача. Це не просто протестувати або зробити back-end частину. У класичному форматі User Story: “As a User I want to … so that …” це вказується наприкінці, після “so that”. «Як Користувач Х, я хочу функціонал Y, щоб отримати цінність Z».
  • Estimable (Піддається оцінці). Вимога має бути настільки малою та зрозумілою, щоб команда розробки могла її оцінити. Якщо команда не може цього зробити, то задають Product owner (власнику продукта) уточнювальні питання, переформульовують саму історію, розбивають її на менші. Також можна виділити невелику технічну задачу — Spike, результати якої допоможуть дати оцінку самій користувацькій історії.
  • Small (Маленька) — повинна бути досить невелика для реалізації протягом короткої ітерації (спрінта). Якщо історія завелика — її розбивають на менші.
  • Testable (Її можна протестувати). Команда має розуміти історію настільки добре, щоб могти її протестувати.

Зауважте, що DoR НЕ є частиною посібника зі Scrum (Скраму). Їх не ​​слід використовувати як додаткову фазу перед плануванням спринту. Це — додаткові критерії для Scrum команди та Product Owner під час Product Backlog Refinement для кращого розуміння вимог.

Тільки користувацькі історії, які відповідають всім пунктам DoR, будуть обрані для реалізації в спринті. Часто команди починають з порожнього DoR та додають до нього чекпоінти в процесі роботи, коли зіштовхуються на ретроспективах із проблемами не якісних та “сирих” вимог.

Типовий DoR може виглядати приблизно так:
  • Product Owner та Команда Розробки обговорили цю вимогу хоча б один раз;
  • Вимога має чітку бізнес-цінність;
  • Вимога має принаймні один АС;
  • Описані функціональні вимоги, бізнес-логіка: створення системи, права користувачів, джерела даних, повідомлення про помилки, альтернативні сценарії;
  • Є дизайн для всіх пристроїв, які підтримує продукт;
  • Описані нефункціональні вимоги;
  • Команда розуміє як розробляти і тестувати користувацьку історію;
  • Вимога оцінена і її можна зробити за один спринт.

DEFINITION OF DONE

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

Він є однаковим для ВСІХ історій.

Цілі DoD:

  • Побудувати у Команді спільне розуміння щодо прийнятної якості та готовності функціоналу;
  • Використовувати як контрольний список для перевірки всіх історій;
  • Перевірити, що весь інкремент має високу якість.

Ось приклад DoD з реального проекту:

  • код написаний;
  • юніт-тести написані і успішно виконані;
  • функціональне тестування успішно завершене;
  • код пройшов ревю;
  • документація оновлена;
  • регресійне тестування успішно завершено.

ACCEPTANCE CRITERIA

Це набір сценаріїв до КОНКРЕТНОЇ вимоги. Їх проходження є підтвердженням того, що функціонал працює як очікувалося бізнесом.

Цілі Acceptance Criteria:

  • Уточнити, що повинна будувати команда перед початком роботи;
  • Переконатись, що всі мають спільне розуміння;
  • Допомогти членам команди дізнатися, коли історія завершена;
  • Допомогти перевірити конкретну історію за допомогою автоматизованих тестів.

На малюнку нижче показаний приклад користувацької історії (User Story) з Acceptance Criteria: 

Джерело https://agileusa.wordpress.com/2018/03/03/how-to-write-a-user-story/

Як DoD (Definition of Ready), DoD (Definition of Done) так й AC (Acceptance Criteria) мають на меті зробити роботу команди розробки та бізнесу максимально прозорою та продуктивною. Їх визначення на кожному конкретному проекті/продукті/в команді значно прискорює процес обговорення вимог та демо продукту. Допомагають знайти спільну мову та виробити спільне бачення розробки.

 

Узнайте, что нового!
Никакого спама, никогда!