Kryteria akceptacji

Skuteczna komunikacja między klientem a zespołem deweloperskim to klucz do sukcesu w projektach IT. Odpowiednio przygotowane kryteria akceptacji mogą mieć istotny wpływ na jej przebieg. Czym więc są i jakie są ich główne cele?

W idealnym scenariuszu programiści doskonale rozumieją potrzeby klienta i tworzą projekt zgodnie z jego oczekiwaniami. Z doświadczenia wiadomo, że bywa niestety inaczej. Ale przy dobrze napisanych kryteriach akceptacji można uniknąć nieporozumień i dostarczyć projekt na czas.

Czym są kryteria akceptacji?

Kryteria akceptacji stosowane w metodyce Agile to lista konkretnych warunków i wymagań, które stanowią punkt odniesienia do zdefiniowania historyjki użytkownika jako kompletnej z biznesowego punktu widzenia.

Kryteria opisują potrzeby użytkowników i określają dokładne funkcje systemu, dając zespołowi programistycznemu lepsze zrozumienie, jak powinien wyglądać produkt końcowy.

Kryteria akceptacji powinny być tworzone przez cały zespół scrumowy. Podstawą powinny być oczekiwania klienta, precyzowane najczęściej za pośrednictwem Właściciela Produktu. Czy nie byłoby najlepiej od razu je szczegółowo i technicznie określić, aby zaoszczędzić czas?

Kryteria akceptacji określają szczegóły historyjek użytkownika, dlatego należy napisać osobne standardy dla każdej historyjki. Pamiętajmy, że kryteria akceptacji powinny jedynie opisywać to, co ma być zrobione, cechy, które produkt powinien mieć i funkcje, które ma pełnić, bez wchodzenia w szczegóły rozwiązań czy technik. Dlatego na tym etapie istotne jest zrozumienie celu klienta.

Kryteria akceptacji z perspektywy zespołu

Kryteria należy napisać przed rozpoczęciem prac programistycznych. Zwykle zaczyna się od przedstawienia przez Właściciela Produktu pomysłu i wstępnych wymagań. Kolejnym krokiem zespołu jest doprecyzowanie szczegółów zawartych w specyfikacji oraz dokonanie niezbędnych poprawek, tak aby obie strony zaakceptowały uzgodnione warunki. Mogą one stać się wówczas punktem odniesienia do określenia, czy produkt jest odpowiednio wykonany.

Historyjki można zmieniać i aktualizować w razie potrzeby, aby zapewnić spełnienie wszystkich kryteriów. Powinno to jednak nastąpić, zanim zespół zaakceptuje historyjkę do wdrożenia. Jeśli zmiany wprowadzone zostaną po rozpoczęciu Sprintu, może to zaszkodzić harmonogramowi i przepływowi pracy.

Zaangażowanie QA w proces tworzenia kryteriów akceptacji

Jeśli historyjka nie została przetestowana, nie można jej uznać za zakończoną. Dlatego specjalista QA powinien sprawdzić, czy kwestie wpływające na jakość produktu nie zostały pominięte na etapie tworzenia kryteriów akceptacji. Na przykład tester oprogramowania powinien być zaangażowany w projekt od samego początku i brać udział we wszystkich spotkaniach. Jego rolą jest nadzorowanie zakresu prac w ramach planowanych funkcjonalności oraz 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.

Kontrola jakości powinna również zwracać uwagę na wymagania funkcjonalne, czyli jak może zachować się produkt, a jak nie.

• Jaki może być odbiór aplikacji z punktu widzenia użytkownika?
• Czy jest on intuicyjny i czy ta intuicyjność zostanie uwzględniona w kryteriach?
• Czy produkt nie będzie niefunkcjonalny?
• Jakie są cechy i ograniczenia systemu, np. wymagania dotyczące pamięci, wydajność systemu lub jego bezpieczeństwa?

