DoD, DoR та AC

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

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

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

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

Маленька ремарка – здебільшого DoD, DoR та AC використовують стосовно вимог, але поняття DoD, DoR можна використовувати і по відношенню до спринту чи релізу.

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 може виглядати приблизно так:

1) Для користувацької історії:

• Користувацькі історії створено в JIRA (системі, у якій ведеться проект).
• Користувацькі історії містять базовий опис функціональності для комерційних цілей. Ідеально у форматі: “Як <тип користувача>, я хочу <якусь мету> так, щоб <якась причина>”.
• До користувацької історії було додано принаймні один АС.
• Користувацька історія прилінкована до відповідного епіка (до укрупненої користувацької історії).
• Визначено, хто буде власником продукту для користувацької історії / епіка.
• Визначено пріоритет користувацької історії: обов’язково має бути / гарно було б мати / і т.д.
• Команді розробки описано технічну реалізацію та створено підзавдання.
• Розробники дали оцінку тривалості та складності розробки.
• Написано сценарії для тестування.
• DoD обговорюється та підтверджується разом із власником продукту.
• Користувацька історія може бути взята у беклог (це повний список робіт, які потрібно виконати).

2) Для Спринту:

• У беклозі спринту є принаймні з одна користувацька історія, яка відповідає DoR.
• Пропускна здатність команди узгоджена з тривалістю Спринту (це одна ітерація циклу розробки програмного забезпечення в скрамі).
• Власник продукту може відвідати необхідні події і готовий відповісти на запитання / перевірити / затвердити користувацькі історії / оновити беклог.
• Спринт сплановано.
• Необхідні події спринту заплановані й внесено до календаря (щоденна п’ятнадцяти хвилинна зустріч, зустріч-огляд спринту, ретроспективна зустріч по спринту).
• Команда потенційно може розпочати розробку.

3) Для релізу:

• Беклог релізу створено.
• Власника продукту визначено і всі комунікації заплановано.
• Розпочато аналіз прогалин.
• Середовища для розробки готові.
• План релізу узгоджено.

DEFINITION OF DONE

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

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

Цілі DoD:

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

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

1) Для користувацької історії:

• Усі питання були задані та роз’яснені бізнес-аналітиками та власником продукту.
• Усі очікувані випадки поведінки та використання були перераховані в описі.
• Усі АС користувацької історії перераховані в описі до неї.
• Власник продукту затвердив очікувану поведінку та АС історії.
• Дизайн для нових полів та компонентів схвалений Власником продукту.
• Всі підзавдання розроблені та перевірені.
• Користувацька історія розгорнута в середовищі інтеграції.
• Користувацька історія перевіряється за сценаріями тестування / АС.
• Користувацька історія відповідає усім АС.
• Користувацька історія була показана та перевірена власником продукту.
• Жодні критичні / основні дефекти чи баги не залишаються невирішеними.

2) Для Спринту:

• Відбулася зустріч-огляд спринту та демонстрація зробленого.
• Проведена ретроспектива спринту та список майбутніх дій задокументовано.
• Жодних блокаторів не існує.
• Користувацькі історії відповідають всім критеріям DoD та розгорнуті в середовищі для тестування.
• Весь інкремент потенційно може бути інтегровано.
• Можна розпочати наступний спринт.

3) Для релізу:

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

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) мають на меті зробити роботу команди розробки та бізнесу максимально прозорою та продуктивною. Їх визначення на кожному конкретному проекті/продукті/в команді значно прискорює процес обговорення вимог та демо продукту. Допомагають знайти спільну мову та виробити спільне бачення розробки.