Kryteria akceptacji w projekcie IT – definicja, tworzenie, przykłady

 

Kryteria akceptacji w projekcie IT – co to jest?

Kryteria akceptacji to lista konkretnych wymagań, które musi spełnić produkt, aby mógł zostać zaakceptowany przez interesariusza. Odnoszą się do user stories.

Jakie powinny być kryteria akceptacji user story?

Kryteria akceptacji powinny być precyzyjne, ale pozostawiające miejsce na modyfikacje, testowalne, zwięzłe, jednoznaczne, zrozumiałe dla każdego, kto pracuje nad projektem, biorące pod uwagę perspektywę biznesową. Kryteria akceptacji opisują intencje interesariuszy i potrzeby odbiorców, ale nie sposób realizacji zadania.

Kto tworzy kryteria akceptacji user story?

Za tworzenie kryteriów akceptacji odpowiedzialny jest Scrum Master lub Product Manager, ale przy udziale Product Ownera lub innej osoby wyznaczonej przez interesariuszy, a także całego zespołu (często scrumowego).

Kiedy sporządza się kryteria akceptacji?

Kryteria akceptacyjne tworzy się podczas wpisywania user stories do backlogu oraz prac nad refinementem. Powinny zostać sformułowane, zanim zespół przystąpi do realizacji zadań.

Jaki format powinny mieć kryteria akceptacji w projekcie?

Kryteria akceptacji powinny mieć formę checklisty (list kontrolnej) w formie zdań twierdzących albo pytań, szablonu Given / When / Then.

Czym są kryteria akceptacji w projekcie IT? Definicja

Kryteria akceptacji stosuje się w zwinnych metodach tworzenia oprogramowania (Agile, Scrum). Są listą konkretnych wymagań, które musi spełnić produkt, aby mógł zostać zaakceptowany przez interesariusza. Stanowią punkt odniesienia do user story – określają ich szczegóły, opisując, co ma zostać wykonane w ramach danego zadania, jakie cechy powinno mieć gotowe rozwiązanie i jakie funkcje spełniać. Nie zawierają przy tym informacji o technikach wykonania. Opisują cel, jaki chcemy osiągnąć, a nie kolejne kroki w procesie, które trzeba zrealizować, aby go uzyskać.

Kryteria akceptacji user story to spojrzenie na projekt z perspektywy biznesowej. Są jak busola, która pomaga nie stracić z oczu głównego celu: stworzenia użytecznego rozwiązania. Dzięki nim zespół developerski wie, czego oczekuje klient i jaki dokładnie powinien być produkt, aby uznać go za funkcjonalny.

Kryteria akceptacji a Definition of Done w Agile

Zdarza się, że kryteria akceptacji są mylone z innym pojęciem używanym w Agile – Definition of Done (DoD), czyli definicją ukończenia. DoD opisuje kryteria, które musi spełnić produkt, aby uznać, że prace nad nim zostały zakończone. Warunki te odnoszą się przede wszystkim do jego jakości i użyteczności technologicznej.

Przykładowa darmowa lista kontrolna Definition of Done do pobrania: Ageno – Ageno – Definition of Done przykładowa lista kontrolna – 1.0.0

Przykład: produkujemy biurka. Nasza Definition of Done mówi, że gotowy produkt będzie meblem, przy którym da się siedzieć i pracować. Nie określamy w niej jednak, jakie konkretnie cechy ma mieć to biurko: czy powinno zostać wykonane ze sklejki czy litego drewna, być czarne czy białe, czy ma mieć szuflady lub regulację wysokości. Takie szczegóły znajdą się dopiero w kryteriach akceptacji.

Czy któryś z tych terminów jest w pracy nad projektem ważniejszy? Nie. DoD mówi nam, że biurko jest biurkiem i że spełnia swoją podstawową funkcję. Dopiero po jej wypełnieniu możemy sprawdzić, czy produkt realizuje oczekiwania klienta – nie ma przecież sensu dywagować nad rozkładem szuflad, jeżeli przy biurku nie da się pracować, bo całe się chwieje. Bez zdefiniowania kryteriów akceptacji może się jednak okazać, że cała nasza praca była chybiona. Mieliśmy skonstruować minimalistyczne biurko do pracowni architektonicznej (duży blat, regulacja wysokości), a stworzyliśmy nieporęczny mebel w stylu Ludwika XIX (reprezentacyjny design do gabinetu adwokata).

