Scrum Flashcards
Co to jest Scrum?
to uproszczone ramy postępowania, które pomagają poszczególnym osobom, zespołom i
organizacjom wytwarzać wartość poprzez adaptacyjne rozwiązywanie złożonych problemów
Na czym oparty jest Scrum?
Scrum oparty jest na empirycznym sterowaniu procesem. Empiryzm zakłada, że wiedza pochodzi z doświadczenia, a decyzje należy podejmować na podstawie tego co zaobserwowaliśmy lub doświadczyliśmy, czyli na podstawie faktów.
Na czym opierają się procesy empiryczne?
Procesy empiryczne opierają się na trzech filarach:
- przejrzystości (wspólnym rozumieniu pracy i jej rezultatów)
- inspekcji (poddawaniu ocenie zgodności z oczekiwaniami)
- adaptacji (podejmowaniu działań, gdy rezultat prac jest inny niż oczekiwany
Jak przebiega proces postępowania w scrum?
- Product Owner porządkuje pracę potrzebną do rozwiązania złożonego problemu, tworząc
Product Backlog. - Scrum Team przekształca wybraną część tej pracy w wartościowy Increment w trakcie Sprintu.
- Scrum Team oraz jego interesariusze sprawdzają efekty i dostosowują swoje działania na
potrzeby kolejnego Sprintu. - Powtórz
Teoria Scruma
Fundamentem Scruma jest empiryzm i koncepcja lean. Istotą empiryzmu jest to, że wiedza wynika z
doświadczenia, a decyzje podejmowane są na podstawie tego, co można zaobserwować. Koncepcja lean ogranicza straty i koncentruje się na tym, co najważniejsze.
Wartości Scruma
Aby stosowanie Scruma mogło przynosić pożądane efekty, członkowie zespołu muszą doskonalić się w
postępowaniu według pięciu wartości, jakimi są:
Zaangażowanie, Skupienie, Otwartość, Szacunek, Odwaga
Powyższe wartości nadają Scrum Teamowi kierunek w odniesieniu do pracy, działań i zachowań jego
członków. Podejmowane decyzje, kroki oraz sposób stosowania Scruma powinny wzmacniać powyższe
wartości, zamiast je osłabiać czy podważać. Członkowie Scrum Teamu poznają i zgłębiają te wartości podczas wydarzeń scrumowych i w ramach pracy nad artefaktami. Kiedy wymienione wartości są wcielane w życie przez Scrum Team oraz osoby, które z nim współpracują, wyłaniają się filary empiryzmu Scruma w postaci przejrzystości, inspekcji i adaptacji, co przyczynia się do budowania zaufania.
Scrum team
Podstawowym elementem Scruma jest niewielki zespół, czyli Scrum Team. W skład Scrum Teamu
wchodzi jeden Scrum Master, jeden Product Owner oraz Developerzy. Scrum Team nie dzieli się na
podzespoły, nie obowiązuje w nim hierarchia. To spójna grupa profesjonalistów skupionych na
pojedynczym celu określanym jako Cel Produktu.
Scrum teamy
Scrum Teamy są interdyscyplinarne, co oznacza, że ich członkowie mają wszystkie umiejętności
potrzebne do wytwarzania wartości co Sprint. Są także zespołami samozarządzającymi, co oznacza, że
samodzielnie podejmują decyzję o tym, kto będzie wykonywał określone zadania, kiedy i jak.
Scrum Team jest wystarczająco niewielki, aby pozostawać zwinnym, a jednocześnie wystarczająco liczny,
aby móc ukończyć znaczącą część pracy w Sprincie, zwykle składa się z 10 osób lub mniej. Jak wynika z
naszego doświadczenia, mniejsze zespoły na ogół lepiej się komunikują i są bardziej produktywne. Jeśli
Scrum Teamy stają się zbyt liczne, powinny rozważyć przeorganizowanie się w kilka spójnych Scrum
Teamów skupionych na tym samym produkcie. Dlatego powinny mieć wspólny Cel Produktu, Product
Backlog oraz tego samego Product Ownera.
Developerzy
Developerzy to osoby w Scrum Teamie zobowiązane do wytworzenia każdego aspektu użytecznego
Incrementu w każdym Sprincie.
Zakres konkretnych umiejętności niezbędnych Developerom często bywa szeroki i różni się w zależności
od dziedziny. Tym niemniej Developerzy zawsze ponoszą odpowiedzialność za:
● stworzenie planu Sprintu, czyli Sprint Backlogu;
● ciągłe zapewnianie jakości poprzez postępowanie zgodnie z Definicją Ukończenia
● codzienne dostosowywanie planu tak, aby osiągnąć Cel Sprintu
● wzajemne egzekwowanie odpowiedzialności zawodowej
Product Owner
Product Owner ponosi odpowiedzialność za maksymalizowanie wartości produktu będącego efektem
pracy Scrum Teamu. Sposób, w jaki to robi, może znacznie się różnić w zależności od organizacji, Scrum
Teamu bądź poszczególnych osób.
Product Owner ponosi również odpowiedzialność za skuteczne zarządzanie Product Backlogiem, co
obejmuje:
● opracowywanie i jasne artykułowanie Celu Produktu;
● tworzenie i jasne artykułowanie elementów Product Backlogu;
● porządkowanie elementów Product Backlogu; oraz
● zapewnienie przejrzystości, dostępności i zrozumienia Product Backlogu.
Product owner ciąg dalszy
Product Owner może wykonywać powyższe zadania samodzielnie lub zlecać je innym osobom. Niemniej
to Product Owner pozostaje za nie odpowiedzialny.
Aby praca Product Ownera mogła przynosić pożądane efekty, jego decyzje muszą być respektowane
przez całą organizację. Decyzje te uwidoczniają się w treści oraz kolejności elementów Product Backlogu
oraz w Incremencie, który może zostać poddany ocenie podczas Sprint Review.
Product Owner to jedna osoba, nie komitet. Product Owner może w Product Backlogu uwzględniać
potrzeby licznych interesariuszy. Ci, którzy chcą dokonać zmian w Product Backlogu mogą to zrobić,
próbując przekonać do tego Product Ownera.
Scrum Master
Scrum Master ponosi odpowiedzialność za to, aby Scrum był stosowany zgodnie z tym, co zostało
opisane w tym Przewodniku. Realizuje to zadanie, pomagając wszystkim w zrozumieniu teorii i praktyki
Scruma, zarówno w samym Scrum Teamie, jak i w organizacji.
Scrum Master ponosi odpowiedzialność za efektywność Scrum Teamu. Czyni to poprzez stwarzanie mu
odpowiednich warunków do poprawy stosowanych przez niego praktyk, zgodnie z regułami Scruma.
Scrum Masterzy to prawdziwi liderzy działający na rzecz Scrum Teamu, jak i szerzej rozumianej
organizacji.
Scrum Master wspiera Scrum Team na kilka sposobów, m.in.:
● instruuje członków zespołu, na czym polega samozarządzanie i interdyscyplinarność;
● pomaga Scrum Teamowi skupić się na wytwarzaniu wartościowych Incrementów zgodnych z
Definicją Ukończenia;
● sprawia, że przyczyny ograniczające postępy Scrum Teamu zostają usunięte; oraz
● dba o to, aby wszystkie wydarzenia scrumowe się odbywały, były konstruktywne i produktywne
oraz by mieściły się w wyznaczonych ramach czasowych
Scrum Master wspiera Product Ownera na kilka sposobów, m.in.:
● pomaga znajdować techniki pozwalające na skuteczne określenie Celu Produktu oraz
zarządzanie Product Backlogiem;
● pomaga Scrum Teamowi zrozumieć potrzebę jasnego i zwięzłego formułowania elementów
Product Backlogu;
● pomaga wprowadzać empiryczne podejście do planowania pracy nad produktem w złożonym
środowisku; oraz
● wspomaga współpracę z interesariuszami, kiedy zostanie o to poproszony lub kiedy zachodzi
taka potrzeba.
Scrum Master wspiera organizację na różne sposoby, m.in.:
● przewodzi organizacji, szkoli i instruuje ją w procesie wdrażania Scruma;
● planuje i doradza w wykorzystaniu Scruma w organizacji;
● pomaga pracownikom i interesariuszom w zrozumieniu oraz stosowaniu empirycznego podejścia
do złożonych problemów; oraz
● usuwa bariery pomiędzy interesariuszami a Scrum Teamami.
Wydarzenia w Scrumie
Sprint jest wydarzeniem scrumowym zawierającym w sobie wszystkie pozostałe. Każde wydarzenie w
Scrumie jest formalną okazją do inspekcji i adaptacji artefaktów Scruma. Celem tych wydarzeń jest
stworzenie odpowiednich warunków do uzyskania wymaganej przejrzystości. Rezygnacja z
któregokolwiek z wydarzeń bądź przeprowadzanie ich niezgodnie z tym, co tu opisano, jest utraconą
szansą na inspekcję i adaptację. Wydarzenia są wykorzystywane w Scrumie dla wprowadzenia
regularności oraz ograniczenia konieczności organizowania innych, nieujętych w Scrumie spotkań.
Optymalnie jest, kiedy wszystkie wydarzenia odbywają się o stałej porze i w tym samym miejscu, aby
ograniczyć złożoność.
Sprint
Sprinty są pulsem Scruma. W Sprintach pomysły są przekształcane w wartość.
8
Są to wydarzenia o ustalonej długości, trwają maksymalnie miesiąc dla uzyskania regularności. Nowy
Sprint rozpoczyna się natychmiast po zakończeniu poprzedniego.
Cała praca niezbędna do osiągnięcia Celu Produktu, z uwzględnieniem zdarzeń: Sprint Planning, Daily
Scrum, Sprint Review oraz Sprint Retrospective, odbywa się w Sprintach.
W czasie trwania Sprintu:
● nie dokonuje się żadnych zmian, które zagrażałyby osiągnięciu Celu Sprintu;
● jakość nie spada;
● Product Backlog jest w razie potrzeby uszczegóławiany; oraz
● zakres pracy może być doprecyzowywany lub renegocjowany z Product Ownerem wraz z
rosnącym zrozumieniem.
Sprint Planning
Sprint Planning rozpoczyna Sprint poprzez rozplanowanie pracy do wykonania w Sprincie. Powstały plan
jest efektem wspólnej pracy całego Scrum Teamu.
Product Owner gwarantuje, że uczestnicy są przygotowani do omówienia najważniejszych elementów
Product Backlogu oraz tego, jak powinien zostać sformułowany Cel Produktu. Scrum Team może
zaprosić na Sprint Planning także inne osoby w charakterze doradców
Sprint Planning to wydarzenie, podczas którego uczestnicy zajmują się następującymi tematami:
Temat pierwszy: Dlaczego ten Sprint ma wartość?
Product Owner proponuje, jak zwiększyć wartość produktu oraz jego użyteczność w bieżącym Sprincie.
Następnie cały Scrum Team współpracuje nad sformułowaniem Celu Sprintu, który opisuje to, dlaczego
dany Sprint jest wartościowy dla interesariuszy. Cel Sprintu musi zostać określony przed zakończeniem
Sprint Planningu.
Temat drugi: Co może zostać Ukończone w tym Sprincie
Podczas dyskusji z Product Ownerem Developerzy wybierają elementy Product Backlogu, nad którymi
będą pracować w ramach bieżącego Sprintu. W trakcie tego procesu Scrum Team może uszczegółowić te
elementy, co zwiększa ich zrozumienie oraz poczucie pewności.
Wybór ilości pracy możliwej do wykonania w Sprincie może być trudny. Jednak im większa jest wiedza
Developerów na temat przebiegu ich dotychczasowej pracy, dostępności w rozpoczynającym się Sprincie
oraz Definicji Ukończenia, z tym większą pewnością będą mogli prognozować pracę w Sprincie.
Temat trzeci: W jaki sposób zostanie wykonana praca?
Dla każdego wybranego elementu Product Backlogu Developerzy planują pracę niezbędną do
wytworzenia Incrementu zgodnego z Definicją Ukończenia. Często odbywa się to w ten sposób, że
elementy Product Backlogu dzielone są na mniejsze części możliwe do wykonania w ciągu maksymalnie
jednego dnia. Decyzja o sposobie tego podziału należy wyłącznie do Developerów. Nikt inny nie narzuca
im, jak przekształcić elementy Product Backlogu w wartościowe Incrementy.
Cel Sprintu, elementy Product Backlogu wybrane do wykonania w ramach Sprintu oraz plan ich realizacji
razem składają się na Sprint Backlog.
Ramy czasowe Sprint Planningu to maksymalnie osiem godzin dla miesięcznego Sprintu. W przypadku
krótszych Sprintów wydarzenie to zwykle trwa krócej.
Daily Scrum
Celem Daily Scrum jest sprawdzenie postępów w dążeniu do osiągnięcia Celu Sprintu oraz w razie
konieczności adaptacja Sprint Backlogu, czyli dostosowanie zaplanowanej pracy.
Daily Scrum to 15‐minutowe wydarzenie dla Developerów danego Scrum Teamu. Aby ograniczyć
złożoność, odbywa się ono o tej samej porze i w tym samym miejscu w każdy dzień roboczy w trakcie
trwania Sprintu. Jeśli Product Owner lub Scrum Master wykonują pracę związaną z elementami Sprint
Backlogu, uczestniczą w spotkaniu jako Developerzy.
Developerzy mogą zdecydować się na dowolną strukturę oraz techniki, o ile tylko Daily Scrum dotyczy
postępów w realizacji Celu Sprintu, a efektem tego wydarzenia jest możliwy do wykonania plan na
nadchodzący dzień pracy. Pozwala to osiągnąć większe skupienie i poprawia umiejętność
samozarządzania.
Daily Scrum poprawia komunikację, ukazuje przeszkody, wspomaga szybkie podejmowanie decyzji, a co
za tym idzie, eliminuje potrzebę organizowania innych spotkań.
Daily Scrum to nie jedyna możliwość dla Developerów do modyfikacji planu. Często spotykają się w
trakcie dnia pracy, aby bardziej szczegółowo omówić modyfikacje czy zaplanować na nowo pozostałą
pracę w Sprincie.
