A Scrum Útmutató. Meghatározó útmutató a Scrum-hoz: A játék szabályai. Kifejlesztette és karbantartja Ken Schwaber és Jeff Sutherland

Átírás

1 A Scrum Útmutató Meghatározó útmutató a Scrum-hoz: A játék szabályai Kifejlesztette és karbantartja Ken Schwaber és Jeff Sutherland

2 Tartalomjegyzék A Scrum útmutató célja...3 Scrum áttekintés...3 Scrum keretrendszer...3 Scrum elmélet...3 Scrum...4 Scrum-csapat...5 A Terméktulajdonos...5 A Fejlesztőcsapat...6 A Scrum Mester...6 Scrum Események...7 Sprint...8 Sprint-tervező Megbeszélés...9 Napi Scrum...10 Sprint Áttekintő...11 Sprint Visszatekintő...12 Scrum Munkaanyagok...12 Termék Backlog (Termék Teendőlista)...12 Sprint Backlog (Sprint Teendőlista)...14 Inkrementum...15 A Kész meghatározása...15 Összegzés...15 Köszönetnyilvánítás...15 Emberek...15 Történet Ken Schwaber és Jeff Sutherland, Minden jog fenntartva! 2 Oldal

3 A Scrum útmutató célja A Scrum egy olyan keretrendszer, amelyet komplex termékek fejlesztésére és fenntartására hoztak létre. Ez a kalauz a Scrum leírását tartalmazza, mely a Scrum szerepekből, eseményekből, munkaanyagokból és az ezeket összekötő szabályokból áll. A Scrumot Ken Schwaber és Jeff Sutherland fejlesztette ki; ezt az útmutatót is ők írták és tették elérhetővé. Ők ketten állnak a Scrum útmutató mögött. Scrum áttekintés Scrum (főnév): Egy olyan keretrendszer melynek segítségével emberek komplex problémákat tudnak adaptív módon kezelni úgy, hogy közben termelékenyen és kreatívan szállítják le a lehető legmagasabb értéket jelentő termékeket. A Scrum: Egyszerű Könnyen érthető Rendkívül nehezen művelhető mesteri szinten A Scrum egy folyamat-keretrendszer, amit az 1990-es évek eleje óta használnak komplex termékek fejlesztésére. Nem egy termékek létrehozására kitalált folyamat vagy technika; sokkal inkább egy olyan keretrendszer, melyen belül különböző folyamatokat és technikákat lehet alkalmazni. A Scrum felszínre hozta a termék menedzsmentjének és a fejlesztési gyakorlatainak relatív hatékonyságát, így elősegítve annak tökéletesítését. Scrum keretrendszer A Scrum keretrendszer a Scrum Csapatokból, valamint a hozzájuk rendelt szerepekből, eseményekből, munkaanyagokból (artifacts) és szabályokból áll. A keretrendszeren belül minden egyes komponens meghatározott célt szolgál, és mindegyik alapvetően szükséges a Scrum sikeréhez és használatához. A Scrum keretrendszer használatára vonatkozó konkrét stratégiák eltérőek lehetnek, ezeket jelen Útmutató nem tárgyalja. A Scrum szabályai kapcsolják össze az eseményeket, szerepköröket és a munkaanyagokat, meghatározva a köztük lévő viszonyokat és kölcsönhatásokat. A Scrum szabályai ezen dokumentum törzsében kerülnek ismertetésre. Scrum elmélet A Scrum a tapasztaláson alapuló folyamatellenőrzési elméleten, vagy más néven empirizmuson alapul. Az empirizmus azt állítja, hogy a tudás a tapasztalatokból és az adott ismereteken alapuló döntésekből ered Ken Schwaber és Jeff Sutherland, Minden jog fenntartva! 3 Oldal

4 A Scrum egy iteratív (ismétlődő), inkrementális megközelítést alkalmaz a kiszámíthatóság optimalizálása és a kockázat kézben tartása érdekében. Az empirikus folyamatellenőrzés megvalósítása három pilléren nyugszik: transzparencia (átláthatóság), ellenőrzés és korrekció. Transzparencia A folyamat lényeges nézőpontjainak láthatónak kell lenni azok számára, akik felelősek az eredményért. A transzparencia elve megköveteli, hogy ezeket a nézőpontokat egy közös szabvány szerint határozzák meg, hogy a minden résztvevő ugyanazzal az értelmezéssel rendelkezzen. Például: Egy egyezményes nyelvet kell kialakítani a folyamatra vonatkózóan, amit meg kell osztani a résztvevők között; és Egyezményes Kész definíciót (definition of done ) kell meghatározni és megosztani a munkát végzők és a munka eredményét átvevők között. Ellenőrzés A Scrum felhasználóknak gyakorta kell ellenőriziük a Scrum munkaanyagait, és a cél felé történő haladást, hogy észleljék a nem kívánatos eltéréseket. Ugyanakkor az ellenőrzés nem lehet olyan gyakori, hogy akadályozza a munkát. Az ellenőrzés akkor a legeredményesebb, ha képzett elemzők hajták végre éppen a munkafolyamat megkezdése előtt. Korrekció Amennyiben egy ellenőr megállapítja, hogy egy folyamat egy, vagy több szempontból a megengedett határokon kívül esik, és azt, hogy a végtermék nem lesz megfelelő, akkor módosítani kell a folyamaton, vagy feldolgozás alatt lévő anyagon. A további eltérések minimalizálása érdekében a módósítást mihamarabb el kell végezni. A Scrum négy formális lehetőséget ír elő a vizsgálatra és az alkalmazkodásra, melyek a Scrum események fejezetben kerülnek kifejtésre. Sprint Tervező Megbeszélés (Sprint Planning Meeting) Napi Scrum (Daily Scrum) Sprint áttekintő megbeszélés (Sprint Review Meeting) Sprint visszatekintés (Sprint Retrospective) Scrum A Scrum egy olyan keretrendszer, melyet komplex termékekfejlesztésének támogatása céljából állítottak össze. Scrum-csapatokból, valamint a rájuk vonatkozó szerepekből, eseményekből, munkaanyagokból és szabályokból áll. A keretrendszeren belül minden komponens meghatározott célt szolgál, és nélkülözhetetlen a Scrum használatához és sikeréhez Ken Schwaber és Jeff Sutherland, Minden jog fenntartva! 4 Oldal