Definition of Done i kryteria akceptacyjne są zatem odrębnymi kwestiami. Pierwszy z terminów określa esencję produktu, jego podstawowe założenie. Drugi – podaje szczegółowe cechy, ważne zwłaszcza pod kątem biznesowym, wyznaczając kierunek, w którym powinniśmy podążać, aby dobrze zrealizować cel.

Kto i na jakim etapie projektu powinien stworzyć kryteria akceptacji user story?

W opracowaniu kryteriów akceptacyjnych uczestniczy cały zespół pracujący nad projektem:

• Product Owner – ponieważ najlepiej zna produkt, intencje i wymagania interesariuszy, a także potrzeby odbiorców.
• Zespół developerski (w tym testerzy), który doprecyzowuje różne kwestie, aby mieć pewność, że każdy dobrze zrozumiał, co należy wykonać.
• Scrum Master / Project Manager, który jest pośrednikiem między zespołem a product ownerem – usprawnia komunikację, dbając o to, by obie strony wszystko dokładnie sobie wyjaśniły.

Ostatecznym sformułowaniem kryteriów – czyli nadaniem im zrozumiałej, spójnej formy – powinna zająć się jedna osoba, najlepiej Scrum Master czy Project Manager.

Kryteria akceptacji produktu można zacząć tworzyć już podczas wpisywania user stories do backlogu. Na tym etapie nie muszą być jednak ściśle sformułowane. W czasie prac nad refinementem prawdopodobnie będą się zmieniać, przyjmując coraz konkretniej sprecyzowaną formę. Najważniejsze, aby opracować je, ZANIM zespół przystąpi do realizacji zadania – w końcu ich istotą jest to, by oddać intencje klienta lub użytkownika, a nie opisywać powstający kod. W trakcie trwania sprintu można oczywiście wprowadzać do nich poprawki, ale z ostrożnością. Duże zmiany mogłyby zmienić sens user story, a to wywróciłoby projekt (i harmonogram) do góry nogami.

Dobrze sformułowane kryteria akceptacji w projekcie – czyli jakie?

Jakie powinny być dobre kryteria akceptacji produktu: ogólne i zwięzłe czy szczegółowe? Odpowiemy ulubionym zwrotem branży: to zależy. Generalnie im precyzyjniej i bardziej szczegółowo sformułowane zostaną kryteria, tym mniejsze będzie ryzyko wykonania zadania w niewłaściwy sposób i tym łatwiejsza będzie jego weryfikacja. Założenia nie mogą jednak przyjmować formy sztywnego wzoru, który należy dokładnie wypełnić. Metodyki zwinne tak dobrze sprawdzają się w zarządzaniu tworzeniem oprogramowania właśnie dlatego, że są ZWINNE – elastyczne i łatwe do zmiany na różnych etapach projektu.

Kryteria akceptacji nie mogą być więc zdefiniowanymi z góry, nienaruszalnymi warunkami. Powinny wyznaczać kierunek działania, ale nie narzucać jednego słusznego rozwiązania.

Oprócz tego kryteria akceptacji user story powinny być:

1. Testowalne – kryterium akceptacji powinno być tak sformułowane, abyśmy mogli prostym testem pass/fail sprawdzić, czy zostało wypełnione.
2. Zwięzłe – bez obszernych komentarzy i rozbudowanej dokumentacji. Jeśli do jednego user story przyporządkowujemy wiele kryteriów, warto się zastanowić, czy nie podzielić go na kilka mniejszych, albo czy wszystkie kryteria na pewno są potrzebne, by zapewnić wartość odbiorcy.
3. W pełni zrozumiałe – napisane prostym językiem, tak, aby każdy członek zespołu scrumowego oraz zlecającego wykonanie prac w pełni i szybko je zrozumiał.
4. Jednoznaczne – nie mogą pozostawiać pola do różnych interpretacji.
5. Sporządzone z zachowaniem perspektywy klienta – mają oddawać jego intencję, więc powinny uwzględniać perspektywę biznesową i określać potrzeby odbiorców.

Jak pisać kryteria akceptacji user story? Format

Nie ma jednego słusznego sposobu na formułowanie kryteriów akceptacji. Można je sporządzić w formie prostej checklisty albo skorzystać z metody Given/When/Then, gdzie:

• Given – określa warunki początkowe;
• When – opisuje akcję wykonywaną dla danej funkcjonalności;
• Then – precyzuje spodziewany rezultat.

