Към съдържанието
wannacode

Критерии за приемане

Накратко: Критериите за приемане казват кога сторито е готово, преди работата да започне. Най-добри са като правило с конкретни примери: „безплатна от 50,00 €“ плюс „49,99 € → 4,90 €, 50,00 € → 0,00 €“. Definition of Done е общото мерило за всяко стори, а Definition of Ready е практика на екипите, не част от Scrum Guide.

Проблем

Отказът, който работи винаги

Сторито е „Като клиент искам да откажа поръчката си, за да не плащам за нещо, което вече не искам.“ Програмистът слага бутон „Откажи“ на всяка поръчка. QA проверява: натискаш, поръчката става отказана. Минава.

След седмица клиент отказва поръчка, която вече е при куриера. Парите му се връщат, а пратката пристига при него. Складът пита кой е решил, че изпратена поръчка може да се откаже.

Никой не го е решил. Никой не е записал кога отказът е позволен. Сторито имаше карта и малко разговор, но нямаше потвърждение.

Идеята

Кога сторито е готово

Критериите за приемане (acceptance criteria) са условията, които сторито трябва да изпълни, за да бъде прието. Те са третото C, потвърждението, записано.

За отказа на поръчка:

  • Нова поръчка може да се откаже.
  • Платена поръчка може да се откаже, преди да е изпратена. Парите се връщат на клиента.
  • Изпратена, доставена или върната поръчка не може да се откаже. Клиентът вижда защо и как да върне продукта.

Три реда, и бъгът от началото нямаше да се случи. Програмистът щеше да знае какво да прави, QA какво да провери, а собственикът какво приема.

Критериите са за едно стори. Пишат се преди работата, заедно: бизнесът, QA и програмистът. Написани след нея, те описват какво е направено, а не какво е трябвало.

Идеята

Правило и пример

Правилото само не стига. „Доставката е безплатна от 50 €“ двама души четат по два начина. Затова до всяко правило се слагат примери с конкретни числа:

Правило: доставката е безплатна при поръчка от 50,00 € включително, иначе е 4,90 €.

  • Количка за 49,99 €: доставката е 4,90 €.
  • Количка за 50,00 €: доставката е безплатна.

Правило: промо кодът не важи за намалени продукти.

  • Тениска за 20,00 € и дънки в намаление за 40,00 €. С ЕСЕН10 отстъпката е 2,00 €, не 6,00 €.

Примерът се чете по един начин. Никой не може да го разбере погрешно, а ако правилото е грешно, примерът го показва: собственикът поглежда 49,99 € и казва „не, искам и тя да е безплатна“.

Запомни формата правило и пример. В следващия модул тя става сценарий на Gherkin: там има ключова дума „Правило“, а под нея идват примерите като сценарии. Тук още няма синтаксис, само навикът.

По-точно, за любопитните

ISTQB CTFL v4.0.1 (раздел 4.5.2) описва два основни формата на критериите: ориентиран към сценарии (scenario-oriented), с „Дадено / Когато / То“, какъвто ползва BDD, и ориентиран към правила (rule-oriented): списък за проверка или таблица вход → изход. Правилото с примери е мостът между двата.

Идеята, че примерите са най-ясната спецификация, е в основата на книгата „Specification by Example“ на Гойко Аджич (2011). В повечето източници примерите, които показват правилото, се наричат ключови примери (key examples): не всички възможни, а тези, които правят разлика.

Другите програми, към които е съобразен курсът, казват същото със свои думи. ISTQB CT-AcT v1.0 (приемно тестване) е писана заедно с борда по бизнес анализ IQBBA и разглежда как анализаторът и тестерът заедно стигат от изискването до критериите и приемните тестове. В BABOK v3 на IIBA сторитата (User Stories) и критериите (Acceptance and Evaluation Criteria) са отделни техники, а Agile Extension към BABOK е за бизнес анализа в гъвкави екипи.

Пробвай

Кой критерий става?

1. Сторито: „Като клиент искам безплатна доставка при по-голяма поръчка.“ Кой критерий става?
2. Сторито: „Като клиент искам да ползвам промо код.“ Кой критерий казва поведение, а не екран?
3. Сторито: „Като клиент искам да откажа поръчката си.“ Кой критерий се забравя най-често?
4. Кой критерий е проверим?

