Ostatnio dla moich zespołów przygotowałem krótki poradnik, jak pracować z user story. Dzisiaj chciałbym się nim z Wami podzielić. Być może komuś się przyda. Zapraszam do lektury.
Bardzo krótki wstęp
Każda historyjka powinna być pisana w kontekście konkretnej zdefiniowanej potrzeby użytkownika i realizować jakąś „mikrofunkcjonalność” od początku do końca. Nie tworzymy osobnych historyjek na każdy etap procesu wytwórczego, czyli na analizę, kodowanie, testowanie, etc. Każda z tych czynności może być składową jednej historyjki. Możemy tę czynność zapisać jako podzadanie lub „przepinać” historyjkę między kolejnymi członkami zespołu deweloperskiego.
Przed zabraniem do sprintu
Przed zabraniem historyjki do sprintu powinna ona zostać odpowiednio przygotowana, tak aby spełniać Definition od Ready. Wydarzeniem, na którym można i powinno się przygotowywać historyjki, nie jest planowanie sprintu lecz refinement. Na planowaniu planujemy wcześniej przygotowane na refinemencie historyjki. Zalecaną praktyką jest, aby w każdym sprincie zespół przeprowadził jeden refinement, na którym przygotuje historyjki na kolejny sprint (z małą nadwyżką, tak, aby w backlogu rosła liczba historyjek do podjęcia w sprintach). Idealnie jest, gdy mamy w backlogu tyle przygotowanych historyjek, aby wypełnić nimi dwa – trzy kolejne sprinty.
Jak powinna wyglądać odpowiednio przygotowana historyjka
Historyjka powinna być na tyle mała, aby można ją było zrealizować w jednym sprincie, powinna być wyestymowana, mieć spisane kryteria akceptacji, zespół MUSI mieć wspólne zrozumienie tego, co jest do zrobienia. Ustalone jest, jakie testy będą automatyzowane.
Przykładowe Definition of Ready może wyglądać tak:
- Zespół ma wspólne rozumienie tego, co jest do zrobienia
- Element jest oszacowany
- Określono kryteria akceptacji
- Jest możliwy do ukończenia w jednej iteracji
- Zdefiniowano testy akceptacyjne jakie mają być zautomatyzowane
- Zdefiniowano obszary dla testów eksploracyjnych
Do sprintu nie powinny wchodzić historyjki, które nie spełniają DoR.
Kryteria akceptacji – a co to?
Kryteria akceptacji jasno definiują, po czym poznamy, że daną historyjkę możemy uznać za zakończoną. Stosujemy je łącznie z Definition od Done. W kryteriach możemy zawrzeć wymagania funkcjonalne oraz pozafunkcjonalne. W DoD (stałym i jednakowym dla wszystkich historyjek) są wymagania jakościowe.
Kryteria spisujemy w formie kolejnych punktów, które można odhaczać, w trakcie prac nad historyjką.
Poniżej przykład historyjki z kryteriami akceptacji:
Historyjka:
Jako użytkownik systemu XYZ chciałbym się do niego zalogować, aby móc skorzystać z oferowanych funkcjonalności.
Kryteria akceptacji:
- okienko logowania pozwala wprowadzić login i password
- pole „hasło” nie pokazuje wpisywanych znaków tylko gwiazdki
- w polu „login” nie można wprowadzić polskich znaków
- okno logowania wyświetlane jest na środku ekranu
- operacja zalogowania od chwili wpisania loginu i hasła trwa nie dłużej niż 5 sekund.
Dobrze spisane kryteria akceptacji są najlepszą instrukcją, jak zrealizować daną historyjkę.
Podzadania w historyjce
Podzadania są to małe, atomowe czynności, które muszą zostać zrealizowane, aby zakończyć prace nad historyjką. Przykładowe podzadania do powyższego przykładu historyjki z kryteriami akceptacji:
- Implementacja okna logowania
- Implementacja walidacji na polach „login” i „password”
- Implementacja serwerowego mechanizmu logowania
- Testy manualne
- Test automatyczny logowania do systemu
- Test wydajnościowy
- Integracja okienka logowania z systemem XYZ
- Dokumentacja użytkownika
- Dokumentacja techniczna
Po sprincie, czyli sprawdzamy, czy historyjka została zrealizowana.
Na koniec sprintu przychodzi moment, aby zweryfikować, czy daną historyjkę zrealizowaliśmy, czy nie. Pomogą nam w tym kryteria akceptacji oraz Definition of Done. W pierwszej kolejności sprawdzamy, czy zastosowaliśmy się do wszystkich wymaganych punktów Definition of Done, a następnie patrzymy, czy wszystkie kryteria akceptacji są spełnione. Jeśli którykolwiek z punktów DoD lub kryteriów akceptacji nie został spełniony – historyjki nie możemy uznać za zakończoną a Product Owner decyduje, czy prace będą kontynuowane w kolejnym sprincie, czy musi ona poczekać na swoją kolej w backlogu.
Definition of Done
Definition of Done, czyli definicja ukończenia – jednakowa dla wszystkich historyjek. Określa wymagania jakościowe całej organizacji i pojedynczego zespołu. Na poziomie całej organizacji zdefiniowane jest jedno spójne DoD, które MUSI być przestrzegane przez wszystkie zespoły. Każdy dział / pion / zespół może sobie do DoD dopisywać własne punkty z zachowaniem jednej podstawowej zasady – DoD niższego poziomu MUSI spełniać założenia przyjęte na poziomie wyższym.
DoD na poziomie całej organizacji -> DoD na poziomie działu / pionu (spełnia DOD na poziomie całej organizacji + może mieć własne warunki) -> DOD zespołu (spełnia DOD działu/pionu + może mieć własne warunki)
Poniżej przykład DoD na poziomie organizacji:
- Historyjka jest udokumentowana
- Spełnia kryteria akceptacji
- Przyrost jest wdrożony na środowisko integracyjne
oraz przykład rozszerzenia na poziomie zespołu:
- Został wykonany i zaakceptowany przegląd kodu
- Statyczna analiza kodu nie wykryła krytycznych nieprawidłowości
- Zaimplementowano przewidziane testy automatyczne i przechodzą one pozytywnie
To już koniec mojego krótkiego poradnika. Poniżej zamieszczam link do pobrania go w postaci PDFa oraz oczywiście zachęcam do komentowania pod postem.