Kryteria akceptacji i Definicja ukończenia

Tytułowe narzędzia, choć powinny ułatwiać zespołom prace, bardzo często sprawiają jednak problemy i bywają ze sobą mylone. Pora zatem przybliżyć je i wyjaśnić nieporozumienia z nimi związane w ramach naszej serii Agile Starter.

Kryteria akceptacji

Czym są Kryteria akceptacji?

Najkrócej i najprościej mówiąc to lista konkretnych wymagań i warunków do spełnienia, aby Zespół Scrumowy wiedział, czy historyjka została poprawnie wykonana z biznesowego punktu widzenia. Co ważne, każda historyjka będzie miała odrębne, tylko sobie właściwe kryteria akceptacji. Dlaczego? Ponieważ kryteria mówią o potrzebach użytkowników, klientów i opisują funkcje, jakie chcemy zaimplementować, a tworząc jak najmniejsze historyjki, staramy się spełnić jedno wymaganie naraz.



Jak tworzyć Kryteria akceptacji?

Kryteria powinny zawsze opisywać tylko to, CO ma zostać wykonane, a nie za pomocą jakich rozwiązań dojdziemy do efektu końcowego. Mówią o tym, jaki ma być produkt, jakie ma posiadać cechy, jakie funkcje spełniać, ale nie definiują kolejnych kroków procesie, nie podpowiadają konkretnych odpowiedzi. Dzięki temu zawsze będziemy pamiętać, co chcemy osiągnąć, jaki cel przyświeca historyjce, a nie skupimy się na warstwie implementacyjnej, która pozostaje w gestii Zespołu Deweloperskiego. Oczywiście, to nie jest dogmat – jeśli przy rozmowie na temat historyjki Zespół Scrumowy dojdzie do jakichś rozwiązań, jak najbardziej może zgodzić się, że wpisze je sobie albo do kryteriów, albo w komentarzu do zadania w Backlogu Produktu, choćby po to, żeby nie zapomnieć o ustaleniach. Im lepiej, bardziej precyzyjnie i szczegółowo opisane kryteria, tym mniejsze ryzyko popełnienia błędu, czy wykonania zadania w niewłaściwy sposób. Starajmy się jednak zachować zdrowy rozsądek – jeśli z kryteriów robi nam się lista dwudziestu wymagań, to może zastanówmy się, czy historyjka nie jest nadal zbyt złożona, czy nie można by jej podzielić na mniejsze, czy faktycznie wszystkie te wymagania muszą zostać spełnione, aby użytkownik/klient odczuł wartość.

Kiedy tworzyć Kryteria akceptacji?

Bardzo możliwe, że pierwsza lista kryteriów pojawi się już przy wpisywaniu historyjki do Backlogu Produktu. Klient, użytkownik czy Product Owner mogą przyjść z gotowym pomysłem i warunkami, które go dodefiniowują. W trakcie pracy nad Backlogiem (refinement) Zespół Scrumowy powinien przejrzeć te kryteria i doprecyzować, o co konkretnie w historyjce chodzi. Kryteria mogą być usuwane i dopisywane tak naprawdę przez cały czas życia historyjki w Backlogu Produktu. Ostatnim momentem na ich poprawki, moim zdaniem, powinno być Planowanie Sprintu. Później ewentualne zmiany mogą wpłynąć na prace Zespołu Deweloperskiego w Sprincie i, co gorsza, na realizację bądź modyfikację celu Sprintu. Nie oznacza to oczywiście, że po wzięciu zadania na sprint zamrażamy jego kryteria – raczej w trakcie Sprintu z większą uwagą i ostrożnością powinniśmy podchodzić do ich zmian. Najważniejsze, by pamiętać, że kryteria tworzymy ZANIM przystąpimy do pracy nad zadaniem, bo chodzi nam o odzwierciedlenie intencji klienta/użytkownika, a nie opisanie kodu, który właśnie powstaje.

Kto tworzy Kryteria akceptacji?

W akapitach powyżej najczęściej wymieniałam głównie Zespół Scrumowy, ponieważ za stworzenie dobrych kryteriów akceptacji odpowiedzialni są wszyscy członkowie zespołu. Product Owner jako osoba, która przekazuje wymagania użytkownika/klienta i warunki do spełnienia podczas implementacji historyjki, Zespół Deweloperski, który dopytuje i doprecyzowuje „o co klientowi chodziło”, żeby mieć pewność, że wie, jaką pracę ma wykonać, a także Scrum Master, który dba o to, żeby obie pozostałe role wyjaśniły sobie całość zadania, zadały wszystkie niezbędne pytania, nie zapomniały o zależnościach, reszcie produktu i innych, dla tego Zespołu Scrumowego szczególnych uwarunkowaniach niezbędnych podczas pracy. Jeśli nie pracujemy Scrumem, nie mamy zespołu Scrumowego, ale chcemy używać Kryteriów Akceptacji w swojej pracy, pamiętajmy, żeby w ich tworzeniu brały udział wszystkie osoby zainteresowane wykonaniem zadania, czyli i biznes, i deweloper, i tester, i UX i każda inna osoba zaangażowana w proces dostarczania produktu klientowi końcowemu. Dzięki temu zminimalizujemy ryzyko wykonania niewłaściwej pracy.

