Kryteria akceptacji: jak je sformułować

Kryteria akceptacji to test określający, czy dana historia została zaliczona czy odrzucona, sporządzany przed rozpoczęciem prac: obejmują one poprawnie działające formaty, przykłady zrealizowanych rozwiązań oraz wskazują, czym różnią się one od definicji „zakończenia”.

Kryteria akceptacji to warunki, które musi spełnić dana historia, aby została zaakceptowana: test typu „zaliczony/niezaliczony”, sporządzony przed rozpoczęciem pisania kodu przez kogokolwiek. Nie ma możliwości uzyskania częściowej oceny: każdy warunek jest spełniony lub nie. Opisują one, co musi robić wynik, a nie jak go zbudować. Stanowią one test, a nie drugą wersję opisu funkcji. Jeśli można je spełnić za pomocą kodu, który nie rozwiązuje problemu, nie są to kryteria akceptacji; są to wymagania w przebraniu.

Każda historia niesie ze sobą domyślne pytanie: skąd będziemy wiedzieć, że jest zakończona? Kryteria akceptacji udzielają na nie jasnej odpowiedzi jeszcze przed rozpoczęciem prac. Jeśli zostaną one właściwie sformułowane, oszacowanie staje się łatwiejsze, prezentacja przygotowuje się niemal sama, a kwestia „zakończenia” przestaje być przedmiotem negocjacji. Jeśli natomiast będą one niejasne, dostarczą Państwo funkcję, co do której nikt się nie zgodził.

Czym są kryteria akceptacji, a czym nie są

Dobre kryterium akceptacji to takie, które można przekazać testerowi, który nigdy nie uczestniczył w Państwa spotkaniu poświęconym dopracowywaniu wymagań, a mimo to będzie on dokładnie wiedział, co ma sprawdzić. Opisuje ono rezultat, który użytkownik może zaobserwować, a nie samą implementację, która go generuje. „Wykorzystanie pamięci podręcznej Redis” nie jest kryterium akceptacji; jest to rozwiązanie. „Wyniki ładują się w mniej niż sekundę w przypadku tabeli zawierającej 10 000 wierszy” – to już jest kryterium akceptacji, ponieważ każdy może to przetestować i nikt nie musi w tym celu zapoznawać się z kodem.

Nie są to również po prostu lista życzeń. Każde kryterium musi dać się obalić. Jeśli danego stwierdzenia nie da się zweryfikować („strona jest intuicyjna”, „wydajność jest dobra”), nie jest to kryterium, lecz nadzieja. Należy je usunąć lub sprawić, by dało się je zmierzyć.

Dwa formaty, które się sprawdzają

W przypadku zachowań zależnych od stanu należy stosować schemat Given/When/Then, a w przypadku zestawu niezależnych wymagań – zwykłą listę kontrolną. Większość zespołów stosuje schemat Given/When/Then we wszystkich sytuacjach; proszę się temu opierać. Lista kontrolna jest szybsza w czytaniu i trudniej ją nadmiernie rozbudować, gdy opowieść sprowadza się po prostu do stwierdzenia: „te pięć rzeczy musi być spełnionych”.

Jeśli / Gdy / Wówczas

Przy założonym stanie początkowym, gdy użytkownik wykonuje jakąś czynność, system reaguje w określony sposób. Format ten sprawdza się, ponieważ wymaga od Państwa określenia wszystkich trzech elementów (warunku wstępnego, czynnika wyzwalającego oraz obserwowalnego wyniku), a właśnie te elementy pomija nieprecyzyjne kryterium.

Przykłady kryteriów akceptacji

Opis procesu logowania, przedstawiony w formacie „Given/When/Then”:

  • Jeżeli na stronie logowania znajduje się zarejestrowany użytkownik, gdy wprowadzi on prawidłowy adres e-mail i hasło, wtedy zostanie przekierowany na swój pulpit nawigacyjny.
  • Jeśli zarejestrowany użytkownik wprowadzi trzykrotnie nieprawidłowe hasło, wówczas konto zostanie zablokowane na 15 minut, a użytkownik zobaczy, ile czasu pozostało do odblokowania.
  • Jeśli na stronie logowania pole adresu e-mail jest puste, wówczas przycisk „Prześlij” jest nieaktywny.

Opis funkcji „filtrowania tabeli wyników”, przedstawiony w formie listy kontrolnej:

  • Filtr jest stosowany po zaznaczeniu, bez oddzielnego przycisku „Zastosuj”.
  • Dwa filtry łączą się za pomocą operatora „AND”, a nie „OR”.
  • Wyczyścić wszystkie filtry powoduje przywrócenie pełnej, nieposortowanej listy.
  • Pusty zestaw wyników oznacza stan „brak wyników”, a nie pustą tabelę.

