Kryteria akceptacji to temat, którym można by zajmować się bez końca. Ba, można by na ten temat napisać całą książkę. Ale na naszym blogu nie chodzi o to, aby się doktoryzować, tylko żeby poznać tę część, która da nam najwięcej. Co przy kryteriach akceptacji i tak znaczy, że tekst będzie dość długi.
Po pierwsze, User Stories
Czymś, co musimy zaadresować na samym początku jest kwestia User Story. „Historyjka Użytkownika” to jeden ze sposobu zapisu wymagań, który zawiera w sobie, jako jeden z elementów, wysokopoziomowe kryteria akceptacji. Nie jest to jednak jedyne miejsce, gdzie te kryteria akceptacji mogą się pojawić. Weźmy na przykład kwestię Definition of Done, która też takie kryteria zawiera. Ba, poświęciliśmy temu osobny tekst „DoDa kontra HLAC„. Tak więc nie mieszajmy US-ów z kryteriami akceptacji (ang. acceptance criteria, AC lub high level acceptance criteria, HLAC). W niniejszym tekście patrzymy na kryteria akceptacji ogólnie, z punktu widzenia wymagań, a nie jakiejś konkretnej techniki.
Jeżeli zaś szukasz informacji na temat samych stories, to polecić możemy nasze filmy, w których mówiliśmy o tym, czym jest US i jakie są typowe błędy przy pisaniu User Story. Ostatnio nagraliśmy też materiał w którym znęcamy się nad Najgorszym User Story Na Świecie. Mówiliśmy też, że US to nie jest dokumentacja systemu oraz dyskutowaliśmy na temat tego, czy powinny być pisane z perspektywy klienta czy użytkownika.
Temat User Stories wydaje się, że mamy pokryty w każdym jego aspekcie, także jeśli chodzi o Rozmiar User Story czy tego, jakie powinny być rezultaty historyjek użytkownika. Podpowiedzieliśmy też, jak można zaadaptować tę technikę i stworzyć zgrabny format zapisu Epika. Materiałów na temat samych US-ów chyba już wystarczy. Ale jakoś do tej pory nie zabraliśmy się w szczegółach za kryteria akceptacji. Najwyższy czas to zmienić.
Po drugie, Kryteria Akceptacji
Kryteria akceptacji to nic innego jak lista, która mówi nam o warunkach, jakie sposób realizacji wymagania powinien spełnić, żebyśmy byli usatysfakcjonowani. Inaczej mówiąc, określa ona co dla nas znaczy „okej” i według czego będziemy sprawdzać czy na pewno wytworzony produkt spełnia oczekiwania. Kryteriami akceptacji dla naszego cotygodniowego posta na blogu mogą więc być „Tekst dotyczy podejścia zwinnego i wszystkiego, co się z nim wiąże”, „Tekst zawiera co najmniej 700 słów”, „T”, „Do tekstu zostało dodane zdjęcie o wymiarach 700×700 korespondujące z tematyką artykułu”, „Tekst nie zawiera błędów ortograficznych”, itd.
W teorii nie jest to więc nic skomplikowanego. Ale jak każda prosta koncepcja, można ją zrozumieć na milion sposobów. Przede wszystkim, weźmy pod uwagę szczegółowość naszych kryteriów akceptacji. Nie mogą one być zbyt ogólne, bo nie dostaniemy tego, czego potrzebujemy. Nie mogą też być zbyt szczegółowe, bo wtedy zabijamy kreatywność naszego zespołu. Kryteria akceptacji muszą opisywać potrzeby, a nie konkretne rozwiązania.
Oczywiście, podstawy muszą być jasno określone. Jeżeli chcemy opublikować w środę tekst na stronie, to piszemy wymagania (i kryteria akceptacji) dotyczące tekstu. Jeżeli jednak naszym wymaganiem są „materiały publikowane na naszym profilu na LinkedIn„, to tutaj już nie chcemy określać, czy mają to być teksty, filmy na YouTube czy może komiksy. W ustaleniu tego, czym ma być rezultat naszych prac pomoże nam wspomniany już format User Story. W nim bowiem musimy jawnie wskazać, po co coś robimy. I jeżeli chodzi nam tylko o regularne publikowanie treści w Internecie, to nada się „cokolwiek”. Jeżeli piszemy teksty, żeby zwiększyć zasięg naszego bloga, to filmy nic nam nie dadzą.
I tu chciałbym sprzedać Wam pierwszą „dobrą praktykę”, która wynika tylko i wyłącznie z moich doświadczeń i fanaberii. Pierwsze kryterium akceptacji powinno oddawać istotę samego wymagania bądź parafrazować treść User Story. Jeżeli User Story to „Jako trener prowadzący zajęcia on-line, chcę żeby skład breakout roomów był zapisywany pomiędzy poszczególnymi dniami szkolenia, abym nie musiał codziennie rano tracić czasu na przypisywanie ludzi do breakout roomów i ryzykować pomyłek”, to pierwsze kryterium akceptacji może brzmieć „Skład breakout roomów ustalony jednego dnia jest zachowywany na dni kolejne tego samego wydarzenia”. Powiedzenie tego samego na dwa sposoby na pewno nie zaszkodzi, a może tylko pomóc każdemu czytającemu nasze wymaganie.
Ogólne kontra szczegółowe kryteria akceptacji
Dlaczego niektóre kryteria akceptacji są bardzo konkretne, a inne bardzo ogólne i zasadniczo niemierzalne? Odpowiedź jest prosta: bo na niektórych rzeczach nam zależy, a na innych zupełnie nie. Wróćmy na chwilę do pierwszego przykładu. Tematyka naszego bloga jest bardzo szeroka, a teksty z pogranicza zwinności bardzo często stają się nad wyraz popularne. Nie ma więc znaczenia o czym piszemy, nie ma co zabijać kreatywności, każdy temat może „chwycić”. Z drugiej strony, konkretne wymagania techniczne dotyczące obrazka, to coś czego nie możemy obejść. Tak ma być i już.
Tu należy uważać na pokusę uznawania, że „wszystko ma być dokładnie tak, jak powiem i już”. Pamiętajmy: „Wymagania, a nie zadania!”
A jak sobie poradzić z bardzo szczegółowymi, konkretnymi kryteriami akceptacji? Na przykład, wymaganie opisuje sposób wynagradzania pośredników, który jest bardzo skomplikowany. Dokument opisujący poszczególne prowizje zawiera kilkustronicowy algorytm oraz kilka tabel wyszczególniających wartości prowizji. Przecież nie będziemy tego przepisywać do kryteriów akceptacji…
Wszyscy czujemy, że nie ma sensu tworzyć przesadnie rozległych kryteriów akceptacji. Z drugiej strony, jeśli nasze wymaganie musi być zrealizowane dokładnie w zgodzie z jakimś dokumentem, to tenże dokument możemy po prostu podlinkować. „Algorytm wyznaczania prowizji zgodny jest z prowizje.docx”, gdzie plik jest umieszczony w odpowiednim repozytorium.
Podobnie rzecz się ma z wymaganiami graficznymi czy np. UX. Jeżeli niezwykle istotne jest, żeby przyciski znajdowały się w odległości x pikseli od krawędzi (bo inaczej ciężko na nie kliknąć), to to zapiszmy. Pamiętajmy jednak, że wklejenie dokładnie zwymiarowanego projektu ekranu z odległościami podanymi w pikselach zwykle spowoduje więcej szkody niż pożytku. Makiety powinny być tylko sugestią, bądź pokazywać ogólny układ i koncepcję. Najważniejsza jest dla nas funkcjonalność dla klienta i zgodność z pewnymi zasadami, a nie konkretne rozmiary elementu w pikselach.
Oczywiście, najlepiej jeżeli takie makiety i w ogóle UX będzie powstawał już na etapie wykonania wymagania, w samych zespołach. Ale to temat na zupełnie inny tekst.
Pytanie czy stwierdzenie?
Kryteria akceptacji, w szczególności te dotyczące User Stories, w swoich początkach były zapisywane jako pytania, na które powinniśmy udzielić odpowiedzi „Tak”. I tak, dla przykładu wymaganie dotyczące tych nieszczęsnych breakout roomów mogłoby brzmieć „Czy po zakończeniu spotkania jednego dnia i rozpoczęciu go ponownie drugiego, osoby nadal są przypisane do tych samych breakout roomów co dzień wcześniej?” Jeżeli wymaganie spełniliśmy, odpowiadamy po prostu „Tak” i przechodzimy do kolejnego.
Jeżeli nasza odpowiedź na kryterium akceptacji zapisane w postaci pytania brzmi jakkolwiek inaczej („Nie”, „Tak, ale…”) to znaczy, że nie spełniliśmy danego wymagania. Dopiero jeśli odpowiemy twierdząco na wszystkie pytania oraz dodatkowo potwierdzimy spełnienie Definition of Done możemy otwierać szampana.
Praktycznie nie spotykamy się z formą zapisu kryteriów akceptacji w postaci pytań. Wydaje mi się jednak, że dla niektórych osób i zespołów może to być rewelacyjne ćwiczenie, które zmusza nas do tego, żeby wyrazić „o co nam chodzi” w nieco inny sposób. Pamiętajmy, że dodając kolejne pytania uszczegóławiamy nasze potrzeby, a nie sugerujemy rozwiązanie. „Czy zachowywanie przypisania osób do breakout roomów dzieje się automatycznie i bez konieczności klikania dodatkowych przycisków?” nadal mówi o naszych potrzebach.
Jest szansa, że pisząc w ten sposób, niektórym będzie łatwiej uniknąć „zadaniowości” w wymaganiach.
Nowe wymagania czy tylko kolejne kryteria?
Na koniec wypadałoby jeszcze poruszyć kwestię pojawiania się kolejnych kryteriów akceptacji. Czy jeśli dopisujemy nowe elementy, to znaczy, że zmieniamy wymagania, czy też po prostu uszczegóławiamy nasze potrzeby? Odpowiedź jest jedna – „to zależy”. Jeśli uszczegółowienie kryterium akceptacji nie powoduje nowej pracy, to problemu nie ma. Gorzej, jeśli pojawienie się nowego wiersza sprawia, że nagle mamy dwa razy więcej do roboty. Albo jeszcze gorzej, że to co zrobiliśmy do tej pory jest bez sensu.
Takie sytuacje to dla nas przede wszystkim nauczka. Na podstawie takich nieporozumień w końcu zmierzamy do właściwego poziomu szczegółowości kryteriów akceptacji. Jeśli zespół robi coś dziwnego i skomplikowanego „bo tak było w kryteriach akceptacji”, to zacznijmy pisać je bardziej ogólnie i pozwólmy zespołom na wybór lepszych rozwiązań. Jeżeli natomiast po skończonej pracy reakcja interesariuszy to „Ale nie o to nam chodziło!”, to znaczy, że zabrakło nam tej szczegółowości.
Jeśli pytacie mnie o zdanie, to decyzję o tym, czy dane kryterium akceptacji to zupełnie nowe wymaganie czy uszczegółowienie starego powinien podjąć zespół. Przy czym pamiętajmy, że jeśli nowe kryterium akceptacji wywraca nam wszystko do góry nogami, to pewnie nie ma już sensu kończyć „starego” wymagania. A to oczywiście jest pewien waste i konieczność zidentyfikowania przyczyn takiej sytuacji. Ale od tego na szczęście mamy retrospektywy.
