Kryteria akceptacji i Definicja ukończenia [agilestarter]

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ęć 🙂

 

 

 

 

Komentarze do wpisu: “Kryteria akceptacji i Definicja ukończenia [agilestarter]

  1. Zaciekawiło mnie stwierdzenie, że na początku DoD może być krótkie, a z czasem się rozrasta. Moje doświadczenia ostatnich lat są dokładnie odwrotne. Mniej dojrzałe zespoły tworzą na początek bardzo rozbudowane DoD, z wieloma „jeśli, to…, a jeśli co innego to…’. Im zespół dojrzalszy, tym częściej DoD ścina do na prawdę fundamentalnych rzeczy, a wiele punktów, które były na początku, wylatują, gdyż po prostu są częścią kultury programistycznej zespołu.

    • Hej Filip 🙂 Nie będę polemizować, bo twoja obserwacja jest jak najbardziej prawdziwa. Dziękuję Ci za zwrócenie uwagi oraz cenny głos do artykułu.
      Gwoli wyjaśnienia – użyłam skrótu myślowego, także opierając się na swoich doświadczeniach (co jak widać się na mnie zemściło ;->), które akurat były odwrotnie. Czasem była to kwestia nowych zespołów, dopiero kształtujących się, w których deweloperzy nie znali się dobrze i nie wiedzieli na początku, czego od siebie oczekiwać w DoD; czasem była to kwestia pracy nad nowym produktem, bądź w nowej technologii, kiedy zespół stwierdzał, że nie jest w stanie na początku określić dobrze, co powinno być w DoD; a czasem odwrotnie – była to kwestia dojrzałego zespołu, który chojrakował, że nie potrzebuje rozbudowanego DoD, a po paru wtopach decydował się jednak na jego porządniejsze rozpisanie.
      Co jeszcze ważne, o tworzeniu DoD piszę raczej w kontekście opcji, możliwości, żeby osoby, które chciałyby zacząć stosować Definicję ukończenia, nie starały się na siłę od początku zawrzeć w niej wszystko (i tak możemy nie przewidzieć różnych przypadków, a możemy stracić dużo czasu). Stąd mój początek zdania „Na początku lista może być krótka(…)”. Jeśli zespół zacznie od jednego punktu, będzie ok. Za tydzień, dwa, czy miesiąc poszerzą DoD o następne warunki. Oczywiście, w drugą stronę też można, jeśli zespół woli na początku spróbować zaopiekować dla bezpieczeństwa wszelkie przypadki, a potem ew. ścinać DoD o już nieaktualne punkty. Co zespół, to inna kultura i podejście do tematu 🙂


Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

*

Ta strona używa Cookies. Korzystając ze strony wyrażasz zgodę na używanie ciasteczek zgodnie z aktualnymi ustawieniami przeglądarki.
Akceptuję, bo lubię Was czytać.
x