5 Az eseményeket, szerepeket, munkaanyagokat a Scrum szabályai kötik össze, irányítva a köztük lévő kapcsolatot és az egymás közötti kölcsönhatást is. A Scrum szabályai ezen dokumentum törzsében kerülnek ismertetésre. Scrum-csapat A Scrum-csapat a Terméktulajdonosból, Fejlesztőcsapatból és Scrum Mesterből (Scrum Master) áll. A Scrum-csapatok önszerveződőek és kereszt-funkcionálisak. Az önszerveződő csapatok döntik el, hogy milyen módon tudják a legjobban elvégezni a munkát szemben azzal, hogy valaki kívülről irányítaná őket. A kereszt-funkcionális csapatok a munka elvégzéséhez minden szükséges kompetenciával rendelkeznek, és nem függnek olyanoktól, akik nem részei a csapatnak. A csapat modellt a Scrumban a rugalmasság, a kreativitás és a produktivitás optimalizálása érdekében tervezték meg. A Scrum-csapatok iteratív módon és fokozatos lépésekben (inkrementálisan) szállítják a terméket, maximalizálva a visszajelzés lehetőségét. A Kész termék fokozatos leszállításai biztosítják, hogy a termékből mindig elérhető egy jó eséllyel hasznosítható változat. A Terméktulajdonos A Terméktulajdonos (Product Owner) felelős a termék értékének maximalizálásáért és a Fejlesztő Csapat munkájáért. Ennek konkrét formája széles körben változhat szervezeti formától, Scrum-csapatoktól és egyéntől függően. A Terméktulajdonos az egyetlen személy, aki felelős a Termék Backlog (Termék Teendőlista - Product Backlog) kezeléséért, mely a következőket foglalja magában: A Termék Backlog tételeinek egyértelmű leírása; A Termék Backlogban szereplő tételeknek sorba rendezése aszerint, hogy azok a a célok és küldetések legjobb, leghatékonyabb elérését szolgálják; Gondoskodás a Fejlesztőcsapat munkájának értékességéről; Annak biztosítása, hogy a Termék Backlog elérhető, könnyen áttekinthető és mindenki számára világos legyen, továbbá egyértelmű legyen, hogy a Scrum-csapatnak mi lesz a következő munkája; valamint Annak biztosítása, hogy a Fejlesztőcsapat legalább a munkavégzéshez szükséges szinten érti a Termék Backlog egyes tételeit. A Terméktulajdonos saját maga is elvégezheti a fenti teendőket, vagy a Fejlesztőcsapattal is elvégeztetheti azokat, viszont ez utóbbi esetben is a Terméktulajdonosé a felelősség. A Terméktulajdonos nem egy bizottság, hanem egyetlen személy. A Terméktulajdonos képviselheti egy bizottság vágyait a Termék Backlog-ban, de ha a bizottság meg szeretné változtatni valamelyik listaelem prioritását, arról előbb meg kell győznie a Terméktulajdonost. Ahhoz, hogy a Terméktulajdonos sikeres tudjon lenni, a teljes szervezetnek tiszteletben kell tartania a döntéseit. A Terméktulajdonos döntései a Termék Backlog tartalmában és az elemek sorrendjében Ken Schwaber és Jeff Sutherland, Minden jog fenntartva! 5 Oldal

