Kryteria akceptacji — jaka jest rola każdej ze stron zaangażowanych w projekt IT?
Skuteczna komunikacja między klientem a zespołem programistów jest kluczem do sukcesu w projektach IT. Duży wpływ na jej przebieg mogą mieć odpowiednio przygotowane kryteria akceptacji. Czym są i jakie są ich główne cele?
W idealnym scenariuszu programiści doskonale rozumieją potrzeby klienta i tworzą projekt zgodny z jego oczekiwaniami. Z doświadczenia wiem, że różnie z tym bywa, jednak z dobrze napisanymi kryteriami akceptacji można uniknąć nieporozumień i oddać projekt w terminie.
Spis treści
Czym są kryteria akceptacji?
Kryteria akceptacji (acceptance criteria), stosowane w metodyce Agile, to lista konkretnych warunków i wymagań, stanowiących punkt odniesienia do określenia historyjki użytkownika (user story) jako kompletnej z biznesowego punktu widzenia. Kryteria opisują potrzeby użytkowników i określają dokładne funkcje systemu, dzięki czemu zespół programistów lepiej rozumie, jak powinien wyglądać produkt końcowy.
Kryteria akceptacji określają szczegóły historyjek użytkowników, zatem dla każdej historyjki należy napisać osobne kryteria. Pamiętaj, że w kryteriach akceptacji powinny być opisane jedynie informacje o tym, co ma zostać wykonane, cechy, jakie powinien posiadać produkt oraz funkcje, jakie ma spełniać, bez wchodzenia w szczegóły dotyczące rozwiązań czy technik. Na tym etapie ważne jest zrozumienie celu, jaki klient chce osiągnąć.
Czym się wyróżniają skuteczne kryteria akceptacji?
1. Można je przetestować
Kryteria akceptacji pomagają sformułować definicję ukończenia dla inżynierów, więc muszą być łatwe do przetestowania. Z kolei wyniki tych testów nie mogą pozostawiać miejsca na interpretację. Wyniki powinny być jasne na zasadzie: wyniki tak/nie lub zaliczone/niezaliczone.
2. Są jasne i zwięzłe
To nie miejsce na spisywanie obszernej dokumentacji. Kryteria powinny być tak proste i jasne, jak to tylko możliwe.
3. Każdy członek zespołu jest w stanie je zrozumieć.
Kryteria powinny być na tyle jasne by wszyscy członkowie zespołu mogli je zrozumieć. Jeśli coś nie do końca jest oczywiste, lepiej poświęcić czas na zasięgnięcie dodatkowych informacji i wprowadzenie poprawek.
4. Dbają o perspektywę użytkownika
Kryteria akceptacji zawsze wiążą się ściśle ze spojrzeniem na problem z punktu widzenia klienta. Powinny być napisane ze zrozumieniem potrzeb i działań odbiorców.
Kryteria akceptacji z perspektywy zespołu
Szczegółowe kryteria akceptacji powinny być napisane przed rozpoczęciem prac programistycznych. Zazwyczaj zaczyna się od przedstawienia pomysłu i wstępnych wymagań przez product ownera. Kolejnym krokiem jest doprecyzowanie przez zespół scrumowy szczegółów zawartych w specyfikacji i dokonanie niezbędnych poprawek, aby obie strony zaakceptowały ustalone warunki. Od teraz, historyjka jest dla zespołu punktem odniesienia do określenia, czy produkt jest taki, jak zakładano.
W razie potrzeby historyjki mogą być zmieniane i aktualizowane, aby wszystkie kryteria były spełnione. Powinno się to jednak odbyć, zanim historyjka zostanie przyjęta przez zespół deweloperski do realizacji. Jeśli zostanie ona zmieniona już po rozpoczęciu sprintu, może to mieć niekorzystny wpływ na harmonogram i przebieg prac.
Zaangażowanie QA w proces tworzenia kryteriów akceptacji
Jeśli historyjka nie została przetestowana, nie można jej uznać za skończoną. Specjalista QA powinien więc już na etapie tworzenia kryteriów akceptacji sprawdzić, czy nie są pomijane kwestie, mające wpływ na jakość produktu.
Tester oprogramowania powinien być zaangażowany w projekt od samego początku i brać udział we wszystkich spotkaniach. Jego rolą jest pilnowanie zakresu prac w ramach zaplanowanych funkcjonalności i informowanie zespołu o problemach, które mogą wpłynąć na jakość produktu. Mogą to być problemy z przeglądarkami (niekompatybilność) lub pominięcie technik RWD.
QA powinien też zwracać uwagę na wymagania funkcjonalne, czyli sposób zachowania się produktu czy odbiór aplikacji od strony użytkownika — czy jest ona intuicyjna i czy ta intuicyjność zostanie ujęta w kryteriach, i niefunkcjonalne, takie jak cechy i ograniczenia systemu, polegające np. na wymaganiach pamięci, wydajności systemu czy jego bezpieczeństwie. Ważne jest też wzięcie pod uwagę różnych przeglądarek, systemów operacyjnych i obsługiwanych urządzeń, aby mieć pewność, że produkt końcowy będzie zgodny z oczekiwaniami.
Co więcej, specjalista QA powinien też umieć przewidywać i wychwytywać złożone zachowania oraz sprawdzić negatywne przypadki testowe, zanim produkt trafi do użytkowników końcowych.
Jaka jest rola klienta?
Zawsze rekomendujemy klientowi wyznaczenie osoby odpowiedzialnej za przygotowanie kryteriów akceptacji. Może to być on sam, jednak zazwyczaj jest to project manager lub product owner, czyli osoba posiadająca szeroką wiedzę na temat produktu. Ważna jest bowiem współpraca między klientem a zespołem projektowym na każdym etapie — od tworzenia kryteriów po realizację samego projektu i kontrolowanie wdrażanych zmian.
Jeśli klient przeniesie odpowiedzialność napisania kryteriów akceptacji na zespół developerów, co nie jest rekomendowane, również powinien zaangażować się w ten proces. Z pewnością oczekuje wysokiej jakości, więc powinien zrobić wszystko, aby doprecyzować wszelkie niejasności i wątpliwości zespołu. Pomoże im to wdrożyć produkt odpowiadający wizji i funkcjonalnościom zaproponowanym przez klienta.
Zespół może potrzebować więcej szczegółów, aby w pełni zrozumieć wizję klienta, więc osoba reprezentująca jego firmę powinna być cały czas dostępna, aby odpowiedzieć na wszystkie pytania i wyjaśnić problemy, które mogą się pojawić.
To w interesie klienta jest, aby dostarczyć możliwie wyczerpujące i dokładne wymagania i warunki do spełnienia podczas implementacji historyjki. Ważna jest więc ścisła współpraca z zespołem, aby ulepszyć kryteria akceptacji i zrozumieć, jak dane wymagania wpłyną na produkt i jego dalszy rozwój. Pomoże to też zrozumieć i oszacować ograniczenia i wyzwania, jakie zespół może napotkać podczas pracy nad produktem.
Każda opinia ma znaczenie
Jako że dany problem może być różnie postrzegany przez różnych członków zespołu i osoby zaangażowane w projekt, przed rozpoczęciem prac programistycznych upewnij się, że każdy (np. programista, tester, analityk, UX-owiec, project manager) zgadza się z założeniami i ma tę samą wizję produktu. Im więcej informacji przekażesz zespołowi programistycznemu, tym lepszy będzie projekt.
