Odpowiedź.

Historycznie formułowanie kryteriów akceptacji (kryteria akceptacji) pozostawało w rękach testerów lub zespołu programistycznego. Jednak w miarę przechodzenia do elastycznych procesów skalowalnych (SAFe, LeSS, Scrum-of-Scrums) bez sformalizowanych scenariuszy testowania pojawiają się ryzyka rozbieżności w oczekiwaniach różnych uczestników dużego projektu: biznes, testowanie, deweloperzy i wsparcie mogą różnie interpretować zakończenie zadania.

Problem w projektach z wieloma zespołami lub rozproszonych: różne obszary odpowiedzialności, różne procesy i narzędzia, różnice językowe lub kulturowe między zespołami. Nawet szczegółowo opracowane wymagania mogą przerodzić się w konfliktowe lub niekompletne kryteria akceptacji, co prowadzi do błędów i niezadowolenia biznesu.

Rozwiązanie — zaangażowanie analityka systemowego na wczesnych etapach formułowania kryteriów akceptacji, zbieżność wymagań między zespołami, ścisła formalizacja i wspólne omawianie scenariuszy i brzegowych przypadków (edge-cases) na wspólnym dema lub warsztatach grupowych.

Kluczowe cechy:

Kryteria akceptacji powinny być jednoznaczne, mierzalne, powtarzalne i walidowalne.
Wstępne uzgodnienie kryteriów (ręczna lista kontrolna + przykłady oczekiwanych danych/zachowań).
Wzajemne śledzenie: kryteria zawsze powinny odnosić się do wymagań, przypadków i użytkowników historii, aby można było śledzić każdy cel.

Pytania z podstępem.

Czy można pozostawić formułowanie kryteriów akceptacji w całości testerom?

Nie, analityk musi uczestniczyć. Tylko on posiada pełnię kontekstu biznesowego i zna wszystkie niuanse wymagań.

Czy kryteria akceptacji powinny obejmować tylko pozytywne scenariusze?

Nie, należy koniecznie dodawać negatywne i przypadki brzegowe (edge cases), w przeciwnym razie pojawią się luki w realizacji i testowaniu.

Czy można definiować kryteria akceptacji ustnie w projektach z wieloma zespołami?

Nie, ustne ustalenia nie wytrzymują obciążenia rozproszonej interakcji i prowadzą do konfliktów. Kryteria akceptacji powinny być ustalane wyłącznie w sposób sformalizowany (na przykład w postaci Gherkin/BDD lub strukturalnych list kontrolnych).

Typowe błędy i antywzorce

Formułowanie kryteriów akceptacji "domyślnie", bez odniesień do wymagań i specyfikacji.
Brak informacji zwrotnej od końcowych zespołów.
Ignorowanie scenariuszy interakcji między komponentami różnych zespołów, zwłaszcza przy integracjach.

Przykład z życia

Negatywny przypadek: W aplikacji bankowej kryteria akceptacji dla funkcji przelewów były uzgodnione tylko z jednym zespołem. Drugi zespół wdrożył własne interfejsy wewnętrzne, nie uwzględniając pierwszego zestawu kryteriów, co doprowadziło do niezgodności formatów ID transakcji.

Zalety:

Szybki początek realizacji.

Wady:

Konieczność refaktoryzacji API.
Utrata czasu na rozwiązywanie kolizji.

Pozytywny przypadek: Analityk przeprowadził serię warsztatów z wizualnymi scenariuszami i szczegółami dla wszystkich uczestniczących zespołów, z obowiązkowym pisemnym zarejestrowaniem kryteriów akceptacji w Confluence/JIRA z dwustronnym śledzeniem wymagań.