Przewodnik po Scrumie: Reguły gry · Scrum Mastera można określić mianem przywódcy...

ScrumGuide™

PrzewodnikpoScrumie:Regułygry

Lipiec2016

PrzygotowanyiutrzymywanyprzezKenaSchwabera

iJeffaSutherlanda

©2016 Scrum.Org i Scrum Inc. Dokument publikowany jest na licencji Creative Commons Uznanie autorstwa-Na tych samych warunkach 4.0. Uproszczona treść licencji w języku polskim: https://creativecommons.org/licenses/by-sa/4.0/deed.pl, pełne brzmienie licencji w języku angielskim: https://creativecommons.org/licenses/by-sa/4.0/legalcode. Korzystając z Przewodnika po Scrumie potwierdzasz wolę przestrzegania treści tej licencji.

Strona|2

SpistreściCelprzewodnika........................................................................................................................3

DefinicjaScruma........................................................................................................................3

TeoriaScruma...........................................................................................................................3

WartościScruma.......................................................................................................................4

ZespółScrumowy......................................................................................................................5

WłaścicielProduktu...............................................................................................................5

ZespółDeweloperski.............................................................................................................5

ScrumMaster........................................................................................................................6

ZdarzeniawScrumie.................................................................................................................7

Sprint.....................................................................................................................................8

PlanowanieSprintu...............................................................................................................9

CodziennyScrum.................................................................................................................10

PrzeglądSprintu..................................................................................................................11

RetrospektywaSprintu........................................................................................................12

ArtefaktyScruma.....................................................................................................................12

BacklogProduktu................................................................................................................12

BacklogSprintu....................................................................................................................14

Przyrost...............................................................................................................................14

PrzejrzystośćArtefaktów.........................................................................................................14

DefinicjaUkończenia...........................................................................................................15

Uwagikońcowe.......................................................................................................................16

Wyrazyuznania.......................................................................................................................17

Historiazmian.........................................................................................................................18

Zmianywprzewodnikupomiędzywersjami2013a2016...................................................18

Zmianywprzewodnikumiędzywersjami2011a2013.......................................................18


Strona|3

CelprzewodnikaScrumtworzyramydlawytwarzaniaiutrzymywaniazłożonychproduktów.TenPrzewodnikzawiera definicję Scruma, na którą składają się: role, zdarzenia, artefakty i zestaw reguł,którespajająteelementywjedną,nierozerwalnącałość.ScrumzostałstworzonyprzezKenaSchwaberaiJeffaSutherlanda.Sąonitakżeautoramitegoprzewodnikaiwspólnienadnimpracują.

DefinicjaScruma Scrum (rzecz.): ramy postępowania (ang. framework), dzięki którym ludzie mogą zpowodzeniem rozwiązywać złożone problemy adaptacyjne, by w sposób produktywnyikreatywnywytwarzaćproduktyonajwyższejmożliwejwartości.

Scrumjest:

• lekki,• łatwydozrozumienia,• trudnydoopanowania.

Scrum to ramyprocesu, które sąwykorzystywanew zarządzaniuwytwarzaniem złożonychproduktówodpoczątku latdziewięćdziesiątych. Samw sobie Scrumnie jestprocesemczytechniką wytwórczą; opisuje jedynie ogólne sposoby postępowania, w obrębie którychmożliwe jest stosowanie różnego rodzaju procesów i technik. Scrum pomaga odkrywaćnieefektywnościpraktykzarządczychitechnikinżynierskich,bymożnabyłojedoskonalić.

W obręb Scrumawchodzą: Zespoły Scrumowe1 (ang. Scrum Teams) oraz związane z nimirole,zdarzenia,artefakty ireguły.KażdyztychelementówsłużykonkretnymcelomikażdyjestniezbędnydoosiągnięciasukcesuwstosowaniuScruma.

Reguły Scruma łączą ze sobą zdarzenia, role i artefakty, regulując powiązania i relacjepomiędzynimi.Zostałyoneopisanewtymdokumencie.

PoszczególnesposobystosowaniaScrumamogąsięróżnićiztegowzględuwykraczająpozazakrestegoprzewodnika.

TeoriaScrumaScrum został osadzony w teorii empirycznej kontroli procesu, lub — krócej — w teoriiempiryzmu. Empiryzm reprezentuje pogląd, iż wiedza wynika z doświadczania ipodejmowaniadecyzjiwoparciuoto,copoznane.Scrumwykorzystujepodejścieiteracyjneiprzyrostowewceluzwiększeniaprzewidywalnościilepszejkontroliryzyka.

Każda realizacja empirycznej kontroli procesu opiera się na trzech filarach: przejrzystości,inspekcjiiadaptacji.

1 WiększośćnazwwłasnychelementówScrumapostanowiliśmyprzetłumaczyćczęściowolubcałkowicie.Abyuniknąćnieporozumień,przypierwszymwystąpieniupodajemyoryginalnebrzmieniewnawiasie.


Strona|4

Przejrzystość

Wszystkie istotne aspekty procesu muszą być widoczne dla osób odpowiedzialnych zaosiągane rezultaty. Reguła przejrzystości wymaga, by aspekty te były opisane jasnymi dlaosóbzaangażowanychstandardami,takbywszyscyobserwatorzytaksamorozumielito,coobserwują.

Przykładowo:

• uczestnicy danego procesu muszą posługiwać się wspólnym nazewnictwemelementówtegoprocesu,

• osobywykonującepracęiosobyakceptującewynikitejpracymusząposługiwaćsięwspólnądefinicją„Ukończonej”pracy.

Inspekcja

Osobywykorzystujące Scrumamuszą poddawać częstej inspekcji artefakty scrumoweorazpostępy w realizacji Celu Sprintu (ang. Sprint Goal), żeby wykrywać niepożądanerozbieżności.Inspekcjaniepowinnajednakbyćzbytczęsta,abyniestanowiłaprzeszkodywwykonywaniu pracy. Inspekcje przynoszą najwięcej korzyści, gdy są sumiennieprzeprowadzaneprzezwykwalifikowanych inspektorówbezpośredniowmiejscu,wktórymwykonywanajestpraca.

Adaptacja

Jeżeli osoba dokonująca inspekcji ustali, że jeden lub więcej aspektów procesu wykraczapoza przyjęte limity oraz że wytwarzany w ten sposób produkt nie będzie akceptowalny,proces lubprzetwarzanymateriałmuszą zostać skorygowane.Korektamusibyćwykonanajaknajszybciej,byograniczyćdalszeodstępstwa.

Scrumprzewidujeczteryformalnepunktyprzeprowadzania inspekcji iokazjedodokonaniaadaptacji(korekty).WszystkietepunktyzostałyopisanewsekcjiZdarzeniawScrumie:

• PlanowanieSprintu(ang.SprintPlanningMeeting) • CodziennyScrum(ang.DailyScrum) • PrzeglądSprintu(ang.SprintReviewMeeting) • RetrospektywaSprintu(ang.SprintRetrospective)

