Agile w praktyce Podręcznik metod zwinnych Andy Brandt Ta książka jest do kupienia http://leanpub.com/agile_w_praktyce Wersja opublikowana 2017-11-22 ISBN 978-83-945494-0-4 This is a Leanpub book. Leanpub empowers authors and publishers with the Lean Publishing process. Lean Publishing is the act of publishing an in-progress ebook using lightweight tools and many iterations to get reader feedback, pivot until you have the right book and build traction once you do. 2013-2017 Andy Brandt
Tweet nij tę książkę Proszę pomóż Andy Brandt rozpowszechniać informację o tej książce na Twitter ze! Sugerowany tweet o tej książce to: A teraz będę czytać Agile w praktyce od @andybrandt Sugerowany tag do tej książki to #agilewpraktyce. Sprawdź co inni ludzie mówią o tej książce i kliknij na ten link, żeby poszukać tego tagu na Twitter ze: #agilewpraktyce
Also By Andy Brandt Environment for Agile Teams
Spis treści 1. Scrum......................... 1 1.1 Scrum w pigułce................ 2 Elementy Scruma.............. 2 Wymagania, backlog produktu....... 3 Role w Zespole Scrum............ 3 Proces.................... 6 Sprint.................. 8 Planowanie Sprintu........... 9 Daily Scrum............... 11 Pielęgnacja backlogu.......... 12 Produkt i kryteria ukończenia..... 13 Przegląd Sprintu............. 15 Retrospekcja............... 16 Podsumowanie i uwagi końcowe...... 17
1. Scrum Scrum został stworzony przez Kena Schwabera i Jeffa Sutherlanda na przełomie ubiegłego i bieżącego wieku. Bardzo szybko zdobył sobie popularność i jest obecnie wiodącą 1, podstawową metodą z rodziny agile. Początkowo metoda 2 ta była przekazywana ustnie, następnie w postaci szkoleń (pierwsze takie szkolenie odbyło się w 2001 roku). W 2006 roku ukazała się książka Software development with Scrum 3 napisana przez Kena Schwabera i Mikea Beedle. Znana wśród praktyków Scruma jako mała czarna książeczka była to pierwsza kompletna prezentacja metody w formie książkowej. Od 2010 roku metoda jest zdefiniowana w Scrum Guide - niezwykle zwięzłym bo zaledwie 17-o stronicowym dokumencie napisanym i utrzymywanym wspólnie przez obu twórców metody. Ostatnia jego wersja ukazała się 1 sierpnia 2013 roku. Poniżej przedstawiam samą metodę w sposób maksymalnie zwięzły, by następnie omówić niektóre praktyczne jej aspekty. Szczegółowe omówienie głównych praktyk znajduje się w innych rozdziałach. Niektóre z nich są używane także w innych metodach agile, a wiele z nich jest technikami samymi w sobie 1 W najróżniejszych badaniach, w których respondenci proszeni są o wskazanie metody czy też procesu stosowanego w ich firmie do budowy oprogramowania Scrum jest wskazywany najczęściej jeśli respondent twierdzi, że jego firma używa metod agile. 2 Za Słownikiem Języka Polskiego PWN: metodyka [gr.], metodol. zbiór zasad dotyczących sposobów postępowania, efektywnych ze względu na określony cel. Scrum wyczerpuje słownikową definicję metodyki, jednak ze względu na skojrzenia jakie niesie ze sobą to słowo (duże, ciężkie, zbiurokratyzowane metodyki takie jak Prince2) oraz na osobistą prośbę twórców Scruma stosuje się raczej na jego określenie słowo metoda. 3 http://goo.gl/itw6a
Scrum 2 czyli można je stosować także pojedyńczo. Siła Scruma polega na połączeniu ich w spójny, sprawnie działający system. Na końcu tego rozdziału znajduje się także krótkie omówienie ostatnich zmian w Scrumie (zarówno tych z 2011 r. jak i z 2013 r.). Może ono być pożyteczne dla osób, które szkoliły się ze Scruma przed ich wprowadzeniem. 1.1 Scrum w pigułce Scrum to metoda organizacji pracy nad wytwarzaniem produktu (oprogramowania - aplikacji, systemu itp.), w której nacisk kładzie się na dostarczanie maksymalnej wartości poprzez działające oprogramowane oraz elastyczność umożliwiającą szybką reakcję na zmiany. Scrum opisuje w jaki sposób przetwarzać pewną listę wymagań na gotowy produkt w regularnych interwałach z pomocą jednego, niewielkiego zespołu. Oficjalna definicja metody jest następująca: Scrum: sposób organizacji ludzkiego działania, w ramach którego możliwe jest rozwiązywanie skomplikowanych problemów oraz budowa produktów o najwyższej możliwej wartości. Elementy Scruma Scrum składa się z następujących elementów: Trzech ról: Zespół Developerski (Development Team), Scrum Master, Product Owner tworzący razem Zespół Scrum (Team, Scrum Team). Iteracji zwanych Sprintami oraz następujących podczas nich pięciu spotkań: Planowania Sprintu (Sprint Planning), codziennego Daily Scrum, Pielęgnacji Backlogu
Scrum 3 (Backlog Refining), Przeglądu Sprintu (Sprint Review) oraz Retrospekcji (Sprint Retrospective). Dwóch list: backlogu produktu (Product Backlog) oraz backlogu sprintu (Sprint Backlog). Wymagania, backlog produktu W Scrumie wymagania gromadzone są na liście zwanej backlogiem produktu. Product Backlog jest jedynym źródłem wymagań, nad którymi może pracować zespół. Wymagania te są uszeregowane w kolejności, w jakiej będą realizowane. Za kolejność na backlogu produktu odpowiada Product Owner. Kolejność ta jest zmienna w czasie, istota roli PO polega na takim zmienianiu backlogu produktu by co sprint praca zespołu dostarczała maksymalnej wartości. Scrum nie definiuje formatu w jakim mają być opisane wymagania, stwierdza natomiast, że backlog powinien być przejrzysty - a więc widoczny i zrozumiały dla wszystkich zainteresowanych. Scrum zakłada, że wymagania na backlogu mają sens - Scrum jako proces nie dostarcza narzędzi do oceny sensowności i wartości wymagań jak i całego przedsięwzięcia. Więcej na temat backlogu produktu piszę w poświęconym mu rozdziale. Role w Zespole Scrum W Zespole Scrum (ang. Scrum Team) wyróżniamy następujące role: Zespół deweloperski (ang. Development Team lub krótko Team) - to liczący od 3 do 9 osób zespół osób posiadających wspólnie wszystkie kompetencje niezbędne, aby
Scrum 4 dostarczać co iterację (Sprint) kompletny, działający, gotowy produkt. Scrum nie narzuca ani nie zaleca żadnej wewnętrznej struktury tego zespołu. Nie ma więc żadnych zdefiniowanych ról w zespole - wszyscy członkowie zespołu to developerzy (ang. developers), przy czym określenie stosowane jest także w stosunku do członków zespołu nie będących programistami. Innymi słowy jest to interdyscyplinarny, samoorganizujący się zespół. Product Owner - osoba odpowiedzialna za porządkowanie backlogu produktu, a przez to decydowanie o kolejności realizacji wymagań czyli kształcie produktu. Product Owner ma za zadanie maksymalizować wartość dostarczaną przez zespół za każdą iteracją (sprintem). Szerzej o roli Product Ownera piszę w poświęconym mu rozdziale. Scrum Master - osoba odpowiedzialna za proces. Scrum Master ma dbać o to, by Scrum był prawidłowo zrozumiany i stosowany zarówno w samym zespole jak i w organizacji. Scrum Master odpowiada także za zespół, jego produktywność i zaangażowanie. Dba o zespół pomagając mu w rozwiązywaniu problemów i usuwaniu przeszkód (w metodyce nazywanych impediments) oraz wspomagając jego samoorganizację. Nie jest jednak kierownikiem zespołu ani liderem technicznym, nie może bezpośrednio polecać członkom zespołu wykonania takiej czy innej pracy, karać ich czy nagradzać ani określać jaką rolę będą pełnić w zespole. Sposób działania Scrum Mastera jest w metodzie definiowany jako servant leadership, co można przetłumaczyć jako przywództwo służebne. Często stosowaną analogią
Scrum 5 jest porównywanie Scrum Mastera do trenera drużyny sportowej - pomaga on graczom, formuje z nich zespół, ale nie wybiega na boisko by brać udział w grze. Jak z tego widać Zespół Scrum może liczyć maksymalnie 11 osób. Choć każdy zespół powinien mieć jasno określonego Product Ownera i Scrum Mastera, to jednak na każdą z tych osób może przypadać kilka zespołów. I tak w przypadku pracy kilku zespołów na raz nad jednym produktem mogą one mieć wspólny backlog produktu, a co za tym idzie wspólnego Product Ownera. Jeśli zespół pracuje nad kilkoma produktami przełączając się pomiędzy nimi na granicy sprintu (a więc poświęcając jeden sprint na jeden produkt a kolejny na następny) może mieć innych Product Ownerów dla każdego z tych produktów. Liczba zespołów przypadających na Scrum Mastera zależy od etapu wprowadzania Scruma (i agile w ogóle) oraz dojrzałości zespołu. Przy świeżym zespole, dopiero co uczącym się pracy z tą metodą (a więc często walczącym ze starymi nawykami) Scrum Master może być rolą wymagającą poświęcenia pełni czasu jednemu zespołowi. Przy dojrzałym zespole, który już od dłuższego czasu pracuje w Scrumie (i używa innych metod agile) jeden Scrum Master może przypadać nawet na 3 zespoły. Scrum kategorycznie zakazuje łączenia roli Scrum Mastera i Product Ownera w jednej osobie. Wynika to z tego, że pomiędzy rolami tymi wstępuje naturalne napięcie - Scrum Master dba o proces (a więc np. o to by produkt był zawsze takiej jakości jaką wyznacza Definition of Done) zaś Product Owner chce zrealizować jak najwięcej wartościowej funkcjonalności w każdym sprincie. Jest wartościowe aby napięcie między nimi było eksternalizowane i mogło prowadzić do twórczych, otwartych
Scrum 6 dyskusji. Scrum nie zakazuje natomiast łączenia roli Scrum Mastera i developera. Stwierdza jednak, że osoba pełniąca taką rolę będzie wówczas mniej efektywna w którejś z nich lub w obu. Jest to dość intuicyjne - jeśli praca Scrum Mastera wymaga czasu, to członek zespołu ją wykonujący będzie miał odpowiednio mniej czasu na pracę nad produktem w sprincie. Drugi problem z takim łączeniem ról wynika z tego, że inni - zwłaszcza inni członkowie zespołu - mogą nie mieć jasności kiedy dana osoba wypowiada się jako członek zespołu, developer, a kiedy jako Scrum Master. Jest to szczególnie widoczne w przypadku konfliktu między developerami - Scrum Masterowi, który jest jednym z nich trudniej funkcjonować jako mediatorowi. Analogicznie Scrum traktuje łączenie ról Product Ownera i developera. Dodatkowe zagrożenie w przypadku takiego połączenia jest takie, że wówczas PO może zacząć dyktować zespołowi nie tylko co ma być zaimplementowane, ale również jak. Proces Scrum to metoda opisująca proces przetwarzania wymagań zebranych na backlogu produktu (Product Backlog) na gotowy do użycia produkt (potentially shippable product increment) podczas krótkich iteracji zwanych sprintami.
Scrum 7 Schemat procesu Scrum Wszystkie zdarzenia opisywane w Scrumie odbywają się wewnątrz sprintu. Każdy sprint rozpoczyna się od spotkania zwanego planowaniem sprintu (Sprint Planning) podczas którego zespół deweloperski przedstawia prognozę jakie wymagania zaimplementuje w ciągu sprintu. Następnie podczas trwania sprintu zespół deweloperski synchronizuje się podczas 15- o minutowych spotkań zwanych Daily Scrum, w których nie bierze udziału nikt spoza tego zespołu. Ponadto, w miarę potrzeb odbywają się spotkania z udziałem Product Ownera poświęcone pielęgnacji backlogu (backlog refining). Na zakończenie sprintu zespół oddaje produkt (increment) - kolejną, gotową wersję rozwijanego przezeń systemu/aplikacji. W produkcie znajdują się tylko te implementacje wymagań, które spełniają kryteria ukończenia (Definition of Done - DoD). Na zakończenie sprintu zespół wraz z Product Ownerem współpracuje z interesariuszami podczas przeglądu sprintu (Sprint Review), którego celem jest sprawdzenie stanu produktu i podjęcie decyzji co do dalszych jego losów. Bezpośrednio po przeglądzie
Scrum 8 zespół odbywa retrospekcję (Sprint Retrospective) - spotkanie z udziałem Scrum Mastera i Product Ownera, podczas którego zespół analizuje swój sposób pracy, zastanawia się w jaki sposób mógłby go poprawić i planuje jakie konkretne usprawnienia (actionable improvements) będzie próbował wprowadzić do swej pracy w następnym sprincie. Koniec retrospekcji jest końcem sprintu. Cykl ten powtarzany jest w kolejnych sprintach aż do ukończenia prac z tego czy innego powodu. Poniżej omawiam w szczegółach każdy z tych elementów procesu Scrum. Sprint Wszystkie zdarzenia w Scrumie odbywają się wewnątrz iteracji o stałej długości zwanych sprintami. Sprint może mieć długość do 1 miesiąca i jest wskazane, aby w obrębie jednego przedsięwzięcia długość sprintu pozostawała stała. Należy bardzo dokładnie i stanowczo przestrzegać ustalonej długości sprintu. Sprintu nie wolno skracać ani wydłużać choćby o parę godzin. Celem takiego podejścia jest umożliwienie działania empiryzmu poprzez wyznaczenie stałego, obiektywnego interwału, po którym produkt jest poddawany sprawdzeniu (inspect) i może nastąpić dostosowanie (adapt). Co sprint interesariusze poznają rzeczywisty stan produktu. Wyznaczają go wymagania, które zespół całkowicie ukończył podczas ostatniego sprintu. Ponieważ długość sprintu jest sztywna jest zarazem znana rzeczywista prędkość (velocity) zespołu - wydłużanie sprintu np. o 6 godzin by coś dokończyć prowadziłoby do zafałszowania rzeczywistych możliwości zespołu. Ponadto celem sprintu o niezmiennej długości jest wytworzenie stałego rytmu pracy. Rytm ten będzie istotny nie tylko
Scrum 9 dla zespołu, ale i dla całej organizacji. Wszyscy będą wiedzieć, że co dwa albo trzy tygodnie pojawia się nowa wersja produktu oraz rozpoczyna praca nad następną. Długość sprintu ustala się podczas rozpoczynania pracy nad danym przedsięwzięciem, nie powinna być ona potem pochopnie zmieniana. Jeśli z jakichś powodów zmiana jest konieczna nie powinna ona dotyczyć jednego sprintu, lecz winna być następnie stosowana przez dłuższy czas. Planowanie Sprintu Każdy sprint rozpoczyna się od planowania sprintu. Jest to spotkanie, w którym bierze udział cały Zespół Scrum (a więc Product Owner, Scrum Master i Zespół Developerski). Jego celem jest zastanowienie się co można zrobić w nadchodzącym sprincie a także jak to zrobić. Produktem planowania jest backlog sprintu (Sprint Backlog) oraz cel sprintu (Sprint Goal). Maksymalny czas trwania planowania to 8h dla sprintu miesięcznego, jest zalecane aby planowanie dla krótszych sprintów było odpowiednio krótsze. Dobry wskaźnik to max. 2h na tydzień sprintu. By odpowiedzieć na pytanie co można zrobić w tym sprincie Product Owner przedstawia backlog produktu w jego aktualnej 4 kolejności, omawia jakie cele chciałby osiągnąć kolejną wersją produktu (inkrementem) oraz które wymagania powinny być zrealizowane by osiągnąć ten cel. Zespół Scrum wspólnie dyskutuje i ustala zakres pracy. Zespół Developerski kolejno, od góry analizuje wymagania z backlogu produktu, a następnie prognozuje ile z nich zrobi w najbliższym sprincie. O wymaganiach, 4 Do ostatniej chwili przed planowaniem Product Owner ma prawo zmieniać kolejność i zawartość backlogu produktu.
Scrum 10 które zmieściły się w tej prognozie mówimy potocznie, że zostały wzięte na sprint. Następnie, cały Zespół Scrum wypracowuje cel sprintu (Sprint Goal). Cel sprintu zostanie osiągnięty poprzez implementację wybranych wymagań z backlogu produktu, jest on zarazem celem do osiągnięcia jak i uzasadnieniem dlaczego ten sprint warto wykonać. Po ustaleniu celu sprintu Zespół Developerski buduje na swój użytek konkretny plan pracy nad wymaganiami wziętymi do sprintu. Wymagania te wraz z owym planem to Sprint Backlog. Scrum nie narzuca konkretnej formy tego planu poza tym, że powinien on umożliwiać śledzenie postępów pracy. Często stosowaną praktyką jest tworzenie dla każdego z wymagań na sprint backlogu zadań (tasks), a więc opisów czynności jakie zespół zamierza wykonać aby dane wymaganie zaimplementować. Są one szacowane w godzinach, co służy następnie do monitorowania postępu prac. Są jednak zespoły, które nie praktykują stosowania zadań lub ich szacowania i monitorują postęp prac w sprincie w inny sposób. Najczęściej zespoły takie stosują tablice kanbanowe i śledzenie na nich jedynie stanu zadań lub całych wymagań (PBI). Niezależnie od przyjętej formy planu tworzenie go oznacza zazwyczaj dalszą dekompozycję wymagań - Product Owner może pomagać w tym odpowiadając na pytania itp. Nie wymaga się, aby w trakcie planowania powstał na cały sprint plan o równym poziomie szczegółowości. Plan na najbliższe dni powinien być szczegółowy - tak, by zaraz po zakończeniu planowania można było przystąpić do pracy. Plan na dalsze dni może być ogólny. Zostanie on doprecyzowany w miarę postępów prac.
Scrum 11 Daily Scrum Jest to codzienne, krótkie spotkanie mające na celu synchronizację zespołu, a więc uzyskanie stanu, w którym wszyscy w zespole wiedzą jak wygląda sytuacja w kontekście postępu prac w sprincie. Spotkanie to ma następujące cechy: trwa maksymalnie 15 minut (czas ten nie zależy ani od długości sprintu ani liczebności zespołu), odbywane jest na stojąco, odbywane jest zawsze w tym samym miejscu i o tej samej godzinie, w spotkaniu tym bierze udział wyłącznie Zespół Developerski oraz opcjonalnie Scrum Master. Udział innych osób - choćby bierny - jest niedopuszczalny. Podczas Daily Scrum członkowie Zespołu Developerskiego omawiają następujące kwestie: - co wczoraj zrobiłem/am, co pomogło w osiągnięciu celu sprintu? - co zamierzam zrobić dziś by pomóc w osiągnięciu celu sprintu? - czy dostrzegam jakieś problemy, bariery, które przeszkadzają mi lub całemu Zespołowi Developerskiemu w osiągnięciu celu sprintu? Zatem, podczas tego spotkania Zespół Developerski dokonuje sprawdzenia (inspect) jak wygląda postęp prac nad osiągnięciem celu sprintu oraz dostosowuje się (adapt) poprzez odpowiednie, wspólne zaplanowanie kolejnego dnia. Przyjmuje się zarazem, że przynajmniej raz dziennie, właśnie w okolicach tego spotkania zespół powinien uaktualnić sprint backlog i narzędzie, z pomocą krótego monitoruje postępy swojej pracy. A więc jeśli używane są zadania i wykres burndown, to powinny one być aktualne przed kolejnym Daily
Scrum 12 Scrum. W praktyce nie nastręcza to problemu, bo większość zespołów uaktualnia to na bieżąco w miarę postępów prac. Pielęgnacja backlogu Aby zachować płynność pracy jest wskazane aby backlog produktu był wypielęgnowany 5, a więc aby wymagania były przedyskutowane zawczasu między Zespołem Developerskim a Product Ownerem, a także oszacowane i zdekomponowane odpowiednio do swojej pozycji na backlogu. Wymagania, które są na początku backlogu powinny być mniejsze, dokładniejsze i lepiej zrozumiane niż te poniżej. Wymagania, które są tak zdekomponowane, że mogą być przez Zespół Developerski całkowicie zrealizowane w czasie jednego sprintu określane są jako Gotowe (ang. Ready). W Scrumie na pracę Zespołu Scrum nad przyszłym backlogiem produktu przeznaczono do 10% czasu trwania sprintu. Tak więc przykładowo dla dwutygodniowego sprintu jest to maksymalnie jeden cały dzień pracy. Scrum Guide nie określa czy czas ten ma zostać spożytkowany jako jedno długie spotkanie czy kilka mniejszych pozostawiając to decyzji zespołów. Wydaje się, że czynienie z pielęgnacji backlogu jednej sesji, mogącej potencjalnie trwać cały dzień nie byłoby sensowne. Dlatego większość zespołów korzysta z tego czasu podczas kilku krótszych spotkań z Product Ownerem zwanych potocznie groomingami. Podczas tych spotkań zespół i Product Owner wspólnie pracują nie nad wymaganiami bieżącego sprintu, lecz nad backlogiem produktu przygotowując go do kolejnych planowań sprintu. 5 Więcej na temat pielęgnacji backlogu w rozdziale o backlogu produktu.
Scrum 13 Produkt i kryteria ukończenia Na zakończenie każdego sprintu zespół dostarcza kolejnej wersji rozwijanego produktu, czasem zwanej inkrementem (od potentially shippable product increment). Produkt ów musi być tak dobry (takiej jakości), by mógł być zastosowany produkcyjnie - by użytkownicy mogli z niego korzystać. Innymi słowy produkt nie może wymagać wykonywania nad nim żadnej dodatkowej pracy poza ewentualną instalacją. W praktyce rzeczywiście zespoły wydają często produkt każdego sprintu na produkcję. Żądanie co sprint w pełni zintegrowanego, działającego produktu, który może być natychmiast wdrożony i używany ma następujące przyczyny: tylko produkt, który jest zdatny do użytku (co do jego jakości) przedstawia jakąkolwiek wartość dla użytkownika/klienta, ponieważ Scrum kładzie nacisk na dostarczanie wartości konieczne jest aby co sprint dostarczany był zdatny do użytku produkt, jedynie informacja o tym jakie funkcje są już w produkcie zaimplementowane i dostępne jest informacją pewną, wszelkie inne informacje to jedynie prognozy - aby więc na poziomie produktu mógł działać empiryzm konieczne jest przedstawianie podczas przeglądu klientowi (lub jego reprezentantowi PO) tylko tego, co jest naprawdę ukończone, konieczność oddawania w pełni zintegrowanego, działającego produktu co sprint wymusza podnoszenie poziomu praktyk technicznych zespołu zarazem wykluczając możliwość pojawienia się nieprzewidzianego okresu stabilizacji, kiedy to okazuje się że integracja zbudowanych na
Scrum 14 przestrzeni długiego czasu fragmentów nie daje działającego produktu, praktyka ta podnosi jakość produktu, ponieważ kod napisany na początku przedsięwzięcia jest cały czas testowany i sprawdzany w każdym kolejnym sprincie - jako że zaczynamy od elementów najważniejszych dzięki temu podejściu są one najlepiej sprawdzone. Aby mieć pewność, że produkt co sprint jest w istocie zdatny do użytku definiuje się listę wymagań, które musi on spełniać. Lista ta jest znana jako kryteria ukończenia (Definition of Done, w skrócie DoD). Powstaje ona w wyniku współpracy Product Ownera i Zespołu Developerskiego, który to jest jej właścicielem i decyduje ostatecznie o jej kształcie. Znajdują się tam zarówno kryteria wydajnościowe czy inne wymagania niefunkcjonalne wynikające z potrzeb (te zwykle dostarcza Product Owner) jak i kryteria pozwalające utrzymać jakość strukturalną produktu (te zwykle określa zespół). Jeśli w danej organizacji obowiązują jakieś standardy co do tego co to oznacza, że produkt jest ukończony, to wówczas są one minimalnym - podstawowym - DoD. Tylko wymagania, których implementacja spełnia DoD mogą wejść do produktu (inkrementu) na końcu sprintu. Jeśli implementacja jakiegoś wymagania nie spełnia DoD jest uznawana za nie zrobioną i nie wchodzi do produktu (inkrementu) sprintu. W takiej sytuacji samo wymaganie powraca do backlogu produktu (potocznie mówimy, że zrzuca się je ze sprintu ) do decyzji Product Ownera co do jego dalszych losów. Warto podkreślić, że kryteria ukończenia muszą być tak określone, by miały charakter obiektywnego, binarnego testu (tak - spełnia, nie - nie spełnia). Nie ma tu miejsca na dowolność,
Scrum 15 a już szczególnie niewłaściwe jest stosowanie tu odbioru przez Product Ownera, który wedle uznania przyjmuje albo nie daną implementację. Powoduje to rozmycie tego co właściwie jest zrobione, a co nie jak również brak pewności co do tego czy ten sam poziom jakości był utrzymany w całym produkcie. Kryteria ukończenia (DoD) mogą ewoluować podczas pracy nad danym systemem/produktem, przy czym naturalne jest raczej podnoszenie wyrażonych tak wymagań jakościowych wraz ze wzrostem oczekiwań klienta jak i możliwości zespołu niż ich obniżanie. Przegląd Sprintu Gdy produkt (increment) jest już przygotowany odbywa się Przegląd Sprintu (Sprint Review). Jest to spotkanie, w którym uczestniczy Zespół Deweloperski, Product Owner, Scrum Master oraz wszyscy zainteresowani interesariusze i użytkownicy. Jego maksymalny czas trwania to 4 godziny, przy sprintach krótszych niż miesiąc zazwyczaj jest ono krótsze (dobry wskaźnik to 1h na tydzień sprintu). Chociaż Zespół Developerski może opowiedzieć jak przebiegała praca w sprincie - co poszło dobrze, jakie problemy napotkano i jak je rozwiązano - to niejako wbrew swej nazwie spotkanie to nie koncentruje się na analizowaniu przebiegu sprintu, lecz skupia się na aktualnym stanie produktu. Podczas Przeglądu Sprintu zespół przedstawia ukończony właśnie inkrement, często pokazując (demonstrując) jego działanie. Przegląd Sprintu nie ma jednak charakteru demo - celem ewentualnego pokazu jest zapoznanie uczestników (przede wszystkim interesariuszy) z aktualnym stanem produktu poprzez pokazanie jakie funkcje są w nim obecnie dostępne. Poza pokazem Product Owner omawia także aktualny stan backlogu produktu, a także - jeśli jest to
Scrum 16 potrzebne - prognozy co do dalszego postępu prac. Istotą przeglądu sprintu jest następująca na kanwie zapoznania się ze stanem produktu dyskusja co do dalszych losów przedsięwzięcia. Najczęściej jej owocem jest dodanie do backlogu produktu nowych pomysłów i wymagań oraz zmiany w kolejności na nim. Mogą jednak być podjęte inne decyzje, na przykład takie jak o wydaniu produktu (jeśli nie dzieje się to automatycznie dla każdej nowej wersji - wówczas wydanie następuje jeszcze przed przeglądem sprintu), o zwiększeniu lub zmniejszeniu zespołu albo liczby zespołów czy wreszcie o przerwaniu przedsięwzięcia. W dyskusji tej bierze się pod uwagę nie tylko stan produktu i projektu (backlog), ale także posiadane informacje o czynnikach zewnętrznych wpływających na produkt (np. reakcja klientów/użytkowników na wprowadzone zmiany, zmiana budżetu itp.). Także i tutaj widzimy empiryzm w działaniu - interesariusze dokonują przeglądu (inspect) produktu i całego przedsięwzięcia, by następnie dokonać dostosowania (adapt) dalszych prac nad nim. Retrospekcja Bezpośrednio po zakończeniu przeglądu zespół odbywa już we własnym gronie Retrospekcję Sprintu (Sprint Retrospective). Jest to spotkanie, w którym udział bierze cały Zespół Scrum (Zespół Developerski, Scrum Master i Product Owner), i podczas którego analizuje się sposób pracy zespołu podczas dobiegającego końca sprintu. Celem jest zastanowienie się w jaki sposób pracę tą można by było usprawnić w przyszłości. Efektem spotkania jest lista konkretnych usprawnień (actionable improvements), które zespół będzie próbował wprowadzić w życie w następnym sprincie. Retrospekcja Sprintu trwa maksymalnie 3 godziny dla
Scrum 17 miesięcznych sprintów, zazwyczaj jest krótsza przy krótszych sprintach (dobry wskaźnik to 45 min na tydzień sprintu). Scrum nie określa sposobu prowadzenia retrospekcji, która jest praktyką samą w sobie. Scrum wymaga jednak, aby zespół co sprint analizował swoją pracę i szukał usprawnień. Dzięki temu można powiedzieć, że coraz lepszy zespół jest drugim produktem (po inkremencie) każdego sprintu. Określenie konkretne usprawnienia (actionable improvements) oznacza, że oczekujemy nie ogólnych życzeń ale konkretnych działań - i to takich, których wprowadzenie jest realne w czasie jednego sprintu. Tak więc zamiast np. chcemy pisać więcej testów (życzenie) powinno to być raczej w kolejnym sprincie dla jednego z wymagań zaimplementujemy komplet testów (konkretne działanie, realistycznie realizowalne w jednym sprincie). Podejście to wynika ze słusznej obserwacji, że wszelkie usprawnienia są osiągane nie metodą przełomów i wielkich postanowień lecz systematycznych, małych kroków ku lepszemu. Konieczność realizowania retrospekcji co sprint ma zapewnić, że zespół będzie owe kroki co sprint podejmował. Więcej o retrospekcji piszę w rozdziale poświęconym w całości temu tematowi. Podsumowanie i uwagi końcowe Scrum jest zatem metodą, która opisuje sposób organizacji pracy zespołu, który przetwarza pewne życzenia (wymagania, problemy) uszeregowane w postaci listy (backlogu) na gotowy produkt. Produkt ów powstaje stopniowo, iteracyjnie - w kolejnych sprintach powstają jego kolejne wersje, zawsze technicznie ukończone i działające.
Scrum 18 Warto zauważyć, że wbrew dość rozpowszechnionemu przekonaniu Scrum zdecydowanie nie jest metodą zarządzania projektami. Projekt - z definicji - jest przedsięwzięciem, które ma określony z góry zakres i cel. Scrum niczego takiego nie oczekuje ani nie wymaga - jest procesem ciągłym, o nie zakreślonych granicach. Tworzy potok przetwarzania strumienia wymagań na produkt, który może działać tak długo jak są nowe wymagania do zaimplementowania. Dobrze odpowiada to zresztą rzeczywistości pracy większości zespołów, które nie realizują de facto projektów, lecz nie kończący się ciąg zmian w jakimś systemie/produkcie. Scrum jest także metodą, która ma wąski zakres. Scrum nie zajmuje się tym skąd wzięły się wymagania albo zespół - czasem podkreślam to mówiąc, że Scrum jest metodą organizacji pracy, która już jest. Scrum nie zajmuje się również analizowaniem sensowności przedsięwzięcia, aczkolwiek dzięki dostarczaniu działającego oprogramowania co sprint umożliwia wcześniejsze sprawdzenie przydatności produktu czy to jako oferty rynkowej czy narzędzia na własne potrzeby. Wszystkie wydarzenia w Scrumie - począwszy od sprintu po spotkania - mają wyznaczone sztywne ramy czasowe. W oryginale Scrum Guide stosowane jest tutaj określenie timebox. Sugeruje ono sztywność owego czasu - i tak rzeczywiście jest. W prawidłowym stosowaniu Scruma bardzo ważne jest ścisłe i stanowcze przestrzeganie maksymalnych limitów czasu na wszystkie spotkania i inne zdarzenia. Oznacza to, że zdarzenie kończy się wraz z końcem czasu na niego przeznaczonym niezależnie od tego czy znajdujemy się właśnie w trakcie jakiejś dyskusji czy pracy. Poniżej podsumowanie maksymalnych czasów trwania poszczególnych spotkań w Scrumie:
Scrum 19 Spotkanie Planowanie sprintu Pielęgnacja backlogu produktu Przegląd sprintu Retrospekcja Daily Scrum Maksymalny czas trwania 8h 10% sprintu 4h 3h 15 minut Wszystkie powyższe czasy to czasy maksymalne. Oznacza to, że wymienione spotkania mogą trwać krócej jeśli temat zostanie wyczerpany. Jedyne zdarzenie Scruma, które nie może trwać ani dłużej ani krócej to sprint. Jest także zalecane proporcjonalne skracanie spotkań dla sprintów krótszych niż miesięczne. W poprzednich wersjach Scruma było to wręcz wymagane - maksymalny czas trwania spotkań był określony właśnie w proporcji do długości sprintu. Ograniczenie to zostało zniesione od wersji Scrum Guide wydanej 1 sierpnia 2013.