6 nyilvánulnak meg. Senki nincs felhatalmazva arra, hogy azt mondja a Fejlesztőcsapatnak, hogy a meghatározottól eltérő követelmény-rendszer szerint dolgozzon, és a Fejlesztőcsapat sem fogadhat el utasítást senki mástól. A Fejlesztőcsapat A Fejlesztőcsapat olyan szakemberekből áll, akik azon dolgoznak, hogy minden egyes Sprint végén leszállítható legyen egy, a Kész termék potenciálisan kibocsátható inkrementuma. Az inkrementum elkészítésében csak a Fejlesztőcsapat tagjai vesznek részt. A Fejlesztőcsapatokat úgy struktúrálja és hatalmazza fel a szervezet, hogy ők maguk szervezzék és menedzseljék saját munkájukat. Az így létrejövő szinergia optimalizálja a Fejlesztőcsapat hatékonyságát és termelékenységét. A Fejlesztőcsapatok az alábbi tulajdonságokkal rendelkeznek: Önszerveződőek. Senki még a Scrum Mester sem mondja meg a Fejlesztőcsapatnak, hogy miként hozzanak létre a Termék Backlog-ból potenciális termék inkrementumokat; A Fejlesztőcsapatok kereszt-funkcionálisak, és csapatként minden olyan ismerettel és készséggel rendelkeznek, ami szükséges a termék-inkrementum elkészítéséhez; A Scrum a Fejlesztő -n kívül nem alkalmaz külön titulust a Fejlesztőcsapat egyes tagjaira, függetlenül attól, hogy milyen tevékenységet végeznek egyenként. Ez alól a szabály alól nincs kivétel. A Fejlesztőcsapatban az egyes tagok speciális ismeretekkel, készségekkel és szakterülettel rendelkezhetnek, de a felelősség az egész csapatra, mint egy egységre hárul; ill. A Fejlesztőcsapatokban nincsenek al-csoportok egyes célfeladatok pl. teszt vagy üzleti elemzés elvégzésére. Fejlesztőcsapat nagysága A Fejlesztőcsapat optimális mérete elég kicsi ahhoz, hogy a csapat gyors reagálású maradjon, de elég nagy ahhoz, hogy jelentős mennyiségű munkát tudjon végezni. Háromnál kevesebb tag esetében csökken az interakció szintje, és ez alacsonyabb termelékenységhez vezet. A kisebb csapatok a Sprint során készségkorlátokba ütközhetnek, aminek következtében előfordulhat, hogy nem tudnak a Sprint végére egy potenciálisan kiadható inkrementumot készíteni. Kilenc tagnál több tag már túl sok koordinációt igényel. A nagy létszámú Fejlesztőcsapatok túl nagy komplexitást generálnak a tapasztalási folyamat sikeres menedzseléséhez. A Terméktulajdonos és a Scrum Mester szerepe nem számít bele ebbe a létszámba kivéve, ha ők is dolgoznak a Sprint-Backlog (Sprint Teendőlista) megvalósításában. A Scrum Mester A Scrum Mester a Scrum megértéséért és betartásáért felelős. A Scrum Mesterek ezt az által érik el, hogy megbizonyosodnak a csapat Scrum elmélet-, gyakolat- és szabályismeretéről, valamint meggyőződnek elkötelezettségükről is. A Scrum Mester szolgáló-vezetője a Scrum csapatnak. A Scrum Mester segíti a Scrum-csapaton kívülieknek megérteni azt, hogy mely Scrum Csapattal való interakciójuk lesz hasznos és melyik nem. A Scrum Mester mindenkinek segít megváltoztatni ezeket az interakciókat azért, hogy azok a Scrum-csapat által létrehozott értéket maximalizálják Ken Schwaber és Jeff Sutherland, Minden jog fenntartva! 6 Oldal

7 A Scrum Mester szolgáltatásai a Terméktulajdonos felé A Scrum Mester többféle módon segíti a Terméktulajdonost, beleértve: Hatékony technikákat alakít ki a Termék Backlog kezelésére; Világosan kommunikálja az elképzeléseket, célokat és Termék Backlog-tételeket a Fejlesztőcsapat felé; Megtanítja a Fejlesztőcsapatot a világos és tömör Termék Backlog elemek készítésére; Megérti a hosszútávú terméktervezést empirikus környezetben; Megérti és gyakorolja az agilitást; valamint, Elősegíti a kívánt vagy szükséges Scrum események létrejöttét. A Scrum Mester szolgáltatásai a Fejlesztőcsapat felé A Scrum Mester többféle módon segíti a Fejlesztőcsapatot, beleérétve: Felkészíti, támogatja a Fejlesztőcsapatot az önszerveződés és a kereszt-funkcionalitás kialakításában; Tanítja és vezeti a Fejlesztőcsapatot magas színvonalú termékek előállításában; Eltávolítja a Fejlesztőcsapat útjába kerülő akadályokat; Megszervezi a kívánt vagy szükséges Scrum eseményeket; és, Vezeti a Fejlesztőcsapatot olyan szervezeti környezetben, ahol még nem teljes mértékben vezették be és értették meg a Scrum-ot. A Scrum Mester szolgáltatásai a Szervezet felé A Scrum Mester többféle módon segíti a Szervezetet, beleértve: Vezeti és képzi a szervezetet a Scrum elsajátításában; Megtervezi a Scrum megvalósítását a szervezetben; Segít az alkalmazottaknak és az üzleti oldal szereplőinek megérteni és elfogadni a Scrum-ot és az empirikus termék fejlesztést; Olyan változásokat eszközöl, melyek növelik a Scrum-csapat termelékenységét; és, Együttműködik a többi Scrum Mesterrel annak érdekében, hogy növelje a Scrum alkalmazásának hatékonyságát a szervezetben. Scrum Események Az előírt eseményeket a Scrum-ban arra használják, hogy rendszerességet, szabályszerűséget teremtsenek, és hogy minimalizálják az egyéb, Scrum-ban nem meghatározott megbeszélések szükségességét. A Scrum időkorlátos, ún. idő-dobozos (time-boxed) eseményeket használ, ami azt jelenti, hogy minden eseménynek van egy maximális hossza. Ez megfelelő mennyiségű ídőt biztosít a tervezésre anélkül, hogy lehetőséget adna az idő pazarlására a tervezési folyamat során. Magán a Sprinten kívül, ami az összes többi esemény gyűjtője, minden egyes Scrum-esemény egy formális lehetőség valaminek az ellenőrzésére és korrekcióra. Ezeket az eseményeket kifejezetten úgy Ken Schwaber és Jeff Sutherland, Minden jog fenntartva! 7 Oldal