WartościScrumaGdy Zespół Scrumowy przyjmie wartości zaangażowania, odwagi, skupienia, otwartości iposzanowania i postępuje zgodnie z nimi, do życia powoływane są filary Scruma –przejrzystość, inspekcja i adaptacja, tworząc atmosferęzaufania pomiędzy wszystkimiwspółpracującymiosobami.CzłonkowieZespołuScrumowegoodkrywają tewartości i ucząsięich,pracujączwydarzeniami,rolamiiartefaktamiScruma.

Powodzenie w wykorzystaniu Scruma zależy od biegłości postępowania zgodnie z tymipięciomawartościami.WszyscyosobiściezobowiązująsięosiągaćceleZespołuScrumowego.Członkowie Zespołu Scrumowego mają odwagę postępować właściwie i przezwyciężaćtrudności.Wszyscy skupiająsię na pracy w Sprincie i celach Zespołu Scrumowego. ZespółScrumowy i jego interesariusze zgadzają się pozostawać otwartymi na wszystkie aspektywykonywanejpracyizwiązanezniąwyzwania.CzłonkowieZespołuScrumowegowzajemnierespektująswojeprawodobycianiezależnymi,kompetentnymiludźmi.


Strona|5

ZespółScrumowyWskład Zespołu Scrumowegowchodzą:Właściciel Produktu (ang. ProductOwner), ZespółDeweloperski (ang. Development Team) oraz Scrum Master. Zespoły Scrumowe sąsamoorganizujące się i międzyfunkcjonalne (ang. cross-functional). Samoorganizujące sięzespoły samodzielnie decydują,w jaki sposób najlepiejwykonywać pracę, nie są przy tymwżaden sposób kierowane przez osoby spoza zespołu. Zespoły międzyfunkcjonalneposiadają wszelkie kompetencje niezbędne do ukończenia pracy, nie będąc zależnymi odosób nienależących dozespołu. Model zespołu proponowany w Scrumie zostałzaprojektowanytak,abyzoptymalizowaćelastyczność,kreatywnośćiproduktywność.

Zespoły Scrumowe dostarczają produkty iteracyjnie i przyrostowo, zwiększając szanse nawczesneuzyskanieinformacjizwrotnej.Przyrostowedostarczanie„Ukończonego”produktuzapewnianieprzerwanądostępnośćjegodziałającej,potencjalnieużytecznejwersji.

WłaścicielProduktu

Właściciel Produktu jest odpowiedzialny za maksymalizację wartości produktu i pracyZespołu Deweloperskiego. Sposoby, w jakie jest to osiągane, mogą się znacznie różnić wzależnościodkonkretnejorganizacji,ZespołuScrumowegoiosób.

Właściciel Produktu jest jedyną osobą zarządzającą Backlogiem Produktu (ang. ProductBacklog).PojęciezarządzaniaBacklogiemProduktumieściwsobie:

• jasneartykułowanieelementówBackloguProduktu, • ustalanie kolejności elementów Backlogu Produktu w sposób pozwalający osiągać

założoneceleimisje, • optymalizowaniewartościpracywykonywanejprzezZespółDeweloperski, • zapewnianie, że Backlog Produktu jest dostępny, przejrzysty oraz jasny dla

wszystkich, atakże, że dobrze opisuje to, czym Zespół Scrumowy będzie sięzajmowałwdalszejkolejności,

• zapewnianie, że Zespół Deweloperski rozumie elementy Backlogu Produktuwwymaganymstopniu.

Właściciel Produktu może wykonywać powyższe zadania samodzielnie lub zlecać jeZespołowi Deweloperskiemu, jednak to Właściciel Produktu pozostaje za nieodpowiedzialny.

Właściciel Produktu to pojedyncza osoba, nie komitet. Właściciel Produktu możereprezentowaćinteresygrupyosób,leczosobychcącezmienićpriorytetelementuBackloguProduktu,muszązwrócićsiędoWłaścicielaProduktu.

Aby Właściciel Produktu mógł odnieść sukces, cała organizacja musi respektować jegodecyzje.Decyzjetesąodzwierciedlonewtreści ikolejnościelementówBackloguProduktu.Nikt nie może nakazać Zespołowi Deweloperskiemu, aby pracował z innym zestawemwymagań,aZespołowiDeweloperskiemuniewolnopodejmowaćdziałańwoparciuoto,comówiąinneosoby.

ZespółDeweloperski

ZespółDeweloperskizłożonyjestzprofesjonalistów,którychzadaniemjestdostarczenie,nazakończenie każdego Sprintu, gotowego do potencjalnego wydania Przyrostu (ang.Increment)produktu.TylkoczłonkowieZespołuDeweloperskiegotworząPrzyrost.


Strona|6

Zespoły Deweloperskie są ustanowione i uprawnione przez organizację do samodzielnegoorganizowania własnej pracy i zarządzania nią. Synergia, będąca rezultatem takiegopostępowania,zwiększaogólnąwydajnośćiefektywnośćZespołuDeweloperskiego.

CharakterystykaZespołówDeweloperskichjestnastępująca:

• Są samoorganizujące się. Nikt (nawet Scrum Master) nie może mówić ZespołowiDeweloperskiemu, jak przekształcać elementy Backlogu Produktu w Przyrostygotowejdopotencjalnegowydaniafunkcjonalności.

• Zespoły Deweloperskie są międzyfunkcjonalne, w swoim składzie posiadająwszystkieumiejętnościniezbędnedowytworzeniaPrzyrostu.

• Scrum nie uznaje tytułów innych niż Deweloper 2 dla członków ZespołuDeweloperskiego,bezwzględunacharakterwykonywanejprzeznichpracy.Od tejregułyniemawyjątków.

• Niezależnieodrodzajuwykonywanychzadań—naprzykładtestowaniaczyanalizybiznesowej – Scrum nie uznaje podzespołów w Zespole Deweloperskim i od tejregułyniemawyjątków.

• Mimo, iż pojedynczy członkowie Zespołu Deweloperskiego mogą posiadaćwyspecjalizowane umiejętności i mogą skupiać się na konkretnych dziedzinach,odpowiedzialnośćzawykonywanąpracęponosicałyZespółDeweloperski.

WielkośćZespołuDeweloperskiego

Zespół Deweloperski powinien być na tyle mały, by pozostał zwinnym i jednocześniewystarczającoduży, żebymógłwykonać znaczącąpracęw ramach Sprintu.Mniej niż trojeczłonków oznacza mniejszy stopień interakcji i niższy wzrost produktywności. MniejszeZespoły Deweloperskie mogą napotykać w trakcie Sprintu braki kompetencjiuniemożliwiająceimdostarczanieProduktugotowegodopotencjalnegowydania.Więcejniżdziewięcioro członków wymaga zbyt dużych nakładów na koordynację. Wysoka liczbaczłonkówzespołupowoduje,żezarządzaniezespołemstajesięzbytzłożone,bymożliwebyłozastosowanie procesu empirycznego. OsobyWłaściciela Produktu i ScrumMastera nie sąwliczanewpodanewyżejwartości,chybażewykonująonejednocześniepracęwynikającązBackloguSprintu(ang.SprintBacklog).