Definicja ukończenia

Czym jest Definicja ukończenia?

Wg Scrum Guide’a „w celu zapewnienia przejrzystości wszyscy członkowie danego zespołu muszą mieć wspólne zrozumienie, co oznacza stwierdzenie, że praca została zakończona.” Definicja ukończenia, albo w skrócie DoD (Definition of Done) jest zatem również listą kryteriów, warunków i cech, które historyjka musi spełnić, by można było ją uznać za skończoną. Co ważne, w przeciwieństwie do Kryteriów akceptacji, które mówią o stronie biznesowej, DoD dotyczy strony technicznej – pomaga zespołom podnosić jakość i dbać o kompletność wykonywanych zadań. W związku z tym Definicja ukończenia będzie wspólna dla wszystkich historyjek danego zespołu.

Jak tworzyć Definicję ukończenia?

Spisując DoD Zespół Scrumowy powinien mieć zawsze z tyłu głowy jakość i kompletność wykonywanych zadań. Definicja ukończenia będzie więc mówić i o tym, CO trzeba wykonać (testy, code review), i o tym, JAK trzeba wykonać poszczególne wymogi DoD. Najprościej będzie, jeśli zespół wyjdzie od stwierdzenia, że zadanie ukończone (done), to takie, przy którym już NIC nie trzeba zrobić i które może w dowolnym momencie, po znaku od Product Ownera zostać wdrożone (przy czym wdrożenie również nie oznacza żadnych dodatkowych działań). Taki komunikat bardzo szybko wygeneruje zespołowi długą listę zadań, która może służyć za DoD. Pamiętajmy jednak o tym, że DoD żyje – warto mu się przyglądać i uaktualniać, jeśli któreś z warunków już nie są potrzebne, albo pojawiły się nowe, bo zmieniła się technologia, architektura, czy infrastruktura dla produktu.

Kiedy tworzyć Definicję ukończenia?

DoD kształtuje się cały czas, gdy zespół pracuje nad produktem. Na początku lista może być krótka i zawierać tylko np. wymóg sprawdzenia kodu przez dwie osoby i konieczność pokrycia testami przynajmniej 60% kodu. Z czasem, gdy produkt będzie coraz dojrzalszy, zespół będzie również powiększał Definicję ukończenia o dodatkowe warunki, uwzględniające problemy, które pojawiały się podczas implementacji i wdrożenia. Mogą to być punkty dotyczące choćby testów regresyjnych, utrzymania wydajności  serwerów, czy SLA produktu. Wymogi te będą właściwe dla specyfiki pracy danego zespołu, ale jeśli nad danym produktem pracuje ich kilka, to prędzej czy później zespoły dojdą do przekonania, że wspólne DoD usprawni ich współpracę. DoD może być również globalne – wspólne dla całej organizacji, by wspierać standardy pracy, wysoką kulturę techniczną i zapewniać równą jakość dla wszystkich wydań.

Kto tworzy Definicję ukończenia?

W tworzeniu Definicji ukończenia największy udział mają deweloperzy, ponieważ oni są odpowiedzialni za jakość, kompletność i sposób wykonania zadań. Warto jednak, aby DoD było tworzone w obecności i przy udziale Product Ownera. Odwrotnie niż przy Kryteriach akceptacji, tutaj on jest stroną zadającą pytania, by zrozumieć, jak ta lista wymagań będzie wpływać na rozwój jego produktu, jakie może narzucać mu ograniczenia i z czym wiązać się będą dla niego wdrożenia. Scrum Master natomiast ponownie jest tutaj stroną dopilnowującą, by pozostałe dwie role wyjaśniły sobie wszystko i wyszły z tworzenia DoD ze wspólnym i takim samym rozumieniem tego narzędzia. W tym miejscu, jeszcze raz wspomnę o globalnej Definicji ukończenia, funkcjonującej na poziomie całej organizacji – Scrum Guide wspomina, że standardy ogólnofirmowe powinny być uwzględnione w DoD, czyli obok Zespołów Scrumowych również inne osoby w firmie mogą wziąć udział w tworzeniu DoD, np. architekci, Security, czy CTO. I podobnie, jak w przypadku Kryteriów akceptacji, niezależnie od tego, czy pracujemy Scrumem, czy nie, możemy wykorzystać Definicję ukończenia do poprawy naszych procesów na poziomie pojedynczego zespołu i całej organizacji.

P.S. Dzięki zapędom artystycznym Izy artykułowi towarzyszą dwa obrazki mnemotechniczne – mam nadzieję, że utkwią wam w głowach i pozwolą w razie wątpliwości odświeżyć sobie pamięć 🙂

Posłuchaj też podcastu Porządny Agile. Odcinek #094 – Kryteria akceptacji.

Ta strona używa Cookies, korzystając z niej wyrażasz zgodę na używanie ciasteczek zgodnie z ustawieniami przeglądarki. Nasza Polityka Prywatności
Akceptuję, bo lubię Was czytać.
x