8 tervezték meg, hogy biztosítani tudják a kritikus átláthatóságot és ellenőrizhetőséget. Ezen események bármelyikének elhagyása csökkenti az átláthatóságot, és minden egyes ilyen egy egy-elveszített lehetőség az ellenőrzésre és korrekcióra. Sprint A Scrum lelke a Sprint, ami egy olyan egy hónapos vagy rövidebb idő-doboz, ami alatt egy Kész, használható és potenciálisan kibocsátható termék-inkrementum elkészül. A Sprintek hossza a teljes fejlesztési idő során azonos. Az előző Sprint lezárása után azonnal egy újabb Sprint kezdődik. A Sprintek Sprint-tervező megbeszélésből, Napi Scrumokból, a fejlesztési munkából, a Sprint-áttekintő és a Sprint-visszatekintő megbeszélésből épülnek föl. A Sprint során: Nem történnek olyan változtatások, melyek befolyásolnák a Sprint Célját; A Fejlesztőcsapat összeállítása változatlan; A minőségi célok nem csökkennek; és, A Terméktulajdonos és a Fejlesztőcsapat újratárgyalhatja és tisztázhatja a Feladatokat (Scope) az időközben szerzett ismeretek alapján. Minden egyes Sprint egy hónapnál nem hosszabb horizonttal rendelkező projektnek tekinthető. Hasonlóan a projektekhez, a Sprinteket is valamilyen cél elérése érdekében használják. Minden egyes Sprint tartalmaz egy meghatározást, ami leírja, hogy minek kell megvalósulnia, - egy modellt és egy rugalmas tervet, ami irányt mutat a megvalósításban. A Sprint részének tekintjük továbbá az elvégzett munkát és az eredményül kapott terméket. A Sprintek egy naptári hónapra vannak korlátozva. Ha a Sprint horizontja túl hosszú, megváltozhat a megvalósítandó dolog specifikációja, emelkedhet a komplexitása és nőhet a kockázat. A Sprintek úgy biztosítják a tervezhetőséget, hogy legalább minden naptári hónapban egyszer ellenőrzik a cél felé haladást, és szükség esetén kiigazítják a folyamatot. A Sprintek a kockázatot is egy naptári hónap költségére csökkentik. Egy Sprint lefújása A Sprintet az idő-doboz lejárta előtt le lehet fújni. Kizárólag a Terméktulajdonosnak van joga erre, jóllehet ezt teheti úgy is, hogy az üzleti oldali résztvevők, a Fejlesztőcsapat vagy a Scrum Mester befolyásolják őt. Egy Sprintet akkor is törölnek, ha a Sprint Cél elavul, okafogyottá válik. Ilyen akkor fordulhat elő, ha a cég irányt változtat, vagy ha a piaci, vagy technológiai feltételek megváltoznak. Általánosságban elmondható, hogy egy Sprintet olyan esetekben érdemes lefújni, ha az adott körülmények között már nincs értelme folytatni. Viszont a Sprintek rövidsége miatt a törlésnek ritkán van értelme. Amikor lefújnak egy Sprintet, minden befejezett és Kész Termék-Backlog tételt felülvizsgának. Ha a munka egy része potenciálisan szállítható, a Terméktulajdonos általában elfogadja azt. Az összes félkész Ken Schwaber és Jeff Sutherland, Minden jog fenntartva! 8 Oldal

9 Termék-Backlog tételt ezután újrabecsülik és visszateszik a Termék Backlog-ba. Az ezeken elvégzett munka hamar veszít értékéből, és gyakran kell új becslést készíteni. A Sprint törlések jelentős erőforrásokat emésztenek fel, mivel mindenkinek át kell szerveződnie egy másik Sprint-tervező Megbeszélésre, hogy egy új Sprint-et kezdjenek el. A Sprint lefújása gyakran nyomasztó a Scrum-csapat számára, de a valóságban ritkán fordul ilyen elő. Sprint-tervező Megbeszélés A Sprint-ben végzendő munkát a Sprint-tervező megbeszélésen tervezik meg. Ez a terv a teljes Scrumcsapat közös munkájának eredménye. A Sprint-tervező megbeszélés időtartama korlátozott, 1 hónapos Sprint esetében max. 8 óra. Rövidebb Sprintek esetén az idő arányosan kevesebb. Például a két hetes Sprintek megbeszélései 4 órásak. A Sprint-tervező megbeszélés két részből áll, mindkettő a Sprint-tervező megbeszélés hosszának fele. A két rész során a következő kérdésekre adandó válaszokat határozzák meg: A következő Sprint eredményeképpen szállítandó inkrementum mit fog tartalmazni? Hogyan lehet elérni, hogy az inkrementum előállításához szükséges munka megtörténjen? Első rész: Mi fog elkészülni a Sprintben? Ebben a részben a Fejlesztőcsapat azon dolgozik, hogy felvázolja a Sprint során megvalósítandó funkcionalitást. A Terméktulajdonos bemutatja a Fejlesztőcsapatnak a Termék-Backlog sorba rendezett tételeit, és az egész Scrum-csapat együttműködik a Sprint-ben elvégzendő munka megértésében. Ennek a megbeszélésnek a bemeneti elemei a Termék Backlog, a legutóbbi termék inkrementum, a Fejlesztőcsapat tervezett kapacitása a Sprint ideje alatt, valamint a Fejlesztőcsapat korábbi teljesítménye. Az, hogy az adott Sprint számára a Termék-Backlogból hány tételt választanak ki, egyedül a Fejlesztőcsapaton múlik. Kizárólag a Fejlesztőcsapat tudhatja, hogy mit képes végrehajtani a soron következő Sprintben. Miután a Fejlesztőcsapat megtervezte, hogy a Termék Backlog mely elemeit fogja leszállítani a Sprint során, a Scrum Csapat elkészíti a Sprint Célt. A Sprint Cél egy olyan célkitűzés, ill. végcél, amit a Sprint során a Termék Backlog megvalósításával érünk el. Ez egy iránytűként szolgál a Fejlesztőcsapatnak abban is, hogy mi a célja a termék inkrementum létrehozásának Második rész: Hogyal készül el a kiválasztott munka? Miután a Sprint feladatait kiválasztották, a Fejlesztőcsapat eldönti, hogy miként építi be ezt a funkcionalitást a Kész termék inkrementumba a Sprint során. Az erre a Sprintre kiválogatott Termék Backlog tételeit, valamint a leszállítás tervet együttesen nevezik Sprint-Backlog-nak (Sprint Teendőlista). A Fejlesztőcsapat általában a Termék-Backlog működő termék inkrementummá konvertálásához szükséges munka és rendszer megtervezésével kezdi meg a munkát. A munka változhat méret és becsült ráfordítás szerint is. Mindamellett a Sprint-tervező megbeszélés során elegendő időt biztosítanak a Fejlesztőcsapat részére annak érdekében, hogy megalapozottan tudják megtervezni, hogy mit vélnek Ken Schwaber és Jeff Sutherland, Minden jog fenntartva! 9 Oldal