ScrumMaster

Scrum Master jest odpowiedzialny za to, by Scrum był rozumiany i stosowany. ScrumMasterzy dokonują tegopoprzez zapewnienie, że Zespół Scrumowy stosuje się do założeńteoriiScruma,jegopraktykireguł.

ScrumMasteramożnaokreślićmianemprzywódcysłużebnegoZespołuScrumowego.ScrumMasterpomagatakżeosobomspozaZespołuScrumowegozrozumieć,którez ich interakcjizZespołem Scrumowym są pomocne, a które nie. Scrum Master pomaga zmieniać tezachowania,abymaksymalizowaćwartośćwytwarzanąprzezZespółScrumowy.

2 Wjęzykuangielskimtermin„Developer”oznaczaosobę,którawspółtworzyproduktbezwzględunaswojąspecjalizację.WtakimznaczeniutenterminjestużywanywScrumie.


Strona|7

JakScrumMasterwspieraWłaścicielaProduktu?

ScrumMasterwspieraWłaścicielaProduktuwwieluaspektach,naprzykład:

• wznajdowaniutechnikefektywnegozarządzaniaBacklogiemProduktu, • pomagając Zespołowi Scrumowemu zrozumieć potrzebę formułowania jasnych

izwięzłychelementówBackloguProduktu • wrozumieniuzasadplanowaniaproduktuwśrodowiskuempirycznym, • zapewniając, że Właściciel Produktu wie, jak porządkować Backlog Produktu, aby

maksymalizowaćwartość, • wrozumieniuipraktykowaniuzwinności(ang.agility), • wspomagającprzebiegzdarzeńscrumowych,kiedyjesttokoniecznelubkiedyjesto

toproszony.

JakScrumMasterwspieraZespółDeweloperski?

ScrumMasterpomagaZespołowiDeweloperskiemunakilkasposobów,naprzykład:

• coachując Zespół Deweloperski w zakresie wykorzystania zasad samoorganizacjiimiędzyfunkcyjności,

• pomagającZespołowiDeweloperskiemuwzakresietworzeniaproduktówowysokiejwartości,

• usuwającprzeszkodyograniczającepostępyZespołuDeweloperskiego, • wspomagającprzebiegzdarzeńscrumowych,kiedyjesttokoniecznelubkiedyjesto

toproszony, • coachując Zespół Deweloperski w zakresie sposobu wykonywania pracy w

organizacjach,wktórychScrumniejestjeszczewpełniprzyjętyirozumiany.

JakScrumMasterwspieraorganizację?

ScrumMasterpomagacałejorganizacjinakilkasposobów,naprzykład:

• przewodząc procesom wdrażania Scruma oraz prowadząc coaching osób w tenproceszaangażowanych,

• planującwykorzystanieScrumawewnątrzorganizacji, • wspierając pracowników i interesariuszy w zrozumieniu i stosowaniu Scruma oraz

empirycznegopodejściadorozwojuproduktu, • powodując zmiany prowadzące do zwiększania produktywności Zespołu

Scrumowego, • współpracując z innymi Scrum Masterami w celu zwiększenia efektywności

wykorzystaniaScrumaworganizacji.

ZdarzeniawScrumieZdarzenia opisane w Scrumie są używane do wprowadzenia regularności i ograniczeniapotrzeby organizowania innych, nieujętych w Scrumie spotkań. Wszystkie zdarzenia wScrumiesąograniczoneczasowo(ang.timebox),cooznacza,żemaksymalnyczasichtrwaniajestustalonyzgóry.CzastrwaniaSprintujestustalanywchwili jegorozpoczęciainiemożebyć skracany ani wydłużany. Pozostałe zdarzenia mogą się kończyć kiedy tylko ich celzostanie osiągnięty, co umożliwia wykorzystanie odpowiedniej ilości czasu i zabezpieczaprzedjegomarnotrawieniem.


Strona|8

KażdezezdarzeńwScrumie,opróczSprintu,któryzawierawsobiepozostałezdarzenia,jestokazją do przeprowadzenia inspekcji i dokonania adaptacji. Zdarzenia te są specjalniezaprojektowanewtakisposób,abyzapewnićniezbędnąprzejrzystośćiumożliwićinspekcję.Nieuwzględnienie któregokolwiek z nich redukuje przejrzystość i zaprzepaszcza szansę nadokonanieinspekcjiiadaptacji.

Sprint

Sercem Scruma jest Sprint — ograniczenie czasowe trwające jeden miesiąc lub krócej,podczas któregowytwarzany jest „Ukończony”, gotowydoużycia i potencjalnegowydaniaPrzyrost.Najlepiej,jeśliSprintymająstałądługośćprzezcałyokrestrwaniaprac.NowySprintrozpoczynasiębezpośredniopozakończeniupoprzedniego.

Sprinty zawierają i składają się z Planowania Sprintu, Codziennych Scrumów, pracywytwórczej,PrzegląduSprintuiRetrospektywySprintu.

PodczasSprintu:

• niesąwprowadzanezmianystanowiącezagrożeniedlarealizacjiCeluSprintu,• celejakościoweniesąobniżane,• zakrespracmożebyćwyjaśnianyirenegocjowanypomiędzyWłaścicielemProduktu

aZespołemDeweloperskimzawsze,gdyodkrywanejestcośnowego.

KażdySprintmożebyćpostrzeganyjakoprojektsięgającyniedalejniżmiesiącwprzód.Jakkażdyprojekt,Sprintużywanyjestdoosiągnięciajakiegoścelu.ZkażdymSprintemzwiązanyjest opis tego, co należy zbudować, projekt oraz elastyczny plan wykonywania pracprowadzącychdopowstaniaoczekiwanegoproduktu.

Czas trwania Sprintu jest ograniczonydo jednegomiesiąca kalendarzowego. Jeśli horyzontzakończenia Sprintu jest zbyt odległy, może zmienić się definicja tego, co ma zostaćzbudowane, może zwiększyć się złożoność oraz wzrosnąć ryzyko. Sprinty wprowadzająprzewidywalność, zapewniając, że proces inspekcji i adaptacji w kierunku osiągnięcia CeluSprintu będzie zachodził przynajmniej co miesiąc. Ponadto Sprinty ograniczają ryzyko dokosztujednegomiesiącakalendarzowego.

PrzerywanieSprintu

Sprint może zostać przerwany przed upływem ograniczenia czasowego. Tylko WłaścicielProduktumaprawoprzerwaćSprint,jednakmożepodjąćtakądecyzjępodwpływemopiniiinteresariuszy,ZespołuDeweloperskiegolubScrumMastera.

Sprintmoże zostać przerwany, jeśli Cel Sprintu się zdezaktualizuje.Może tak się stać, gdyfirma zmieni kierunek rozwoju lub gdy zmienią się uwarunkowania rynkowe lubtechnologiczne. Ogólnie rzecz ujmując Sprint powinien zostać przerwany, jeślikontynuowanie prac nie ma sensu w zaistniałych okolicznościach. Jednak ze względu nakrótkiczastrwaniaSprintówichprzerywanierzadkojestsensowne.

