Korábbi bejegyzésünkben az agilis irányzatokat, valamint a Scrum módszertant mutattuk be. Jelen írással a Sprint Tervezés ceremónia sikeres lebonyolítását szeretnénk segíteni, azon belül is azok számára szeretnénk támogatást adni, akiknek még nincs nagy gyakorlata ezzel kapcsolatban.
Ez a forgatókönyv csupán egy opció, gyakorlott Scrum csapatok más eszközöket, más menetrendet is követhetnek.
SPRINT TERVEZÉS CÉLJA
Az események kapcsán az első és legfontosabb dolog a célok meghatározása. A Sprint Tervezés célja, hogy
- összeálljon, és definiálásra kerüljön a Sprint Backlog
- készüljön egy terv annak végrehajtására, bemutatására, valamint
- a Scrum Csapat összes tagja elköteleződjön annak a teljesítésére.
Ahhoz, hogy a Sprint Tervezés sikeresen megvalósuljon, szükség van inputként a Product Backlogra, valamint a Product Owner által kijelölt Sprint Célra. A ceremónia végtermékeként jó esetben létrejön a Sprint Backlog és az annak végrehajtására szolgáló terv. A Scrum Csapat valamennyi szereplőjének ajánlott részt vennie az eseményen, a Fejlesztőcsapatnak, a Scrum Masternek és a Product Ownernek is.
A SPRINT TERVEZÉS HOSSZA
Sokszor felmerül a kérdés, hogy ezt a találkozót milyen időtartamban célszerű megtartani? A Sprint Tervezés ajánlott hossza relatív a Sprint hosszhoz képest. Mi hüvelykujjszabályként azt szoktuk alkalmazni, hogy a Sprint hetekben kifejezett hosszának kétszerese legyen órában kifejezve. Például egy 2 hetes Sprint esetén törekedjünk a tervezést 4 órában megvalósítani.
Ezt a ceremóniát gyakran nem egyszerű hatékonyan levezényelni, véghezvinni. Tapasztalataink szerint mind a Fejlesztőcsapatoknak, mind a Scrum Mastereknek segíthet, ha az alábbi 8 lépés mentén próbálnak tervezni.
1. lépés: Sprint hosszának meghatározása
A Sprint Tervezés egyik fontos eredménye, hogy meghatározásra kerül a Sprint Review (demo) napja. El kell tehát dönteni, hogy a Sprint milyen hosszú legyen. Mivel az agilis irányzatok jellemzően time-box-szal (időkorlátokkal) operálnak, tehát az idő és költség dimenzió fix, ennek meghatározása kritikus. Így érhető el, hogy a csapat megbecsülhesse, hogy mennyi munka valósítható meg a Sprint időtartama alatt.
Az, hogy mi a megfelelő hossza egy Sprintnek, teljes mértékben projektfüggő. A Product Ownerek általában rövid Sprinteket szeretnének, a fejlesztőcsapatok pedig hosszabbakat. Ajánlott egy kis kísérletezés a Sprint hosszának a meghatározásához, azonban túl sok időt nem érdemes a kutatásra szánni, induljunk egy kényelmesnek gondolt idővel, majd változtassunk rajta, hogyha szükségét érezzük. Amennyiben megtaláltuk a megfelelő Sprinthosszt, akkor érdemes hosszabb távon ehhez ragaszkodni, hogy a Scrum Csapatba beépüljön ez a ritmus.
2. lépés: Kapacitástervezés
A hiteles, vállalható tervhez elengedhetetlen, hogy ismerjük a kapacitásunkat az adott Sprintre. A csapat tagjainak érdemes végig gondolniuk a szabadságokat, más projektek terheléseit és elfoglaltságaikat a Sprint során, tehát hogy ki, mikor és hogyan áll rendelkezésre a csapatból a Sprint során.
3. lépés: Sprint Cél meghatározása
A Scrum Csapat motivációjához és a közös munka segítéséhez járul hozzá a Sprint Cél. Egy hajóban evezünk, de nem mindegy, hogy ki melyik irányba húzza. A cél definiálását a Product Ownertől várjuk. Esetleg, ha nincs még cél definiálva, feltehetjük a Product Ownernek a kérdést, hogy „Miért ne menne mindenki szabadságra a következő Sprintben?”. A cél indokolja meg azt, hogy miért is csináljuk ezt a Sprintet, miért jönnek be az emberek a munkahelyre, ezért fontos, hogy a Product Owner előálljon vele.
4. lépés: Beszélgetés a Product Backlog elemekről, beválogatás a sprintbe
A Product Backlogban lévő legmagasabb prioritású elemeket kezdi el vizsgálni a csapat, amik a Sprint Cél teljesítéséhez szükségesek. A vizsgálat egy párbeszéd a Scrum Csapaton belül, aminek célja, hogy mindenki számára egyértelmű legyen, hogy az adott Backlog elem miről szól. A Backlog elemekről korábban írtunk, ezek leggyakrabban Epicek, User Story-k, Spike-ok, de lehetnek akár Feature-ök vagy például Use Case-ek is. Ezek alkalmazása sok helyen eltérő, de minden esetben fontos, hogy a csapat egységesen értelmezze és alkalmazza őket.
A párbeszédnek fontos része, hogy a Backlog elemek elfogadási kritériumát, azaz a specifikus elvárásokat tisztázzák. Ha mindenki számára egyértelmű a Backlog elem, akkor születhet döntés arról, hogy bekerüljön-e az elem a Sprint Backlogba, azaz a Sprint terjedelmébe. Itt fontos szerepet játszik a Velocity, a csapat fejlesztési sebessége, hiszen ez alapján tudjuk a csapat kapacitását becsülni, feltölteni.
Ha a csapat most indul és nincs még tapasztalat a Velocity-vel kapcsolatban, akkor érdemes óvatosan, józan paraszti ésszel megtippelni a csapat kapacitását. Nem cél, hogy az első Sprint sikeres legyen és egyből eltalálják a megfelelő Velocity-t, ez hosszabb távon (jellemzően 2-3 Sprint) ki fog alakulni és a tapasztalatok alapján beáll.
5. lépés: Definition of Done felülvizsgálata és módosítása
A Definition of Done felel a Scrum Csapat munkájának minőségéért, hiszen ez alapján tudja a csapat eldönteni, hogy az adott elemet késznek gondolják-e vagy sem. Ezt minden Sprint előtt érdemes vizsgálni és felül kell írni, hogyha ennek szükségességét hozza egy visszajelzés vagy egy új követelmény.
6. lépés: Taskok, feladatok tervezése
A tervezés, feladatokra, ún. Taskokra bontás felemésztheti a Sprint Planning időtartamának akár felét is. Itt a csapatnak minden egyes beválogatott Backlog elemre készítenie kell egy megoldási tervet. Itt érdemes lehet a kritikus utakat és a függőségeket is azonosítani annak érdekében, hogy világos legyen, hogy melyik Taskokon csúszhat el a Sprint, illetve, hogy a csapattagok ne tegyenek keresztbe egymásnak. A Taskokat érdemes időre becsülni és felosztani egymás között. Az időbecsléssel vissza lehet mérni, hogy tényleg belefér-e az adott Sprintbe a bevállalandó munka.
Fontos számolni a megbeszélésekkel és egyéb olyan teendőkkel is a Sprint során, amik időt vesznek el a fejlesztésből. Egy bevált módszer a „Planning Glass” eszköz, ahol rajzolunk egy nagy poharat, aminek kapacitása megegyezik a Sprint kapacitásával (órában mérve) és elkezdjünk „beleönteni” a Taskok, megbeszélések, puffer idők és egyéb teendők időtartamát. Ha a pohár túlcsordul, akkor szabni kell valamennyit az eddig beválogatott Backlog elemeken, vagy akár a Sprint Célon.
Fontosabb a fenntartható fejlesztés, mint a túlórákkal elért maximalista célok. Számoljunk utána, ha csupán a ceremóniák idejét, a kávé és ebédszüneteket levonjuk a napi tervezett munkaidőből, egy kéthetes Sprint során jó esetben nettó 6 nap marad a tényleges munkára. A nettó fejlesztési idő nem napi 8 óra (amivel a szponzorok, megrendelők szeretnek kalkulálni), ez inkább napi 4 órára jön ki.
7. lépés: A csapattagok terhelésének vizsgálata
A Taskok betervezése után nézzük meg, hogy nincs-e valaki túlterhelve a csapaton belül, próbáljuk egyenletesen igazítani a terheléseket. A csapat jól felfogott érdeke, hogy ne legyenek a rendszerben potyautasok vagy irreális vállalások.
8. lépés: Elköteleződés a terv iránt
Az egész eddigi munka akkor ér valamit, hogyha a teljes csapatot a hajóban tudjuk, mindenki érti és el is kötelezi magát a tervhez, ami előállt a Sprint Tervezés végére. Itt még mindig lehet tisztázni feltételezéseket, félreértéseket.
Testreszabhatóság
Nem győzzük hangsúlyozni, hogy a fenti lépések iránymutatásként szolgálnak, ez nem egy kőbevésett recept a sikerre. A ceremóniák menetét, beleértve a Sprint Tervezést is, a csapat magára szabja, tehát a Retrospektívek során azonosított tartalékok folyamatos javítása mellett ezek alakulhatnak, változhatnak. Ennek a fejlődésnek az egyik motorja a Scrum Master, aki megfelelő eszköztárral és szemlélettel segíti a csapatot a hatékony működésben.
Fontos továbbá, hogy projektszempontból nem a Sprint Tervezéssel indul a folyamat. A Sprint Tervezést egy sor olyan lépésnek meg kell előznie, ami értelmet ad a Sprintek alkalmazásának. Célszerű tehát azonosítani a felhasználókat, a vélt igényeket, továbbá a megalapozott projekt indítás érdekében megtérülés számításra is szükség lehet. Ennek a folyamatnak a mozgatórugója a Product Owner, aki a csapat aktív bevonásával és a Scrum Master támogatásával a „projektálmot” képes egy release tervezésen keresztül eljuttatni egy konkrét termék definiálásig, azaz a Product Backlogig, a priorizált követelménylistáig.
Képzési lehetőségek
Amennyiben további tapasztalatot szerezne és szívesen megismerne a Scrum Master teendőivel kapcsolatos más módszereket is, jó szívvel ajánljuk gyakorlati Scrum Master képzésünket, ahol a Scrum Master teendőit egy konkrét projekt során végezzük el a résztvevőkkel, akik így megtapasztalhatják a leggyakrabban felmerülő kihívásokat, buktatókat és azok kezelésének lehetőségeit.
Product Ownerek, projektmenedzserek számára pedig gyakorlati Product Owner képzésünket ajánljuk, amely során agilis környezetben és eszközökkel juttatunk el egy konkrét projektötletet a fejlesztésig.
Designabc