Nem csak a rögbiben működik!
A SCRUM egy agilis szoftverfejlesztési módszertan, amelyet Jeff Sutherland, John Scumniotales és Jeff McKenna fejlesztett ki 1993-ban, az Easel vállalatnál. A módszertan egyre népszerűbb, ami Ken Schwabernek, valamint a Scrum Alliance tevékenységének is köszönhető. Sikeréhez az is hozzájárul, hogy egy demokratikus, rugalmas, felelősség- és eredményközpontú megközelítést alkalmaz.
Elsősorban kis csapatok (5-9 fő) esetén alkalmazható jól, de némi fantáziával és leleményességgel egyemberes project esetében is működik.
A módszer sokkal emberközpontúbb, mint más, jól bejáratott és szokványos modellek (V-modell, vízesés-modell): itt mindenki osztozik felelősségben és sikerélményben egyaránt, és nincsenek beégetett felelősségi körök. Ha valaha is úgy érezted, hogy túl sok a kis és nagyfőnök, akkor ezt a megközelítést imádni fogod!
A SCRUM két szerepkör-csoportot definiál: “csirkék” és “malacok” – a következő viccből kiindulva:
“A malac és a csirke együtt sétálgatnak. A csirke kisvártatva megszólal:
– Figyelj, mi lenne, ha beindítanánk közösen egy gyorsbüfét?
A malac felkapja a fejét az ötletre:
– Benne vagyok! Már csak valamilyen frappáns menüt kellene összehozni!
A csirke rávágja:
– Mit szólnál például a sonkás rántottához?
A malac rövid gondolkozás után ezt válaszolja:
– Inkább hagyjuk az egészet, ez a buli mégsem érdekel annyira…”
Lássuk a “malacokat” – tehát azokat a résztvevőket, akik mindent “beleadnak” a projectbe:
A termékgazda (Product Owner)
A termékgazda a megrendelőt képviseli, akivel – jó esetben – folyamatosan tartja a kapcsolatot, egyeztet és tisztázza a követelményeket. A tevékenységének a végeredménye a fontossági sorrendbe állított tennivaló-lista, avagy a “Product Backlog”.
A ScrumMaster
Elsődleges feladata az akadályok elhárítása, ezzel elősegítve a csapat zavartalan munkáját a közös cél elérése érdekében. (Példa: amennyiben az egyik csapattagnak sok projecten kívüli tevékenysége van, akkor elintézi, hogy mentesüljön ezek alól.) A másik fontos szerepe a Scrum folyamatainak betartatása.
A félreértések elkerülése végett: a ScrumMaster nem “főnök”, ugyanolyan csapattag, mint a többi szereplő – bár egyesek hajlamosak ezt félreérteni és hibásan alkalmazni. Ez valószínűleg annak tudható be, hogy más, kevésbé “demokratikus” módszertanokban hierarchikus megközelítést alkalmaznak, és ezek elterjedtebbek, mint a SCRUM.Gyakorlatilag nincs klasszikus értelemben vett “főnök”, csak egyfajta mentor – a már említett termékgazda -, illetve moderátor – a SCRUM master.
A csapat (Team)
A csapat felelős a kitűzött cél eléréséért, végezetül a termék leszállításásért. Általában 5-9 fő az ideális csapatméret – illetve nagyobb létszám esetén ilyen méretű SCRUM-teamekre érdemes osztani az embereket. Különböző szakterületeket lefedő képességekkel rendelkező emberekből ajánlott összeállítani a csapatot, úgy mint: rendszertervező, fejlesztő, tesztelő, minőségügyis szakember.
Természetesen lehetnek átfedések a szaktudást illetően, sőt! Nem titkolt cél annak elérése, hogy mindenki kóstoljon bele kicsit a többi szakterületbe. Ez ismét furcsa lehet, bár nagyon is ésszerű hozzáállás egy kis méretű csapat esetében, ahol nincs lehetőség helyettesek biztosítására; ezért kifejezetten jól jön, ha például a felhasználói felületet vagy a pályaeditort fejlesztő kolléga megbetegedése esetén sem áll meg az élet.
A “csirkék” – azaz azok a szereplők, akik a szó szoros értelmében ugyan nem vesznek részt a projectben, mégis figyelembe kell venni őket:
A Felhasználók
Nekik készül a termék, ezt jobb szem előtt tartani.
Léteznek nagyszerű szoftverek, amelyek mérnöki szempontból nagyszerű alkotások, azonban látszik, hogy nem vették figyelembe a tényleges felhasználói igényeket (aki használta már a Blender-t, az tudja, miről beszélek! ;))
Ügyfelek, forgalmazók, támogatók, üzleti elemzők (Stakeholders)
Ők azok, akik érdekeltek a végtermékben, esetleg a SCRUM folyamatban, azonban nem vesznek részt a fejlesztésben. Ebbe a csoportba tartozik például a vevő vagy a külső szakértők.
Az agilitás egyik fő jellemvonása, hogy bevonja a vevőket és az üzleti szereplőket a folyamat bizonyos részeibe. Azáltal, hogy érdekeltté tesszük őket a készülő termékben, hasznos információkhoz juthatunk.
Némileg adaptálva, a garázsprojectek esetében ez leginkább annak felel meg, amikor megfelelő fórumokon demókat bocsájtunk közszemlére, és figyeljük a visszajelzéseket. Jótanács: számítsunk a negatív kritikára, és ne legyük sértődősek.
Rövid (általában egy hónapos), sprintnek nevezett szakaszokban folyik a fejlesztés. A sprint három szakaszból áll:
1. Sprint megtervezése (Sprint Planning)
A tervezési értekezleten az egész csapat részt vesz, és megtervezi a sprint céljait. Az alap a Product Owner kívánságlistája, azaz a korábban említett, tennivalókat tartalmazó lista (“Product Backlog”). A lista az újabb fejlesztési igényeket, illetve az előző sprint eredményében talált hibákat tartalmazza.
A tervezés során a csapat kiválasztja azokat a feladatokat, amelyeket bevállalhatónak tart a fennmaradó időszakra. Az összetettebb feladatokat a termékgazdával egyeztetve részfeladatokra, kisebb fejlesztésekre bontják, amelyek beleférnek a viszonylag rövid sprint időszakba. Időnként a sprint-tervezési folyamat belassulhat – például az összetettebb feladatok szétbontása, az elvárások pontosítása miatt – ezért nem ritka, hogy egy sprint megtervezése akár két napot is igénybe vesz.
A tervezés végére létrejön – közös megegyezés alapján – egy részletes, lebontott akciótervvel, időbecslésekkel ellátott feladatlista. Ez az úgynevezett “Sprint Backlog”.
Rossz jel, ha a feladatlista két napnál hosszabb feladatokat tartalmaz – az ilyen monolitokat ajánlott jobban szétbontani. A “nagy falatok” arra utalnak általában, hogy a teendő nem elég világos, és ebből szinte biztosan adódnak problémák. Persze vannak kivételek, de tapasztalataim szerint ilyenkor érdemes kielemezni a témát.
Egyszemélyes project esetén is kell tervezni, hiszen itt a legfontosabb a precizitás és az önfegyelem.
2. A sprintcélok megvalósítása
Következik a megszakítás nélküli közös munka, amikor a csapat a munkára koncentrálva megvalósítja a sprint céljait. (A zavaró tényezők kivédése a Scrum master feladata.)
A gyakorlatban ez úgy néz ki, hogy mindenki magához vesz egy feladatot a sprint backlog-ból, majd ha befejezi, jöhet a következő, gazdátlan teendő.
A haladásról a naponta megtartott, negyedórás összejöveteleken számolnak be egymásnak: ez az úgynevezett “daily scrum”, ahol a fejlesztők kizárólag három kérdés megválaszolására szorítkoznak:
– Mit csináltál az előző “daily scrum” óta?
– Mit csinálsz ma?
– Akadályozza valami a munkádat?
A megoldási javaslatokat, részletekbe menő vitákat kerülni kell ezeken az összejöveteleken – ennek kivédése a SCRUM master feladata. A kérdések tisztázását a daily scrumot követő megbeszélésen ajánlott megejteni, lehetőleg kizárólag az érintett felek bevonásával. Itt érvényesül a “szabad lábak” elve, azaz bárki távozhat, akit nem érint a tisztázandó témakör.
A “daily scrum” feladata, hogy minden csapattag értesüljön a project előrehaladásáról, a sikerekről és az esetleges gondokról egyaránt. A gyakorlatban (szoftveres) eszközök segítenek a statisztika karbantartásában – ez lehet speciálisan kifejlesztett célszoftver, azonban az Excel is megteszi.
Kifejezetten motiváló lehet – nálunk legalábbis bevált – az úgynevezett “burndown chart”, amely az elvégzendő és a már elvégzett feladatokat követi és ábrázolja grafikusan.
Mindez az információ-áramlást biztosítja, ugyanakkor rosszul alkalmazva gátolhatja a hatékony munkát. Nem az a cél, hogy a nap nagy részében megbeszéléseken pazaroljuk el az időnket, hanem hogy ésszerű keretek közt információt cseréljünk egymással.
Egy másik, gyakori tévedés a “daily scrum”-ot munkaindítóként felfogni: a megbeszélés előtt is illik dolgozni.
A daily scrum egy nyilvános fórum, azaz bárki részt vehet rajta. Fontos szabály azonban, hogy kizárólag a csapat tagjai szólalhatnak meg.
3. Sprint bemutató, elemzés
Minden sprint végén fel kell mutatni valamilyen eredményt – lehetőleg egy működő, látványos terméket (amolyan “demózás” a megrendelő számára).
Ez az úgynevezett “sprint review”. Több szempontból is hasznos ez a megoldás, hiszen:
– látszata van a közös munkának,
– a megrendelő figyelemmel kísérheti a termék alakulását
Ezáltal nem csak a project késői szakaszában (legrosszabb esetben a végén) derül ki, hogy egyáltalán nem azt hoztuk össze, amit a vevő eredetileg szeretett volna (biztosan sokan ismeritek a hintás analógiát). Ilyesmi pedig sűrűn előfordul, a megrendelő ködös igényeinek vagy a tervezők, UI-designerek tévedései miatt.
A retrospektív elemzés azt szolgálja, hogy az esetleges hibákból okulva leszűrjük a következményeket.
Három lényeges kérdésre válaszolnak ilyenkor a csapat tagjai:
– Mi volt jó a sprint során?
– Mik voltak a negatívumok?
– Hogyan lehet javítani a problémás területeken?
Nem az ujjal egymásra mutogatás a cél, hanem a fejlődés!
Mivel a SCRUM előfeltétele a szabad információáramlás, nagyon ajánlott a csapattagokat egy közös térbe szervezni.
GP esetében ez nem mindig működik, de szerencsére létezik számos lehetőség a hatékony kommunikációra akkor is, ha nem dolgozunk egy irodában.
A fejlesztés eredményeit követhetővé kell tenni; ehhez szükséges a folyamatos integráció és a tesztelés. Ezzel biztosíthatjuk, hogy az alkalmazás nem romlik el, és emiatt ajánlott – bár talán inkább kötelező – a tesztvezérelt szoftverfejlesztés (Test Driven Development) alkalmazása . Az utóbbi témakört egy következő cikkben részletezem.
A SCRUM-ban talán a határidők kezelése a legszimpatikusabb: a határidő szent és sérthetetlen. Nem lehet eltolni, tehát ami nem készült el, azt becsületesen, problémaként szerepeltetjük a review-n.
A megvalósíthatatlan követelményeket így viszonylag gyorsan (akár egy-két sprint után) ki lehet dobni, nem csak több hónapos megbeszélés-sorozat, tervezés és kódolás, tesztelés után, ahogy az más módszertanoknál előfordulhat.
Természetesen a SCRUM sem tökéletes megoldás mindere, azonban könnyű megszeretni, és rövidebb (< 1-1,5 év) projectek megvalósításához véleményem szerintem kiváló.
Nyisztor Károly (Carlos)
Jatekfejlesztes.hu – 2008