KiedySprintjestprzerywany,„Ukończone”elementyBackloguProduktusąprzeglądane.Jeśliczęść tej pracy nadaje się do potencjalnego wydania, Właściciel Produktu zwykle jąakceptuje.WszystkienieukończoneelementyBackloguProduktu sąponownie szacowane izwracane do Backlogu Produktu. Praca na nich wykonana szybko się dewaluuje i z tegowzględumusibyćczęstoszacowanapowtórnie.


Strona|9

Przerwanie Sprintu zużywa zasoby, ponieważ wszyscy muszą się przegrupować podczaskolejnego Planowania Sprintu, aby móc rozpocząć nowy Sprint. Przerwania Sprintów sązwykletraumatycznedlaZespołuScrumowegoizachodząbardzorzadko.

PlanowanieSprintu

Pracaprzeznaczonadowykonaniaw Sprincie jest planowanapodczas Planowania Sprintu.PlantenpowstajewefekciewspólnejpracyczłonkówZespołuScrumowego.

Planowanie Sprintu jest zdarzeniem ograniczonym do ośmiu godzin dla miesięcznegoSprintu. Dla krótszych Sprintów jest ono zwykle krótsze. Rolą Scrum Mastera jestzapewnienie, że Planowanie Sprintu się odbywa i jego uczestnicy rozumieją cel tegozdarzenia. Scrum Master uczy Zespół Scrumowy utrzymywać je w wyznaczonych ramachczasowych.

PlanowanieSprintudajeodpowiedźnanastępującepytania:

• Co może zostać dostarczone w ramach Przyrostu będącego rezultatemnadchodzącegoSprintu?

• Wjakisposób,niezbędnadodostarczeniaPrzyrostu,pracabędzierealizowana?

Tematpierwszy:ComożezostaćzrobionewSprincie?ZespółDeweloperskiprognozujezakresprac,któryzostaniezrealizowanywtrakcieSprintu.Właściciel Produktu omawia założenia Sprintu i te elementy Backlogu Produktu, którychrealizacjawtrakcieSprintupozwolinaosiągnięcieCeluSprintu.ZespółScrumowywspólniepracujenadzrozumieniempracyprzewidzianejnanajbliższySprint.

PlanowanieSprintuopartejestnaBackloguProduktu,ostatnimPrzyroście,przewidywanychmożliwościach Zespołu Deweloperskiego w Sprincie oraz ostatnich odczytach wydajnościtegoZespołu.DecyzjaoliczbieelementówBackloguProduktuwybranychdoSprintunależytylko iwyłączniedo ZespołuDeweloperskiego. Tylko ZespółDeweloperskimożeocenić, cojestwstanieosiągnąćwnadchodzącymSprincie.

Po określeniu przez Zespół Deweloperski, które elementy Backlogu Produktu będądostarczone, Zespół Scrumowy tworzy Cel Sprintu. Jest to cel, który zostanie osiągniętywramachSprintupoprzez implementacjęwybranychelementówBackloguProduktu.PomagaZespołowiDeweloperskiemuzrozumieć,wjakimcelutworzonybędziePrzyrost.

Tematdrugi:Wjakisposóbwybranyzakrespracyzostaniezrealizowany?PookreśleniuCeluSprintuorazwybraniuelementówBackloguProduktudoSprintuZespółDeweloperskidecyduje,wjakisposóbzostanąoneprzekształconew„Ukończony”Przyrost.Wybrane elementy Backlogu Produktu wraz z planem ich dostarczenia nazywane sąBacklogiem Sprintu.

Zespół Deweloperski zwykle rozpoczyna od projektowania systemu i zarysowania pracniezbędnych do przekształcenia elementów Backlogu Produktu w działający Przyrostproduktu.Pracamożebyćzróżnicowanapodkątem ilości lubszacowanejpracochłonności.NiemniejpodczasPlanowaniaSprintuZespółDeweloperskirozplanowujeswojedziałaniawstopniu dającym mu możliwość oceny, co może zostać zrealizowane w nadchodzącymSprincie.WtrakcietegospotkaniapracaplanowananapierwszedniSprintujestrozpisywanana mniejsze porcje, często nie większe niż jeden dzień roboczy. Zespół Deweloperskisamodzielnie podejmuje się pracy wynikającej z Backlogu Sprintu, zarówno podczasPlanowaniaSprintu,jakizgodniezpotrzebamiwtrakcieSprintu.


Strona|10

WłaścicielProduktumożepomócwyjaśniaćwybraneelementyBackloguProduktuiosiągaćkompromisy. Jeśli Zespół Deweloperski ustali, że ma za dużo lub za mało pracy, możerenegocjować wybrane elementy Backlogu Produktu z Właścicielem Produktu. ZespółDeweloperskimoże także zaprosić na to spotkanie inneosoby, abywsparły Zespółwiedzątechnicznąlubdomenową.

Zanim Planowanie Sprintu dobiegnie końca, Zespół Deweloperski powinien być w staniewytłumaczyćWłaścicielowiProduktuiScrumMasterowi,wjakisposóbmazamiarpracować,organizującsięsamodzielnie,byosiągnąćCelSprintuiwytworzyćoczekiwanyPrzyrost.

CelSprintu

CelSprintutozałożenie,którezostaniespełnionewramachSprintupoprzezimplementacjęwybranych elementów Backlogu Produktu. Dostarcza Zespołowi Deweloperskiemuwskazówek w jakim celu tworzony jest Przyrost. Jest on tworzony podczas PlanowaniaSprintu.CelSprintudajeZespołowiDeweloperskiemupewnąswobodęcodosposobu,wjakidana funkcjonalność zostanie zaimplementowana. Zazwyczaj wybrane elementy BackloguSprintustanowiąspójnącałość,któramożestaćsięCelemSprintu.CelemSprintumożetakżebyć cokolwiek, co spowoduje, że Zespół Deweloperski będzie pracował razem, a nie nadodrębnymiinicjatywami.

WtrakcieSprintuZespółDeweloperskipamiętaoCeluSprintu.Abygoosiągnąć,wprowadzanowe funkcjonalności i wdraża nowe technologie. Jeśli podczas Sprintu charakter pracokazuje się inny niż oczekiwał Zespół Deweloperski, Zespół Deweloperski podejmujewspółpracęzWłaścicielemProduktu,abyrenegocjowaćzakresBackloguSprintu.

CodziennyScrum

CodziennyScrum jest zdarzeniemdlaZespołuDeweloperskiego,ograniczonymczasowodopiętnastuminut,podczasktóregobieżącedziałaniasąsynchronizowane ipowstajeplannanajbliższedwadzieściaczterygodziny.Jesttoosiąganepoprzezinspekcjęprac,którezostaływykonane od ostatniego Codziennego Scruma i prognozowanie prac, które mogą zostaćwykonane przed kolejnym spotkaniem. Aby zredukować złożoność, Codzienny Scrum mawyznaczone stałe miejsce i czas. Podczas tego spotkania każdy członek ZespołuDeweloperskiegoudzielainformacji:

• Co zrobiłem wczoraj, co pomogło Zespołowi Deweloperskiemu przybliżyć się doosiągnięciaCeluSprintu?

• Co zrobię dzisiaj, co pomoże Zespołowi Deweloperskiemu przybliżyć się doosiągnięciaCeluSprintu?

• Czy widzę jakiekolwiek przeszkody mogące uniemożliwić mi lub ZespołowiDeweloperskiemuosiągnięcieCeluSprintu?

ZespółDeweloperskiużywaCodziennychScrumówdoocenypostępówpracwkierunkuCeluSprintu i trendu względem ukończenia całej pracy z Backlogu Sprintu. Codzienny Scrumzwiększa szanse osiągnięcia przez Zespół Deweloperski Celu Sprintu. Każdego dnia SprintuZespółDeweloperskipowinienwiedziećwjakisposóbbędzieprzebiegaładalszawspółpracaw zespole by, przy wykorzystaniu reguł samoorganizacji, osiągnąć Cel Sprintu i zbudowaćoczekiwany Przyrost. Cały Zespół Deweloperski lub poszczególni jego członkowie częstospotykają się bezpośrednio po Codziennym Scrumie, aby szczegółowo przedyskutowaćwybranezagadnienialubdostosowaćplanpracnapozostałączęśćSprintu.


Strona|11

ScrumMasterzapewnia,żeZespółDeweloperskispotykasięwramachCodziennegoScruma,jednak to Zespół Deweloperski jest odpowiedzialny za przebieg tego spotkania. ScrumMaster uczy Zespół Deweloperski, jak utrzymać piętnastominutowe ograniczenie czasoweCodziennegoScruma.

ScrumMasteregzekwujezasadę,żetylkoZespółDeweloperskibierzeudziałwCodziennymScrumie.

CodzienneScrumypoprawiająkomunikację,eliminująinnespotkania,identyfikująiusuwająprzeszkody, sprzyjają szybkiemupodejmowaniu decyzji i podnoszą poziomwiedzy ZespołuDeweloperskiego.Jesttospotkaniekluczowedlaprocesuinspekcjiiadaptacji.

PrzeglądSprintu

PrzeglądSprintutospotkanieorganizowanenazakończenieSprintuwceluprzeprowadzeniainspekcji Przyrostu i, jeśli zajdzie takapotrzeba,dostosowaniaBackloguProduktu.PodczasPrzegląduSprintuZespółScrumowyiinteresariuszewspółpracująwzakresietego,cozostałoukończone w Sprincie. Na tej podstawie oraz na podstawie zmian wprowadzonych doBackloguProduktuwtrakcieSprintu,uczestnicyspotkaniawspólnierozważają,comogłobybyćwykonanewnastępnejkolejności,abyzwiększyćdostarczanąwartość.PrzeglądSprintujest nieformalnym spotkaniem roboczym, a nie spotkaniem statusowym. PrezentacjaPrzyrostumanaceluuzyskanieinformacjizwrotnejipobudzeniewspółpracy.

Przegląd Sprintu jest maksymalnie czterogodzinnym spotkaniem dla miesięcznego Sprintuikrótszym dla krótszych Sprintów. Rolą ScrumMastera jest zapewnienie, że spotkanie sięodbywaijegouczestnicyrozumiejąjegocel.ScrumMasteruczywszystkichzgromadzonych,jakutrzymywaćjewwyznaczonychramachczasowych.

PrzeglądSprintuobejmujenastępującepunkty:

• Obecni są Zespół Scrumowy oraz kluczowi interesariusze zaproszeni przezWłaścicielaProduktu.

• Właściciel Produktu wyjaśnia, które funkcjonalności zostały „Ukończone”, a którenie.

• ZespółDeweloperski omawia, coposzłodobrzew trakcie Sprintu, jakie napotkanoproblemyorazjakteproblemyrozwiązano.

• Zespół Deweloperski prezentuje „Ukończoną” pracę i odpowiada na pytaniadotyczącePrzyrostu.

• Właściciel Produktu omawia Backlog Produktu w jego aktualnej postaci. Jeślizachodzi taka potrzeba, przewiduje termin zakończenia prac, biorąc pod uwagędotychczasowepostępyitempo.

• Całagrupawspólnieomawiakolejnekroki.WtensposóbPrzeglądSprintudostarczawartościowegowkładuwnastępująceponimPlanowanieSprintu.

• Dokonuje się przeglądu tego, jak rynek lub potencjalne zastosowanie produktumogłysięzmienićicowtejsytuacjijestnajbardziejwartościowąrzecządozrobienia.

• Rewiduje się czas, budżet, potencjalne możliwości i uwarunkowania rynkowe dlakolejnegoprzewidywanegowydaniaproduktu.

Rezultatem Przeglądu Sprintu jest zaktualizowany Backlog Produktu, pokazujący, któreelementy prawdopodobnie zostaną zaplanowane na kolejny Sprint. Ponadto BacklogProduktumożezostaćzmienionywtakisposób,abywykorzystaćnadarzającesięokazje.


Strona|12

RetrospektywaSprintu

Retrospektywa Sprintu jest okazją dla Zespołu Scrumowego do przeprowadzenia inspekcjiswoich działań i opracowania planu usprawnień, który zostanie wcielony w życie wnajbliższymSprincie.

RetrospektywaSprintuprzeprowadzanajestpoPrzeglądzie,aprzedkolejnymPlanowaniemSprintu i trwa nie dłużej niż trzy godziny dla Sprintówmiesięcznej długości. Dla krótszychSprintówzwyklezajmujemniejczasu.ScrumMasterzapewnia,żewydarzeniesięodbędzie,uczestnicyzrozumiejąjegocel iuczyich,jakutrzymaćjewokreślonychramachczasowych.ScrumMasteruczestniczywRetrospektywiejakozwykłyczłonekzespołuodpowiedzialnyzaScruma.

RetrospektywaSprintumanacelu:

• sprawdzenie, co działo się w ostatnim Sprincie, biorąc pod uwagę ludzi, relacje,procesyinarzędzia,

• zidentyfikowanie i uporządkowanie istotnych elementów, które sprawdziły sięwdziałaniuoraztych,którekwalifikująsiędousprawnienia,

• stworzenie planu wprowadzania w życie usprawnień sposobu wykonywania pracyprzezZespółScrumowy.

ScrumMaster zachęca członkówZespołu Scrumowegodousprawnianiaw ramach Scrumaprocesu i praktyk wytwórczych tak, aby w kolejnym Sprincie uczynić wykonywaną pracębardziej efektywną i dającą więcej radości. Podczas każdej Retrospektywy Sprintu ZespółScrumowy planuje, w jaki sposób podniesie jakość produktu dostosowując DefinicjęUkończeniadoaktualnychpotrzeb.

