Definicja Gotowości wobec Kryteriów Akceptacji w Scrumie – Pełny Przewodnik

Definicja Gotowości (DoD) to lista wymagań, które historia użytkownika musi spełnić, aby zespół uznał ją za zakończoną. Podczas gdy kryteria akceptacjihistorii użytkownika obejmuje zestaw przypadków testowych, które muszą zostać spełnione, aby potwierdzić, że oprogramowanie działa zgodnie z oczekiwaniami.

Kluczowa różnica polega na tym, że DoD jest wspólne dla wszystkich historii użytkownika, podczas gdy kryteria akceptacji są specyficzne dla poszczególnych historii użytkownika. Kryteria akceptacji dla każdej historii użytkownika będą się różnić w zależności od konkretnych wymagań tej historii.

Innymi słowy, obie Definicja Gotowości i kryteria akceptacji muszą zostać spełnione, aby historia użytkownika mogła być uznana za zakończoną. Inkrement produktu nie jest uznawany za zakończony, chyba że obie listy sprawdzające zostały w pełni spełnione. Dlatego musimy zdefiniować dwa aspekty Definicji Gotowości: DoD i kryteria akceptacji:

Definicja Gotowości wobec Kryteriów Akceptacji

Definicja Gotowości:

Definicja Gotowości jest zbudowana jako lista kontrolna, przy czym każdy element stanowi punkt weryfikacji dla historii lub PBI. Jej celem jest zapewnienie, że zespół deweloperski zgadza się na jakość pracy, którą dostarcza. Służy jako lista kontrolna do weryfikacji kompletności każdego katalogu produktuelementu (znane również jako PBI lub historia użytkownika). Elementy Definicji Gotowości mają zastosowanie do wszystkich elementów katalogu produktu, a nie tylko do poszczególnych historii użytkownika. Można ją podsumować następująco:

• Dotyczy całego inkrementu produktu
• Wskazuje, że inkrement produktu jest potencjalnie gotowy do wysyłki w większości przypadków
• Zdefiniowane w Przewodniku Scrum
• Służy jako narzędzie komunikacji między członkami zespołu:
  • Ogólna jakość oprogramowania
  • Czy inkrement jest gotowy do wysyłki

Cele Definicji Gotowości

• Ustalić wspólną koncepcję jakości i kompletności w całym zespole
• Służyć jako lista kontrolna do weryfikacji historii użytkownika (lub PBIs)
• Zapewnić, że inkrement wytworzony na końcu Sprintu ma wysoką jakość i że wszyscy uczestnicy jasno rozumieją standardy jakości

Przykład – Definicja Gotowości

Na przykład w branży oprogramowania zespoły mogą zadać następujące pytania, aby zdefiniować swoją Definicję Gotowości:

• Czy kod został sprawdzony przez kolegę?
• Kod zakończony?
• Kod przejrzany?
• Kod zapisany?
• Testy jednostkowe zaliczone?
• Testy funkcyjne zaliczone?
• Testy akceptacyjne zakończone?
• Właściciel produktu ma przejrzał i zaakceptował

Kryteria akceptacji

Historia użytkownika to jedno z kluczowych artefaktów w rozwoju agilnym, ale Scrum nie wymaga jawnie używania historii użytkownika ani kryteriów akceptacji. Jeśli element listy backlogu produktu jest zbyt duży, by zmieścić się w Sprint, zwykle dzieli się go na historie użytkownika, a następnie dalej na zestaw zadań, jak pokazano poniżej:

Kryteria akceptacji

Historie użytkownika zawierają kryteria akceptacji, dlatego często widzimy Definicję Gotowości i kryteria akceptacji współistniejące w naszych procesach Scrum. Historia użytkownika dostarcza kontekstu dla funkcjonalności, którą zespół powinien dostarczyć. Kryteria akceptacji dostarczają szczegółowych wskazówek, co funkcja powinna robić i jak klient ją zaakceptuje. Razem definiują kompletny produkt gotowy do dostarczenia.

Niektóre kryteria akceptacji są odkrywane podczas trwającej sesji dopasowania listy backlogu przed rozpoczęciem Sprintu, podczas gdy inne są identyfikowane od razu po Planowaniu Sprintu, aby zespół mógł przeprowadzić rozmowę na temat historii użytkownika. Dlatego kryteria akceptacji są unikalną cechą historii użytkownika lub elementu listy backlogu produktu.

• Dotyczy poszczególnych elementów listy backlogu produktu/historii użytkownika
• Kryteria akceptacji różnią się w zależności od elementu listy backlogu produktu/historii użytkownika
• Nie są zdefiniowane w Przewodniku Scrum
• Służy jako narzędzie komunikacji do spełnienia określonych wymagań elementu listy backlogu produktu/historii użytkownika
• Znane również jako testy akceptacyjne, warunki zadowolenia lub w niektórych przypadkach „przypadki testowe”

Cele kryteriów akceptacji

• Ustalić, co zespół powinien ustalić przed rozpoczęciem pracy
• Zapewnić, że wszyscy mają wspólną wiedzę na temat wymagań
• Pomóc członkom zespołu zrozumieć, kiedy historia jest zakończona
• Pomóc zweryfikować historię za pomocą testów automatycznych

Przykład – Kryteria akceptacji

• Użytkownik nie może przesłać formularza bez wypełnienia wszystkich wymaganych pól
• Informacje z formularza są przechowywane w bazie danych rejestracji
• Goście mogą płacić kartą kredytową
• Po przesłaniu formularza użytkownikowi wysyłany jest e-mail potwierdzający

Przykład historii użytkownika z kryteriami akceptacji

Poniższy obraz pokazuje przykład kryteriów akceptacji dla historii użytkownika.

Przykład definicji gotowości