niedziela, 11 listopada 2012

Od czego zaczynamy każdą iterację - spotkanie sprint planning

sprint planning meeting
Spotkanie sprint planning
Spotkanie sprint planning determinuje początek nowego sprintu. Celem spotkania w tak wczesnej fazie każdej nowej iteracji jest doprecyzowanie, przy czynnym udziale zespołu, kompletnej listy zpriorytetyzowanego product backlogu, która będzie stanowić zakres pracy do wykonania. Zakres pracy który zostanie podczas tego spotkania doprecyzowany i wyceniony przez zespół, biorąc pod uwagę dodatkowe dane takie jak wydajność zespołu czy czas trwania sprintu, wejdzie w skład sprint backlog.Spotkanie jest ograniczone w czasie(time boxed), dla sprintów trwających 2 tygodnie do około 8h. Najlepiej aby takie spotkanie odbywało się na początku tygodnia. Nie jest do zawsze łatwe ponieważ wymaga się od  Product Ownera wcześniejszego przygotowania product backlog, pod kątem priorytetów i zawartości merytorycznej itemów.

Aby spotkanie było efektywne należy zapewnić:
  • Itemy z najwyższym priorytetem powinny być oszacowane przez zespół pod kątem skomplikowania, przypisana odpowiednia ilość story points
  • Product backlog zbudowany w odpowiedni sposób tzn. itemy o najwyższym priorytecie są na górze
  • Zespół powinien posiadać ogólną wiedzę na temat planowanych na dany sprint itemów
  • Product Owner jako właściciel produktu może chcieć w ramach sprintu budować nowe funkcjonalności lub poprawiać już istniejące, konkretne user story powinny być odpowiednio małe tak aby mogły być zrobione w ramach jednej iteracji, jeśli jest inaczej zbyt duże itemy muszą zostać podzielone na mniejsze.

W tym spotkaniu zazwyczaj biorą udział:

1) Scrum Master, rolą Scrum Mastera jest przedstawienie członków zespołu, przybliżenie ich ról w projekcie oraz prowadzenie spotkania od strony organizacyjnej.
2) Product Owner, przegląda z zespołem itemy o najwyższym priorytecie, przedstawia cel sprintu jaki będzie oczekiwany, objaśnia szczegóły oraz kryteria akceptacji poszczególnych funkcjonalności, dodatkowo może wyjaśnić zespołowi czemu interesariusze nadali priorytety właśnie tym konkretnym itemom, tak aby jasno przestawić cel sprintu i zmotywować zespól do wydajnej pracy.
3) Zespoł, rolą zespołu jest zdefiniować prognozę prac i wysiłek jaki trzeba będzie w to włożyć aby dotrzymać prognozowany kawałek product backlogu, dodatkowo wypytać product ownera o wszystkie szczegóły których w danych momencie nie rozumieją aby pozytywnie rozpoznać ilość i skomplikowanie pracy oraz móc podzielić user story na zadania
4) Inni zainteresowani interesariusze

Czynnikiem który należy wziąć pod uwagę planując nową iterację jest wydajność zespołu. Dojrzałe zespoły mają zbadaną i potwierdzoną średnią wydajności, mogą w oparciu o te dane i plan dostępności zasobów dawać dość dokładną prognozę itemów które mogą wejść w skład sprint backlogu. Nowe zespoły nie będą znały swojej wydajności wobec czego będą zmuszone opierać się na kompetencjach i tym czy im się wydaje że dadzą radę dostarczyć tyle na czas. Aby określić wydajność nowego zespołu lub nowego członka zespołu należy poznać 3 wartości (liczbę wydajnych godzin pracy, ilość dni w sprincie kiedy dana osoba uczestniczy w projekcie oraz procent czasu jaki będzie dedykowana do zespołu) Mając dane te 3 wartości możemy zgrubnie oszacować wydajność.

Sugerowana agenda spotkania Sprint Planning może wyglądać następująco:

1) Product Owner mając przygotowany "wierzchołek product backlog" przedstawia zespołowi co będzie celem danego sprintu(tzw. sprint goal)
2) Product Owner razem z zespołem przechodzi przez wszystkie itemy z detalami, które życzy sobie aby były częścią sprintu, zespół doprecyzowuje detale itemów, stara się zrozumieć zakres prac tak aby móc później szybko podzielić każde user story na zadania
3) Po skończonym przeglądzie i mając określony stopień trudności każdego z user story, zespół przystepuje do podziału user story na zadania, Product Owner nie musi uczestniczyć w tej części prac, jednak nadal powinien pozostawać w dyspozycji zespołu, gdyby pojawiły się wątpliwości
4) Zespół każde user story dzieli na odpowiednie zadania, następnie zadania są wyceniane pod kątem czasochłonności, mając te informacje zespół wie ile zadań będzie w stanie wykonać w ramach sprintu
5) Mając zważone user stories zespół selekcjonuje spośród itemów o najwyższym priorytecie te które mogą być zrobione, zazwyczaj na sprint backlog składa się kilka dużych user stories o najwyższym priorytecie uzupełnionych o user story mniejsze również o wysokim priorytecie. 
6) Scrum Master potwierdza prognozę prac w oparciu o znaną z przeszłości wydajność zespołu oraz dostępność zasobów, dla nowych zespołów pomaga wyznaczyć zgrubne wartości wydajności.
7) Następnie kompletna lista user storych prognozowanych do dostarczenia przez zespół jest przedstawiana product ownerowi do finalnego zatwierdzenia, user stories z najwyższym priorytetem które nie zmieściły się w prognozie mogą być umieszczone na liście rezerwowej(w odpowiedniej kolejności)
8) Kiedy Product Owner daje akceptację mamy uformowany sprint backlog oraz mogą rozpocząć się prace deweloperskie...     

Brak komentarzy:

Prześlij komentarz