Kilka słów o Definition of Done

W ramach cyklu artykułów “Scrum oczami testera” postaramy się tym razem przybliżyć Wam, co to takiego jest i czym charakteryzuje się definicja zakończenia (ang. Definition of Done, DoD).

 

Pojęcie …

Definicja zakończenia to nic innego, jak lista kontrolna, która pozwala nam odpowiedzieć na pytanie, czy element Product Backlogu, który był realizowany (ang. Product Backlog Item, PBI), jest rzeczywiście ukończony. Jak wiemy, na koniec Sprintu powinien być dostarczany przyrost gotowy do potencjalnego wdrożenia. W sytuacji, gdybyśmy nie mieli wspólnej dla wszystkich członków zespołu listy DoD, każdy mógłby w inny sposób rozumieć to, co kryje się pod pojęciem “zakończone”.

Definition Of Done

 

Charakterystyka …

  • DoD jest znana i stosowana przez cały Scrum Team

Zawartość DoD musi być dostępna i przejrzysta dla wszystkich członków Zespołu Scrumowego, aby każdy był w stanie zapoznać się z jej treścią. Dodatkowo każda osoba ze Scrum Teamu powinna jednakowo rozumieć, co kryje się pod poszczególnymi elementami DoD. Aby to zapewnić, definicja zakończenia powinna być pisania w sposób jasny i zrozumiały dla osób zainteresowanych.

  • DoD wpływa na szacunki realizowanego zakresu

DoD ma duży wpływ na szacunki, których dokonuje Zespół Deweloperski. Im definicja zakończenia jest bardziej restrykcyjna i zawiera więcej elementów pozwalających uzyskać wysoką jakość tworzonego przyrostu, tym realizacja danego elementu Product Backlogu jest czasochłonniejsza. W związku z tym należy mieć stworzoną listę DoD przed spotkaniem Planowania Sprintu, gdyż od niej zależy, ile czasu będzie trzeba poświęcić na realizację danej funkcjonalności.

  • Kto definiuje DoD

Definicja i zawartość DoD jest wspólnie ustalana w ramach Scrum Teamu.

  • Kiedy można zmieniać DoD

Definicja zakończenia jest tworzona na długość jednego Sprintu. Na koniec Sprintu – na spotkaniu Sprint Retrospective, należy zrobić przegląd zawartości DoD i dostosować ją do potrzeb kolejnego Sprintu. Czasem jest tak, że definicja ta jest niezmienna przez okres kilku Sprintów, a czasem zmienia się co Sprint. Wszystko to zależy od potrzeb Scrum Teamu. Warto pamiętać, że DoD powinna być żywym elementem Scruma, być ciągle aktualizowana i dostosowywana do potrzeb kolejnych Sprintów. Należy jednak zaznaczyć, że ustalona definicja zakończenia nie może być zmieniana w trakcie trwania Sprintu, aby nie obniżać aspektów jakościowych poszczególnych elementów Product Backlogu w trakcie Sprintu.

  • DoD a wiele zespołów pracujących nad jednym produktem

Często spotykamy się z pytaniem, co w sytuacji, gdy nad jednym produktem pracuje więcej niż jeden Zespół Deweloperski. W takiej sytuacji powinna zostać stworzona wspólna definicja zakończenia, która będzie obowiązywać wszystkie te zespoły.

  • Aktualizacja DoD

Tak jak już wspominaliśmy, listy DoD należy poddawać regularnemu przeglądowi / aktualizacji (co najmniej jeden raz w trakcie Sprintu – podczas Sprint Retrospective). Często wraz z nabywaniem doświadczenia przez Zespół, definicja zakończenia staje się bardziej rozbudowana i zawiera coraz bardziej zaawansowane rzeczy do zrealizowania celem ciągłego podnoszenia jakości wytwarzanego produktu.

Aktualizacja DoD

 

Przykłady …

Należy pamiętać, że tworzenie DoD zależy od bardzo wielu czynników, takich jak technologie używane do budowy produktu czy standardy stosowane w organizacji itp. Wszystkie te elementy powinny być uwzględnione w trakcie tworzenia naszej listy DoD. Poniżej prezentujemy przykładowe definicje zakończenia z różnych perspektyw.

  • Testowanie
    • Opracowano testy jednostkowe dla krytycznej funkcjonalności
    • Wykonano testy regresyjne
    • Wszystkie błędy o priorytecie ‘krytyczny’, ‘bloker’ zostały rozwiązane i ponownie zweryfikowane
    • Przetestowano eksploracyjnie nową funkcjonalność
    • Wszystkie nowe funkcjonalności sprawdzono na przeglądarkach Internet Explorer 10 >, Safari, Firefox > 53
    • Zweryfikowano poprawność działania responsywności (dla nowej funkcjonalności oraz regresji)
    • Product Owner / Tester zweryfikowali każdą User Story w oparciu o kryteria akceptacji
    • Napisano testy UI do nowej funkcjonalności wraz z weryfikacją, czy działają poprawnie
    • Przegląd wszystkich wykrytych defektów i nadanie im priorytetów kolejności rozwiązania (bieżący bądź kolejny Sprint)
  • Kodowanie
    • Kod został umieszczony w repozytorium
    • Zmiany w kodzie zostały wprowadzone na środowisku testowym
    • Kod został napisany i opatrzony komentarzami zgodnie ze standardem panującym w organizacji
    • Kod został poddany przeglądowi przez innego programistę (Code Review)
  • Pozostałe
    • Utworzono / Zaktualizowano dokumentację techniczną
    • Utworzono / Zaktualizowano dokumentację użytkownika

 

Jeśli macie jakieś pytania o Definition of Done (bądź związane z tematem Scruma), piszcie do nas na adres kontakt@testpro.pl. Postaramy się rozwikłać Wasze wątpliwości.