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 formaty, które się sprawdzają, przykładowe rozwiązania oraz różnice w stosunku do definicji zakończenia.

Kryteria akceptacji to warunki, które musi spełnić dana historia, aby została zaakceptowana — test typu „zaliczony/niezaliczony”, sporządzany przed rozpoczęciem jakichkolwiek prac programistycznych. Nie ma możliwości uzyskania częściowej oceny: każdy kryterium jest spełnione albo 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 sformułuje się je nieprecyzyjnie, wprowadzą Państwo na rynek 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 spotkaniu poświęconym dopracowywaniu wymagań, a mimo to będzie on dokładnie wiedział, co ma sprawdzić. Opisuje ono efekt, 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 — to rozwiązanie. „Wyniki ładują się w mniej niż sekundę dla tabeli zawierającej 10 000 wierszy” 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ę poddać weryfikacji. Jeśli danego stwierdzenia nie da się sprawdzić — np. „strona jest intuicyjna”, „wydajność jest dobra” — nie jest to kryterium, lecz tylko 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 przypadkach; proszę się temu oprzeć. Lista kontrolna jest szybsza w odczytaniu 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 wykona jakąś czynność, system reaguje w określony sposób. Format ten sprawdza się, ponieważ zmusza do nazwania wszystkich trzech elementów — warunku wstępnego, czynnika wyzwalającego oraz obserwowalnego wyniku — a właśnie to pomija nieprecyzyjne kryterium.

Przykłady kryteriów akceptacji

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

  • Jeśli 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 trzykrotnie wprowadzi 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 gdy pole adresu e-mail jest puste, wtedy przycisk „Prześlij” jest nieaktywny.

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

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

Zwróćcie uwagę na to, czego w obu przypadkach nie uwzględniono: bazy danych, frameworka oraz nazw komponentów. Opisują one to, co otrzymuje użytkownik, a nie sposób, w jaki to dostarczą Państwo — a każdy wiersz stanowi element, który tester może uznać za pozytywny lub negatywny bez zadawania Państwu 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ę wymienić „niepożądane scenariusze”. Stan pusty, przekroczenie limitu czasu, nieprawidłowe dane wejściowe — właśnie tam kryje się najwięcej pracy.
  • 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 ma więcej niż pięć kryteriów akceptacji, to zazwyczaj właśnie te kryteria stanowią punkt podziału. Lista ta jest w istocie 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 dokonał już podziału zadania, nawet tego nie zauważając. Każde kryterium stanowi niewielki fragment, który zespół mógłby 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 przypadku każdej 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ę, są historiami. Punkty, które nie spełniają tych kryteriów, zazwyczaj należą do jednej z historii, które przeszły test — stanowią one część zakresu historii, którą już wyodrębnili Państwo, a nie samodzielne zadanie.

Problem pojawia się w przypadku ściśle powiązanych kryteriów — „formularz sprawdza poprawność danych wprowadzonych i zapisuje je w bazie danych i 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 odzwierciedlają jedynie dbałość zespołu o szczegółowość.

Kryteria akceptacji a wymagania

Wymaganie określa, co należy stworzyć. Kryterium akceptacji określa, w jaki sposób można stwierdzić, że stworzono właściwe rozwiązanie. „Użytkownicy mogą zresetować swoje hasło” to wymaganie — i można je 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 jednej godziny” to kryterium akceptacji, ponieważ jest to test, którego wadliwy proces nie przejdzie. Wymagania wyznaczają zakres prac; kryteria stanowią barierę kontrolną.

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 — przetestowana, zweryfikowana pod kątem kodu, udokumentowana, wdrożona 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.

Punkty fabularne a kryteria akceptacji

Kryteria akceptacji opisują wynik — co musi zostać spełnione, aby dana historia mogła zostać uznana za dostarczoną. Punkty opowieści opisują ścieżkę — jak duży jest zakres pracy między stanem „jeszcze tego nie mamy” a stanem „kryteria są spełnione”. Są to dwie różne osie. Ich pomylenie prowadzi do ustalenia kryteriów opartych na wielkości, co jest bezsensowne, lub do szacunków punktowych bez kryteriów, na których się opierają, 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 dotychczas 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 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, nie jest to kryterium — a jeśli mają Państwo więcej niż pięć kryteriów, prawdopodobnie mają Państwo 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 „zaliczony/niezaliczony”, opracowany przed rozpoczęciem prac. Opisują one, jakie funkcje musi spełniać wynik, a nie jak go stworzyć, i nie ma tu miejsca na oceny częściowe: 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ł zostać przekazany testerowi, który nigdy wcześniej nie zapoznał się z danym opisem. W przypadku zachowań zależnych od stanu proszę stosować schemat „Given/When/Then”, a w przypadku zestawu niezależnych wymagań – zwykłą listę kontrolną. Opisy powinny dać się przetestować i skupiać się na wynikach; proszę ograniczyć ich liczbę do około pięciu — jeśli będzie ich więcej, oznacza to, że mamy do czynienia z kilkoma odrębnymi 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 są określane dla 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, ale są one opracowywane wspólnie z zespołem podczas fazy dopracowywania. 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ć