Istotne jest również rozważenie różnych przeglądarek, systemów operacyjnych i obsługiwanych urządzeń, aby upewnić się, że produkt końcowy jest taki, jakiego oczekuje klient.

Ponadto specjalista ds. QA powinien również przewidywać i rejestrować złożone zachowania oraz sprawdzać negatywne przypadki testowe, zanim produkt dotrze do użytkowników końcowych.

Każda opinia ma znaczenie

Ponieważ 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 należy upewnić się, że wszyscy (np. programista, tester, analityk, osoba UX, kierownik projektu) zgadzają się z tymi samymi założeniami i wizją produktu. Im więcej informacji podasz zespołowi programistycznemu, tym lepszy będzie projekt.

Kiedy uszczegółowić kryteria akceptacji?

Właściciel Produktu powinien powiedzieć zespołowi, co ma robić i dlaczego, ale nie powinien od razu zagłębiać się we wszystkie możliwe szczegóły. O wiele lepsze wymagania mogą być tworzone wspólnie przez cały Zespół Scrumowy podczas Spotkań Doskonalenia Rejestru Produktu. Wynikiem tego procesu powinny być bardziej szczegółowe kryteria akceptacji. W początkowym zestawie nie musi być ich zbyt wiele.

Ostatnim momentem na zmianę kryteriów akceptacji powinno być Planowanie Sprintu. Po pierwsze, przed rozpoczęciem pracy nad zadaniem cały zespół powinien zrozumieć potrzeby klienta. Nie oznacza to, że nie możemy dokonać pewnych korekt podczas Sprintu. Jednak trzeba z tym postępować bardzo ostrożnie. Przecież podczas planowania określony został zakres historyjki użytkownika. Bardziej znaczące zmiany mogłyby spowodować komplikacje.

W teorii nie wygląda to na coś skomplikowanego. Ale jak każdą prostą koncepcję, można ją zrozumieć na milion sposobów. Przede wszystkim warto rozważyć szczegółowo nasze kryteria akceptacji. Nie mogą być one zbyt ogólne, ponieważ nie dostaniemy tego, czego potrzebujemy. Nie mogą też być zbyt szczegółowe, bo wówczas zabijamy kreatywność naszego zespołu. Kryteria akceptacji muszą opisywać potrzeby, a nie konkretne rozwiązania.

Dlaczego zespół programistów może polubić szczegółowe kryteria akceptacji?

Kryteria akceptacji mogą być dużą oszczędnością czasu. Po co więc tracić czas i omawiać szczegóły, skoro Właściciel Produktu i tak powinien o wszystkim wiedzieć – jest przecież ekspertem w dziedzinie domeny? W końcu rozmawiał z klientem lub interesariuszami, żeby wszystko dokładnie opisać.

Niestety takie podejście może być bardzo trudne. Podczas dopracowywania lub planowania, wyjątkowo mniej doświadczony zespół może zgodzić się na wdrożenie i nie zastanawiać się nad konsekwencjami kryteriów akceptacji. Taka rzecz doprowadzi do wytworzenia przyrostu, który nie w pełni odpowiada potrzebom klienta.

Podsumowanie

Kryteria akceptacji są kluczowym elementem każdej historyjki użytkownika, nad którą pracuje zespół zwinny. Jasno określają one zakres, pożądane wyniki i kryteria testowania elementów funkcjonalności, nad którymi pracuje zespół dostarczający. Sam proces tworzenia i uzgadniania kryteriów akceptacji jest również nieocenioną okazją do komunikacji między programistami a produktami.

Literatura:

Dzierżek T., „Kryteria Akceptacji wymagań”, #bialko, 2021.

Fliszta M., „Kryteria akceptacji – jak bardzo powinny być szczegółowe?”, marcinfliszta.pl, 2020.

Gowin E., „Kryteria akceptacji i definicja ukończenia”, Agile247, 2017.

„Kryteria akceptacji – jaka jest rola każdej ze stron zaangażowanych w projekt IT?”, Studio Software, 2020.