Идеята

Добрият критерий

Критерият за приемане е изискване в малко, затова качествата от урока „Доброто изискване“ важат и тук. Най-важните:

  • Проверим. Може да падне на тест. „Правилно“, „бързо“, „удобно“ не могат.
  • За поведение, не за екран. „Кодът дава 10 %“, не „зелен бутон под сумата“. Как изглежда, решава екипът.
  • С отрицателните случаи. Какво не е позволено и какво вижда клиентът тогава. Отказът след изпращането е точно такъв.
  • С границата. 49,99 и 50,00 €. 14-ият и 15-ият ден. Грешките живеят около границите.

И едно правило за броя. Ако критериите стават петнайсет, сторито е твърде голямо. Много критерии значи много правила, а много правила е сигнал за разбиване.

Идеята

Definition of Done и Definition of Ready

Критериите са за едно стори. Има и мерила, които важат за всяко стори.

Definition of Done (дефиниция за готово) е списъкът, който екипът изпълнява за всяка промяна, каквато и да е. Например:

  • всички критерии за приемане са проверени;
  • тестовете минават;
  • друг човек от екипа е прегледал промяната;
  • помощната страница е обновена, ако нещо видимо се е сменило.

Сторито е готово, когато е изпълнило и своите критерии, и Definition of Done.

Definition of Ready (дефиниция за готовност) е обратната проверка, преди работата: сторито има роля и полза, критерии с примери, няма отворени въпроси, побира се в няколко дни.

Тук е честото объркване. Scrum Guide дефинира само Definition of Done, като задължение за всяка готова част от продукта. Definition of Ready не е в Scrum Guide. Тя е практика, която много екипи са приели сами. Полезна е, докато е списък за разговор. Ако стане порта, през която сторито не минава без подпис, работата пак тръгва бавно.

По-точно, за любопитните

Scrum Guide (изданието от 2020 г.) описва Definition of Done като формалното описание на състоянието на частта от продукта (Increment), когато тя отговаря на нужното качество. За готовността казва само, че елементите от списъка (Product Backlog), които екипът може да направи за един спринт, се смятат за готови да бъдат избрани. Отделен списък с име Definition of Ready няма.

Пробвай

Кое е кое?

1. „Промо кодът не важи за намалени продукти.“
2. „Всички критерии за приемане са проверени и тестовете минават.“
3. „Сторито има критерии с примери и няма отворени въпроси, преди да влезе в работа.“
4. „Друг човек от екипа е прегледал промяната, преди да се пусне.“

Упражнение

Критериите в работа

1. От нуждата до приемането. Подреди пътя на едно стори.

Подреди стъпките от нуждата до приетото стори.

  1. Собственикът приема сторито
  2. Собственикът казва нуждата
  3. Проверявате по критериите
  4. Разговаряте: правила, примери, въпроси
  5. Екипът прави сторито
  6. Записвате сторито: роля, цел, полза
  7. Записвате критериите за приемане

2. Липсващият пример. Всяко правило има примери, но не тези, които правят разлика.

1. Правилото: „Връщане до 14 дни от получаването.“ Примерите: получена на 1 октомври, заявена на 10 октомври, приема се. Кой пример липсва най-много?
2. Правилото: „Доставката е безплатна от 50,00 € включително.“ Примерите: 30,00 € → 4,90 €, 80,00 € → 0,00 €. Кой пример ще хване „над 50“ вместо „от 50“?
3. Правилото: „Промо кодът не важи за намалени продукти.“ Примерът: тениска за 20,00 €, с ЕСЕН10 струва 18,00 €. Какво липсва?

Тест

Провери се

1. Кога се пишат критериите за приемане?
2. Защо „правило и пример“ е по-силно от само правило?
3. Каква е разликата между критерий за приемане и Definition of Done?
4. Кое е вярно за Definition of Ready?
5. Сторито има 18 критерия за приемане. Какво подсказва това?

Създаден от Иво Гергов като част от кампанията на Evo Tech за достъпно обучение по програмиране ·