kanban és scrum mindkettőből a legjobbat

Kanban s Scrum mindkett!b!l a legjobbat Henrik Kniberg s Mattias Skarin Fordtotta: Csutors Zoltn s Marhefka Istvn !"#$%&'()*+,(-.//0123045(6$(7*832(9120+$.1(

2010 C4Media Inc. Minden jog fenntartva. C4Media, Publisher of InfoQ.com. Ez a knyv az InfoQ Enterprise Software Development knyvsorozat rsze. A knyv angol vltozatnak megrendelshez lpjen kapcsolatba a kiadval a [email protected] cmen. Jelen knyvet vagy annak rszleteit tilos reproduklni, adatrendszerben trolni, brmely formban vagy eszkzzel elektronikus, fnykpszeti ton vagy ms mdon a kiad engedlye nlkl kzlni. Termkek megklnbztetsre hasznlt elnevezsek gyakran mrkanvknt vdettek. Minden olyan esetben, ahol a C4Media Inc. ismeretben volt a vdett mrkanvnek nagy Kezd!bet"vel, vagy NAGY BET#VEL szerepelnek. Tovbbi informcirt a mrkanevekkel s vdjegyekkel kapcsolatban annak tulajdonoshoz kell fordulni. Felel!s szerkeszt!: Diana Plesa Bort terv: Bistrian Iosip Composition: Accurance ISBN: 978-0-557-13832-6 Fordtotta: Csutors Zoltn (www.adaptiveconsulting.hu) Marhefka Istvn (http://infokukac.com) A fordts nyelvi lektorlst a Factory Creative Studio tmogatta.