ZanimRetrospektywaSprintudobiegnie końca, Zespół Scrumowypowinien zidentyfikowaćusprawnienia, które zostaną wprowadzone w kolejnym Sprincie. Zastosowanie tychusprawnień w kolejnych Sprintach jest przejawem adaptacji, która nastąpiła w efekcieautoinspekcji Zespołu Scrumowego. Mimo, że usprawnienia mogą być wprowadzane wdowolnym momencie, Retrospektywa jest formalnym elementem Scruma, całkowicieskoncentrowanymnaprocesieinspekcjiiadaptacji.

ArtefaktyScrumaArtefakty Scruma reprezentują pracę lub wartość, aby uzyskać przejrzystość i okazję dodokonania inspekcji i adaptacji. Są one zaprojektowane w taki sposób, by zwiększaćdostępność iczytelność kluczowych informacji tak, by wszyscy zainteresowani rozumielidanyartefaktwtakisamsposób.

BacklogProduktu

BacklogProduktutouporządkowanalistawszystkiego,comożebyćpotrzebnewprodukcieoraz jedyne źródło wymaganych zmian, które mają być w produkcie wprowadzone.OdpowiedzialnymzaBacklogProduktu,w tym jegozawartość,dostępność i kolejność, jestWłaścicielProduktu.

Backlog Produktu nigdy nie jest kompletny. Jego wczesna wersja jedynie nakreślapoczątkowo znane i najlepiej rozumiane wymagania. Backlog Produktu ewoluuje wraz zproduktemiśrodowiskiem,wktórymtenproduktbędzieużywany.Backlogjestdynamiczny


Strona|13

–ciąglesięzmienia,abyuwzględnićto,czegoproduktwymaga,abystaćsięodpowiednim,konkurencyjnymiużytecznym.BacklogProduktuistniejetakdługo,jakistniejeprodukt.

Backlog Produktu jest listą wszystkich cech, funkcji, wymagań, ulepszeń i korekt błędów,które reprezentują zmiany wprowadzane do produktu w jego przyszłych wydaniach.ElementyBackloguProduktuposiadająnastępująceatrybuty:opis,kolejność,oszacowanieiwartość.

W miarę, jak produkt jest używany i nabiera wartości, a otoczenie rynkowe dostarczainformacji zwrotnej,BacklogProduktu staje się corazwiększą ibardziejwyczerpującą listą.Wymagania nie przestają się zmieniać, więc Backlog Produktu jest żywym artefaktem.Zmianywwymaganiachbiznesowych,sytuacjirynkowejczytechnologiimogąprowadzićdozmianwBackloguProduktu.

CzęstonadjednymproduktempracujewspólniekilkaZespołówScrumowych.DoopisywaniaprzyszłejpracynadproduktemużywanyjestjedenBacklogProduktu.WtakichprzypadkachmożezostaćzastosowanydodatkowyatrybutgrupującyelementyBackloguProduktu.

Doskonalenie (ang. refinement) Backlogu Produktu jest działaniem polegającym nadodawaniuszczegółów,oszacowańiporządkowaniuelementówBackloguProduktu.Jesttociągły proces, podczas którego Właściciel Produktu wraz z Zespołem Deweloperskimopracowują szczegóły elementów Backlogu Produktu. Podczas doskonalenia BackloguProduktu jego elementy są przeglądane i korygowane. To, jak i kiedy dochodzi dodoskonalenia, zależy od decyzji Zespołu Scrumowego. Doskonalenie zazwyczaj nie zajmujewięcejniż10%czasuZespołuDeweloperskiegowSprincie.Niezmieniatofaktu,żeelementyBackloguProduktumogąbyćuaktualnianewkażdejchwiliprzezWłaścicielaProduktulubzajegozgodą.

ElementyBackloguProduktuznajdującesięwyżejsązwykleklarowniejszeiposiadająwięcejszczegółów niż te poniżej.W oparciu o zwiększoną czytelność i większą liczbę szczegółówprzygotowywane są bardziej precyzyjne oszacowania. Im niższa pozycja w BackloguProduktu, tym mniej szczegółów. Elementy przewidziane na najbliższy Sprint mają takąwielkośćiszczegółowość,bykażdyznichmógłbyćbeztruduukończonywjednymSprincie.ElementyBackloguProduktu,któremogązostać„Ukończone”przezZespółDeweloperskiwpojedynczym Sprincie, uznawane są za „Przygotowane” do Planowania Sprintu. ElementyBacklogu Produktu zwykle osiągają taki poziom przejrzystości poprzez opisany powyżejprocesdoskonalenia.

Zespół Deweloperski jest odpowiedzialny za wszystkie oszacowania. Właściciel Produktumoże wpływać na Zespół Deweloperski pomagając dostrzegać kompromisy i dokonywaćodpowiednichwyborów,aleostateczniepracęszacująosoby,którebędąjąwykonywać.

Monitorowaniepostępówwzględemcelu

W dowolnym momencie można podsumować całą pozostającą do wykonania pracę.Właściciel Produktu dokonuje takiego podsumowania przynajmniej podczas każdegoPrzegląduSprintu.NastępnieporównujetęilośćzilościąpracysprzedrozpoczęciaSprintu–określonąpodczaspoprzedniegoPrzegląduSprintu—abyocenić, jak kształtuje siępostęppracyimożliwośćjejukończeniazgodniezzałożonymcelemiwwyznaczonymczasie.Ocenatajestprezentowana wprzejrzystysposóbwszystkiminteresariuszom.

Doprognozowaniapostępówpracstosowanesąróżnesposobymonitorowaniatrendutakiejak: spalanie/wypalanie (ang.burn-down/burn-up) lubwykresykumulatywne.Wszystkie są


Strona|14

pomocne, jednak nie zastępują istoty empiryzmu. W złożonych środowiskach to, co sięwydarzy, jest niewiadomą. Tylko to, co już się zdarzyło, może być wykorzystywane dopodejmowaniadecyzjiwybiegającychwprzyszłość.

BacklogSprintu

BacklogSprintutozbiórelementówBackloguProduktuwybranychdoSprinturozszerzonyoplandostarczeniaPrzyrostuproduktuirealizacjiCeluSprintu.PoprzezBacklogSprintuZespółDeweloperski prognozuje, które funkcjonalności znajdą się w kolejnym Przyroście i jakąpracę należy wykonać, aby te funkcjonalności dostarczyć w postaci „Ukończonego”Przyrostu.

Backlog Sprintu obrazuje pracę, którą Zespół Deweloperski uznaje za niezbędną doosiągnięciaCeluSprintu.

BacklogSprintutoplanwystarczającoszczegółowy,bypostępypracbyłyzrozumiałepodczasCodziennego Scruma. Zespół Deweloperski modyfikuje Backlog Sprintu w czasie trwaniacałegoSprintu, tymsamym„wyłaniasię”onpodczasSprintu.Towyłanianiesięzachodziwmiarę jak ZespółDeweloperski realizuje plan i dowiaduje się corazwięcej na temat pracy,którajestpotrzebnadoosiągnięciaCeluSprintu.

