Scrum tapasztalatok II.

Fogalmak

A scrum fogalmakra találtam egy leírást, nem másolom ide, érdemes átnézni. Arról valószínűleg mindenkinek (aki ezt a blogot olvassa) kialakul egy kép, hogy mi a napi standup, mit csinál a scrum master. Ezért megpróbálok olyanról írni, ami kicsit "különös".

Taskok, story-k, backlog

A megszokott (TFS, JIRA stb) feladat leírásoktól kicsit eltér a scrum-os felfogás. A task-okat eleve nem becsüljük meg hogy mennyi idő, és nem a "főnök" osztja ki őket, hanem a fejlesztők válogatnak belőle. A task-ok story-ba vannak szervezve, egy ilyen story egy adott funkciót ír le. Alap, hogy funkció szerint vannak csoportosítva a feladatok. Példa: story a helyettesítés kezelése, annak vannak olyan task-jai mint pl adatbázis táblák kiegészítése, entitások kiegészítése, funkciókhoz helyettesítés bekötése, helyettesítési logika, stb.

Egy sprintben a sprint indító megbeszélésen meghatározott, backlog-ból összeválogatott story-k szerepelnek, prioritás szerinti sorrendben. Ami nekem itt fura volt, hogy sehol nincs megbecsülve, hogy mi mennyi ideig fog tartani. Egyetlen becslés van, ami a story-ra vonatkozik, erről a következő bekezdésekben.

Sprint zárás

A sprint záró meeting egy egész délutános elfoglaltság, amin minden fejlesztő részt vesz, a scrum masterrel és a product ownerrel. Az első szakasz arról szól, hogy bemutatjuk a product ownernek az elkészült funkciókat, és ő elfogadja azt (rosszabb esetben csak részben fogadja el). Ezután a csapat közösen összeállít egy listát az elmúlt sprint sikeres jellemzőiről (pl elkészült az adatbázis réteg, kevés hiba volt a release-ben, bővült a csapat stb.), és az összegyűjtöt pontokra mindenkinek kell szavazni. Ennek az az eredménye, hogy lesz egy 5-7 elemű lista, amiből egy szavazás után kettőt-hármat kiemelünk, és látjuk hogy mi volt nagyon tuti. Ugyanez a másik irányra, 5-6 pontban összeszedve hogy mit érzünk problémásnak(kevés unit teszt készült, kiesett 2 ember a csapatból, 3 napig tartott a telepítés). Ezeket megszavazva megint kijön 2-3 olyan pont, ami a sötétebb oldalt jellemzi. Ezekre akciótervet kell létrehozni, megoldási javaslatot, hogy hogyan lehet ezen segíteni.

Tömören ennyi szól az előző sprintről, ez a zárás.

Sprint indítás

Összeválogatjuk, hogy mi legyen benne a következő sprintben. Megnézzük, hogy az előző sprintből milyen story nincs kész, azokat átrakjuk a következőbe, behúzunk újakat a backlog-ból, és átbeszéljük, melyik miről szól. Nem becsüljük meg, hogy mennyi idő, hanem szavazunk.

A szavazás:

Nem idő alapon becsüljük a feladatokat. Poker-nek hívják azt, amikor a sprint indító megbeszélésen a fejlesztők megszavazzák, hogy egy adott story milyen bonyolultságú. Ez amolyan érzésre megy, előző becslések alapján. Fibonacci számsorból kell mondani egy számot (0, 0.5, 1, 2, 3, 5, 8...), amilyennek az adott story komplexitását érezzük. Furán hangzik, de az első 2-3 sprint után rááll az ember agya, és megérzi. Mindenki szavaz egy számra (úgy hogy egymás szavazatát nem lehet látni csak a szavazás végén), és amelyik a legtöbb szavazatot kapja, az nyer. Akik túl sokat vagy túl keveset becsültek, megindokolják hogy szerintük miért, és elkezdődik egy vita, majd ha sikerül meggyőzni egymást, módosítanak az értékeken.

Miután megvannak a poker eredmények (elég hülye név ez hogy poker, de ezt találták ki neki), összeadjuk a story-k megpokerezett mérőszámát. Ha túl sok, és érzésre nem fér bele a sprintbe (előző sprinteknek ugyebár van teljesített mérőszáma, pontszáma), akkor újrapriorizáljuk a feladatokat, és a kiesőket áttoljuk a következő sprintbe.

Ha ez megvan, akkor jöhet a "taskosítás", amikor lebontjuk konkrét task-okra a story-kat.

A lényeg: minden sprint végén egy működő, stabil release-nek kell előállni, amit ki lehet vinni az ügyfélnek mutogatni. Ne legyen benne félkész funkció (tele server error-al)! Hibák lehetnek, de hát ugye azok mindig vannak. Az ügyél nagyon szereti látni kéthetente, hogy megint volt haladás, szereti kattintgatni, próbálgatni. Ilyenkor persze egy csomó minden eszébe jut, és van hogy nagyon jókor, időben rájön hogy neki mégsem lesz az úgy jó ahogy először akarta (nameg van amikor elkezd álmodni, képzelegni, hogy milyen jó lenne ha, de a product owner feladata ezeket kezelni).

Tehát az ügyfél nagyon szereti látni, hogy mi készül a pénzéből, szeret hozzászólni, szereti nyomkodni, próbálgatni. Azt hiszem hogy a közelmúltban egy igen nagy projekt elsősorban azon bukott meg, hogy akinek készült, csak folyamatos tervezést látott, kézzel fogható eredményeket pedig nem.

folyt. köv.