10 elvégezhetőnek a soron következő Sprint alatt. A megbeszélés végére a Fejlesztőcsapat a Sprint első napjaira tervezett feladatokat 1 napos vagy annál kisebb részekre bontja le. A Fejlesztőcsapat önszerveződve vállalja el a Sprint-Backlog-ban szereplő egyes feladatokat a Sprint-tervező megbeszélés alatt, valamint amennyire szükséges, a Sprint közben is. A Terméktulajdonos jelen lehet a Sprint-tervező megbeszélés második részén annak érdékében, hogy világossá tegye a kiválasztott Termék-Backlog elemeket, és hogy elősegítse a kompromisszumokat. Ha a Fejlesztőcsapat úgy ítéli meg, hogy túl sok vagy túl kevés az elvégzendő munka, újratárgyalhatja a Sprint- Backlog tételeket a Terméktulajdonossal. A Fejlesztőcsapat másokat is meghívhat a megbeszélésre, hogy technikai vagy szakmai tanácsokat adjanak. A Sprint-tervező megbeszélés végére a Fejlesztőcsapatnak el kell tudni magyarázni a Terméktulajdonos és a Scrum Mester részére, hogy miként szándékozik önszerveződő csapatként dolgozni a Sprint Cél megvalósítása és az elvárt inkrementum elkészítése érdekében. Sprint Cél A Sprint Cél enged némi rugalmasságot a Sprint során megvalósított funkcionalitás kapcsán a Fejlesztőcsapatnak. A Fejlesztőcsapat ezt a célt tartja szem előtt a munka során. A Sprint Cél megvalósítása érdekében hozza létre a funkcionalitást és a technológiát. Ha kiderül, hogy a munka eltér a Fejlesztőcsapat által elvártaktól, a Terméktulajdonossal együttműködve újratárgyalja a Sprint-Backlog terjedelmét (scope) a Sprintben. A Sprint Cél lehet akár egy mérfőldkő is a teljes termékfejlesztési ütemtervben. Napi Scrum A Napi Scrum megbeszélés egy 15 perces határozott időtartamú megbeszélés, ahol a Fejlesztőcsapat összehangolja a tevékenységeket, és megtervezi az elkövetkezendő 24 órát. Ezt a legutóbbi Napi Scrum megbeszélés óta elvégzett feladatok elemzésével, majd a következő előtt elvégezhető feladatok megtervezésével végzi el. A Napi Scrum-ot minden nap ugyanabban az időben, ugyanazon a helyen tartják az esetleges akadályok csökkentése érdekében. A megbeszélés során a Fejlesztőcsapat minden egyes tagja az alábbiakat fejti ki: Mit sikerült elvégezni az előző megbeszélés óta? Mit fog csinálni a következő megbeszélésig? Milyen akadályozó tényezők vannak? A Fejlesztőcsapat a Napi Scrumot a Sprint Célhoz vezető folyamat haladásának felmérésére, valamint annak megállapítására használja, hogy miként változik a haladás tendenciája a Sprint-Backlog-ban szereplő munka teljesítése felé. A Napi Scrum maximálja annak a valószínűségét, hogy a Fejlesztőcsapat eléri a Sprint Célt. A Fejlesztőcsapat gyakran közvetlenül a Napi Scrum után összeül, hogy újratervezze a hátralevő Sprint-munkát. A Fejlesztőcsapatnak minden nap el kell tudnia magyarázni a Terméktulajdonos Ken Schwaber és Jeff Sutherland, Minden jog fenntartva! 10 Oldal

