Postać w postaci karteczki samoprzylepnej trzymająca listę kontrolną, na której jedna pozycja jest zaznaczona, a druga przekreślona, i porównująca ją z gotowym rysunkiem na tablicy.

Kryteria akceptacji: jak je sformułować

Kryteria akceptacji stanowią test określający, czy dana historia została zaliczona, czy odrzucona; są one sporządzane przed rozpoczęciem prac i obejmują: formaty, które się sprawdzają, przykłady z praktyki 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ądzony 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, lecz 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ę sama, a kwestia „zakończenia” przestaje być przedmiotem negocjacji. Jeśli natomiast zostaną sformułowane niejasno, 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 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 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” 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 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 sytuacjach; proszę się temu opierać. Lista kontrolna jest szybsza w odczytaniu i trudniej ją nadmiernie rozbudować, gdy opis wymagań sprowadza się po prostu do stwierdzenia: „te pięć rzeczy musi być spełnionych”.

Jeśli / Gdy / Wówczas

Przy danym 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 strona logowania jest wyświetlona, 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, bez oddzielnego 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ę.

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ć dostarczone. Każda z tych pozycji stanowi element, który tester może uznać za spełniony lub niespełniony bez konieczności zadawania Państwu dodatkowych pytań.

Jak sformułować kryteria akceptacji

  • Proszę je sporządzać podczas doprecyzowywania backlogu, wspólnie z zespołem, a nie samodzielnie po zakończeniu tego etapu.
  • W każdym wierszu powinien znajdować się jeden obserwowalny wynik. Jeśli w wierszu występuje spójnik „i”, który pełni rzeczywistą funkcję, oznacza to dwa kryteria.
  • Proszę wskazać „niepożądaną ścieżkę”. Stan pusty, przekroczenie limitu czasu, nieprawidłowe dane wejściowe: 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?

Około pięciu. 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 składa się z kilku historii udających jedną. Gdy lista staje się zbyt 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ą podstawę 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 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 przypadku każdej historii użytkownika: czy zespół wdrożyłby to samodzielnie? Czy użytkownik odniósłby z tego korzyść jako samodzielny element? Czy dałoby się to zademonstrować? Punkty, które przetrwają tę analizę, są historiami. Punkty, które nie spełniają tych kryteriów, zazwyczaj należą do jednej z tych, które przeszły test: stanowią one część zakresu opowieści, którą już wyodrębnili Państwo, a nie samodzielne zadanie.

Problem pojawia się w przypadku ściśle powiązanych kryteriów: „formularz weryfikuje dane wprowadzone przez użytkownika 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 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, 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 jednej godziny” to kryterium akceptacji, ponieważ jest to test, którego wadliwy proces nie jest w stanie przejść. 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 (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.

Punkty fabularne a kryteria akceptacji

Kryteria akceptacji opisują wynik: co musi mieć miejsce, aby dana historia została uznana za dostarczoną. Punkty opowieści opisują drogę: jak duży jest zakres 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 ustalenia kryteriów opartych na wielkości, co jest bezsensowne, lub do szacunków punktowych pozbawionych kryteriów, co jest jedynie pobożnym życzeniem.

Czy dodanie kryterium zmienia oszacowanie? Czasami. Kryterium, które ujawnia ukrytą pracę („musi być dostępne dla czytników ekranu”), zazwyczaj ma taki wpływ, ponieważ określa nakład pracy, 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 tego robić. Kolejność ma znaczenie: najpierw kryteria, potem punkty. Szacowanie przed ustaleniem kryteriów oznacza 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”, sporządzony przed rozpoczęciem prac. Opisują one, jakie funkcje musi spełniać wynik, a nie jak go stworzyć, 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 go przekazać testerowi, który nigdy wcześniej nie zapoznał się z tym 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ć, skupiać się na wynikach i nie przekraczać liczby 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 wymaganie w przebraniu.

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

Kryteria akceptacji są określane dla poszczególnych zadań: opisują one, co dane zadanie musi spełniać. Definicja zakończenia to jedna ogólna lista kontrolna, która ma zastosowanie do każdego zadania (przetestowane, zweryfikowane, udokumentowane, wdrożone). Zadanie może spełniać swoje kryteria akceptacji, a mimo to nie być uznane za zakończone, 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 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.

Materiały powiązane