(iii

Tartalom EL!SZ A MAGYAR FORDTSHOZ ..............................................v MARY POPPENDIECK EL!SZAVA ................................................ vii DAVID ANDERSON EL!SZAVA ..................................................... viii BEVEZETS ......................................................................................... xiii ELS! RSZ SSZEHASONLTS....................................................1 1. Mir!l is szl a Scrum s a Kanban? .....................................................2

2. Hogyan viszonyul egymshoz a Scrum s a Kanban? .........................5

3. A Scrum szerepkrket r el! .............................................................10

4. A Scrum id!keretek kz szortott itercikat r el! ..........................11

5. A Kanban munkafolyamat lpsenknt, a Scrum itercinknt korltozza a WIP-et ............................................................................13

6. Mindkett! empirikus ..........................................................................15

7. A Scrum ellenll az itercikon belli vltoztatsoknak ...................21

8. A Scrum-tbla minden iterci utn alaphelyzetbe kerl ..................23

9. A Scrum keresztfunkcionlis csapatokat r el! ..................................24

10. A Scrum backlog elemeinek bele kell frnik egy sprintbe...............26

11. A Scrum el!rja a tervezst s a sebessg mrst .............................27

12. Mindkett! lehet!v teszi, hogy tbb termken dolgozzunk prhuzamosan.....................................................................................29

13. Mindkett! lean s agilis......................................................................31

14. Apr klnbsgek...............................................................................33

15. Scrum-tbla vs. Kanban-tbla - egy kevsb trivilis plda ..............37

16. Scrum vs. Kanban sszefoglal..........................................................44

MSODIK RSZ ESETTANULMNY ...........................................47 17. Az zemeltetsi munka termszete ....................................................48

18. Mirt vltoztassunk? ..........................................................................49

19. Hol kezdjk el?...................................................................................50

20. Az induls...........................................................................................51

21. A csapatok elindtsa..........................................................................53

22. Az rdekeltek bevonsa......................................................................55

23. Az els! tbla megalkotsa ..................................................................56

iv | KANBAN S SCRUM MINDKETT"B"L A LEGJOBBAT(

iv

24. Az els! WIP-korlt belltsa ............................................................59

25. A WIP-korlt tisztelete.......................................................................61

26. Melyik feladatok kerljenek a tblra? ..............................................63

27. Hogyan becsljnk? ...........................................................................64

28. Hogyan dolgoztunk a valsgban? ....................................................66

29. Egy m#kd! tervezsi mdszer keresse...........................................70

30. Mit mrjnk?......................................................................................73

31. Hogyan indult be a vltozs ...............................................................76

32. ltalnos tanulsgok ..........................................................................82

VGS! TANULSGOK .......................................................................84 A SZERZ!KR!L...................................................................................87

(v

(El!sz a magyar fordtshoz

vekkel ezel!tt egy kritikus llapotba kerlt projektbe csppentnk vlsgkezel!knt s j vezet!fejleszt!knt. Gyorsan vilgoss vlt szmunkra, hogy az eddig alkalmazott vzess mdszerekkel nem jutunk messzire. A projekt kzel egy vvel korbban indult, a kvetelmnyspecifikcit pedig mg mindig nem sikerlt lezrni. A megrendel! trelme elfogyott, lthat eredmnyt vrt a csapattl, mghozz nagyon gyorsan. Ekkor kezdtnk el j projektvezetsi mdszerek utn kutatni.

Az agilis s XP irnyzatokrl hallottunk mr, nhny elemket alkalmaztuk is, de emellett szksgnk volt egy hatkony s dokumentlt menedzsmentmdszerre. Az interneten sok informcit lehetett tallni a Scrum ideolgirl, de neknk konkrt, gyakorlati tancsokra volt szksgnk, viszont nem ismertnk hazai, jelent!s tapasztalattal rendelkez! embert. Ekkor jelent meg Henrik Kniberg Scrum and XP from the trenches cm# knyve az InfoQ-n. Pont ilyet kerestnk!

A projekt vgl sikeres lett, a termket les hasznlatba vettk, mi is kln utakra tvedtnk. A Scrumrl id!kzben rengeteget tanultunk, mr magabiztosan alkalmaztuk s bevezettk j helyeken is. Jval ks!bb mindketten br ms projekten, ms cgnl jra kzs problmba botlottunk. A mr tadott termkek les zemi tmogatsa, s ezzel egy id!ben tovbbfejlesztse j kihvsok el lltott minket. A hromhetes, megszakthatatlan sprintek valahogy nem m#kdtek ebben a helyzetben.

Ekkor mr ismertk a Lean-/Kanban-mdszert, ami j vlasztsnak t#nt az adott helyzetben. Nagyobb rugalmassgot, er!sebb folyamatszemlletet grt. Mindketten alkalmazni kezdtk. A sors gy hozta, hogy ebben a tmban is megjelent egy knyv Henrik Kniberg s Mattias Skarin tollbl. Miel!tt letltttk volna, tudtuk, hogy mire szmthatunk. Nem csaldtunk.

(vi

gy reztk, itt az ideje, hogy hasznlhat, gyakorlatias knyv formjban magyar nyelven is ismertt vljon ez a tma. Az angol szveg nagyon szemlyes hangvteln kicsit ugyan vltoztattunk, de meggy!z!dsnk szerint a fordts hven tkrzi az eredeti tartalmat.

A knyvet azoknak ajnljuk, akik az agilis projektvezetsi mdszertanok irnt rdekl!dnek. Clkznsgnk mindenki, aki szoftverfejlesztssel foglalkozik: legyen az megrendel! vagy szoftverfejleszt! cg, ezen bell is zleti elemz!, projektmenedzser, fejleszt! vagy akr tesztel!.

Az Olvas ezzel a kiadvnnyal egy csapsra kt legyet is thet: megismerheti mind a Scrum, mind a Kanban lehet!sgeit.

A manapsg oly divatos Scrum j megvilgtsba kerl. A knyv elrugaszkodik a tananyagknt oktatott dogmktl, megmutatja, mik a Scrum korltai, s azokon hogyan lehet vltoztatni gy, hogy kzben ne vesztsk el az irnytst.

Szmos tletet, tippet kaphatunk arrl, hogyan szervezhet! meg tbb csapat vagy akr egy teljes szervezet munkja, hogyan lehet kezelni egyszerre tbb fejleszts alatt ll termket, amelyeken egy kzs csapat dolgozik.

A knyv fordtsa abban a remnyben kszlt, hogy a benne szerepl! tleteket az Olvas a valsgban is kiprblja, s eredmnyesen alkalmazza.

Sok sikert kvnunk!

Csutors Zoltn Marhefka Istvn http://www.adaptiveconsulting.hu http://infokukac.com

(vii

(Mary Poppendieck el!szava

Henrik Kniberg egyike azon a keveseknek, akik kpesek egy bonyolult helyzet lnyegt megragadni, kiemelni a fontos gondolatokat a lnyegtelenek kzl, s kristlytisztn, knnyen rthet! formban kzlni azokat. Ebben a knyvben Henrik brilinsan magyarzza el a Scrum- s a Kanban-rendszer kztti klnbsgeket. Vilgoss teszi, hogy ezek csak eszkzk, s arra van igazn szksgnk, hogy megrtsk, hogyan hasznljuk !ket gyengesgeik ellenre s er!ssgeik kiaknzsval.

Ebb!l a knyvb!l megrthet!, mir!l is szl a Kanban, mik az er!ssgei s korltai, illetve mikor rdemes alkalmazni. Szintn j leckt mutat arrl, hogyan s mikor fejleszthetjk vele a Scrumot vagy brmely ms mdszert, amit ppen alkalmazunk. Henrik vilgoss teszi, hogy nem az a lnyeg, milyen eszkzk alkalmazsval kezdnk, hanem az a md, ahogyan id!r!l-id!re folyamatosan fejlesztjk s b!vtjk a rendelkezsnkre ll lehet!sgeket.

A Mattias Skarin ltal rt msodik fejezet mg hasznosabb teszi a knyvet azltal, hogy egy vals letb!l vett pldn keresztl vgigvezet minket a Scrum s a Kanban alkalmazsn. Ebben a rszben kvethetjk vgig, hogy ezen eszkzk hogyan segtettk egytt s kln-kln is egy szoftverfejlesztsi folyamat tkletestst. szrevehetjk, hogy a sikernek nincs egyetlen igaz tja, hanem a sajt, pillanatnyi helyzetnk fggvnyben magunknak kell kitallnunk a kvetkez! lpst a jobb szoftverfejlesztsi folyamat fel.

Mary Poppendieck

(viii

(David Anderson el!szava

A Kanban nagyon egyszer# gondolaton alapszik. A vgrehajts alatt ll feladatok (angolul work-in-progress, rvidtse WIP) szmt korltozni kell, s j teend!t csak abban az esetben szabad elkezdeni, ha egy munkadarab elkszlt, vagy azt egy kvetkez! feldolgozsi folyamat tvette. A Kanban (vagy vezrl!-/jelz!krtya) olyan vizulis jel, ami arra utal, hogy megkezd!dhet egy j feladat vgrehajtsa, mivel a folyamatban lv!k szma nem ri el a megengedett maximlis rtket. Mindez nem hangzik tl forradalmi gondolatnak, sem olyasvalaminek, ami alapvet!en megvltoztatn egy csapat s az !t krlvev! szervezet teljestmnyt, kultrjt, rettsgt vagy alapvet! kpessgeit. Pedig pontosan ezt teszi, s ez az igazn bmulatos! A Kanban bevezetse apr dolognak t#nik, mgis mindent megvltoztat a szervezet m#kdsben.

Neknk vltozskezelsi megkzeltse t#nt fel igazn. Maga a Kanban nem szoftverfejlesztsi vagy projektmenedzsment letciklusmodell vagy -folyamat. A Kanban-szemllet, mely a meglv! projektmenedzsment vagy szoftverfejlesztsi mdszereink rszv teszi a vltozst. Alapelve, hogy abbl indulunk ki, ahogyan aktulisan m#kdnk. Megrtjk a jelenlegi folyamatainkat azltal, hogy feltrkpezzk az rtkteremts teljes menett, s annak minden lpsre meghatrozunk egy vgrehajts alatt ll feladatszm- (WIP-) korltot. Ezek utn az elvgzend! munkt vgigramoltatjuk ezen a rendszeren gy, hogy akkor kezdnk bele egy folyamatlps vgrehajtsba, ha megjelent egy Kanban-jelzs.

A Kanban-mdszer hasznosnak bizonyult az agilis szoftverfejlesztst kvet! csapatoknl, de egyre gyakrabban trsul tradicionlisabb megkzeltst alkalmaz csoportok munkjhoz is. A Kanban a Lean-kezdemnyezsben bukkant fel el!szr, hogy segtse a vllalati kultra talaktst s a folyamatos fejl!dst.

BEVEZETS | ix

ix

Mivel a vgrehajts alatt ll feladatok szma korltozott a Kanban-rendszerben, brmi, ami megakad a folyamatban, a teljes rendszer bedugulst eredmnyezi: ha sok feladat blokkoldik, az a teljes rendszert lellsra knyszertheti. Ez arra kszteti a szervezetet, hogy a megakadt munkafzisra figyeljen, s elhrtsa az akadlyt, hogy jra megindulhasson a folyamat.

A Kanban vizulis visszajelzsi mechanizmusokat alkalmaz a feladatok nyomon kvetsre, ahogy azok vgigramlanak az rtkteremt! folyamat klnbz! llomsain. Ehhez jellemz!en fehr tblt s post-it cetliket vagy elektronikus rendszereket hasznlnak. A legjobb megolds valszn#leg mindkt mdszer egyttes alkalmazsa. A Kanban-rendszerb!l fakad magas szint# tlthatsg nagyban hozzjrul a szervezet kulturlis vltozshoz. Az agilis mdszerek jnak bizonyultak a folyamatban lv! s elvgzett feladatok szmnak, valamint az olyan mr!szmok mint a sebessg (azaz az egy iterci alatt elvgzett feladatok mennyisgnek) tlthatv ttelben. A Kanban ennl egy lpssel tovbbmegy lthatv tve a folyamatokat s az rtkramot. Felsznre hozza a sz#k keresztmetszeteket, a sorban ll feladatokat, az inkonzisztencikat s a vesztesget is; az elvgzett rtkes munka mennyisgben s az ehhez szksges ciklusid!ben kifejezve minden olyan tnyez!t lthatv tesz, ami befolysolja a szervezet teljestmnyt. A Kanban lehet!v teszi a csapat rsztvev!i s a kls! rintettek szmra, hogy gyors visszajelzst kaphassanak minden olyan cselekedetk hatsrl, amit vgrehajtottak vagy ppen nem hajtottak vgre. Mindezeknek ksznhet!en az esettanulmnyok azt mutatjk, hogy a Kanban az emberek viselkedst a nagyobb egyttm#kds irnyba tereli. Az inkonzisztencik, a sz#k keresztmetszetek, a vesztesgek s ezek hatsainak felsznre hozatala sztnzi a problmk okainak feltrst, a tovbbfejlesztsi lehet!sgekr!l foly eszmecserket, ezrt a csapatok gyorsan hozzltnak a folyamataik javtshoz.

Ennek eredmnyeknt a Kanban sztnzi a meglv! folyamatok lland fejlesztst, mely alapvet!en sszhangban van az agilis s Lean rtkekkel. A Kanban nem vrja el, hogy mindenestl felforgassuk azt, ahogyan az emberek dolgoznak, hanem a fokozatos s folyamatos vltozs feltteleit teremti meg, a szervezet minden szintjnek egyetrtsvel s tmogatsval.

(x

A hzrendszer sajtossgainak ksznhet!en a Kanban el!segti a visszafordthatatlan ktelezettsgvllalsok s dntsek lehet! legks!bbi id!pontra trtn! halasztst. A csapatok s a vezet!k ltalban kialaktjk a rendszeres priorizcis tallkozk temezst, ritmust, melyeken meghatrozzk a kvetkez! elvgzend! feladatokat. Ezek a tallkozk meglehet!sen gyakoriak is lehetnek, mivel az id!tartamuk rvid. Ezeken a megbeszlseken leegyszer#stve az albbihoz hasonl krdseket trgyalnak meg: Az utols egyeztets ta kt teend! szmra szabadult fel hely. A jelenlegi ciklusid!nk a feladatok leszlltsra hat ht. Melyik az a kt feladat, aminek leszlltsra a leginkbb szksg van mhoz hat htre? Ennek a mdszernek kett!s hatsa van. Az egyszer# krdsek felttele ltalban gyors s lnyegre tr! vlaszt eredmnyez, ami segt a megbeszlst mederben tartani. A mechanizmus az utols pillanatig tmogatja a dntsi lehet!sgek nyitva tartst, ami az elvrsok kordban tartsval nveli a hatkonysgot, valamint cskkenti a feladat vllalsa s megoldsa kztt eltelt ciklusid!t, gy annak valszn#sgt is, hogy a prioritsok a feladat vgrehajtsa kzben megvltoznak.

A Kanban melletti vgs! rv, hogy a vgrehajts alatt lv! teend!k korltozsa lehet!v teszi a ciklusid! el!rejelzst, s megbzhatbb teszi a feladatok leszlltst. Az akadlyokhoz s hibkhoz trtn! lltsd meg a folyamatot! (stop the line) hozzlls nagyon magas min!sgi sznvonalhoz vezet, s cskkenti a mdostsok, javtsok szmt.

Br mindezek magtl rtet!d!v vlnak a knyv nagyszer#en megrt, tiszta lersaibl, az azonban nem kerl ismertetsre, hogyan is jutottunk el idig. A Kanban nem egy dlutn alatt szletett meg valami csodlatos ihlet eredmnyeknt, hanem vek alatt fejl!dtt azz, ami. Azon mly pszicholgiai s szociolgiai hatsok kzl, melyek megvltoztatjk a szervezetek kpessgeit s rettsgt, sokat soha nem terveztek meg, inkbb felfedeztek. A Kanban eredmnyei kzl tbb nehezen megmagyarzhat. Az, ami els! ltsra technikai megkzeltsnek t#nik korltozzuk a vgrehajts alatt lv! feladatok szmt, s alkalmazzunk hzrendszert vgs! soron alapvet! hatssal van arra, ahogy az emberek egyttm#kdnek egymssal. Sem n, sem ms azok kzl, akik a Kanban korai id!szakban rszt vettek, nem lttk el!re mindezt.

BEVEZETS | xi

xi

Azt kerestem, amiv a Kanban lett: gy kzelti meg a vltozsokat, hogy csak minimlis ellenllst eredmnyez; ez mr 2003-ban vilgoss vlt el!ttem. A technikai megoldsai miatt is rdekl!dtem irnta. Ahogyan a gyakorlatban megismertem a Lean-eszkzket szrevettem, hogyha van rtelme foglalkozni a vgrehajts alatt ll feladatok szmval, akkor plne van rtelme korltozni azokat, hiszen ez cskkentette a menedzsmentterheket. 2004-ben gy dntttem, hogy a legfontosabb Lean-alapelvek kzl megkezdjk a hzrendszer bevezetst. Erre akkor nylt lehet!sgem, amikor a Microsoft egyik vezet!je felkrt, hogy segtsek egy bels! IT-rendszerek karbantartst vgz! csoport m#kdsnek megjtsban. Az els! megvalstst a Theory of Constraints elmletben1 DobPufferKtl nven ismert hzrendszer alkalmazsval vgeztk. Az eredmny igazi sikertrtnet lett: a ciklusid! 92 szzalkkal cskkent, a teljestmny tbb, mint hromszorosra n!tt, az el!rejelzsi pontossg pedig 98 szzalk lett.

2005-ben Donald Reinertsen beszlt r, hogy valstsunk meg egy teljes Kanban-rendszert. Erre 2006-ban nylt lehet!sgem, amikor a Corbisnl megbzst kaptam a szoftverfejlesztsi rszleg vezetsre, Seattle-ben. Az els! eredmnyekr!l 2007-ben kezdtem beszmolni, el!adst el!szr az 2007 mjusban tartottam a Lean Termkfejlesztsi Konferencin, Chicagban. Ezt kvette egy OpenSpace beszlgets mg ebben az vben Washingtonban, az Agile 2007 konferencin, huszont rsztvev!vel, kzlk hrman a Yahoo!-tl voltak (Aaron Sanders, Karl Scotland s Joe Arnold). Ezt kvet!en hazamentek Kaliforniba, Indiba, illetve az Egyeslt Kirlysgba, majd bevezettk a Kanban-rendszert sajt, Scrummal bajld csapataiknl. Szintn !k indtottak egy Yahoo!-vitacsoportot is, melyben e sorok rsakor kzel nyolcszz tagot szmllnak. A Kanban-rendszer megkezdte trhdtst, a korai alkalmazk elkezdtek beszmolni a tapasztalataikrl.

Most, 2009-ben, a Kanban-rendszer alkalmazsa igazn terjed!ben van, s egyre tbb s tbb tapasztalati beszmol kerl napvilgra. Az elmlt t vben sokat tanultunk a Kanbanrl, s ez minden nap valami jjal egszl ki. A sajt munkmat annak szentelem, hogy alkalmazzam a (((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((1 A Theory of Constraints (A knyszerek elmlete) dr. Eliyahu M. Goldratt ltal megfogalmazott megkzelts, mely a hzrendszerek egyfajta lerst adja (a ford.).(

(xii

Kanbant, rjak, beszljek s gondolkodjak rla, hogy jobban megrtsem, s msoknak is segtsek megrteni. Szndkosan kerlm, hogy a Kanbant ms agilis mdszerekhez hasonltgassam, br 2008-ban tettem er!fesztseket, hogy megrtessem, mirt van mlt helye az agilis mdszertanok kztt.

Az olyan krdsek megvlaszolst, hogy Milyen a Kanban a Scrumhoz kpest? azokra hagyom, akik nlam tbb tapasztalattal rendelkeznek. ppen ezrt nagyon rlk, hogy Henrik Kniberg s Mattias Skarin e krds lre llt. nnek a tuds vilgban trtn! munkhoz informcikra van szksge, hogy megalapozott dntseket hozhasson s magasabb szintre lphessen. Henrik s Mattias gy elgti ki ezeket az ignyeket, ahogyan n sosem tudnm. Engem klnsen megfogott az a tnyszer#, blcs s elfogulatlan md, ahogy Henrik sszehasonltja a kt mdszert. Rajzai s illusztrcii klnsen tallak, s gyakran tbb oldalnyi szveg elolvasst sproljk meg. Mattias esettanulmnya azrt fontos, mert jl pldzza, hogy a Kanban lnyegesen tbb mint egy elmlet, s pldkon keresztl mutatja be, hogyan lehet hasznos az n projektjeiben is.

Bzom benne, hogy lvezni fogja ezt a knyvet a Kanban s a Scrum sszehasonltsrl, mely mlyebb bepillantst enged ltalban az agilits vilgba, s klnskppen a Kanban s Scrum mdszereibe. Ha tbbet szeretne megtudni a Kanbanrl, ltogasson el a Limited WIP Society kzssgi oldalra a http://www.limitedwipsociety.org/ cmen.

David J. Anderson

Sequim, Washington, USA 2009. jlius 8.

(xiii

(Bevezets

Nem szoktunk knyvet rni. Jobban szeretjk az id!nket les krnyezetben tlteni, s az gyfeleinket segteni abban, hogy jobban megrtsk, optimalizljk s tszervezzk folyamataikat s szervezetket. jabban szrevettnk nhny irnyvonalat, amelyekkel kapcsolatban szeretnnk gondolatainkat megosztani az Olvasval. Kezdjk egy tipikus szitucival!

Jim: Vgre tl vagyunk a Scrum bevezetsen!

Fred: Na, s milyen?

Jim: Tulajdonkppen sokkal jobb, mint ahogy korbban m#kdtnk...

Fred: ...de?

Jim: ... csak, tudod, mi egy tmogat s karbantart csoport vagyunk.

Fred: Igen, s?

Jim: Nos, ht imdjuk ezt a dolgot a product backloggal, a prioritsok rendezgetsvel, az nszervez!d! csoportokkal, a napi Scrum egyeztetsekkel, kirtkelsekkel stb...

Fred: Akkor, mi a gond?

Jim: Ht az, hogy rendre elbukjuk a sprintjeinket.

Fred: De mirt?

Jim: Mert nehz kthetes terveket bevllalnunk. Az iterciknak nincs tl sok rtelme a mi esetnkben, ltalban csak az aznapra ppen legfontosabb feladatokon dolgozunk. Szervezznk esetleg egyhetes itercikat?

(xiv

Fred: Be tudntok vllalni egy htre val feladatot? Meg tudntok oldani, hogy csak az egy htre el!re betervezett feladatokon dolgozzatok?

Jim: Nem igazn, naponta bukkannak fel jak. Esetleg, ha egynapos sprintekben dolgoznnk...

Fred: A feladataitok megoldhatk kevesebb, mint egy nap alatt?

Jim: Nem, nha nhny napig is eltartanak.

Fred: Teht az egynapos sprintek sem m#kdnnek nlatok. Nem gondoltatok arra, hogy teljesen megszabaduljatok a sprintekt!l?

Jim: Nos, tulajdonkppen nem lenne rossz. De ez nem Scrum-ellenes?

Fred: A Scrum csak egy eszkz. Te dntd el, hol s hogyan hasznlod. Ne lgy a szolgja!

Jim: Teht, mit kellene tennnk?

Fred: Hallottatok mr a Kanbanrl?

Jim: Az meg micsoda? Miben klnbzik az a Scrumtl?

Fred: Tessk, olvasd el ezt a knyvet!

Jim: De n egybknt szeretem a Scrumot, most akkor vltsak?

Fred: Nem, kombinlhatod is a kett!t!

Jim: Micsoda? Hogy?

Fred: Csak olvasd el...

BEVEZETS | xv

xv

A knyv clja

Ha n rdekl!dik az agilis szoftverfejleszts irnt, bizonyra ismeri mr a Scrumot, s hallhatott mr a Kanbanrl is. Egyre gyakrabban tallkozunk a krdssel: Mi ez a Kanban? Milyen a Scrummal sszehasonltva? Hogyan egsztik ki egymst? Van kzttk potencilis ellentt?

E knyv clja a kd eloszlatsa, hogy az Olvas is megtlhesse, hogyan hasznosthatn a Kanbant s a Scrumot sajt krnyezetben.

Ha sikerrel jrtunk, rtestsen rla!

(1

Els! rsz sszehasonlts A knyv ezen els! rsze trgyilagos s gyakorlati sszehasonltst kvn adni a Scrumrl s Kanbanrl. Ez a 2009 prilisban Kanban vs. Scrum cmmel rt cikk kiss mdostott vltozata. Az rs npszer"v vlt, ezrt gy dntttem, hogy knyv formjban is kiadom, s megkrem Mattias nev" kollgmat, hogy tuningolja fel egy kis esettanulmnnyal. Szerintem jl sikerlt. Ez az els! rsz akr egy az egyben kihagyhat, s elkezdhet! a msodik, esettanulmnyt tartalmaz fejezettel.

Henrik Kniberg

(2

1 Mir!l is szl a Scrum s a Kanban?

Ok, prbljuk meg sszefoglalni mindkt mdszert kevesebb, mint szz szban.

A Scrumrl dihjban

Osszuk fel a szervezetet kismret#, keresztfunkcionlis (cross-functional) nszervez!d! csapatokra!

A munknkat szintn daraboljuk fel kis, konkrt, szlltand elemekre! Ezt a listt rendezzk priorits szerint, s becsljk meg mindegyik elem relatv rfordtst!

MIR"L IS SZL A SCRUM S A KANBAN? | 3

Osszuk a rendelkezsre ll id"t rvid, fix-hosszsg (ltalban egy-ngyhetes) itercikra (azaz sprintekre, ahogy a Scrum hvja)! Minden egyes iterci vgn egy potencilisan szllthat kdot demonstrlunk.

Finomtsuk a releasetervnket a vev!vel egyttm#kdve s frisstsk az abban szerepl! prioritsokat az itercik sorn szerzett tapasztalatokra alapozva.

llandan javtsuk a folyamatainkat gy, hogy minden iterci utn kirtkelst tartunk!

Ezzel a mdszerrel ahelyett, hogy nagy csoporttal sok id"t tltennk nagymret# munka elvgzsvel, kismret# csapattal rvid id" alatt kismret# munkt teljestnk. Ezeket azonban rendszeresen integrljuk, hogy az egsz kp lthat maradjon.

A Scrum rszletes ismertetse megtallhat a Scrum and XP from the Trenches cm# kiadvnyban, amely ingyen elrhet!:

http://www.crisp.se/ScrumAndXpFromTheTrenches.html

Tovbbi scrumos linkek tallhatk a http://www.crisp.se/scrum oldalon.

A Kanban dihjban

Tegyk lthatv a munkafolyamatot!

o Bontsuk fel a munkt kisebb rszekre, mindegyiket rjuk fel egy krtyra, s helyezzk a falra!

o Vezessnk be tallan elnevezett oszlopokat, ezzel illusztrlhatjuk, hogy az egyes krtyk hol tartanak a folyamatban!

Korltozzuk a WIP-et (WIP = work in progress, folyamatban lv! munkk) rendeljnk egyrtelm# korltokat mindenegyes folyamatlpsekhez, amik azt jelzik, hogy az egyes oszlopok hny krtyt tartalmazhatnak!

4 |(KANBAN S SCRUM MINDKETT"B"L A LEGJOBBAT(

(

Mrjk az tfutsi id"t (egy krtya tlagos teljestsi idejt, ezt gyakran nevezik ciklusid!nek is), s optimalizljuk a folyamatot, hogy ez az id! a lehet! legkisebb s legtervezhet!bb legyen!

Kanbannal kapcsolatos hasznos cikkek linkgy#jtemnye itt tallhat: http://www.crisp.se/kanban(

(

(5

2 Hogyan viszonyul egymshoz a

Scrum s a Kanban?

A Scrum s a Kanban egyarnt mdszertani eszkzk

Eszkz = brmi, amit arra hasznlunk, hogy vgrehajtsunk vele egy feladatot, vagy elrjnk egy clt.

Mdszer = ahogyan dolgozunk.

A Scrum s a Kanban mdszertani eszkzk, azaz a hatkonyabb munkavgzsben tmogatnak bennnket azltal, hogy bizonyos mrtkig meghatrozzk mit, hogyan tegynk. A Java is eszkz, mely a szmtgp programozsnak egyszer#bb mdjt biztostja; a fogkefe is eszkz, ami a fogaink tiszttsban segt bennnket.

Azrt hasonltsunk ssze eszkzket, hogy megrtsk !ket, ne azrt, hogy tlkezznk

felettk!

Ks, vagy villa melyikk jobb?

Meglehet!sen rtelmetlen krds, nem? A vlasz a krlmnyeken mlik. Kicsi fasrtok elfogyasztshoz a villa feltehet!en jobb eszkz, gombaszeletelshez inkbb a ks t#nik megfelel!nek. Az asztalon

6 | KANBAN S SCRUM MINDKETT"B"L A LEGJOBBAT(

(

trtn! dobolshoz brmelyik megfelel!. Egy steak elfogyasztshoz valszn#leg mindkett!t egyszerre fogjuk alkalmazni. Rizsevshez..., nos..., van, aki a villt kedveli, msok viszont ev!plcikt vlasztannak.

Ha teht eszkzket hasonltunk ssze, rdemes vatosnak lennnk. Arra hasznljuk a hasonltgatst, hogy megrtsk a m#kdsket, ne arra, hogy brljuk !ket.

Nem ltezik ksz vagy tkletes eszkz

Mint brmely ms eszkz, sem a Scrum, sem a Kanban nincs tklyre fejlesztve. Nem mondanak el mindent arrl, hogy mit tegynk, mindssze bizonyos irnymutatsokat s szablyokat nyjtanak. A Scrum pldul azt rja el!, hogy keresztfunkcionlis csoportokat hozzunk ltre s id!keretek kz szortott itercikat alkalmazzunk. A Kanban szablyai kz tartozik, hogy vizualizljuk a folyamatot, s korltozzuk a sorban ll feladatok szmt.

Meglehet!sen rdekes dolog, hogy egy eszkz rtke ppen abban rejlik, hogy korltozza a lehet!sgeink szmt. Egy mdszertani eszkz, ami szerint brmi megtehet!, nem klnsebben hasznos; elnevezhetnnk Csinlj brmit, vagy akr Tedd a megfelel!t mdszernek. Ez utbbi garantltan m#kdik, ez a csodafegyver! Ha ugyanis nem m#kdtt, akkor nyilvnvalan nem kvettk a mdszert. !

A megfelel! eszkzk alkalmazsa segt a siker elrsben, de nem garantlja azt. Egyszer# zavart kelteni a projektek sikere/buksa s az eszkzk sikere/buksa sszekeversvel.

Egy projekt sikeres lehet egy nagyszer# eszkznek ksznhet!en.

Egy projekt sikeres lehet annak ellenre, hogy gyenge eszkzt hasznltunk.

Egy projekt elbukhat egy gyenge eszkz miatt.

Egy projekt elbukhat egy nagyszer# eszkz ellenre is.

HOGYAN VISZONYUL EGYMSHOZ A SCRUM S A KANBAN? | 7

A Scrum el!rbb, mint a Kanban

sszehasonlthatunk eszkzket aszerint, hogy mennyi szablyt hatroznak meg. Az el!r szerint kvess tbb szablyt, mg az adaptv azt jelenti, hogy kvess kevesebb szablyt. A teljes mrtkig el!r mdszer nem engedi, hogy hasznljuk az agyunkat, mg az abszolt adaptv azt jelenti, hogy azt tesznk, amit akarunk, egyltaln nincsenek megktsek s szablyok. Knnyen belthat, hogy mindkt vglet kptelensg...

Az agilis mdszereket nha knnyednek nevezik els!sorban azrt, mert kevsb el!rak, mint a tradicionlis mdszertanok. Tny, hogy az Agilis Kiltvny els! ttele ez: az egyn s a szemlyes kommunikci az eszkzk s folyamatok felett.

A Scrum s a Kanban meglehet!sen adaptv mdszerek, de a Scrum szigorbb a Kanbannl: tbb megktst tartalmaz, ennlfogva kevesebb lehet!sget hagy nyitva. El!rja pldul az id!keretek kz szortott itercikat, amit a Kanban nem.

Hasonltsunk ssze nhny mdszertani eszkzt az el!r-adaptv-skln:

A RUP meglehet!sen szablyozott tbb mint harminc szerepkrt, hsz feletti tevkenysget s hetvennl tbb termket hatroz meg. Iszonyan sok tanulnival... Nem felttlenl szksges ugyanakkor mindegyik elem hasznlata, az alkalmazra van bzva, hogy kivlogassa az adott projektben relevnsakat. Sajnlatos mdon ez a gyakorlatban elgg bonyolultnak bizonyult. Hmmmm... szksgnk lesz vajon Konfigurci


(

audit jelents termkre? Kell-e neknk Vltozsmenedzser szerepkr? Nem felttlenl, de biztos, ami biztos alapon tartsuk meg !ket. Ez lehet az oka annak, hogy a RUP-megvalstsok meglehet!sen nehzslyra sikerednek a vgn, sszehasonltva a Scrum- vagy XP-mdszerekkel.

Az XP (eXtreme Programming) meglehet!sen el!r a Scrumhoz kpest. Majdnem mindent tartalmaz amit a Scrum, kiegsztve egy halom specilis fejlesztsi mdszerrel, mint pldul a test-driven development vagy a pros programozs. A Scrum kevsb el!r, mint az XP tekintettel arra, hogy egyetlen specifikus fejlesztsi technikt sem hatroz meg , ugyanakkor szigorbb, mint a Kanban, mivel olyan dolgokat r el!, mint az itercik vagy a keresztfunkcionlis csoportok.

A Scrum s a RUP kztti egyik nagy klnbsg, hogy a RUP tl sokat ad s a felhasznljra van bzva, hogy megszabadtsa azoktl az elemekt!l, amikre nincs szksge. A Scrum kevesebbet r el! s az alkalmazjra hrul a feladat, hogy hozztegye azokat az elemeket, amikre mg szksge van.

A Kanban majdnem mindent nyitva hagy. Szinte annyi az sszes el!rsa, hogy Jelentsd meg a munkafolyamatot s Korltozd a vgrehajts alatt lv! feladatok (WIP) szmt. Csak egy hajszlnyira van a Tgy brmit mdszert!l, de mgis meglep!en hatkony.

Ne korltozd magad egyetlen eszkzre!

Vegytsk az eszkzket ignyeink szerint! Nehezen tudok elkpzelni sikeres Scrum-csoportot anlkl, hogy ne hasznln pldul az XP elemeinek tbbsgt. Sok Kanban-csapat tart napi megbeszlseket (ami Scrum-mdszer). Nhny Scrum-csapat a backlog-bejegyzsek egy rszt hasznlati esetekbe (use case; RUP-elem) szervezve rja meg, vagy korltozza a WIP-et (Kanban-mdszer). Akrmelyik mdszer m#kdhet.

Musashi (XVII. szzadi szamurj, aki hres volt kt kardos harci technikjrl) fogalmazta meg tallan:

HOGYAN VISZONYUL EGYMSHOZ A SCRUM S A KANBAN? | 9

Tartsuk ugyanakkor tiszteletben minden mdszer szablyait! Ha pldul Scrumot alkalmazunk, s gy dntnk, hogy nem ragaszkodunk tovbb a szigor id!keretek kz szortott itercikhoz (vagy a Scrum brmely ms szablyhoz), ne nevezzk tbb Scrumnak. A Scrum elg minimalista nmagban is ahhoz, hogyha brmit!l megfosztjuk s tovbbra is Scrumnak nevezzk, a nv rtelmt vesztse. Nevezzk valami msnak, pldul Scrum-alap mdszernek, Scrum-tredknek, vagy mit szlnnk a scrumos elnevezshez? !

- Miyamoto Musashi

Soha ne korltozd magad egyetlen fegyverre vagy harcm#vszetre!

(10

3 A Scrum szerepkrket r el!

A Scrum hrom szerepkrt r el!: product owner (meghatrozza a termkkel kapcsolatos vzit s a prioritsokat), team (megvalstja a termket) s Scrum master (problmk elhrtsa s a fejlesztsi folyamat vezetse).

A Kanban egyltaln nem hatroz meg semmilyen szerepkrt.

Ez persze nem jelenti azt, hogy ne lehetne vagy kellene betlteni a product owner szerepkrt a Kanbanban. Ez mindssze annyit jelent, hogy nem ktelez!! A Scrum s a Kanban egyarnt lehet!v teszi, hogy brmilyen tovbbi szksges szerepkrrel kiegsztsk !ket.

A tovbbiak meghatrozsval ugyanakkor bnjunk vatosan! Gy!z!djnk meg arrl, hogy az ltalunk kialaktott szerepek hozzadott rtket kpviselnek, s nem tkznek a mdszer ms szerepkreivel. Biztos, hogy szksgnk van projektmenedzserre? Egy nagy munkban hasznos lehet, ha ! hangolja ssze tbb csapat s product owner munkjt; de kis projektekben feleslegess vlhat, vagy ami mg rosszabb, mikromenedzsmenthez s konfliktusokhoz vezethet.

A Scrum s a Kanban szerint is az az alapelv, hogy a kevesebb jobb! Ha bizonytalanok vagyunk, kezdjnk a kevesebbel!

A tovbbiakban a product owner kifejezst a trgyalt mdszert!l fggetlenl arra a szerepl!re alkalmazzuk, aki meghatrozza a team feladatainak prioritsait.

(11

4 A Scrum id!keretek kz szortott

itercikat r el! A Scrum az id!keretek kz szortott itercikon alapszik. Brmilyen hosszsgt vlaszthatunk, de az ltalnos vlekeds szerint rdemes egy id!szakon bell ugyanolyan hosszsgokat alkalmazni, hogy kialakulhasson a fejleszts megszokott teme.

Az iterci kezdetn erre vonatkoz tervet hozunk ltre: a product owner prioritsai alapjn a csapat annyi elemet vlaszt ki a product backlogbl, amennyir!l gy gondolja, hogy teljesteni tudja az adott iterciban (tervezs s vllals).

Az iterci kzben a csapat a bevllalt elemek befejezsre koncentrl. Az iterci szkpja rgztett.

Az iterci vgn a csapat bemutatja a legfontosabb rsztvev!knek a m#kd! kdot (demo), amelynek elmletileg potencilisan szllthatnak kellene lennie (azaz leteszteltnek s indulsra ksznek). A csapat azutn rtkelst tart (retrospective), s megvitatja, hogyan javthat a folyamatain.

Egy Scrum-iterci teht nem ms, mint egyetlen id!keretek kz szortott tem, amely az albbi hrom tevkenysget kombinlja: a tervezst, a folyamatfejlesztst s idelis esetben a kibocstst.

A Kanban nem rja el! az id!keretek kz szortott itercikat. Mi vlaszthatjuk ki, hogy mikor terveznk, mikor javtunk a folyamatunkon, s mikor bocstunk ki verzit. Dnthetnk gy, hogy ezen tevkenysgeket bizonyos rendszeressggel vgezzk (pl. minden htf!n verzit adunk), de gy is dnthetnk, hogy szksg esetn vgezzk el a feladatokat (pl. akkor adunk release-t, ha sikerlt valami hasznosat el!lltanunk).


(

Egyes szm csapat (egyetlen tem)

Scrum-itercikban dolgozunk

Kettes szm csapat (hrom tem)

Hrom klnbz! temet alkalmazunk. Minden hten kibocstjuk, amivel elkszltnk. Minden msodik hten terveznk, valamint frisstjk a prioritsokat s a release-terveket. Minden negyedik hten visszatekintst tartunk, hogy tovbb fejlesszk a folyamatunkat.

Hrmas szm csapat (f!knt esemnyvezrelt)

Minden alkalommal, amikor kifogyunk a tennivalkbl, tervezst tartunk. Akkor bocstunk ki egy verzit, amikor mr van piackpes funkci. Mindenegyes alkalommal egyeztetnk, ha msodszor futunk bele ugyanabba a problmba, s minden negyedik hten tartunk egy teljesen tfog visszatekintst is.

(13

5 A Kanban munkafolyamat lpsenknt, a Scrum itercinknt korltozza a WIP-et

A Scrumban a sprint backlog tartalmazza azokat a feladatokat, amiket az adott iterciban el kell vgezni. Ezeket a feladatokat ltalban a falon lv! krtyk jelentik meg, amit Scrum- vagy Feladattblnak neveznk.

Mi a klnbsg teht egy Scrum- s egy Kanban-tbla kztt? Kezdjk egy vgtelenl leegyszer#stett pldval, s hasonltsuk ssze a kett!t:

Mindkt esetben egy halom elem tjt kvetjk nyomon a munkafolyamaton keresztl. Hrom llapotot hatroztunk meg: Teend!, Folyamatban s Ksz. Brmilyen llapotot vlaszthatnnk, ami szimpatikus nhny csapat tovbbiakat ad hozz, pldul Integrci, Teszt, Kibocsts stb. Sose feledkezznk meg ugyanakkor a kevesebb tbb alapelvr!l!

Mi a klnbsg a pldban mutatott kt tbla kztt? Igen, a kicsi kettes szm a Kanban-tbla kzps! oszlopban. Mindssze ennyi. Ez a kettes azt jelenti, hogy ez az oszlop egy pillanatban sem tartalmazhat kett!nl tbb elemet.

A Scrumban nincs olyan szably, ami megakadlyozn a csapatot abban, hogy az sszes elemet egyszerre helyezze a Folyamatban oszlopba! Ltezik ugyanakkor egy implicit korlt, hiszen az itercinak nmagban meghatrozott terjedelme van. Ebben az esetben az egy oszlopban elhelyezhet! feladatok korltja ngy, hiszen mindssze ennyi szerepel a


(

tbln. A Scrum teht indirekt mdon korltozza a WIP-et, mg a Kanban direkt.

A legtbb Scrum-csapat vgl is beltja, hogy nem j tlet tl sok feladatot folyamatban tartani, s kialaktanak egy rendet arra, hogy miel!tt nekiltnak egy j feladat elvgzsnek, a folyamatban lv!t lezrjk. Nhny csapat radsul r is sznja magt arra, hogy explicit korltozza a folyamatban lv! feladatok szmt s lm! a Scrum-tbla Kanban-tblv alakult.

Teht mind a Scrum, mind a Kanban korltozza a feldolgozs alatt ll feladatok szmt, csak klnbz! mdon. A Scrum-csapatok ltalban mrik a sebessget mennyi feladatot (vagy munkamennyisg mrtkt mr! egysget, pl. sztoripontot) kpesek elvgezni egy iterci alatt. Amint egy csapat ismeri sajt sebessgt, az lesz az egy itercira vonatkoz WIP-korltjuk (vagy legalbbis egy irnymutats arra). Ha egy csapat tlagos sebessge pldul tz elem (vagy sztoripont), akkor ennl tbbet ltalban nem tervez egy sprintre.

A Scrumban teht a WIP id!egysgre vonatkoztatva korltozott.

A Kanbanban a WIP munkafolyamat-lpsekre korltozott.

A fenti Kanban-pldban brmely pillanatban maximum kt elem lehet a Folyamatban munkafzisban, fggetlenl a fejleszts temezst!l. Magunknak kell megvlasztanunk, hogy mely munkafzishoz milyen WIP-korltot hatrozunk meg, de az ltalnos szably az, hogy az rtkram lehet! legkorbbi s legks!bbi lpse kztt mindenegyes fzishoz rendeljnk ilyen korltot. A fenti pldban teht trekedni kell arra, hogy a Teend! (vagy akrhogy nevezzk az els! fzist) oszlop elemszmt is korltozzuk. Ha mr egyszer meghatroztuk a WIP-korltokat, megkezdhetjk mrni s el!rejelezni az tfutsi id!t, azaz egy elem sszes munkafzison trtn! thaladshoz sszesen szksges tlagos id!t. Az el!rejelezhet! tfutsi id! teszi lehet!v szmunkra a ktelezettsgvllalst s a relis tervek ksztst.

Ha az egyes feladatok mrete nagymrtkben klnbz!, akkor rdemes megfontolni a WIP-korltok sztoripontban vagy brmely ms feladatmretet kifejez! mrtkegysgben trtn! meghatrozst. Nhny csapat kln energit fektet abba, hogy a teend!ket kzel azonos mret# elemekre bontsa, hogy elkerlje a klnbz! feladatmretek kezelsb!l add komplikcikat s cskkentse a becslsek idejre fordtott id!t. Knnyebb zkken!mentes ramlst megvalstani, ha a feladatok nagyjbl azonos mret#ek.

(15

6 Mindkett! empirikus

Kpzeljk el, hogy ezen mutatk szablyozsval szabadon konfigurlhatjuk folyamatainkat. Nagy fejlesztsi sebessget akarok, alacsony tfutsi id!vel, magas min!sggel s nagyfok tervezhet!sggel. Teht a mutatkat rendre 10, 1, 10, 10 rtkekre lltom be.

Ez nagyszer# lenne, ugye? Sajnos nem lteznek ilyen direkt szablyozk, legalbbis n nem ismerek ilyeneket.

Helyette van egy halom indirekt szablyozsi eszkznk.

A Scrum s a Kanban empirikus rendszerek abban az rtelemben, hogy ksrletezsen keresztl a felhasznlnak kell sajt krlmnyeinek megfelel!re hangolnia !ket. Sem a Scrum, sem a Kanban nem adja meg a vlaszt mindenre mindssze az alapvet! szablyokat hatrozzk meg ahhoz, hogyan fejleszthetjk sajt folyamatainkat.


(

A Scrum azt javasolja, hogy lltsunk fel keresztfunkcionlis csapatokat. Kik legyenek egy csapatban? Nem tudjuk, ksrletezni kell.

A Scrum szerint a csapatnak kell meghatroznia, hogy mennyi munkt emeljen be egy sprint terjedelmbe, teht pontosan mennyit vllaljon. De mennyi legyen az? Nem tudjuk, ksrletezni kell.

A Kanban szerint korltozni kell a WIP-et. Mekkorra lltsuk be a WIP-korltot? Nem tudjuk, ksrletezni kell.

Ahogyan korbban emltettk, a Kanban kevesebb szablyt r el!, mint a Scrum. Ez azt jelenti, hogy tbb paramter szablyozsrl kell magunknak gondoskodni. Ez, a krlmnyekt!l fgg!en, egyszerre lehet el!ny vagy htrny. Ha pldul megnyitjuk egy szoftver paramterez! fellett, melyik esetet preferljuk: ha hrom paramtert llthatunk be, vagy ha szzat? Feltehet!en valahol a kett! kztt. Attl fgg, hogy mekkora rugalmassgra van szksgnk, s hogy mennyire ismerjk az eszkzt.

Tegyk fel teht, hogy cskkentjk a WIP-korltot arra a felttelezsre alapozva, hogy ez hatkonyabb teszi folyamatainkat. Ezek utn megfigyeljk, hogy milyen irnyba alakultak a sebessget, tfutsi id!t, min!sget s tervezhet!sget jelz! mutatink. Az eredmnyek alapjn kvetkeztetseket vonunk le, s tovbbi mdostsokat vgznk, hogy folyamatosan javtsuk a folyamatainkat.

Erre tbb elnevezst is hasznlnak. Kaizen (folyamatos fejl!ds a Lean-szhasznlatban), vizsgl s adaptl (Scrum-terminolgia), empirikus folyamatirnyts, vagy mirt ne lehetne tudomnyos mdszer?

Mindezek legfontosabb eleme a visszacsatolsi hurok. Vltoztass valamin => vizsgld meg mi lett az eredmnye => tanulj bel!le => ismt vltoztass valamin. ltalban vve olyan rvid visszacsatolsi hurkot akarunk, amennyire csak lehet, gy gyorsan javthatjuk a folyamatainkat.

A Scrumban az alap visszacsatolsi hurok a sprint. Ennl lnyegben tbb is van, klnsen, ha az XP-technikival egytt alkalmazzuk:

MINDKETT" EMPIRIKUS | 17

Helyesen alkalmazva a Scrum s az XP egy sor rendkvl rtkes visszacsatolsi ciklussal szolgl szmunkra.

A legbels! visszacsatolsi mechanizmus a pros programozs, mindssze nhny msodpercen bell biztostja a visszajelzst. A hibk megtallsa s kijavtsa mindssze nhny pillanatot vesz ignybe (Ennek a vltoznak nem hromnak kellene lennie?). Ez a jl fejlesztjk a termket? visszacsatolsi ciklus.

A kls! visszacsatolsi hurok, a sprint, nhny hten bell biztost visszajelzst. Ez biztostja a j termket fejlesztnk? visszacsatolsi ciklust.

Mi a helyzet a Kanbannal? Nos, az el!bb emltett visszacsatolsi hurkok mindegyikt alkalmazhatjuk (s!t, javasolt alkalmaznunk), akr Kanbant hasznlunk, akr nem. A Kanban kevs, de nagyon hasznos, vals idej# mr!szmot knl.

tlagos tfutsi id!. Minden alkalommal frisstend!, amint egy elem a Ksz (vagy akrhogy is nevezzk a jobb szls! oszlopot) llapotba kerl.

Sz#k keresztmetszetek. Jellemz! tnet, hogy az X oszlop zsfolt feladatokkal, mg az X+1 oszlop res. Keressk a lgbuborkokat a tbln!

A vals idej# mr!szmok szpsge abban rejlik, hogy magunk vlaszthatjuk meg a visszacsatolsi ciklus hosszt annak fggvnyben, milyen gyakran sznjuk r magunkat az eredmnyek kirtkelsre s a vltoztatsok bevezetsre. A tl hossz visszacsatolsi ciklus azt eredmnyezi, hogy folyamatfejlesztsnk teme lass lesz. A tl rvid visszacsatolsi id! eredmnyeknt el!fordulhat, hogy folyamataink nem tudnak stabilizldni a vltoztatsok kztt, ami koszhoz vezethet.


(

Valjban a visszacsatolsi ciklus hossza az egyik olyan tnyez!, amivel ksrletezhetnk... egyfajta meta-visszacsatolsknt. Na j, itt befejeztk :-)

Plda: Ksrletezs a Kanban WIP-korlttal

A Kanban egyik tipikus kulcskrdse a WIP-korlt. Honnan tudjuk, hogy jl hatroztuk meg?

Tegyk fel, hogy egy ngyf!s csapattal dolgozunk, s a WIP-korlt rtkt egyben hatrozzuk meg.

Valahnyszor hozzltunk egy feladat megoldshoz, nem indthatunk jat addig, amg az els!t le nem zrtuk, gy nagyon gyorsan Ksz sttuszba kerl.

Nagyszer#! De hamar kiderl, hogy ltalban nem tl kifizet!d!, hogy mind a ngy ember ugyanazon a feladaton dolgozzon (ebben a pldban), teht kt embernk ttlen marad. Ha ez hossz id! alatt csak egyszer fordul el!, nem nagy problma, de ha rendszeresen, annak kvetkezmnyeknt az tlagos tfutsi id!nk nvekedni fog. Vgs! soron az egy WIP-korlt azt jelenti, hogy a feladat gyorsan tovbblp a Folyamatban sttuszbl, ha egyszer oda kerl, viszont a szksgesnl tovbb marad a Teend! llapotban, teht a teljes folyamaton val tfutsi id! szksgtelenl hossz lesz.

Ha teht az egy WIP-korlt tl alacsony volt, mi lenne, ha felemelnnk nyolcra?


Ez egy darabig jobban m#kdik. szrevesszk, hogy a prokban trtn! munkavgzs gyorsabb feladatmegoldst tesz lehet!v, egy ngyf!s csapattal teht brmely adott id!pontban ltalban kt folyamatban lv! feladatunk lesz. A nyolcas WIP-korlt csak fels! hatr, teht ha ennl kevesebb van folyamatban, az mg j.

Most kpzeljk el, hogy az integrcis szerverrel egy problmba futottunk bele, ezrt egy feladatot sem tudunk teljes egszben lezrni (a Ksz defincija nlunk tartalmazza az integrcit is). Ilyesmi el!fordul nha, ugye?

Mivel nem tudjuk lezrni a D s E elemeket, dolgozni kezdnk az F feladaton. Mivel azt sem tudjuk integrlni, kivesznk egy j elemet, a G-t. Egy id! utn a Folyamatban sttuszban elrjk a nyolcas WIP-korltot.


(

Ezen a ponton mr nem tudunk tbb elemen dolgozni, ezrt jobban jrunk, ha kijavtjuk azt az integrcis szervert! A WIP-korlt figyelmeztetett bennnket arra, hogy reagljunk s szntessk meg a sz#k keresztmetszet okozjt ahelyett, hogy egy raks befejezetlen feladatot halmoznnk fel.

Ez j. De ha a WIP-korlt ngy lett volna, akkor sokkal hamarabb reaglunk, s jobb tlagos tfutsi id!t rhetnk el ez az egyensly. Mrjk az tlagos tfutsi id!t, s addig finomtjuk a WIP-korltot, amg el nem rjk a legjobb id!rtket.

Egy id! utn el!fordulhat, hogy a Teend! oszlopban feltorldnak a feladatok. Ilyenkor itt az ideje, hogy nveljk a WIP-korltot.

Mirt van egyltaln szksgnk a Teend! oszlopra? Nos, ha a megrendel! mindig elrhet! lenne a fejleszt!csapat szmra, hogy brmikor megkrhessk, hogy megmondja, mi legyen a kvetkez! elvgzend! feladat, akkor a Teend! oszlopra nem lenne szksg. De ebben az esetben a megrendel! nem rhet! el brmikor, teht a Teend! oszlop egy kis puffert kpez a csoport szmra a kztes id!ben.

Ksrletezznk! Vagy ahogy a Scrumolgus mondan: vizsgldj s adaptlj!

(21

7 A Scrum ellenll az itercikon belli

vltoztatsoknak Tegyk fel, hogy a Scrum-tblnk a kvetkez! mdon nz ki:

Mi van, ha valaki felbukkan, s az E feladatot szeretn elhelyezni a tbln?

A Scrum-csapat reakcija feltehet!en valami ilyesmi lesz: Sajnljuk, de nem lehet, mi ebben a sprintben az A, B, C s D feladatokat vllaltuk, viszont az E feladatot nyugodtan be lehet tenni a product backlogba. Ha a product owner elg magas prioritsnak tallja, beemeljk a kvetkez! sprintbe. A megfelel! hosszsg sprintek ppen elegend! id!t hagynak a fejleszt!i csapatnak, hogy valamit elksztsenek, valamint lehet!sget biztostanak a product owner szmra a prioritsok rendszeres meghatrozsra.


(

Hogyan kezeli ezt a helyzetet egy Kanban-team?

A Kanban-csapat azt mondhatja, hogy Nyugodtan helyezd az E feladatot a Teend! oszlopba. Mivel azonban a WIP-korltunk erre az oszlopra kett!, ezrt a C s D elemek kzl valamelyiket ki kell onnan venni. Jelenleg az A s B feladatokon dolgozunk, de amint lesz szabad kapacitsunk, megkezdjk a Teend! oszlop legfontosabb feladatnak vgrehajtst.

A Kanban-team vlaszideje (azaz amennyi id! alatt a prioritsok vltozsra reagl) teht annyira hossz, amennyi id! alatt szabad kapacitsa szabadul fel az egy elem ki = egy elem be szablyt kvetve (amit a WIP-korlt vezrel).

A Scrumban az tlagos vlaszid! a sprint hossznak fele.

A Scrumban a product owner nem nylhat hozz a Scrum-tblhoz, mivel a team egy iterciban az el!re meghatrozott feladatokra vllalt ktelezettsget. A Kanbanban magunknak kell kialaktanunk a sajt szablyainkat arra nzve, hogy ki s mit vltoztathat a tbln. Jellemz!en a product owner szmra fenntartanak egy Teend!, El!ksztett, Backlog vagy El!terjesztett nev# oszlopot a bal szlen, amelyben szabadon varilhatja a feladatokat.

Ez a kt megkzelts egybknt nem zrja ki egymst. Egy Scrum-csapat is dnthet gy, hogy lehet!v teszi a product owner szmra, hogy a sprint kzben is vltoztathasson a prioritsokon (igaz, ezeket kivteles eseteknek kell tekinteni). A Kanban-team szintn dnthet gy, hogy korltozza a prioritsok vltoztatsnak szabadsgt, vagy akr gy is, hogy, hasonlan a Scrumhoz, id!korltok kz szortott, rgztett szkp itercikat alkalmaz.

(23

8 A Scrum-tbla minden iterci

utn alaphelyzetbe kerl A Scrum-tbla tipikusan a kvetkez!kppen nz ki a sprint egyes fzisaiban:

Amikor a sprint vget r, a tbla alaphelyzetbe kerl, azaz minden elemet eltvoltanak rla. A kvetkez! sprint elkezd!dik, s a tervezs utn j Scrum-tbla vr rnk, amelynek a bal oldaln sorakoznak az j elemek. Technikailag gy t#nhet, ez id!pazarls, de egy gyakorlott Scrum-csapat szmra ez a m#velet ltalban nem tart sokig, s a tbla alaphelyzetbe lltsa, a befejezs s lezrs egyfajta kellemes rzst ad. Olyan, mintha elmosogatnnk vacsora utn: nincs kedvnk hozz, de utna jl rezzk magunkat.

A Kanbanban a tbla ltalban folyamatos dolog, nem szksges alaphelyzetbe lltani s jra indtani.

(24

9 A Scrum keresztfunkcionlis

csapatokat r el! Egy Scrum-tblt csak egy csapat hasznlhat. A csapatnak keresztfunkcionlisnak kell lennie, azaz tartalmaznia kell mindazon szaktudst s kpessget, amellyel az iterci sszes elemt teljesteni tudja. A tblt ltalban brki lthatja, akit rdekel, de csupn a csapat vltoztathat rajta. Ez az ! eszkzk, amelyen az iterci vllalsait kezelik.

A Kanbanban opcionlisak a keresztfunkcionlis csapatok, s az sem szksges, hogy a tblt egyetlen csapat birtokolja. A tbla egy munkafolyamathoz tartozik, nem felttlenl egy csapathoz.


me kt plda:

1. plda: Az egsz tbla egyetlen keresztfunkcionlis csapatot szolgl ki csakgy, mint a Scrumban.

2. pda: A product owner az 1. oszlopban lltja fel a prioritsokat. Egy keresztfunkcionlis csoport fejleszt (2. oszlop), illetve tesztel (3. oszlop), a kibocstst (4. oszlop) egy specialista csapat vgzi. Valamennyi tlapolds a kompetencikban van, ezrt ha a kibocst csapat vlik a sz#k keresztmetszett, akkor valamelyik fejleszt! besegt.

A Kanbanban teht pr alapszablyt kell fellltani, hogy kik s hogyan hasznlhatjk a tblt. Ksrletezznk azutn a szablyokkal, hogy optimalizlhassuk a folyamatot!

(26

10 A Scrum backlog elemeinek bele kell

frnik egy sprintbe Mind a Scrum, mind a Kanban az inkrementlis fejlesztsen alapszik, azaz a munkt kisebb rszekre bontjk.

Egy Scrum-csapat csak olyan elemeket vllal el, amelyekr!l azt gondolja, hogy a Ksz defincija alapjn egy itercin bell kpes teljesteni. Ha egy elem tl nagy ahhoz, hogy befrjen a sprintbe, a csapat s a product owner egyttesen prblja kitallni, hogyan lehetne kisebb rszekre bontani. Ha az elemek rendszerint nagymret#ek, az iterci is hosszabb lesz (de ltalban ngy htnl nem hosszabb).

A Kanban-csapatok megprbljk minimalizlni az tfutsi id!t s szintekre bontani a folyamatot, amelynek kzvetett hatsa, hogy az elemeket viszonylag kismret# rszekre bontjk. Arra azonban nincs kimondott szably, hogy az elemeknek bele kellene frnik valamely id!korltba. Ugyanazon tbln lehet egy hnapig, de akr egy napig tart feladat is.

(27

11 A Scrum el!rja a

tervezst s a sebessg mrst A Scrum elvrja a csapatoktl, hogy megbecsljk a bevllalt feladatok egymshoz viszonytott mrett. Azzal, hogy minden, a sprint vgig elvgzett feladat mrett sszeadjuk, megkapjuk a csapat sebessgt (v). A sebessg a csapat kapacitsnak mrst szolglja mennyi feladatot tud elvgezni sprintenknt. me egy nyolcas tlagsebessg# csapat pldja.

Azrt hasznos tudni, hogy a csapat sebessge nyolc, mert gy relis el!rejelzst adhatunk arrl, hogy melyik feladatokat tudjuk teljesteni a kvetkez! sprintben, ami vgl relis release-tervek ksztst teszi lehet!v.

A Kanban nem rja el! a tervezst. Ha teht vllalsokat kell tennnk, ki kell tallnunk, hogyan teremtsk meg az el!rejelezhet!sg feltteleit.

Nhny csapat azt vlasztja, hogy a Scrumhoz hasonlan becsl, s mri a sebessget. Msok gy dntenek, hogy kihagyjk a becslst, de megprbljk kzel azonos mret# rszekre sztbontani a feladatot ezltal egyszer#en az adott id!egysg (pl. hetente) alatt elvgzett feladatok szmval mrik a sebessget. Vannak, akik a feladatokat gynevezett MMF-ekbe (minimum marketable feature, minimlis hasznos funkci) csoportostjk, az MMF tlagos tfutsi idejt mrik, s ez alapjn llaptjk meg sajt szolgltatsi szintjket pl. ha egy MMF fejlesztst bevllaljuk, akkor az minden esetben tizent napon bell leszllthat lesz.


(

Mindenfle rdekes technika ltezik a Kanban-stlus release-tervezsre s menedzsmentre, de nincs semmilyen ktelez! mdszer sem el!rva szval gyernk s keressnk az interneten, amg meg nem talljuk azt, ami illeszkedik a helyzetnkhz. Id!vel feltehet!en lthatunk majd kifejl!dni nhny legjobb gyakorlatot.

(29

12 Mindkett! lehet!v teszi, hogy tbb

termken dolgozzunk prhuzamosan A Scrumban alkalmazott product backlog elnevezs meglehet!sen szerencstlen, mivel azt sugallja, hogy minden elem ugyanahhoz a termkhez tartozik. Albb lthat kt termk a zld s srga, mindkett! a sajt product backlogjval s fejleszt! csapatval:

Mi a helyzet akkor, ha csak egyetlen csapatunk van? Gondoljunk inkbb a product backlogra, mint egy team backlogra, ami egy adott csapat (vagy csapatok) kvetkez! iterciinak priorizlt feladatait tartalmazza. Ha teht a csapat tbb termken dolgozik, egyestsk az sszes feladatait egyetlen listba. Ez rknyszert bennnket arra, hogy rangsoroljunk a termkek kztt, ami nhny esetben hasznos lehet. A gyakorlatban tbb mdszer is knlkozik erre.

Egy lehetsges megkzelts, hogy a csapat figyelmt egy sprintben egy termkre koncentrljuk:


(

Msik megkzelts lehet, hogy a csapat egy sprinten bell mindkt termk funkciin egyszerre dolgozik:

Ugyanez a helyzet a Kanban estn. Egyszerre tbb termknk is vgighaladhat ugyanazon tbla folyamatain. Megklnbztethetjk !ket klnbz! szn# krtykkal:

Vagy alkalmazhatunk vzszintes svokat:

(31

13 Mindkett! Lean s agilis

Most nem fogjuk rszletesen elemezni a Lean szemllet cm# knyvet s az agilis kiltvnyt, de ltalban vve mind a Scrum, mind a Kanban jl illeszkedik ezekhez az rtkekhez s alapelvekhez. Pldul:

Mind a Scrum, mind a Kanban hzrendszert valst meg, ami illeszkedik a Lean JIT (just in time) kszletkezelsi elveihez. Ez azt jelenti, hogy a csapat vlasztja meg, mikor s mennyi munkt vllal fel, azaz amint vgeztek egy feladattal, egy jat hznak ki ahelyett, hogy valaki kvlr!l toln rjuk azokat. Ahogyan egy nyomtat is csak akkor hzza ki a kvetkez! lapot, ha az el!z!vel vgzett (jllehet egy korltozott mret# kteget el!re betltenek a trolba).

A Scrum s a Kanban egyarnt tapasztalati alapon trtn! lland folyamatoptimalizlst valst meg, ami illeszkedik a Lean Kaizen (folyamatos javts) alapelvhez.

A Scrum s a Kanban is a vltozsra trtn! reaglst hangslyozza a tervek rigorzus kvetse helyett (jllehet a Kanban tipikusan gyorsabb reakciid!t tesz lehet!v, mint a Scrum), ami egyike az agilis kiltvnyban megfogalmazott ngy rtknek

... s folytathatnnk.

Bizonyos szempontbl a Scrum kevsb Leannek t#nhet, mivel a feladatok id!keretek kz szortott itercikba trtn! sszegy#jtst rja el!. De mindez csak az itercik hosszsgtl, s attl fgg, hogy mihez hasonltjuk. Egy tradicionlisabb mdszerhez hasonltva ahol taln vente kett!ngy alkalommal szlltunk le valamit egy kthetente j funkcit kibocst Scrum-csapat kifejezetten Lean.

Ha viszont folyamatosan rvidebb s rvidebb itercikat kezdnk bevezetni, alapvet!en kzelteni kezdnk a Kanbanhoz. Amint arrl kezdnk beszlgetni, hogy az itercik hosszt egy ht al cskkentsk, rdemes megfontolnunk az id!keretes itercik teljes elhagyst.


(

Eddig is mondtuk, s tovbbra is javasoljuk: ksrletezznk, amg nem tallunk valamit, ami jl m#kdik nlunk! Aztn folytassuk a ksrletezst

(33

14 Apr klnbsgek

Van nhny klnbsg, ami kevsb ltszik jelent!snek, mint a fent bemutatottak. Ennek ellenre rdemes tudatban lenni ezeknek is.

A Scrum priorizlt product backlogot r el!

A Scrumban a priorizls minden esetben a product backlog elemeinek sorba rendezsn keresztl trtnik s hatst a kvetkez! sprintre fejti ki (nem pedig a folyamatban lv!re). A Kanbanban tetsz!leges priorizcis mechanizmust alakthatunk ki (akr el is hagyhatjuk), amely hatst azonnal kifejti, amint a csapatnak kapacitsa szabadul fel (nem pedig fix id!kznknt). A product backlog vagy ltezik, vagy nem s vagy priorizlt, vagy nem.

A gyakorlatban ez kevs klnbsget jelent. A Kanbanban jellemz!en a bal szls! oszlop tlti be a Scrum product backlogjnak szerept. A feladatlista akr priorizlt, akr nem, a csapatnak dntsi szablyokra van szksge, amik alapjn meghatrozza, hogy melyik legyen a kvetkez! elvgzend! feladat. Pldk dntsi szablyokra:

Mindig a legfels! elemet vesszk ki.

Mindig a legrgebbi elemet vesszk ki (teht minden elem id!blyeggel rendelkezik).

Brmelyik elemet kivehetjk.

Az id!nk kb. hsz szzalkt tltsk tmogatsi feladatokon, s nyolcvan szzalkt j funkcik fejlesztsn.

A csapat kapacitst egyenl! arnyban osszuk el A s B termkek kztt.

Ha van piros elem, akkor azt vegyk ki els!nek.

A product backlogot a Scrumban is kezelhetjk Kanban-szer#en; azaz korltozhatjuk az elemszmot s felllthatunk a priorizls mdjra vonatkoz szablyokat.


(

A Scrum napi megbeszlseket r el!

A Scrum-csapat minden nap rvid (maximum tizent perc hosszsg) megbeszlst tart ugyanabban az id!pontban, ugyanazon a helyen. Ennek clja az informcik megosztsa arrl, hogy mi trtnik, mik az aznapra tervezett feladatok, s mik a munkt akadlyoz legnagyobb problmk. Ezt gyakran napi standupnak (felllsnak) nevezik, mivel a rsztvev!k ltalban llnak a megbeszls alatt (azrt, hogy rviden s aktvan tarthassk).

A Kanban nem rja el! a napi megbeszlseket, de a legtbb team ennek ellenre alkalmazza. Ez nagyon j technika fggetlenl attl, hogy melyik mdszert alkalmazzuk.

A Scrumban a megbeszls szemlykzpont minden tag egyenknt szmol be. Sok Kanban-csapat inkbb tblaorientlt rtekezletet tart, a sz#k keresztmetszetekre s az egyb lthat problmkra koncentrlva. Ez a megkzelts jobban sklzhat. Ha pldul ngy csapat osztozik ugyanazon a tbln kzs standup megbeszlskn, rvidebb ideig tart, ha csak a tbla problmkat tartalmaz rszeire fkuszlunk.

A Scrum el!rja a burndown-grafikon vezetst

A sprint burndown chart (lefutsi grafikon) napi szinten mutatja, hogy mennyi munka van htra az adott iterciban vllalt sszes feladat befejezsig.

Az Y tengely mrtkegysge megegyezik a sprintfeladatok mretezsnl hasznlt egysgekkel, jellemz!en rk vagy napok (ha a team feladatokk bontja szt a backlog elemeit) vagy sztoripontok. Rengeteg varici ltezik erre.

A Scrumban az iterci el!rehaladsnak els!szm kvet! eszkzeknt a sprint lefutsi grafikonokat hasznljk.

Nhny csapat release lefutsi grafikonokat is hasznl, amik ugyangy nznek ki, csak release szintet jelentenek meg jellemz!en azt mutatjk, hogy egy-egy sprint utn mennyi sztoripont maradt htra a release befejezsig.

APR KLNBSGEK | 35

A lefutsi grafikon els!dleges clja, hogy egyszer#en kvethet! legyen, hogy a csapat az temtervhez kpest el!rbb jr, vagy elmaradt attl azrt, hogy gyorsan reaglhasson a kialakult helyzetre.

A Kanban nem rja el! a burndown chart alkalmazst, tulajdonkppen semmilyen grafikon alkalmazsa nincs el!rva; ugyanakkor termszetesen brmilyen grafikont (belertve a burndown chartot is) alkalmazhatunk, ha akarunk.

Nzznk egy pldt a kumulatv flow diagramra, amely azt mutatja meg, hogy mennyire kiegyenslyozott a fejlesztsi folyamatunk s a WIP-korlt hogyan hat az tfutsi id!nkre.

Ez a kvetkez!k szerint m#kdik. Minden nap adjuk ssze a Kanban-tbla minden oszlopban lv! elemek szmt, s jelentsk meg ezeket az Y tengelyen. Ezek szerint a negyedik napon kilenc elem volt a Kanban-tbln. A jobb szls! oszloptl kezdve egy elem volt az tadott oszlopban, egy a tesztelsben, kett! a fejlesztsben s t a backlogban. Ha minden nap megjelljk s sszektjk ezeket a pontokat, a fenti diagramhoz hasonlt kapunk. A fgg!leges s vzszintes nyilak mutatjk az sszefggst a WIP-korlt s az tfutsi id! kztt.

A vzszintes nyl azt mutatja meg neknk, hogy a negyedik napon a backlogba tett elem hat nap alatt jutott el az tadsig, a tesztels krlbell ez id! fele volt. Lthatjuk, hogyha a tesztels s backlog oszlopok WIP-korltjt cskkentennk, jelent!sen rvidthetnnk az tfutsi id!n.

A sttkk terlet lejtse mutatja a sebessget (rtsd naponta tadott elemek szma). Id!vel lthatjuk, hogy a nagyobb sebessg hogyan cskkenti az tfutsi id!t, mg a magasabb WIP-korlt nveli azt.


(

A legtbb szervezet gyorsabban akarja elkszteni a dolgait (= cskkenteni az tfutsi id!t). Sajnos sokan esnek abba a hibba, hogy ezt tbb ember tbb tlrztatsn keresztl akarjk elrni. ltalban a dolgok elksztsnek gyorstshoz vezet! legjobb mdszer a folyamat kiegyenslyozsa s a munkamennyisg illesztse a csapat kapacitshoz, nem pedig a mg tbb ember mg kemnyebb dolgoztatsa. Ez a diagram megmutatja hogy mirt, gy nvelve az eslyt annak, hogy a csapat s a menedzsment egyttm#kdse hatkony lesz.

Ez mg vilgosabb vlik, ha klnbsget tesznk a sorban lls (pl. tesztelsre vrakoz) s vgrehajts (pl. tesztels alatt) llapotok kztt. Teljes mrtkben minimalizlni akarjuk a sorban vrakoz elemek szmt, amihez a kumulatv flow diagram mutatja a j irnyokat.

(37

15 Scrum-tbla vs. Kanban-tbla

- egy kevsb trivilis plda A Scrumban a sprint backlog a teljes kpnek csak egy rsze az, amely megmutatja, hogy a csapat min dolgozik az adott sprintben. A msik rsze a product backlog, azon dolgok listja, amiket a product owner a tvolabbi sprintek sorn akar megvalstani.

A product owner lthatja, de nem rintheti a sprint backlogot. A product backlogot brmikor kedve szerint mdosthatja, de ennek nem lesz hatsa (legalbbis az elvgzett feladatokra) egszen a kvetkez! sprintig.

Amikor a sprintnek vge, a csapat potencilisan szllthat kdot lltott el! a product owner szmra; lezrja a sprintet, elvgzi a kirtkelst s bszkn bemutatja a product owner szmra az elkszlt A, B, C s D funkcikat. A product owner ekkor eldntheti, hogy ezek a funkcik lesbe lljanak-e, vagy sem. Ez az utols mozzanat a termk tulajdonkppeni lesbe lltsa ltalban nem rsze a sprintnek, ezrt nem is lthat a product backlogban.


(

E forgatknyv szerint a Kanban-tbla inkbb valahogy gy nzne ki:

Most az egsz workflow ugyanazon a tbln van nem csak azt ltjuk, amit egy Scrum-csapat csinl egy iterciban.

A fenti pldban a Backlog oszlop mindssze ltalnos kvnsglista, klnsebb sorrend nlkl. A Kivlasztva oszlop tartalmazza a magas priorits elemeket, ktelem# Kanban-korlttal. Teht brmely adott pillanatban sszesen kt magas priorits feladat lehet. Amint a csapat ksz egy j feladat megvalstsra, azt a Kivlasztva oszlopbl veszi ki. A product owner brmikor vltoztathat a Backlog s a Kivlasztva oszlopokban, de a tbbiben nem.

A Fejleszts oszlop (kt tovbbira bontva) mutatja, hogy mi ll fejleszts alatt, hrmas Kanban-korlttal. Hlzati terminolgival lve a Kanban-korlt felel meg a svszlessgnek, mg az tfutsi id! a pingnek (vlaszid!nek).

Mirt osztottuk kett a Fejleszts oszlopot egy Folyamatban s egy Ksz oszlopra? Azrt, hogy a telept!csapat lthassa, mely elemek llthatk lesbe.

A Fejleszts hrmas korltjn osztozik a kt aloszlop. Mirt? Tegyk fel, hogy kt elem van a Kszben:

SCRUM TBLA VS. KANBAN TBLA- EGY KEVSB TRIVILIS PLDA | 39

Ez azt jelenti, hogy sszesen egy elem lehet Folyamatban. gy tbbletkapacitsunk lesz: fejleszt!k, akik elkezdhetnnek egy j ttelen dolgozni, de nem tudnak a Kanban-korlt miatt. Ez er!s sztnz! lesz szmukra, hogy kapacitsaikat a teleptsre koncentrljk, hogy a Ksz oszlopot kirthessk s gyorstsk az ramlst. Ez hasznos s folyamatos hats, hiszen minl tbb dolog van a Kszben, annl kevesebb megengedett a Folyamatban, ami segti a csapat figyelmt a megfelel! dolgokra irnytani.

Egydarabos ramls

Az egydarabos ramls tkletes ramls, ahol egy elem halad vgig a folyamaton anlkl, hogy brhol beragadna; azaz minden pillanatban valaki ppen dolgozik rajta. Ez valahogy gy nzne ki a tbln:

Az adott pillanatban B fejleszts alatt van, A-t ppen lesbe lltjk. Brmikor, amikor a csapat ksz egy kvetkez! elem feldolgozsra, megkrdezik a product ownert, hogy melyik a legfontosabb feladat, s azonnali vlaszt kapnak t!le. Ha ez az idelis llapot hossz ideig tarthat, megszabadulhatunk a Backlog s Kivlasztva oszlopoktl, s igazn rvid tfutsi id!t kaphatunk.

Cory Ladas gy fogalmazott: Az idelis munkatervezsi folyamat mindig a legjobb elemet jelli ki a csapat kvetkez! feladatnak, nem tbbet s nem kevesebbet.

A WIP-korltok clja megakadlyozni, hogy a problmk kicssszanak a kezeink kzl, teht ha a munkafolyamat zkken!mentesen zajlik, nincs is igazn szksg rjuk.


(

Egy nap a Kanban vilgban


(


Pontosan gy kell kinznie egy Kanban-tblnak?

Nem, a fenti tbla csak egy plda volt!

Az egyetlen dolog, amit a Kanban el!r, hogy a folyamatot lthatv kell tenni, s a feldolgozs alatt lv! elemek szmt korltozni kell. A cl, hogy zkken!mentes ramlst alaktsunk ki, s minimalizljuk az tfutsi id!t; teht rendszeresen fel kell tennnk a krdst:

Milyen oszlopaink legyenek? Minden oszlop egy munkafolyamat-lpst, vagy a kt munkafzis kztt vrakoz sort jelent. Kezdjnk kevs oszloppal, s csak akkor adjunk hozz jat, ha kell.

Mekkora legyen a Kanban-korlt? Ha elrtk a sajt oszlopunk Kanban-korltjt, s nincs feladat, amit elkezdhetnnk, nzznk utna a duguls oknak (a tbla jobb oldaln sorakoz elemek), s segtsnk elhrtani. Ha nincs duguls, lehet, hogy tl alacsony a Kanban-korltunk, mivel ppen azrt vezettk be, hogy cskkentsk a sz#k keresztmetszetek tovbbtmsnek kockzatt.

Ha azt tapasztaljuk, hogy sok elem sokig ll anlkl, hogy valamilyen munkt vgeznnk rajta, meglehet, hogy Kanban-korltunk tl magas.

Tl alacsony Kanban-korlt => vrakoz emberek => gyenge termelkenysg

Tl magas Kanban-korlt => vrakoz feladatok => hossz tfutsi id!

Mennyire szigorak a Kanban-korltok? Nhny csapat szigor szablyknt kezeli !ket (azaz a korlt nem lphet! tl), msok irnyelvekknt vagy vitaindtkknt tekintenek rjuk (azaz a Kanban-limit tlphet!, de csak megalapozott s egyeztetett indokkal). Ez teht rajtunk mlik. Szltunk el!re, hogy a Kanban nem tl el!r, igaz?

(44

16 Scrum vs. Kanban sszefoglal

Hasonlsgok

Mindkett! Lean s agilis.

Mindkett! hzrendszeren alapul.

Mindkett! korltozza a vgrehajts alatt lv! feladatok szmt.

Mindkett! az tlthatsgot hasznlja a folyamatok fejlesztshez.

Mindkett! a korai s gyakori szoftverkibocstsra koncentrl.

Mindkett! nszervez! csapatokra alapul.

Mindkett!nl szksges a munka rszfeladatokra bontsa.

Mindkett! esetben folyamatosan finomtjuk a kibocstsi tervet a tapasztalati adatok alapjn (sebessg/tfutsi id!).


Klnbsgek

Scrum Kanban

Id"keretek kz szortott itercit r el".

Az id"keretek meghatrozsa opcionlis. A release-tervezs s a folyamat javts ritmusa elvlhat egymstl. Id!keretek helyett esemnyvezrelt is lehet.

A csapat elktelezi magt egy adott mennyisg# feladat elvgzsre az iterci sorn.

A ktelezettsgvllals opcionlis.

A tervezs s folyamatfejleszts alaprtelmezett mr!szma a sebessg.

A tervezs s folyamatfejleszts alaprtelmezett mr!szma az tfutsi id".

Keresztfunkcionlis csapatokat r el!.

A keresztfunkcionlis csapatok opcionlisak. Megengedi a specializlt csoportokat.

A feladatokat olyan mret#re kell bontani, hogy azok egy sprint alatt megvalsthatak legyenek.

Nincs el!rs a feladatok mretre vonatkozan.

El"rja a lefutsi diagram alkalmazst.

Nincs megkts brmilyen konkrt diagram alkalmazsra.

A WIP-korlt indirekt mdon (sprintenknt) meghatrozott.

A WIP kzvetlenl (folyamat-llapotonknt) korltozott.

El"rja a becslst. A becsls opcionlis.

Folyamatban lv" itercihoz nem adhat jabb feladat.

Brmikor hozzadhat jabb feladat, amikor rendelkezsre ll a vgrehajtsi kapacits.

A sprint backlog egyetlen meghatrozott csoporthoz tartozik.

A Kanban-tbla megoszthat tbb team vagy nll szemly kztt.

Hrom szerepkrt r el" (PO/SM/Team).

Nem r el! semmilyen szerepkrt.

A Scrum-tblt a sprintek kztt jraindtjk.

A Kanban-tbla lland.

Priorizlt product backlog vezetst rja el".

A priorizls opcionlis.


(

me, ennyi. Most mr ismerjk a klnbsgeket.

De ezzel mg nincs vge, most jn a legjobb rsz! Hzzuk fel a csizminkat, itt az ideje, hogy Mattiasszal belevessk magunkat a lvszrkokba, s megnzzk hogyan is m#kdik ez a gyakorlatban!

(47(

Msodik rsz esettanulmny Kanban a gyakorlatban

Egy trtnet arrl, hogyan tanultunk meg fejl!dni a Kanban segtsgvel. Amikor elkezdtk, alig talltunk informcit a Kanbanrl s mg dr. Google is fakpnl hagyott bennnket. Ma a Kanban sikeres, fejl!dik, s egyre tbb tuds ll rendelkezsnkre. Btran ajnlom David Anderson munkit, pldul a szolgltatsok osztlyai tmban. me az els! (s egyben utols) felel!ssghrts. Brmilyen megoldst is alkalmazunk, bizonyosodjunk meg rla, hogy az a konkrt problmk megoldst szolglja. Ennyi volt. Vgjunk bele, ez a trtnetnk

Mattias Skarin

(48(

17 Az zemeltetsi munka termszete

Aki mr volt 7/24 rs gyeletben, annak van fogalma arrl, hogy mit jelent egy les zemben lv! rendszer zemeltetsvel jr felel!ssg. A problma megoldst vrjk t!lnk akr az jszaka kzepn is , fggetlenl attl, hogy a problma forrsa nlunk van, vagy nem. Senki nem tudja, hogy mirt ppen minket hvnak. Elg nagy kihvs, mivel soha nem gyrtottunk hardvert, drivereket, opercis rendszert vagy egyedi szoftvert. A lehet!sgeink gyakran arra korltozdnak, hogy lesz#ktsk a problma lehetsges okait, cskkentsk a kvetkezmnyt, adatokat gy#jtsnk a problma reproduklhatsghoz, s vrjuk, hogy a megfelel! emberek megoldjk a problmt, aminek tani lettnk.

A kulcs: reakcikpessg s problmamegolds, gyorsasggal s pontossggal prostva.

(49(

18 Mirt vltoztassunk?

2008-ban egyik gyfelnk egy skandinv jtkfejleszt! cg tbb folyamatfejlesztsen ment keresztl. Az egyik ezek kzl a Scrum vllalati szintre trtn! kiterjesztse volt, amely sorn egyenknt szmoltk fel a fejlesztsi munkt akadlyoz tnyez!ket. Ahogy a munkamdszerek fejl!dtek s a szoftverfejleszts felgyorsult, a nyoms egyre fokozdott az !ket kiszolgl m#szaki tmogat csapaton. Korbban a m#szaki tmogats tbbnyire csak kvlr!l figyelte az esemnyeket, most viszont egyre inkbb a fejlesztsi folyamat aktv rszeseiv vlt.

1. bra. A m#szaki tmogatcsoport hrom csapatbl llt: az adatbzis-specialistkbl (DBA), a rendszer-adminisztrtorokbl s a msodik vonalbeli tmogat csapatbl.

A fejleszt!csapatok m#kdsnek javtsa tbb nem volt elg. Ha tovbbra is csak rjuk koncentrlunk, az mg tbb lemaradst okozott volna a kritikus fontossg m#szaki tmogatsi feladatokat ellt csapatoknl. Mindkett! fejlesztsre szksg volt.

A fejleszt!csapatok munkamdszereinek talakulsa az j tletek rtkelsre s elemzsre folyamatosan tbb energit ignyelt a menedzsmentt!l, ennek kvetkeztben a vezet!knek egyre kevesebb ideje maradt a feladatok prioritsainak meghatrozsra s az operatv problmamegoldsra. A vezet!sg gyorsan felismerte, hogy cselekednie kell, miel!tt a helyzet kezelhetetlenn vlik.

(50(

19 Hol kezdjk el?

J kiindulsi pont volt a fejleszt!k a m#szaki terlet vev!i megkrdezse.

A fejleszt!k vlemnye a m"szaki tmogatsrl

Megkrdeztem, hogy mi az els! hrom dolog, ami eszkbe jut a m#szaki tmogat csapatrl? A leggyakoribb vlaszok ezek voltak:

Vltoz szakrtelem A hibajegy rendszerk szvs

rtik a dolgukat, ha infrastruktrrl van sz

Mivel foglalkoznak azok a srcok?

Segteni akarnak, de igazi segtsget kapni nehz t!lk

Sok email-be kerl, mire elvgeznek egy egyszer" dolgot

A projektek tl sokig tartanak Nehz elrni !ket

Rviden ez volt a fejleszt!k vlemnye a m#szaki tmogat terletr!l. Most hasonltsuk ssze ezt a m#szakiak vlemnyvel a fejleszt!kr!l

A m"szakiak vlemnye a fejleszt!kr!l


Mirt nem hasznljk ki a platform lehet!sgeit?

Ne legyen a release-ads ekkora gy!

Mi tartjuk a htunkat a gyenge min!sg" munktok miatt!

Vltozniuk kellene a kt oldal vlemnyben ez volt a kzs. Nyilvnvalnak t#nt, hogy ezen a hozzllson kell vltoztatni, ha ki akarunk jutni a ktybl. A bztat jelekb!l rtik a dolgukat, ha infrastruktrrl van sz (annak a jele, hogy bznak a szakmai hozzrtskben) arra lehetett kvetkeztetni, hogy az !k s mi mentalits megszntethet!, ha sikerl megfelel! munkakrnyezetet kialaktani. A tlrk cskkentse s a min!sg el!trbe helyezse j kiindulsi pontnak t#nt.

(52(

20 Az induls

Teht valahogy el kell indulnunk. De hol kezdjk? Az egyetlen dolog, amit tudtunk, hogy nem ott fogunk vgezni, ahol indultunk.

Fejleszt!i mlttal rendelkeztem, teht meglehet!sen keveset tudtam az zemeltetsr!l. Nem az volt a clom, hogy berobbanjak, s mindent megvltoztassak. Sokkal kevsb konfrontatv megkzeltsre volt szksgem, ami rvilgt a fontos dolgokra, elkerli a lnyegteleneket, s knny# alkalmazsba venni.

A kvetkez! jelltjeim voltak:

1. Scrum ez mr bevlt a fejleszt! csapatoknl.

2. Kanban j s kiprblatlan, de jl passzol a Lean-alapelvekhez, amiknek hjn voltunk.

Egyeztetve a vezet!kkel, a Kanban s Lean-alapelvek ltszdtak megoldst knlni a megclzott problmkra. Megltsuk szerint a sprintekbe szervezs nem t#nt j alternatvnak, mivel a feladatok prioritsainak meghatrozsa napi szinten trtnt. Teht a Kanban ltszdott j kiindulsi pontnak, annak ellenre, hogy mindannyiunknak j llatfajta volt.

(53(

21 A csapatok elindtsa

Hogyan indtsuk el a csapatokat? Nem volt fellelhet! semmilyen kziknyv arrl, hogyan induljunk, rosszul csinlni nagyon kockzatos lett volna. Az, hogy esetleg nem sikerl fejl!dst elrni, csak egy dolog. Nagyon specilis szaktuds embereket ignyl! terleten dolgoztunk, akiket nehz lett volna ptolni, elidegenteni pedig nagyon rossz tletnek t#nt.

Vgjunk egyszer#en bele? Lesz, ami lesz?

Vagy kezdjnk egy workshoppal?

Szmunkra egyrtelm# volt: kezdjnk egy workshoppal, igaz? De hogyan? Komoly kihvs volt a teljes zemeltet! csapatot egyszerre beterelni egy workshopra (ki veszi fel a telefont, ha valami trtnik?). Vgl gy dntttnk, hogy egyszer#, feladatorientlt, flnapos workshopot szerveznk.

A workshop A workshop egyik el!nye, hogy gyorsan felsznre hozza a problmkat, emellett bizalmas kzeget teremt, ahol a klnbz! szempontokat a team tagjai gyorsan s kzvetlenl tbeszlhetik. Az igazsg az nzznk szembe vele , nem volt mindenki tl lelkes a munkamdszerek vltozsrt, de a csapat legtbb tagja nyitott volt a prblkozsra. Lebonyoltottunk egy workshopot, ahol bemutattuk a legfontosabb alapelveket, s eljtszottunk egy leegyszer#stett Kanban-gyakorlatot.


(

A workshop vgn tujjas szavazst rendeztnk, hogy lssuk a csapat hajlandsgt mindezek lesben trtn! kiprblsra. Nem volt ellenvets, teht belevgtunk. (Az tujjas szavazs [angolul Fist of Five] egy konszenzusmr! mdszer, melynek sorn minden rsztvev! a felmutatott ujjaival fejezi ki egyetrtsnek mrtkt. Egy ujj felmutatsa er!s ellenvetst jelent, t er!s egyetrtst. A hrom ujj egyetrtst jelent, de fenntartsokkal. A konszenzust akkor rtk el, ha mindenki legalbb hrom ujjt felmutatta.)

(55(

22 Az rdekeltek bevonsa

Megjsolhat volt, hogy a csapat krnyezett is rinteni fogja a Kanban bevezetse. Ezek a vltozsok az ! szempontjukbl pozitv irnyak tbbek kztt elkezdenek nemet mondani azokra a feladatokra, amiket nem tudnak elvgezni, killnak a min!sgrt, s elkezdik kitakartani a backlogbl a kevsb fontos feladatokat. Mindezek ellenre a vltozsok el!tti egyeztets mindig j tlet.

A legkzelebbi rintettek az els! vonalbeli tmogats s a csoportvezet!k voltak. Mivel rszt vettek a workshopon, mr tmogattk a vltozst; ugyanez llt a fejleszt!i csoportokra (akik tbb-kevsb egybknt is fejl!dst vrtak). A supportcsapat ugyanakkor ms volt, hiszen az ! legnagyobb problmjuk a tlterheltsg volt, !k kezeltk a felhasznli bejelentseket, s a cg elktelezte magt amellett, hogy minden felhasznli bejelentsre reagl. A Kanban bevezetsvel s a WIP-korltok betartatsval ez a helyzet j esllyel vltozs el!tt llt.

Krutat tettnk a legfontosabb rdekelteknl, s bemutattuk az elkpzelseinket, az elvrt eredmnyeket s a lehetsges kvetkezmnyeket. Megknnyebblsemre elkpzelseink alapvet!en kedvez! fogadtatsra talltak, nha a nagyszer# lesz, ha vgre megoldjuk ezeket az gyeket! megjegyzssel.

(56(

23 Az els! tbla megalkotsa

A Kanban-tbla elksztsnek j kiindulpontja az rtkfolyamattrkp felrajzolsa. Ez alapvet!en az rtkfolyamat megjelentse, ami betekintst nyjt a munkafzisokba, a folyamatba, s az ezekre fordtott id!be (ciklusid!).

De mi ennl lnyegesen egyszer#bben kezdtk: ami nem ms, mint egy, a vezet!vel kzsen paprra rajzolt minta Kanban-tblval. Nhnyszor fellvizsgltuk, majd belevgtunk. Ebben a fzisban tbbek kztt a kvetkez! krdsek merltek fel:

Milyen tpus feladataink vannak?

Ki vgzi el !ket?

Megosszuk a felel!ssget a klnbz! feladattpusok kztt?

Hogyan kezeljk a megosztott felel!ssget az adott specilis szakterletek kztt?

Mivel a klnbz! munkatpusokhoz klnbz! szolgltatsi szintmegllapodsok (SLA) tartoztak, termszetesnek t#nt, hogy minden csoport maga alaktsa ki a sajt tbljt. Maguk hatroztk meg a sorokat s az oszlopokat.

HOGYAN BECSLJNK? | 57

A kvetkez! nagy dnts az volt, hogy megosztott felel!ssget alkalmazzunk-e a klnbz! feladattpusok kztt. Hagyjuk-e, hogy a csapat egy lland rsze csak a supportfeladatokkal foglalkozzon (reaktv munka), mg a msik rsze a projektfeladatokra koncentrljon (proaktv munka)? Els!re gy dntttnk, hogy prbljuk ki a megosztott felel!ssget. A legf!bb rv emellett az volt, hogy a csapatok nszervez!dse s a csapattagok egyni fejl!dse kulcsfontossg a folyamatos alakuls szempontjbl. A dnts htrnya, hogy a supportfeladatok potencilisan brki id!beosztst megzavarhatjk, de elindulskor mg ezzel egytt is ez t#nt a legjobb megoldsnak. Egy megjegyzs: amikor a workshopot tartottuk, a csapat tulajdonkppen maga alaktotta ki ezt a megoldst. Egy embert az azonnali feladatok megoldsval bztak meg, mg a tbbiek a nagyobb gyekkel foglalkoztak.

Az els! Kanban-modell

Lent lthat az egyszer# Kanban-modell. Megjegyezzk, hogy a team dnttte el, hogy a feladatok ramlsa flfel haladjon (mint a buborkok a vzben) szemben a tipikus, balrl jobbra irnnyal.

2. bra. Ez az els" Kanban-modell. A prioritsok balrl jobbra nvekednek, a folyamat felfel halad. A feldolgozs alatt lv" feladatok szmtsa a Folyamatban sorban lv" feladatok szmnak sszege alapjn trtnik (pirossal bekarikzva). A modell kialaktst a Linda Cook ltal lert tapasztalatok befolysoltk.


(

3. bra. A rendszeradminisztrcis csapat els" Kanban-tblja.

Az alkalmazott sorok Workflow llapot (sor) Meghatrozs Backlog Azok a sztorik, amelyeket a vezet!

szksgesnek tart. Vgrehajtsra ksz Felbecslt s maximum nyolc rs

feladatokra bontott sztorik. Folyamatban A WIP-korlttal rendelkez! sor. A

kezdeti rtk a 2$[team ltszm]1 volt. (A 1 az egyttm#kds miatt.) Egy ngyf!s csapat WIPkorltja teht ht.

Ksz A felhasznl ltal futtathat.

Alkalmazott oszlopok Feladattpus Meghatrozs Release Fejleszt! csapat tmogatsa a release

kiadsban. Support Ms csapatok kisebb krsei. Nem tervezett Vratlan feladatok, melyeket el kellett

vgezni, de nem volt egyrtelm# gazdja, pl. kisebb infrastruktrajavtsok.

Projekt A Nagyobb infrastruktraprojekt, pl. egy staging krnyezet teljes hardver-kltztetse.

Projekt B Egy msik nagyobb projekt.

Nem minden Kanban-tbla volt ugyanolyan; mindegyik egyszer# vzlattal kezd!dtt, majd az id!k sorn fejl!dtt.

(59(

24 Az els! WIP-korlt belltsa

Az els! feldolgozs alatt lv! feladatszm- (WIP-) korltunk meglehet!sen nagyvonal volt. Ezt azzal indokoltuk, hogy el!bb tegyk lthatv a folyamatot s nzzk meg, hogy mi trtnik. Valszn#tlennek tartottuk, hogy els!re eltalljuk a legjobb rtket. Ahogy az id! mlik, majd minden alkalommal finomtjuk a WIP-korltot, ha j okot ltunk erre.

Az els! WIPkorlt, amit hasznltunk ez volt: 2n1 (n = a team tagjainak szma, 1 azrt, hogy el!segtsk a kommunikcit). Mirt? Egyszer#en azrt, mert nem volt jobb tletnk, s mert vdhet!nek t#nt ezzel kezdeni. A kplet egyszer# s logikus rvvel szolglt brki szmra, aki r akart er!ltetni egy feladatot a teamre: teht ha minden teamtag egyszerre kt feladattal tud foglalkozni egy aktvval s egy passzvval , mirt vrnd el t!le, hogy belekezdjen mg egybe? Visszanzve, kezdetnek brmilyen b! WIP-limit megteszi, hiszen a Kanban-tbla folyamatos ellen!rzsvel knny# menet kzben megtallni a megfelel! korltot.

4. bra. gy alkalmaztuk a WIP-korltot az adatbzis rendszeradminisztrcis csoportban: munkatpusonknt egy feladat.

Egyik tapasztalatunk, hogy rtelmetlen a WIP-korltot sztoripontokban meghatrozni, mivel tl bonyolult a kvetse. Az egyetlen knnyen


(

kezelhet! mdszer egyszer#en a feladatok szmnak kvetse (= prhuzamos feladatok).

A supportcsapat esetben a WIP-et oszlopokra hatroztuk meg, mert gyorsabb reakcira volt szksg, ha a korlt kezdett megtelni.

(61(

25 A WIP-korlt tisztelete

A WIP-korlt betartsa elmletben egyszer#nek hangzik, a gyakorlatban ugyanakkor komoly elktelezettsget ignyel. Ez azt jelenti, hogy adott esetben ki kell tudni mondani, hogy nem! Mi tbb megkzeltst is kiprbltunk.

Megvitatni a tblnl

Ha a WIP-korlt tllpst tapasztaltuk, odahvtuk az rintetteket a tblhoz, s megkrdeztk mit akartak elrni. Kezdetben a korlt tllpsnek leggyakoribb oka egyszer#en a tapasztalatlansg volt. Nha a prioritsok klnbz! szempontok szerinti rtelmezsvel tallkoztunk, aminek tipikus esete, hogy egy specialista team tagja egy specilis feladaton dolgozott. Egyedl ilyenkor jelentkeztek srldsok, de az esetek tbbsgben ott s akkor, a tbla el!tt el tudtuk simtani a problmkat.

Tlfoly terlet kijellse

Ha nemet mondani tlzottan konfrontatv, s valamelyik feladatrl lemondani nehz volt, az alacsony priorits teend!ket egy tlfoly terletre helyeztk, amennyiben tllptk a WIP-korltot. A tlfoly terletre kt szablyt alkalmaztunk:

1. Nincsenek elfelejtve, amint kapacitsunk szabadul fel, foglalkozunk velk.

2. Ha kidobjuk, rtestnk rla.

Mindssze kt ht alatt bebizonyosodott, hogy a tlcsordult elemekkel soha nem fogunk foglalkozni, teht a csapat vezet!jnek tmogatsval vgl megszabadultunk t!lk.


(

5. bra. Vzlat a tmogatcsapat Kanban-tbljrl. A jobb szls" a tlfoly szakasz.

(63(

26 Melyik feladatok kerljenek a tblra?

Hamar arra az elhatrozsra jutottunk, hogy nem rdemes minden teend!t a tblra aggatni. A Kanbant az olyan feladatok kvetse, mint pl. egy telefonhvs vagy kvzs, adminisztrcis szrnyetegg vltoztatja. Mi azrt voltunk itt, mert problmkat kellett megoldani, nem pedig jabbakat generlni. gy dntttnk, csak azok kerlnek fel a tblra, amelyek egy rnl tovbb tartanak, minden ennl kisebb feladatot fehr zajnak tekintettnk. Ez az egyrs limit aztn vgl elg jl bejtt, s egyike lett azon kevs dolognak, amelyek a ks!bbiekben vltozatlanul maradtak.

6. bra. Kezdetben azt feltteleztk, hogy a teljes kapacitsunkat f"leg kt tpus munkavgzs kti le: a nagyobbak (projektmunkk), illetve a kisebbek (supportjelleg# feladatok). A projektekre vonatkoztatott sebessg kvetse szksg esetn jelezte szmunkra a vrhat szlltsi dtumot. A fehr zaj jelenltt lland jelensgnek tekintettk (egy rnl rvidebb supportjelleg# tevkenysgek, meetingek, kv, kollgk segtse).

(64(

27 Hogyan becsljnk?

Ez lland tma, s termszetesen tbb vlasz is felmerl ennek kapcsn:

Becsljnk rendszeresen!

Csak akkor becsljnk, ha szksg van r!

Szmoljunk idelis napokban/sztoripontokban!

A becslsek bizonytalanok, ezrt becsljnk inkbb plmretekkel (kicsi, kzepes, nagy)!

Egyltaln ne becsljnk, vagy csak akkor, ha a csszs kltsge indokolja!

Scrumos befolysoltsgunk eredmnyekppen gy dntttnk (mgiscsak ezt ismertk), hogy sztoripontokkal kezdjk a becslseket. A gyakorlatban azonban a csapatok a sztoripontokat ekvivalensnek tekintettk az emberrkkal (sokkal termszetesebbnek reztk). Kezdetben minden sztorit megbecsltnk, id!vel a menedzserek megtanultk, hogyha a prhuzamos projektek szmt alacsonyan tartjk, kevsbe vrakoztatjk meg az gyfelet. Arra is rjttek, hogyha nem vrt vltozs kvetkezik be, brmikor jrapriorizlhatnak, s gy kezelhetik a problmt.

A szlltsi hatrid! szksgessge mr nem volt igazn tma tbb. A menedzserek leszoktak arrl, hogy llandan a becslsekr!l krdezzenek, csak akkor tettk ezt, ha attl fltek, hogy megvrakoztatjk az gyfelet.

Valamikor az elejn az egyik menedzser, bestresszelve egy telefonhvstl, meggrte, hogy a projektet a ht vgig leszlltjuk. Mivel a projekt fenn volt a Kanban-tbln, az elvgzett sztorik alapjn knnyen meg lehetett becslni a halads folyamatt, s gy arra a kvetkeztetsre jutottunk, hogy egy ht alatt huszont szzalkot teljestnk, gy tovbbi hrom htre van szksg a befejezshez. Ezzel a tnnyel szembeslve a menedzser azonnal megvltoztatta a projekt prioritsait, lelltotta a prhuzamos munkkat, gy lehet!v tette az grt szlltst. Mindig figyeljk a tblt!

HOGYAN BECSLJNK? | 65

Mit jelent a becslt mret? tfutsi id!t vagy munkart?

Sztoripontjaink a munkarkat tkrztk, azaz azt, hogy hny megszakts nlkli rarfordtst vrunk egy sztori befejezshez, s nem pedig az tfutsi id!t (naptri id!intervallumot vagy eltelt rt). Azzal, hogy mrtk, hny sztoripontot teljestnk egy ht alatt (sebessg), kvetkeztetni tudtunk az tfutsi id!re.

Mindenegyes j sztorit csak egyszer becsltnk, s a megvalsts sorn soha nem korrigltuk a becslsnket, ezzel cskkentettk a csapat ltal becslsekre fordtott id!t.

(66(

28 Hogyan dolgoztunk a valsgban?

A Kanban tnyleg nagy szabadsgot biztost, ezrt brmilyen mdon alkalmazhatjuk. A csapat dolgozhat id! szerinti temezsben vagy esemnyvezrelten, pldul arra reaglva, ha adott mennyisg# feladat sszegy#lt.

7. bra. Ha hrom elem sszegy#lt a backlogban, tervezs-/ becslsmegbeszlst tartunk.

gy dntttnk, kt ismtl!d! esemnyt tartunk rendszeresen:

Napi standup a csapattal a tbla el!tt azrt, hogy felsznre hozzuk a problmkat s tlthatv tegyk egyms feladatait.

Heti itercitervezs a tervezs s folyamatos javts fenntartsa rdekben.

HOGYAN DOLGOZTUNK A VALSGBAN? | 67

Ez nlunk bevlt.

Napi standup

A napi standup a Scrumhoz hasonlan zajlott. Ezt a napi Scrum of Scrums megbeszls utn tartottuk, ahol minden team kpviseltette magt (fejleszts, tesztels, zemeltets). A Scrum of Scrums egyeztetsek rtkes informcival szolgltak a Kanban-csapatok szmra arrl, hogy mely problmkat kell els!nek megoldani, melyik team van a legnagyobb bajban. Kezdetben a menedzsment rendszeresen ltogatta ezeket a megbeszlseket, megoldsi javaslatokat tettek s priorizcis dntseket hoztak. Id!vel, ahogy a csapatok egyre tapasztaltabbak s nllbbak lettek, ritkbban jelentek meg (de szksg esetre mindig a kzelben voltak).

Itercitervezs

Hetente egyszer itercitervezst tartottunk, minden hten ugyanabban az id!pontban, mert ha nem volt el!re betervezve, valami fontosabb mindig elvitte az id!t, neknk viszont tbb kommunikcira volt szksgnk. A tipikus menetrend a kvetkez! volt:

Grafikonok s a tbla aktualizlsa. (A befejezett projektek a Kszek falra kerltek.)

Visszatekints az el!z! htre: Mi trtnt? Mirt gy trtnt? Mit tehetnk, hogy javtsunk ezen?


(

A WIP-korltok hangolsa (ha szksges).

Feladatlebonts s j projektek becslse (ha szksg volt r).

Az itercitervezs tulajdonkppen becslsi s folyamatfejlesztsi impulzusok keverke volt. A kicsi s kzepes gyeket az els! vonalbeli vezet!k tmogatsval helyben orvosoltuk, a komplexebb infrastruktraproblmk megoldsnak kvetse mr lnyegesen nagyobb megprbltatst jelentett. ppen ezrt bevezettk, hogy minden csapat maximum kett! akadlyoz tnyez! megoldst oszthatta ki a vezet!je szmra.

(A szablyok ezek voltak:

1. A vezet!k egyszerre kt problmn tudnak dolgozni.

2. Ha mindkt hely betelt, j feladatot akkor lehet kihelyezni, ha a kevsb fontosat levettk.

3. A csapat dnti el, mikor tekinti megoldottnak a problmt.

Ennek nagyon pozitv hatsa volt, mivel a csapatok lthattk, hogy a vezet!k mellettk llnak, mg a kemny problmk megoldsban is. Rmutathattak a problmra, s megkrdezhettk hogy halad?. Nem

kanban és scrum mindkettőből a legjobbat

Documents