11 és a Scrum Mester részére, hogy miként szándékozik önszerveződő csapatként dolgozni a cél elérése érdekében, és hogyan hozza létre a remélt inkrementumot a Sprint hátralévő részében. A Scrum Mester biztosítja azt, hogy a Fejlesztőcsapat tagjai minden nap megtartsák a megbeszélést, de a Fejlesztőcsapat felelős a Napi Scrum levezetéséért. A Scrum Mester tanítja meg a Fejlesztőcsapatnak, hogy miként tudják a Napi Scrum-ot a 15 perces időkereten belül megtartani. A Scrum Mester ügyel arra, hogy kizárólag a Fejlesztőcsapat tagjai vegyenek részt a Napi Scrum-ban. A Napi Scrum nem státuszmegbeszélés, és csak azok vesznek részt benne, akik a Termék-Backlog tételeket inkrementummá alakítják. A Napi Scrum javítja a kommunikációt, szükségtelenné tesz egyéb megbeszéléseket, azonosítja és eltávolítja a fejlesztés útjába kerülő akadályokat, kiemeli és elősegíti a gyors döntéshozatalt és növeli a Fejlesztőcsapat projekttel kapcsolatos tudását. Ez egy kulcsfontosságú elemző és adaptáló megbeszélés. Sprint Áttekintő A Sprint Áttekintő (Sprint Review) megbeszélést a Sprint végén tartják, hogy ellenőrizzék a termékinkrementumot, és módosítsák a Termék Backlog-ot, amennyiben az szükséges. A Sprint Áttekintőn a Scrum Csapat tagjai és az üzleti oldal (stakeholders) egyeztetik, hogy mi történt a Sprint során. Ezt, és a Sprint során a Termék-Backlog-ban történt bármely változtatást alapul véve a résztvevők együttműködnek a következő teendőket illetően. Ez egy informális megbeszélés, és az inkrementum bemutatójának az a célja, hogy az üzleti oldal részéről (stakeholders) visszajelzés érkezzen, valamint hogy erősítse az együttműködést. Ez egy 4 órás időkorláttal rendelkező megbeszélés 1-hónapos Sprint esetén. Rövidebb Sprintek esetében ez arányosan kevesebb ideig tart. Például kéthetes Sprintek kétórás Sprint Áttekintővel rendelkeznek. A Sprint Áttekintő az alábbi elemeket tartalmazza: A Terméktulajdonos megállípítja, hogy mi lett Kész és mi nem lett Kész ; A Fejlesztőcsapat megvitatja, mi ment jól a Sprint során, milyen problémákba futott bele, és hogyan oldotta meg azokat; A Fejlesztőcsapat szemlélteti a Kész munkát, és válaszol az inkrementumokkal kapcsolatos kérdésekre; A Terméktulajdonos bemutatja a Termék-Backlog aktuális állapotát, előrevetíti a várható befejezési dátumokat az addig elért fejleményekalapján; és, Az egész csoport egyeztet annak érdekében, hogy közösen meghatározzák, mik legyenek a következő lépések, így a Sprint Áttekintő értékes bemenetként szolgál a következő Sprint-tervező megbeszéléshez. A Sprint Áttekintő eredménye egy módósított Termék-Backlog, ami meghatározza a következő Sprint során megvalósítani tervezett Termék-Backlog tételeket. A Termék-Backlog-ot teljeskörűen is lehet módosítani, hogy az akár új lehetőségeknek is megfeleljen Ken Schwaber és Jeff Sutherland, Minden jog fenntartva! 11 Oldal

12 Sprint Visszatekintő A Sprint Visszatekintő (Sprint Retrospective) egy lehetőség a Scrum Csapatnak arra, hogy elemezze saját tevékenységét, és készítsen egy fejlesztési tervet, amit a következő Sprintek során beiktat. A Sprint Visszatekintő a Sprint Áttekintő után, a következő Sprint-tervező megbeszélés előtt történik. Egy hónapos Sprintek esetén ez egy három órás, határozott időtartamú megbeszélés. Rövidebb Sprinteknél arányosan rövidebb. A Sprint Visszatekintő célja, hogy: Megvizsgálják, hogy mennyire volt sikeres a legutóbbi Sprint az emberek, kapcsolatok, folyamatok és eszközök szempontjából; Azonosítsák és sorba rendezzék a jól működő főbb elemeket és a lehetséges javításokat; valamint, Tervet készítsenek a Scrum Csapat működésének javítására. A Scrum Mester támogatja a Scrum Csapatot abban, hogy a Scrum folyamat keretrendszerén belül folyamatosan javítsa a fejlesztés folyamatait és gyakorlatait annak érdekében, hogy a következő Sprint még hatékonyabb és élvezetesebb legyen. A Scrum Csapat minden egyes Sprint Visszatekintő során különféle terveket készít a termék minőségének javítására, a Kész termék definíciójának módosításával. A Sprint Visszatekintő végére a Scrum Csapatnak meg kell határozni a szükséges javításokat, amiket a következő Sprintben meg fog valósítani. Ezen javítások megvalósítása a következő Sprintben tulajdonképpen magának a Scrum-csapat által végzett ellenőrzéshez igazodó korrekció. Habár a javítások bármikor bevezethetők, a Sprint Visszatekintő megbeszélés egy formális lehetőséget biztosít hogy az ellenőrzésre és és korrekcióra koncentráljon a csapat. Scrum Munkaanyagok A Scrum munkaanyagai (scrum artifacts) olyan munkát vagy értéket képviselnek különböző formákban, melyek segítenek az átláthatóság megteremtésében, és lehetőséget nyújtanak az elemzésre és kiigazításra. A Scrum által meghatározott munkaanyagokat kifejezetten úgy tervezték meg, hogy azok maximalizálják a kulcsfontosságú információk átláthatóságát, amelyek annak biztosításához szükségesek, hogy a Scrum csapat sikeresen le tudja szállítani a Kész inkrementumot. Termék Backlog (Termék Teendőlista) A Termék-Backlog egy sorba rendezett lista, ami minden olyan dolgot tartalmaz, amire szükség lehet a termékben, valamint ez alkotja a termékkel kapcsolatos változtatási követelmények egyetlen forrását. A Terméktulajdonos felelős a Termék Backlog-ért, beleértve annak tartalmát, elérhetőségét és sorba rendezését. A Termék-Backlog sosem tekinthető teljesnek. A legelső változata csak a kezdetben ismert és legjobban megértett követelményeket fekteti le. A Termék Backlog a termék és a majdani haszálati környezet változásával összhangban változik. A Termék-Backlog dinamikus; folyamatosan változik annak érdekében, Ken Schwaber és Jeff Sutherland, Minden jog fenntartva! 12 Oldal

