definicja zakończenia (DoD) to lista wymagań, które historia użytkownika musi spełniać, aby zespół mógł uznać ją za zakończoną.
kryteria akceptacji dla historii użytkownika obejmują zestaw scenariuszy testowych, które spełnią wymagania, aby potwierdzić, czy oprogramowanie działa zgodnie z oczekiwaniami.
Kiedy historia użytkownika będzie zakończona?
Innymi słowy, aby zakończyć historie użytkownika, muszą być spełnione DOD i kryteria akceptacji. Przyrosty produktu nie są uważane za zakończone, chyba że obie listy są ukończone. Dlatego musimy zdefiniować dwa aspekty definicji DoD – kryteria zakończenia i kryteria akceptacji:
Definicja Zrobione
Definicja Zrobione jest zorganizowana jako lista elementów, z których każdy służy do walidacji Historii lub PBI, co ma na celu zapewnienie, że Zespół Rozwojowy zgadza się co do jakości pracy, którą próbują wykonać. Służy jako lista kontrolna, która jest używana do sprawdzania każdy Backlog Produktu Element (znany również jako PBI) lub Historia Użytkownika dla kompletności. Elementy w definicji „Zrobione” mają być stosowane do wszystkich elementów w Backlogu Produktu, a nie tylko do pojedynczej Historii Użytkownika.
Można to podsumować w następujący sposób:
- Termin ten odnosi się bardziej do przyrostu produktu jako całości
- W większości przypadków termin ten sugeruje, że przyrost produktu jest gotowy do wysyłki
- Termin ten jest zdefiniowany w Przewodniku Scrum
- Używany jako sposób komunikacji wśród członków zespołu
- Ogólna Jakość Oprogramowania
- Czy przyrost jest gotowy do wysyłki, czy nie
Przykład — Definicja Zrobione
- Kod zrecenzowany przez kolegów?
- Kod ukończony?
- Kod zrecenzowany?
- Kod zatwierdzony?
- Testy jednostkowe zaliczone?
- Testy funkcjonalne zaliczone?
- Testy akceptacyjne ukończone?
- Właściciel Produktu zrecenzowane i zaakceptowane?
Kryteria Akceptacji
Historie użytkownika są jednym z podstawowych artefaktów dla rozwoju Agile, ale Scrum nie wymaga wyraźnie ani Historii Użytkownika, ani Kryteriów Akceptacji. Jeśli element backlogu produktu jest uważany za zbyt duży, aby umieścić go w sprincie, zazwyczaj jest dzielony na historię użytkownika, a następnie na zestaw zadań, jak pokazano na rysunku:
Historie użytkownika zawierają Kryteria Akceptacji, dlatego często widzimy, że definicja zakończenia i kryteria akceptacji współistnieją w naszym procesie rozwoju scrum. Historia użytkownika dostarcza kontekstu funkcjonalności, którą zespół powinien dostarczyć. Kryteria akceptacji dają wskazówki dotyczące szczegółów wspomnianej funkcjonalności i tego, jak klient je zaakceptuje. Oba te elementy razem stanowią całość dostarczanego produktu.
Niektóre z Kryteriów Akceptacji zostaną odkryte podczas bieżących wydarzeń Refinement Backlogu przed rozpoczęciem Sprintu, a inne zostaną odkryte tuż po Planowanie Sprintu gdy siądziemy, aby porozmawiać o historii użytkownika w małym zespole. Kryteria Akceptacji są więc atrybutami, które są unikalne dla Historii Użytkownika lub Elementu Backlogu Produktu.
- Termin ten odnosi się do pojedynczego PBI/Historii
- Kryteria Akceptacji są różne dla każdego PBI/Historii
- Termin nie jest zdefiniowany w Przewodniku Scrum
- Używany jako sposób komunikacji do wszystkich zaangażowanych, że wymagania dla danego PBI/historii zostały spełnione
- Znane również jako Testy Akceptacyjne, Warunki Satysfakcji, w niektórych przypadkach „Przypadki Testowe”, itd.
Przykład Historii Użytkownika z Kryteriami Akceptacji
Rysunek poniżej pokazuje przykład kryteriów akceptacji historii użytkownika.
Ten post dostępny jest również w Deutsch, English, Español, فارسی, Français, Bahasa Indonesia, 日本語, Portuguese, Ру́сский, Việt Nam, 简体中文 and 繁體中文