Scrum gyorstalpaló

infokukac.com/2009/12/scrum-gyorstalpalo

By Marhefka István 2009. 12. 07.

A céges projektünk lassan 3 éve tart. Az első évben szenvedtünk. Állandóan a

projekttervet próbáltuk karbantartani: feladatokra bontottunk, ütemeztünk, erőforrásokat
terveztünk. Ezt az akkori projektteamből 3 ember végezte (közülük én voltam az egyik).
Hiába próbáltuk up-to-date tartani a projekttervet, és frissítettük rendszeres
időközönként, az újabb és újabb projekttervek is néhány nap múlva szétcsúsztak.

Pár hónap alatt eljutottunk oda, hogy semmit nem ér az egész. Semmit nem lehet előre
tervezni és jelezni, ráadásul sok időt visz el a tervezés. Jött az ötlet, próbáljuk ki a Scrum-
ot. (Csuti hozta az ötletet.) Akkor a fejlesztői csapat még nem hallott róla, ezért
elolvastunk az Infoq-n egy elég jó összefoglalót. Ez egy emészthető bevezetés a Scrum-ba,
gyakorlati megközelítéssel. Utólag 2 év “Scrumozás” után az a véleményem, hogy bőven
elég volt ezt az egy ismertetőt elolvasni. Ez alapján el lehet indulni.

Azonban sokszor nem elegendő a tehetséges fejlesztői csapat lelkesedése. A vállalati

kultúra részéve kell tenni a Scrumot, támogatást kell szerezni a cégen belül, hogy egy
csapat sikeres lehessen. A csapatnak segíteni kell abban is, hogy megtanulhassa önmagát
kezelni. Ma már vannak itthon is gyakorlati tapasztalattal rendelkező tanácsadók, akik
talán segíthetnek egy-két kezdeti buktatót elkerülni, például Csuti is ezzel foglalkozik.

Szeretném leírni, hogy mi mit értünk Scrumon, mit jelent nekünk az egész, és mi mit
hogyan csináltunk. Először – azok kedvéért, akik nem jártasak a Scrum-ban – egy gyors
összefoglalót írok.

A product backlog
Ahhoz, hogy a fejlesztés Scrum szerint elindulhasson, szükség van az ún. product
backlog-ra. Ez tartalmazza az összes még le nem fejlesztett funkciót. (A Scrum az egyes
funkciókat story-nak hívja, a magyarosítás jegyében a továbbiakban sztorit írok.) A
sztorikat priorizálni kell, azaz meg kell határozni, hogy a rengeteg funkció közül melyik a
leginkább fontos, mi az utána következő stb.

A Scrum lényege, hogy a fejlesztés egymást követő sprint-ekben zajlik. Egy sprint

tipikusan 1-4 hétig tart. (Mindig a csapat előzetes döntése alapján.)

Egy sprint alatt a következők történnek.

1. momentum: A sprinttervezés

1/5
A tervezés célja, hogy a rendelkezésre álló sprintet (1-4 hét, döntés szerint) telezsúfoljuk a
legnagyobb prioritású sztorikkal, és eközben mindenki megértse, hogy mire is vállalkozik
a teljes csapat. Időtartama célszerűen pár óra.

(Alapfeltétel: rendelkezésre áll a priorizált product backlog.)

1. Kiválasztjuk a product backlog-ból a soron következő legfontosabb sztorit.

2. Közösen megbeszéljük, mi a sztori célja, a teljes csapat megérti, mi a
lefejlesztendő funkció. (A tervezésen célszerű, ha mindig van valaki, akitől lehet
kérdezni: ügyfél, üzleti elemző, üzleti szakértő).
3. A csapat a sztorit – ha szükséges – lebontja feladatokra (ha túl nagy).
4. Megbecsüljük, hogy az egyes feladatok mennyi időt vesznek igénybe. Ez egy
szavazással történik (planning poker). Mindenkinek van egy kártyakészlete, az
egyes kártyákon a 0, 0.5, 1, 2, 3, 5, 8 … számok találhatóak (nagyjából Fibonacci-
sorozatot követnek). Ezek reprezentálják a ráfordítást (sztoripont-nak hívja
a Scrum, most az egyszerűség kedvéért 1 sztoripont legyen egyenlő 1 embernappal.)
A szavazáskor mindenki egyszerre emeli fel azt a kártyát, ami a legközelebb van az
általa gondolt ráfordításhoz. Eltérések esetén a csapat konszenzussal dönt a
várható ráfordításról.
5. Ha még be tudunk tervezni újabb sztorit (befér az előre meghatározott sprint-
hosszba), GOTO 1.

A product backlog-ból a sprintre elvállalt sztorikból áll össze a sprint backlog-ja.

2. momentum: A sprint (implementáció)

2/5
A Scrum központi fogalma maga a sprint, mert a fejlesztés nem más, mint az 1-4 hétig
tartó rövid sprintek egymás utáni sorozata. Ilyenkor a csapat neki gyűrközik, és az
előzetesen elvállalt sztorikat lefejleszti. A csapat munkáját egy burndown chart
szemlélteti, amin látszik, hogy ideális esetben hogyan csökkenne a sprintben még
hátralévő feladatok mennyisége, és hogy a csapat valójában mennyit teljesített.

