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, az Easel vállalatnál. A módszertan egyre népszerűbb, ami Ken Schwabernek, valamint a Scrum Alliance (www.scrumalliance.org) 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; piramisszerűen skálázva nagyobb - akár multinacionális - csapatok esetén is bevethető.
A módszer sokkal emberközpontúbb, mint például a poroszos V-modell: mindenki osztozik felelősségben és sikerélményben egyaránt, és nincsenek beégetett felelősségi körök.

A SCRUM két szerepkör-csoportot definiál: "csirkék" és "malacok" - a következő viccből kiindulva (az eredeti, angol nyelvű változat a cikk végén szereplő wiki oldalon olvasható):

"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.
  
  Megjegyzés
  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 (pl. vízesés- vagy V-modell) 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.

 Megjegyzés

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 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.
  
  Megjegyzés
  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.

Megjegyzés
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.

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".
   
   Megjegyzés
   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.
   
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.

Megjegyzés
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.

Burndown chart

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.
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ó.