13 hogy meghatározza azt, hogy mi szükséges ahhoz, hogy a termék megfelelő, versenyképes és hasznos legyen. Ameddig egy termék létezik, Termék-Backlog is létezik. A Termék-Backlog felsorolja az összes jellemzőt, funkciót, követelményt, fejlesztést és javítást, mely azokat a változtatásokat tartalmazza, amiket a jövőbeni kibocsátásoknál a terméken el kell végezni. A Termék-Backlog tételeihez leírást, sorrendi helyezést és becslésst rendelnek. A Termék-Backlog elemeit gyakran érték, kockázat, prioritás és szükségesség szerint rendezik sorba. Az előre sorolt tételek azonnali fejlesztési teendőket indukálnak. Minél előrébb áll a sorban egy Termék- Backlog tétel, annál többet foglalkoztak vele, és annál nagyobb az egyetértés vele és az értékével kapcsolatban. A sorban előrébb álló tételek világosabbak és részletesebben kifejtettek, mint a hátrébb állók. A nagyobb átláthatóságnak és részletezésnek köszönhetően pontosabb becslések készíthetők; minél hátrébb van a sorban egy tétel, annál kevesebb a részlet. Részletesen kidolgozzák és szétbontják azokat a Termék- Backlogtételeket, amikkel a Fejlesztőcsapat a következő Sprint alatt foglalkozni fog, hogy így bármely ilyen elemet Készre lehessen hozni a Sprint korlátozott időtartalmán belül. Azokat a Termék Backlog tételeket, amiket a Fejlesztőcsapat egy Sprinten belül el tud Kész -íteni, választásra késznek vagy alkalmasnak nyilvánítanak a Sprint-tervező megbeszélésen. Amint egy terméket elkezdenek használni, értéke lesz és a piacról visszajelzések érkeznek, a Termék- Backlog egy nagyobb és átfogóbb listává alakul. A követelmények változása sosem szűnik meg, ennek megfelelően a Termék-Backlog egy élő, folyamatosan alakuló munkaanyag. Az üzleti követelményekben, piaci vagy technológiai feltételekben beállt változások hatására a Termék-Backlog is változhat. Gyakran több Scrum-csapat dolgozik együtt ugyanazon a terméken. Ilyenkor is egy Termék-Backlog-ot használnak a termékkel kapcsolatos várható munkák leírására, de ilyen esetben egy olyant, mely csoportosítja az elemeket. A Termék-Backlog grooming (Product Backlog grooming) az a tevékenység, melynek során részletes információkat, becsléseket és sorrendet rendelnek a Termék Backlog elemeihez. Ez egy állandó folyamat, melyben a Terméktulajdonos és a Fejlesztőcsapat egyeztet a Termék-Backlog tételek részleteiről. A grooming során az egyes elemeket átnézik és felülvizsgálják. Viszont bármely időpontban frissíthetők a Terméktulajdonos által, vagy az ő beleegyezésével. A Sprintek során a grooming egy részidős tevékenység a Terméktulajdonos és a Fejlesztőcsapat között. Általában a Fejlesztőcsapat rendelkezik mind azzal a szakmai tudással, hogy egyedül végezze el magát a grooming-ot. Azt, hogy ez mikor és miként történik, a Scrum-csapat dönti el. A grooming normális esetben a Fejlesztőcsapat kapacitásának kevesebb, mint 10%-át veszi igénybe. Az összes becslésért a Fejlesztőcsapat felelős. A Terméktulajdonos hathat a Csapatra úgy, hogy segít megérteni és kiválasztani a kompromisszumokat, de a végső becslést azok az emberek mondják ki, akik a munkát ténylegesen el fogják végezni. A Cél felé haladás ellenőrzése Ken Schwaber és Jeff Sutherland, Minden jog fenntartva! 13 Oldal

14 Bármely időpontban össze lehet számolni, hogy mennyi munka szükséges még egy adott cél eléréséhez. A Terméktulajdonos legalább minden Sprint-áttekintő alkalmával nyomon követi ezt a fennmaradó munkát. Ezt a mennyiséget összehasonlítja a korábbi Sprint-áttekintők alkalmával megállapított fennmaradó munkával, hogy felmérje a cél kívánt határidőre való elérése érdekében szükséges haladás ütemét. Ez az információ minden érintett számára elérhető és világos. Korábban különféle előretekintő, visszamutató és más jövőt becslő technikákat használtak a haladás becsléséhez. Ezek hasznosnak bizonyultak, viszont ezek nem helyettesítik a megtapasztalás fontosságát. Komplex környezetekben nem lehet megjósolni, hogy mi fog történni. Csak azokat az információkat lehet hasznosítani a jövőre vonatkozó döntéshozatalhoz, ami már megtörtént. Sprint Backlog (Sprint Teendőlista) A Sprint-Backlog a Termék-Backlog elemeinek egy, a Sprintre kiválasztott halmazát, plusz a termékinkrementum leszállítására és a Sprint Cél megvalósítására vonatkozó tervet tartalmaz. A Sprint-Backlog a Fejlesztőcsapat becslése arra vonatkozóan, hogy a következő inkrementum milyen funkcionalitást fog tartalmazni, és milyen munka szükséges ennek leszállításához. A Sprint-Backlog határozza meg azt a munkát, amit a Fejlesztőcsapat fog végezni ahhoz, hogy a Termék Backlog tételeket Kész inkrementummá alakítsa. A Sprint Backlog mindazt a munkát láthatóvá teszi, melyet a Fejlesztőcsapat szükségesnek vél a Sprint Cél teljesítéséhez. A Sprint Backlog egy olyan terv, ami elég részletes ahhoz, hogy a haladásban bekövetkezett változások a Napi Scrum során érthetőek legyenek. A Fejlesztőcsapat a Sprint során folyamatosan módosítja a Sprint Backlog-ot, mely egyre tisztábbá, világosabbá válik a Sprint során. Ez úgy működik, hogy amikor a Fejlesztőcsapat dolgozik a terven, mindig egyre több ismeretet gyűjt össze a Sprint Cél eléréséhez szükséges munkáról. Amikor új munkafolyamat válik szükségessé, a Fejlesztőcsapat felveszi azt a Sprint Backlog-ba. Ahogy haladnak a munkával, a becsült fennmaradó ráfordítást folyamatosan frissítik. Amennyiben a terv egyes elemeit szükségtelennek tartják, eltávolítják azokat. A Sprint alatt kizárólag a Fejlesztőcsapat változtathat a Sprint Backlog-on. A Sprint-Backlog egy nyilvános, elérhető, valós idejű képe annak a munkának, amit a Fejlesztőcsapat a Sprint során el kíván végezni, és csak és kizárólag a Fejlesztőcsapaté. A Sprint haladásának felügyelete A Sprint során bármely tetszőleges időpontban össze lehet számolni, mennyi munka szükséges még a Sprint Backlog tételek elvégzéséhez. A Fejlesztőcsapat legalább minden Napi Scrum alkalmával nyomon követi ezt az értéket. A Fejlesztőcsapat naponta vizsgálja ezt a mennyiséget, és előrevetíti a Sprint Cél elérésének valószínűségét. A Sprint során, a fennmaradó munka követésével a Fejlesztőcsapat felügyelni tudja a haladását. A Scrum nem veszi figyelembe, mennyi a Sprint-Backlog tételein való munkával eltöltött idő. A fennmaradó munka és az átadás időpontja az egyedüli fontos tényező Ken Schwaber és Jeff Sutherland, Minden jog fenntartva! 14 Oldal