Jeśli pojawia siępotrzebawykonaniadodatkowejpracy, ZespółDeweloperskidodaje jądoBacklogu Sprintu.Wmiarę jak praca jest wykonywana albo kończona, aktualizowane jestoszacowanie pozostałej dowykonania pracy. Zbędne elementy planu są usuwane. JedynieZespółDeweloperskimożezmieniaćswójBacklogSprintuwtrakcieSprintu.BacklogSprintujest dobrze widocznym, tworzonym na bieżąco obrazem pracy, jaką Zespół Deweloperskiplanuje wykonać w trakcie Sprintu. Backlog Sprintu jest wyłączną własnością ZespołuDeweloperskiego.

MonitorowaniepostępówSprintu

WkażdymmomencieSprintucałapozostającadowykonaniapracazBackloguSprintumożezostaćzsumowana.ZespółDeweloperskipodsumowujetępracęprzynajmniejrazdziennie–podczasCodziennegoScruma.ZespółDeweloperskiobserwujezmianyjejilościkażdegodniaSprintu i na tej podstawie określa prawdopodobieństwo osiągnięcia Celu Sprintu. Poprzezcodzienne monitorowanie pozostałej do wykonania pracy, Zespół Deweloperski zarządzapostępamiswojejpracy.

Przyrost

PrzyrostjestsumąwszystkichelementówBackloguProduktuzakończonychpodczasSprintuiwszystkichSprintówpoprzednich.NakoniecSprintunowyPrzyrostmusibyć„Ukończony”,cooznacza,żemusionbyćgotowydoużyciaizgodnyzDefinicjąUkończeniadanegoZespołuScrumowego. Przyrost musi być gotowy do użycia niezależnie od tego, czy WłaścicielProduktudecydujesięnajegowydanie.

PrzejrzystośćArtefaktówScrumopierasięnaprzejrzystości.Decyzjemającenaceluoptymalizacjęwartościikontrolęryzyka są podejmowane na podstawie obserwowanego stanu artefaktów. W przypadkuzachowaniapełnejprzejrzystościdecyzje temają solidnąpodstawę.Natomiastbrakpełnej


Strona|15

przejrzystościartefaktówmożeprowadzićdobłędnychdecyzji,obniżeniawartościiwzrosturyzyka.

Scrum Master musi pracować z Właścicielem Produktu, Zespołem Deweloperskim ipozostałymi zainteresowanymi stronami, aby ustalić czy artefakty są w pełni przejrzyste.IstniejeszeregsposobówradzeniasobiezbrakiempełnejprzejrzystościiScrumMastermusipomagaćwszystkimw doborze praktyk najbardziej odpowiednichw danej sytuacji. ScrumMaster może identyfikować brak pełnej przejrzystości poddając artefakty inspekcji,wyczuwając schematyczność, słuchającuważnie tego,o czymsię rozmawiaorazwyłapującróżnicepomiędzyoczekiwanymiarzeczywistymiwynikami.

Zadaniem Scrum Mastera jest praca z Zespołem Scrumowym i całą organizacją w celuzwiększenia przejrzystości artefaktów. Praca ta polega zazwyczaj na dowiadywaniu się,przekonywaniuipowodowaniuzmiany.Przejrzystośćniepojawiasięzdnianadzień—jestdrogą.

DefinicjaUkończenia

Kiedy element Backlogu Produktu albo Przyrost jest określany jako „Ukończony”, wszyscymuszą rozumieć, co to właściwie oznacza. Mimo, że różni się to znacznie pomiędzyZespołami Scrumowymi, w celu zapewnienia przejrzystości wszyscy członkowie danegozespołu muszą mieć wspólne rozumienie, co oznacza stwierdzenie, że praca zostałazakończona. Tym właśnie jest Definicja Ukończenia (ang. Definition of Done) ZespołuScrumowego,używanawocenie,czypracanadPrzyrostemproduktujestzakończona.

Ta sama definicja pomaga Zespołowi Deweloperskiemu w określeniu, ile elementówBacklogu Produktu może zostać wybranych podczas Planowania Sprintu. Celem każdegoSprintu jest dostarczenie Przyrostu gotowej do potencjalnego wydania funkcjonalności,zgodniezaktualnąDefinicjąUkończeniaZespołuScrumowego.

W każdym Sprincie Zespoły Deweloperskie dostarczają Przyrost funkcjonalności produktu.Przyrosttenmusibyćgotowydoużycia,żebyWłaścicielProduktumógłzdecydowaćojegoniezwłocznym wydaniu. Kiedy Definicja Ukończenia Przyrostu jest elementem konwencji,standardówlubwytycznychstosowanychprzezorganizacjęwytwarzającąoprogramowanie,wszystkie Zespoły Scrumowe muszą jej przestrzegać jako niezbędnego minimum. JeślinatomiastDefinicjaUkończeniaPrzyrostunienależydokonwencjiorganizacjiwytwarzającejoprogramowanie, ZespółDeweloperskimusi opracowaćDefinicjęUkończeniawłaściwądlawytwarzanegoproduktu.KiedynadwydaniemsystemulubproduktupracujewieleZespołówScrumowych, wszystkie Zespoły Deweloperskie muszą wspólnie ustanowić DefinicjęUkończenia.

Każdy Przyrost jest rozszerzeniem wszystkich poprzednich Przyrostów i jest dokładnieprzetestowanywceluzapewnienia,żewszystkieonedziałająrazem.

WmiaręjakZespołyScrumowedojrzewają,oczekujesię,żeichDefinicjaUkończeniabędziezawierała coraz bardziej rygorystyczne kryteria zapewniania jeszczewyższej jakości. Każdyprodukt lubsystempowinienposiadaćDefinicjęUkończenia,któraokreślastandardypracynadnim.


Strona|16

UwagikońcoweScrum jest bezpłatny i oferowany za pośrednictwem tego przewodnika. Role, artefakty,zdarzenia oraz reguły Scruma są niezmienne i choć możliwe jest wykorzystanie tylkowybranych jego elementów, wynikiem takiego postępowania nie będzie Scrum. Scrumistniejetylkowswojejpełnejpostaciisprawdzasiędoskonalewroliramydlainnychtechnik,metodykczypraktyk.


Strona|17

Wyrazyuznania

Ludzie Spośród tysięcy osób, które przyczyniły się do powstania Scruma, należy wyróżnić tych,którzy aktywnie uczestniczyli w jego tworzeniu podczas pierwszych dziesięciu lat. Przedewszystkim Jeffa Sutherlanda współpracującego z Jeffem McKenną oraz Kena Schwaberadziałającego wspólnie z Mike’iem Smithem i Chrisem Martinem. Wiele innych osóbprzyczyniłosiędo jegorozwojuwciągukolejnych lat ibez ichpomocyScrumnieprzyjąłbypostaciznanejnamdzisiaj.

Historia

KenSchwaberiJeffSutherlandporazpierwszyzaprezentowaliScrumapodczaskonferencjiOOPSLAw1995 r. Prezentacja tamerytorycznieudokumentowaławiedzę, którąKen i JeffnabylistosującScrumawciągukilkupoprzednichlat.