Minden nap egy standup-ot tart a csapat, amelyen minden csapattag résztvesz, és röviden
elmondja, mit csinált tegnap, és mit csinál ma. Ha valami problémába ütközik, jelzi.

[Update, 2009.12.07. 09:54] A standup egy fal előtt zajlik. A falon egy flipchart található,
amely három részre van osztva: todo - in progress - done. A sprint backlogban lévő
sorokhoz egy-egy kártya tartozik, amelyek mindegyike kezdetben a todo oszlopban
található. Ahogy az egyes emberek magukhoz veszik a feladatot, azok átkerülnek az in-
progress oszlopba, majd befejezés esetén a done-ba kerülnek át.

3. momentum: Sprint demó

A sprint befejeztével egy demó veszi kezdetét, amelyre meghívjuk az ügyfelet. A csapat
bemutatja az elkészült új funkciókat, az ügyfél elmondja az észrevételeit.

4. momentum: Retrospective

A retrospective-en (vagy visszatekintésen) a csapat közösen áttekinti, hogy mi történt a

sprint alatt. Milyen dolgok mentek rosszul? Mi volt az oka? Mit csináljunk másképpen? A
korábbi retrospective-eken milyen dolgokat említettünk már, azokkal mi a helyzet?
Bevált-e a korábbi döntésünk, amit egy probléma kiküszöbölésére megkíséreltünk?

A retrospective egy 0,5-1 órás szösszenet, formálisan a teljes sprint-ciklus végét jelenti.
Ezután indul egy újabb ciklus (tervezés-implementáció-demó-retró).

Csapatmodell
A Scrum résztvevői három csoportba esnek:

3/5
 a (megvalósító) csapat: a szoftverfejlesztők, tesztelők, mindenki, aki a szoftver
effektív készítésében részt vesz,
Product Owner: az az ember, aki priorizálja a product backlog-ot. Lehet az ügyfél,
marketinges vagy akár belső ember is.
Scrummaster: Az ő elsődleges feladata, hogy a Scrum működhessen, és a csapat
útjában álló összes problémát elhárítsa. Koordinálja és moderálja a teljes Scrum
folyamatot. Résztvesz az összes standup-on, tervezésen, demón és retrospective-en.
Ha valami gond támad, amit a csapat nem tud megoldani, a Scrummaster-hez
fordul.

Na, gyerünk akkor…

Sokan olvasnak, hallanak a Scrum-ról. Nagy divat lett manapság, de meggyőződésem,
hogy sokan félreértik, vagy inkább azt mondanám, hogy nem használják ki a benne rejlő
lehetőségeket.

Amikor meglátják a Scrum egyszerű folyamatát, a napi standup-ok nyújtotta folyamatos

számonkérési lehetőséget, a csapat folyamatos számonkérési lehetőségét a sprintek végén,
felcsillannak a szemek. Azonban ahhoz, hogy működjön az egész, több dolog kell:

jó csapat: vége a magányos farkasok útjának, a Scrum valódi csapatjátékosokat vár,

akik hajlandóak és képesek is tanulni saját hibáikból; motiváltak is legyenek (ebben
segíthet is a Scrum),
cross-functional csapat: olyan csapat, ami önmagában képes megoldani a teljes
problémát, tehát a szükséges kompetenciának a teljes vertikuma a rendelkezésére
áll. Egy csapat nem külön architektek csoportja, akik csak tervezést végeznek, nem
csak külön GUI-fejlesztők, akik egy csapatként csak a GUI fejlesztéséért felelősek.
Egy csapat, az egy komplett csapat, aki le tudja fejleszteni a szoftvert. (Jó vita alap,
hogy a tesztelők bele értendők-e.)
vezetői támogatás: “Vezetőként a csapat élvezi teljes támogatásomat. Megbízom
Bennük, mert tudom, hogy képesek megoldani a problémát. Megértem, miről szól a
sprint, és nem veszek ki embert egy sprint közepén, nem adok neki más feladatot.”,
ügyfél: van kedve eljönni a demókra, értelmes észrevételeket ad, megérti, hogy
prioritás szerint kell haladni, nem pedig a “kihányunk az elején egy értelmetlenül
összegányolt kövspecet, amiben minden egyformán fontos, és utána leszarom az
egészet” – attitűddel él,
megfelelő projekt: ahhoz, hogy értelme legyen a Scrum-nak, olyen projektekben kell
gondolkoznunk, amelynek kellő kifutása van (jó pár hónap), és folyamatosan van
feladat, ami előre egy sprintnyire tervezhető (1-4 hétre),
és az egyik legfontosabb: meg kell érteni, hogy a Scrum nem oldja meg a
problémáinkat (sőt számos újabb problémát is felszínre fog hozni!), azokat
mindig a csapatnak kell megoldania! TANULNI ÉS ADAPTÁLÓDNI!

A Scrum csupán egy eszköz, ami bizonyos körülmények között jól használható, és jól
kiaknázható vele a csapatban rejlő agilitás. Hogy mi hogy csináltuk? A cikk következő
részében folytatom.

4/5


5/5