15 Inkrementum Az Inkrementum azon Termék-Backlog elemek összessége, amelyeket ebben és az előző Sprintekben elvégeztek. A Sprint végére egy új Inkrementumnak Kész -nek, azaz használhatónak kell lennie, és meg kell felelnie a Scrum Csapat által meghatározott Kész definíciójának. Felhasználható állapotban kell lennie független attól, hogy a Terméktulajdonos úgy dönt-e, ténylegesen kibocsátja-e azt. A Kész meghatározása Amikor egy Termék Backlog tételt vagy egy Inkrementumot Kész -nek nyilvánítanak, mindenkinek pontosan kell tudnia, hogy a Kész definíció (Definition of Done ) mit is jelent. Habár ez Scrum csapatokként jelentősen eltérhet, az áttekinthetőség biztosítása érdekében a csapattagoknak közös, egyértelmű elképzeléssel kell rendelkezniük arról, mikor tekintenek egy munkát késznek. Ez a Kész definíciója a Scrum Csapat számára, és ezt használják annak megállípítására, hogy a termékinkrementummal való munka mikor fejeződik be. Ugyanez a definíció segíti a Fejlesztőcsapatot abban, hogy mennyi Termék-Backlog tételt válasszon ki a Sprint-tervező megbeszélésen. Minden egyes Sprint-nek az a célja, hogy olyan potenciálisan használható funkcionalitással rendelkező termék inkrementumot szállítson le, ami megfelel a Scrum Csapat aktuális Kész definíciójának. A Fejlesztőcsapatok minden Sprint-ben egy használható funkcionalitással rendelkező termék Inkrementumot szállítanak le. Mivel ez egy használati értékkel bíró termék, a Terméktulajdonos akár azonnal úgy is dönthet, hogy kibocsátja azt. Minden inkrementum alapos tesztelés után hozzáadódik a korábbi inkrementumhoz, biztosítva azt, hogy az összes inkrementum együttműködik. Ahogy a Scrum Csapatok érnek, fejlődnek, általában a Kész definíciójuk is velük együtt fejlődik, és még magasabb minőséget biztosító, szigorúbb feltételeket fog tartalmazni. Összegzés A Scrum ingyenes és ebben az útmutatóban elérhető. A Scrum szerepkörei, munkaanyagai, eseményei és szabályai nem megváltoztathatók, és habár csak a Scrum egyes részeinek is lehetséges a bevezetése, az eredmény nem Scrum lesz. A Scrum csak a maga teljességében létezik és működik jól, más módszertanok és szokások gyűjtőjeként. Köszönetnyilvánítás Emberek A több ezer ember közül, akik hozzájárultak a Scrum-hoz, ki kell emelnünk azokat, akik meghatározóak voltak annak első tíz évében. Először is Jeff Sutherland, aki Jeff McKenna-val dolgozott, majd Ken Schwaber, aki Mike Smith-szel és Chris Martin-nal dolgozott együtt. Sokan mások is hozzájárultak a Ken Schwaber és Jeff Sutherland, Minden jog fenntartva! 15 Oldal

16 további években, és az ő segítségük nélkül a Scrum nem lenne olyan kifinomult, mint ma. David Starr kulcsfontosságú meglátásokkal és szerkesztői tudásával formálta meg a Scrum Útmutató jelen verzióját. Történet Először Ken Schwaber és Jeff Sutherland mutatták be közösen a Scrum-ot az OOPSLA konferencián, ben. Ez az előadás alapvetően azt a tudáshalmazt dokumentálta, amit Ken és Jeff szerzett a Scrum alkalmazásával az azt megelőző évek során. A Scrum története most már hosszúnak tekinthető. Hogy elismerjük az első projekteket, ahol a módszertant kikísérletezték és csiszolták, emlékezzünk meg az Individual Inc.-ről, Fidelity Investments-ről és az IDX-ről (jelenleg GE Medical). A Scrum Útmutató úgy mutatja be a Scrumot, ahogy azt Jeff Sutherland és Ken Schwaber fejleszti és karbantartja több, mint 20 éve. Egyéb források is elérhetők, amelyek mintákat, folyamatokat és betekintést nyújtanak a gyakorlati alkalmazásba, illetve a Scrum keretrendszer használatára vonatkozó fejlesztéseket és eszközöket mutatnak be. Ezek optimalizálják a termelékenységet, értéket, kreativitást és büszkeséget. Magyar nyelvre fordította: Péntek Gábor és Dr. Bodó Árpád Zsolt Ken Schwaber és Jeff Sutherland, Minden jog fenntartva! 16 Oldal