Proszę zwrócić uwagę na to, czego w obu przypadkach pominięto: bazę danych, framework oraz nazwy komponentów. Określają one, co otrzymuje użytkownik, a nie w jaki sposób ma to zostać zrealizowane. Każda z tych pozycji stanowi element, który tester może uznać za zaliczony lub niezaliczony bez konieczności zadawania Panu dodatkowych pytań.

Jak sformułować kryteria akceptacji

  • Proszę je sporządzać podczas dopracowywania backlogu, wspólnie z zespołem, a nie samodzielnie po zakończeniu tego etapu.
  • W każdym wierszu może znajdować się tylko jeden obserwowalny wynik. Jeśli w wierszu występuje spójnik „i”, który pełni rzeczywistą funkcję, oznacza to dwa kryteria.
  • Proszę nazwać „niepożądaną ścieżkę”. Stan pusty, przekroczenie limitu czasu, nieprawidłowe dane wejściowe – to właśnie tam kryje się największy wysiłek.
  • Proszę skupić się na zachowaniu, a nie na projekcie. Makieta dotyczy układu; kryteria określają, co musi być spełnione.
  • Zatrzymaj się mniej więcej przy piątce.

Ile kryteriów akceptacji to już za dużo?

Mniej więcej pięć. Nie dlatego, że istnieje jakaś zasada, ale dlatego, że historia, która wymaga dziesięciu odrębnych, sprawdzalnych warunków, zawiera dziesięć odrębnych elementów wartości, co oznacza, że jest to kilka historii udających jedną. Gdy lista staje się długa, to właśnie kryteria akceptacji stanowią punkt podziału.

Podział według kryteriów akceptacji

Jeśli dana historia zawiera więcej niż pięć kryteriów akceptacji, to zazwyczaj właśnie te kryteria stanowią punkt podziału. Lista ta jest w rzeczywistości rejestrem zadań pełniącym rolę listy kontrolnej.

Kryteria akceptacji służą opisaniu zadania. Nie powinny one stanowić samego zadania. Gdy lista staje się długa (sześć, osiem, dziesięć punktów), zespół często dokonuje podziału zadania, nie zdając sobie z tego sprawy. Każde kryterium stanowi niewielki fragment, który zespół może dostarczyć, zaprezentować i zamknąć. Traktowanie całej listy jako jednego zobowiązania zmusza zespół do podjęcia się realizacji wszystkich elementów naraz, co stanowi najgorsze połączenie zakresu i ryzyka, jakie można komuś powierzyć w ramach sprintu.

Aby dokonać podziału, proszę przeanalizować każde kryterium i zadać pytanie, które zadałby Pan/Pani w odniesieniu do dowolnej historii użytkownika: czy zespół wdrożyłby to samodzielnie? Czy użytkownik odniósłby z tego korzyść jako samodzielna funkcja? Czy dałoby się to zaprezentować? Punkty, które przetrwają tę analizę, stanowią historie. Punkty, które nie spełniają tych kryteriów, zazwyczaj należą do jednej z tych, które przeszły test: stanowią zakres historii, którą już wyodrębnili Państwo, a nie samodzielne zadanie.

Problem pojawia się w przypadku ściśle powiązanych kryteriów: „formularz weryfikuje wprowadzone dane oraz zapisuje je w bazie danych oraz wyświetla potwierdzenie”. Te trzy elementy wydają się możliwe do rozdzielenia, ale użytkownik nie zyska nic, jeśli zrealizowana zostanie tylko jedna z nich. Nie da się tego rozdzielić według kryteriów; jest to jedna niewielka historia, a punkty na liście są jedynie wyrazem dbałości zespołu o szczegółowość.

Kryteria akceptacji a wymagania

Wymaganie określa, co należy stworzyć. Kryterium akceptacji określa, w jaki sposób będzie można stwierdzić, że stworzono właściwe rozwiązanie. „Użytkownicy mogą zresetować swoje hasło” to wymaganie, które można spełnić za pomocą procesu tak wadliwego, że nikt go nie ukończy. „Użytkownik, który zgłasza prośbę o zresetowanie hasła, otrzymuje w ciągu dwóch minut wiadomość e-mail zawierającą link, który traci ważność po upływie godziny” to kryterium akceptacji, ponieważ jest to test, którego wadliwy proces nie jest w stanie przejść. Wymagania wyznaczają zakres prac; kryteria stanowią warunek ich realizacji.

Kryteria akceptacji a definicja zakończenia zadania