W niektórych projektach mogą sprawdzić się również kryteria akceptacji spisane w formie pytań (a nie zdań twierdzących). Taka konstrukcja ułatwia weryfikację, czy zostały one zrealizowane, bo wymusza konkretną odpowiedź: tak / nie.

Niezależnie od tego, jaki format się wybierze, warto zastosować się do 3 praktycznych wskazówek:

• Używać strony czynnej (użytkownik wykona akcję), a nie biernej (akcja zostanie wykonana przez użytkownika) – to tzw. aktywny głos, zalecany zresztą w całej metodyce Agile. Stosowanie strony biernej sprawia, że komunikat się rozmywa – na pierwszy rzut oka nie widać, jaki sens z niego wynika.
• Pisać proste, zwięzłe zdania – lepiej rozpisać coś w kilku zdaniach niż jednym wielokrotnie złożonym.
• Unikać zdań przeczących – partykuła „nie” komplikuje konstrukcję zdania. Może też sprawiać, że kryterium nie będzie tak łatwo sprawdzalne.

Korzyści ze stosowania kryteriów akceptacji

1. Łatwiejsze planowanie pracy nad projektem. Rozpisanie kryteriów akceptacyjnych do konkretnego user story pozwala oszacować, jak rozbudowane będzie zadanie.
2. Lepsze zrozumienie intencji interesariuszy. Lista sprecyzowanych wymagań sprawia, że zespół od początku prac nad projektem wie, do czego dąży i jaki efekt ma uzyskać. Omówienie kryteriów akceptacyjnych z klientem pozwala, już na etapie ustalania wymagań, wyjaśnić niejasności i nieścisłości, a także zrozumieć ograniczenia czy wyzwania, jakie developerzy mogą napotkać podczas realizacji zadań.
3. Usprawnienie testów akceptacyjnych – przeprowadza się je właśnie na podstawie kryteriów akceptacyjnych, więc jeśli dobrze je sporządzimy, mamy gotowy scenariusz testów.

Kryteria akceptacji w projekcie IT – przykłady

Zadanie: Konfiguracja stanów magazynowych dla wersji językowych

User story: Jako administrator sklepu chcę, aby produkty w sklepie miały właściwe stany magazynowe w zależności od wersji językowej sklepu, abym mógł sprzedawać odpowiednią ilość danych produktów dla danej wersji sklepu.

Kryteria akceptacji:

— Produkty, które mają ustalone stany magazynowe w magazynie odpowiednim dla danej wersji językowej, są dostępne.

— Zakup produktu z danej wersji językowej powoduje, że produkt odejmuje się od stanu magazynowego właściwego dla danego magazynu.

— Stany magazynowe są aktualizowane w uwzględniony w specyfikacji sposób.

Zadanie: Walidacja kodu pocztowego

User story: Jako użytkownik sklepu chcę, aby przy zamówieniu był weryfikowany mój kod pocztowy w celu uniknięcia literówki.

Kryteria akceptacji:

— Walidacja prawidłowo weryfikuje poprawność wprowadzonego przez klienta kodu pocztowego.

— W przypadku wpisania nieprawidłowego kodu pocztowego, klient dostaje komunikat o błędzie.

— Jeżeli wysyłka jest możliwa do różnych krajów, to walidacja powinna być dostosowana do kodów pocztowych każdego z tych krajów.

Najważniejsze jest doświadczenie

Duże ułatwienie przy sporządzaniu kryteriów akceptacji stanowi doświadczenie. Jasne, każdy projekt IT jest inny – wychodzi od innych założeń, dotyczy innego produktu, ma inne cele. Wiele elementów w pracy zespołu developerskiego bywa jednak powtarzalnych. Jeśli wiemy, jakie kryteria wielokrotnie już się sprawdziły, a jakie okazały się całkowicie chybione, możemy definiować je jeszcze skuteczniej. Usprawnia to pracę nad wdrożeniem i sprawia, że produkt, który finalnie prezentujemy, w 100% odpowiada wizji klienta i potrzebom użytkowników.

---

W Ageno udoskonalamy procedurę tworzenia oprogramowania już od ponad 10 lat. Zaufaj naszemu doświadczeniu i przekonaj się, że Twój pomysł może stać się rzeczywistością szybciej, niż myślisz.

 

Źródło zdjęć: undraw.co, pixabay.com, unsplash.com