Scrum ma za sobą długą historię. Warto wyróżnić miejsca, w których był początkowowypróbowywany i udoskonalany: Individual, Inc., Fidelity Investments oraz IDX (obecnie GEMedical).

PrzewodnikpoScrumiedokumentujeScrumawtakiejpostaciwjakiejzostałonstworzonyijest utrzymywany od ponad 20 lat przez Jeffa Sutherlanda i Kena Schwabera. Inne źródładostarczająwzorców, procesów i pomysłów, które uzupełniają wytyczone przez Scrumaramy.Zwiększająoneproduktywność,wartość,kreatywnośćidumęzwykonywanejpracy.

Tłumaczenie

Niniejszy przewodnik został przetłumaczony z wersji oryginalnej, opracowanej przez KenaSchwabera i Jeffa Sutherlanda. Do opracowania tłumaczenia przyczynili się m.in.: TomekWłodarek ([email protected]), Kate Terlecka ([email protected]), BogdanBaraszkiewicz ([email protected]), Norbert Kołakowski([email protected]) oraz Adam Michalczyk ([email protected]), akońcowegoszlifuortograficznegodostarczyłKamilBłażejczak([email protected]).


Strona|18

Historiazmian

Zmianywprzewodnikupomiędzywersjami2013a2016

1. ZostaładodanasekcjapoświęconaWartościomScruma.GdyZespółScrumowyprzyjmiewartości zaangażowania, odwagi, skupienia, otwartości i poszanowania i postępujezgodnie z nimi, do życia powoływane są filary Scruma – przejrzystość, inspekcja iadaptacja,tworzącatmosferęzaufaniapomiędzywszystkimiwspółpracującymiosobami.Członkowie Zespołu Scrumowego odkrywają te wartości i uczą się ich pracując zwydarzeniami,rolamiiartefaktamiScruma.PowodzeniewwykorzystaniuScrumazależyod biegłości postępowania zgodnie z tymi pięcioma wartościami. Wszyscy osobiściezobowiązują się osiągać cele Zespołu Scrumowego. Członkowie Zespołu Scrumowegomająodwagępostępowaćwłaściwie iprzezwyciężaćtrudności.Wszyscyskupiająsięnapracyw Sprincie i celach Zespołu Scrumowego. Zespół Scrumowy i jego interesariuszezgadzająsiępozostawaćotwartyminawszystkieaspektywykonywanejpracyizwiązanezniąwyzwania.CzłonkowieZespołuScrumowegowzajemnierespektująswojeprawodobycianiezależnymi,kompetentnymiludźmi.

Zmianywprzewodnikumiędzywersjami2011a2013

2. Został dodany rozdział poświęcony przejrzystości artefaktów. Scrum opiera się naprzejrzystości. Decyzje podnoszące wartość i kontrola ryzyka zależne są odpostrzeganego stanu artefaktów. Decyzje temajątak solidną podstawę, jak pełna jestprzejrzystość artefaktów. Jeśli przejrzystość nie jest pełna, podejmowane decyzje sąobarczonebłędami,wartośćjestobniżanaaryzykosięzwiększa.

3. Planowanie Sprintu jest teraz jednym wydarzeniem, zajmującym się dwomazagadnieniami: co może zostać wykonane w Sprincie oraz w jaki sposób wybrana doSprintu praca zostanie zrealizowana. W pierwszej kolejności Zespół Deweloperskiprognozuje, które elementy Backlogu Produktu zostanązrealizowanew Sprincie. Zarazpotem Zespół Scrumowy formułuje Cel Sprintu. Cel Sprintu uspójnia działania ZespołuDeweloperskiego, które bez wspólnego celu mogłyby pozostać nieskoordynowane.ZwróćuwagęnawyraźneakcentowanieznaczeniaCeluSprintu.

4. Backlog Produktu jest raczej doskonalony niż pielęgnowany. Udoskonalone elementyBackloguProduktusąprzejrzyste,wystarczającozrozumiałeorazwystarczającomałe,bymogłybyćwejściemdoPlanowaniaSprintuibyćwybranedoSprintu.ElementyBackloguProduktu o takiej przejrzystości są określane jako „Przygotowane” (do PlanowaniaSprintu).„Przygotowane”i„Ukończone”todwastany,którewzmacniająprzejrzystość.

5. Scrum zaleca stosowanie wydarzeń w celu wytworzenia regularności i zredukowaniapotrzeby organizowania innych niezdefiniowanych w Scrumie spotkań. Wszystkiewydarzeniasąograniczoneczasowo,cooznacza,żeczas ichtrwaniazostałwyznaczonyzgóry. Sprint, czyli wydarzenie obejmujące pozostałe wydarzenia, ma ustalony czastrwaniaiczastenniemożebyćskracanyaniwydłużany.Pozostałewydarzeniamogąbyćkończonekiedyichcelzostanieosiągnięty.Zjednejstronyzapewniato,żeprzeznaczonazostanieodpowiedniailośćczasu,zdrugiej–żeczastenniebędziemarnotrawiony.

6. Wzmocnione zostało znaczenie Codziennego Scruma w kontekście planowania. Zbytczęstotowydarzenie jestpostrzegane jakospotkaniestatusowe.KażdegodniaSprintu,Zespół Deweloperski powinien rozumieć w jaki sposób będzie współpracować jakozespółsamoorganizującysię,abyosiągnąćCelSprintuiabystworzyćoczekiwanyPrzyrost


Strona|19

przedkońcemSprintu.Wejściemdotegospotkania jestocena jakzespół radzi sobiewkontekście Celu Sprintu. Wyjściem jest nowy lub zrewidowany plan optymalizującywysiłki zespołu wkierunku Celu Sprintu. Aby to osiągnąć opracowano trzy pytania,akcentującezespółanieosobę:

a. Co zrobiłem wczoraj, co pomogło Zespołowi Deweloperskiemu przybliżyć się doosiągnięciaCeluSprintu?

b. Co zrobię dzisiaj, co pomoże Zespołowi Deweloperskiemu przybliżyć się doosiągnięciaCeluSprintu?

c. Czy widzę jakiekolwiek przeszkody mogące uniemożliwić mi lub ZespołowiDeweloperskiemuosiągnięcieCeluSprintu?

6. Wzmocniona została koncepcja wartości w kontekście Przeglądu Sprintu. PodczasPrzeglądu Sprintu Zespół Scrumowy i interesariusze współpracują w zakresie tego, cozostałowytworzonewSprincie.Woparciuoto i jakiekolwiekzmianywprowadzonedoBackloguProduktuwtrakcietrwaniaSprintuuczestnicyPrzegląduSprintuustalająkroki,którepowinnyzostaćpodjęte,abyzwiększyćwartość.

Przewodnik po Scrumie: Reguły gry · Scrum Mastera można określić mianem przywódcy...

Documents

Transcript of Przewodnik po Scrumie: Reguły gry · Scrum Mastera można określić mianem przywódcy...