Scrum gyorstalpaló


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.

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

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.

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

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

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: todoin progressdone. 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

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?

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:

  • 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!

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.

Share
This entry was posted in Módszertan and tagged , , , , , , , , , . Bookmark the permalink. Follow any comments here with the RSS feed for this post. Post a comment or leave a trackback: Trackback URL.

Comments

  • Gáspár György

    Dec 13th, 2009

    Egy tesztelő annyira tud crossfunctional lenni, amennyire tud programozni, és másik oldalról megközelítve egy fejlesztő nem szabad, hogy "teszteljen" – kivéve unit&integration. A tesztelés általában magában foglalja az üzleti logika ellenőrzését, így amennyiben a kettőjük együttműködése által a teljes probléma (termék) megoldható, akkor a team részei!:)

Leave a Comment