Pojęcia te są nieustannie mylone, a rozróżnienie jest proste: kryteria akceptacji dotyczą poszczególnych historii; natomiast definicja zakończenia ma charakter ogólny. Powyższe kryteria opisują, co konkretnie musi spełniać historia dotycząca logowania. Definicja zakończenia (przetestowane, zweryfikowane pod kątem kodu, udokumentowane, wdrożone do środowiska testowego) ma zastosowanie do każdego zadania, które zespół dostarcza. Zadanie może spełnić kryteria akceptacji, a mimo to nie być zakończone, ponieważ „działa zgodnie ze specyfikacją” i „gotowe do wydania” to różne poziomy wymagań. Konieczne jest spełnienie obu warunków.

Punkty fabularne a kryteria akceptacji

Kryteria akceptacji opisują wynik: co musi mieć miejsce, aby daną historię można było uznać za zrealizowaną. Punkty opowieści opisują ścieżkę: jak duży jest nakład pracy między stanem „jeszcze tego nie mamy” a stanem „kryteria zostały spełnione”. Są to dwie różne osie. Ich pomylenie prowadzi do określenia wielkości kryteriów, co jest bezsensowne, lub do oszacowań punktowych pozbawionych kryteriów, co jest jedynie pobożnym życzeniem.

Czy dodanie kryterium wpływa na oszacowanie? Czasami. Kryterium, które ujawnia ukryty nakład pracy („musi być dostępne dla czytników ekranu”), zazwyczaj ma taki wpływ, ponieważ wskazuje na wysiłek, który wcześniej był domyślny. Kryterium, które jedynie wyjaśnia istniejące założenie („musi działać w przeglądarkach Chrome i Safari”, gdy przeglądarki te zawsze były obsługiwane), nie powinno mieć takiego wpływu. Kolejność ma znaczenie: najpierw kryteria, potem punkty. Szacowanie przed ustaleniem jasnych kryteriów to szacowanie przed doprecyzowaniem, a jest to najczęstsza przyczyna rozbieżności w głosowaniu.

Proszę napisać test przed rozpoczęciem pracy. Jeśli kryterium nie może zakończyć się niepowodzeniem, to nie jest to kryterium. A jeśli ma Pan/Pani ich więcej niż pięć, to prawdopodobnie ma Pan/Pani więcej niż jedną historię.

Najczęściej zadawane pytania

Czym są kryteria akceptacji?

Kryteria akceptacji to warunki, które musi spełnić dana historia, aby została zaakceptowana: test typu „zaliczone/niezaliczone”, sporządzony przed rozpoczęciem prac. Opisują one, jakie funkcje musi spełniać wynik, a nie jak go zrealizować, i nie ma możliwości uzyskania częściowej oceny: każde z kryteriów jest spełnione albo nie.

Jak sporządza się kryteria akceptacji?

Każdy z nich proszę sformułować tak, jakby miał Pan/Pani go przekazać testerowi, który nigdy wcześniej nie widział tego opisu. W przypadku zachowań zależnych od stanu proszę zastosować schemat „Given/When/Then”, a w przypadku zestawu niezależnych wymagań – zwykłą listę kontrolną. Niech opisy będą możliwe do przetestowania, niech skupiają się na wynikach i niech ich liczba nie przekracza około pięciu. Jeśli będzie ich więcej, mamy do czynienia z kilkoma opisami.

Jaka jest różnica między kryteriami akceptacji a wymaganiami?

Wymagania określają, co należy stworzyć; kryteria akceptacji określają, w jaki sposób można stwierdzić, że wszystko działa poprawnie. Wymaganie może zostać spełnione przez kod, który nie trafia w sedno. Kryterium akceptacji jest testem: jeśli zostanie zaliczone, ta część opisu jest gotowa; jeśli można je zaliczyć bez rozwiązania problemu użytkownika, jest to w rzeczywistości ukryte wymaganie.

Jaka jest różnica między kryteriami akceptacji a definicją zakończenia?

Kryteria akceptacji odnoszą się do poszczególnych historii: opisują one, co dana historia musi spełniać. Definicja zakończenia to jedna ogólna lista kontrolna, która ma zastosowanie do każdej historii (przetestowana, zweryfikowana, udokumentowana, wdrożona). Historia może spełniać swoje kryteria akceptacji, a mimo to nie być uznana za zakończoną, jeśli nie przejdzie przez etap weryfikacji obejmujący cały zespół.

Kto opracowuje kryteria akceptacji?

Właściciel produktu jest za nie odpowiedzialny, jednak są one opracowywane wspólnie z zespołem podczas procesu doprecyzowywania. Właściciel produktu określa oczekiwany rezultat, natomiast inżynierowie i testerzy wskazują skrajne przypadki. Kryteria akceptacji sporządzone samodzielnie, po zakończeniu prac, to właśnie te, w których pominięto przypadek powodujący awarię w środowisku produkcyjnym.

Warto przeczytać