Scrum

A Wikipédiából, a szabad enciklopédiából
The Scrum process.

A Scrum a szoftverfejlesztés egy inkrementális, iteratív módszere, amit gyakran használnak az agilis szoftverfejlesztés eszközeként. A scrum eredetileg szoftverfejlesztési projektmenedzsment módszertannak készült, azonban alkalmazható szoftverkarbantartási projektek vezetésére vagy programmenedzsment-megoldásként is.

Kialakulása[szerkesztés | forrásszöveg szerkesztése]

1986-os cikkükben Hirotaka Takeuchi és Ikujiro Nonaka leírnak egy módszert, ami nagyban felgyorsítja és flexibilisebbé teszi új termékek fejlesztését[1]: A tradicionális módszert (vízesés modell), amelyben az egymást sorban követő fejlesztési fázisokat más-más szakembercsapat kezeli, a váltófutáshoz hasonlítják, ahol egyszerre csak egy ember fut, és a futók egymásnak adják a stafétát. Az új módszert, amiben a fázisok erősen átlapolódnak, és a különböző területeket képviselő szakemberek egy kis csoportja végig, minden fázisban együtt dolgozik, a rögbihez hasonlítják, ahol egyszerre az egész csapat fut, és egymás között passzolgatják a labdát. Az esettanulmányok az autóiparból, a fényképezőgép-, számítógép-, és nyomtatógyártásból merítenek.

1991-ben DeGrace és Stahl [2] hivatkozott rá először úgy, hogy scrum, amely egy rugby-s szakkifejezés, ami már Takeuchi és Nonaka cikkében is szerepel. Ken Schwaber is használt scrum-szerű módszert az 1990-es évek elején. Ezzel egyidejűleg fejlesztett ki Jeff Sutherland egy hasonló módszert az Easel Corporation-nél.[3] Sutherland és Schwaber közös cikkben mutatták be a Scrum-ot az OOPSLA '96-on Austin-ban. Schwaber és Sutherland az azt követő években közösen dolgozott a megjelent írások, a saját tapasztalataik és az szoftveriparban látott gyakorlatok összegyúrásán, melynek eredménye a ma scrum néven ismert módszertan. 2001-ben Schwaber könyvet írt Mike Beedle-lel közösen Agile Software Development with SCRUM címmel.

Jellemzői[szerkesztés | forrásszöveg szerkesztése]

A scrum egy keretrendszer, amely magában foglal bizonyos tevékenységeket és meghatározott szerepeket. A scrum főbb szerepkörei a „Scrum Master”, aki a folyamatot felügyeli és munkája hasonlít a projektmenedzseréhez, a „Product Owner” aki a projektben érdekelt döntéshozókat képviseli, és a „Csapat” (Team) ami a nagyjából 7 főből áll és lefedi az összes munkafolyamatot.

Minden „futam” (sprint) során - amely 2 és 4 hét közötti időtartamot jelent (a csapat döntésétől függően) - a csapat egy működő szoftveregységet hoz létre. A futam során megvalósítandó funkciók a „Product Backlog”-ból (termék teendőlistája) kerülnek ki, ami az elvégzendő munka magas szintű követelményeiből álló, fontossági sorrendbe állított lista. Hogy a futam során a lista melyik elemei kerülnek megvalósításra, azt a futam elején tartott „futamtervező” megbeszélés során választják ki. A megbeszélés során a „Product Owner” közli a csapattal, hogy a teendők listájából melyek azok, amiket leghamarabb akar, hogy elkészüljenek. Ezután a csapat eldönti, hogy ezek közül melyek azok, amelyeket a következö futam során meg tud valósítani, és ezek megvalósítására ígéretet tesz. A futam folyamán a „futam teendőlistáját” nem lehet megváltoztatni, a futam során elvégzett tevékenységek rögzítettek. Amint a futam a végéhez ért, a csapat bemutatja az elkészült funkciókat (demo).

Az önszerveződő csapatok kialakulásának elősegítése végett a scrum arra ösztönöz, hogy a projekt résztvevői egy helyen dolgozzanak és szóban kommunikáljanak egymással.

A scrum egyik legfontosabb alapelve az, hogy felismeri és elfogadja, hogy a megrendelő a fejlesztés során meggondolhatja magát a követelményekkel kapcsolatban, és a váratlan változások nem kezelhetők könnyen a hagyományos, előzetes tervezési fázison alapuló módszerekkel. Ezért a scrum gyakorlati megközelítést választ, és elfogadja hogy nincs lehetőség a probléma teljes megértésére és definiálására. Inkább azt próbálja maximálisan elősegíteni, hogy a csapat gyorsan meg tudja valósítani a funkciókat és gyorsan tudjon reagálni a változó követelményekre.

Szerepek[szerkesztés | forrásszöveg szerkesztése]

A scrum módszertan a szereplőket két csoportra osztja: disznókra és csirkékre. Ez egy disznóról és csirkéről szóló viccen alapul[4]:

A disznó és a csirke mennek az utcán. Egyszer csak a csirke megszólal: „Te, nyissunk egy éttermet!” Mire a disznó: „Jó ötlet, mi legyen a neve?” A csirke erre gondolkozik, majd azt feleli: „Nevezzük Sonkástojásnak!” A disznó erre: „Nem tetszik valahogy, mert én biztosan mindent beleadnék, te meg éppen csak hogy részt vennél benne.”

A „disznók” azok akik kötelezettséget vállalnak a szoftver elkészítésére. A „csirkék” ugyan érdekeltek a projekt sikerében, nem ők azok akik „a bőrüket viszik a vásárra”. A fejlesztés során a csirkék igényeit, vágyait és ötleteit is figyelembe veszik, de nem hagyják, hogy azok akadályozzák a projektet.

Az újabb módszertani útmutatók nem alkalmazzák a csirke és disznó megnevezést.[5]

Disznók[szerkesztés | forrásszöveg szerkesztése]

Azok a disznók, akik „a saját bőrüket viszik a vásárra”.

Terméktulajdonos (Product Owner)
A megrendelőt képviseli. Biztosítja hogy a csapat az üzleti szempontból fontos dolgokkal foglalkozzon. A termék-teendőlistát bővíti a megrendelő szempontjából megfogalmazott bejegyzésekkel, amelyeket prioritással is ellát.
Scrum Master
Az elsődleges feladata hogy elhárítsa az akadályokat amelyek gátolják a csapatot abban, hogy a futam célját megvalósítsa. A scrum master nem a csapat vezetője, (a csapat önszerveződő), hanem a csapat és a zavaró tényezők közötti lökhárító. Ügyel arra, hogy a scrum folyamatot megfelelően alkalmazzák. Ő tartatja be a scrum szabályait. Kulcsfontosságú feladatának számít a csapat védelme és annak biztosítása, hogy a csapat az elvégzendő feladatokra koncentráljon. A scrum master tartja mozgásban a csapatot (facilitator), jelentős szerepet vállal az események lebonyolításában.
Csapat (Scrum Team)
A csapat azért felelős hogy a termék elkészüljön. Általában 5-9 főből áll. A csapattagok különféle képességei lehetővé teszik hogy a feladatot közösen megoldják (fejlesztő, dizájner, tesztelő, ...)

Csirkék[szerkesztés | forrásszöveg szerkesztése]

A csirkék nem részei a scrum folyamatnak, de figyelembe kell venni őket. Az utóbbi évek szakirodalma a csirke megnevezést nem használja, érintett félként (stakeholder) hivatkozik azokra a személyekre, akik közvetlenül nem vesznek részt a scrumban. Az agilis szoftverfejlesztés egyik fontos aspektusa, hogy bevonják a felhasználót a fejlesztési folyamatba, a tőlük érkező visszajelzéseket figyelembe veszik a futamok tervezésénél.

Felhasználók
Akik a szoftvert használni fogják. (A sok egyedi vásárló számára készülő szoftverek esetén a felhasználó hangját megtestesítő személy.)
Üzleti szereplők
Azok az emberek, akik lehetővé teszik a projekt létrehozását és akiknek a termék hasznot fog hozni. Közvetlenül csak a futam áttekintő megbeszélésen (demo) vesznek részt a folyamatban. Ez az adminisztrátorokat és az igazgatókat is magába foglalja.
Menedzserek
A fejlesztésben résztvevő szervezeti egységek munkakörnyezetét teremtik meg. Nem csak a funkcionális vezetőket jelenti.

Megbeszélések[szerkesztés | forrásszöveg szerkesztése]

Napi „scrum” megbeszélés
A futam során naponta tartott megbeszélés. Napi „scrum”-nak vagy álló megbeszélésnek hívják, és a következők vonatkoznak rá:
  • Mindig pontosan kezdődik. A későn érkezőkre gyakran (a csapat által meghatározott) büntetést szabnak (fekvőtámasz, pénz, gumicsirke nyakban való viselése...) A scrumnak nem szerves része a munkatársak megalázása, semmi nem írja elő büntetés alkalmazását, a pontos kezdés ugyanakkor a munka hatékonyságát pozitívan befolyásoló tényező.
  • Bárki részt vehet, de csak a „disznók” beszélhetnek.
  • A megbeszélés ideje 15 vagy 20 percre korlátozott, a csapat méretétől függően.
  • A résztvevők általában állnak a megbeszélés során (ez elősegíti, hogy a megbeszélés ne húzódjon el).
  • Az egyszerűség kedvéért minden nap ugyanazon a helyen és ugyanabban az időpontban tartják.
A megbeszélés során minden résztvevő ugyanazokat a kérdéseket válaszolja meg:
  • Mi az, amit a tegnapi megbeszélés óta csináltam.
  • Mi az, amit a mai nap tervezek csinálni.
  • Vannak-e akadályok, amik gátolnak a cél elérésében. (Az akadályok elhárítása a Scrum Master feladata.)

A napi megbeszélés célja, hogy a csapat tagjai összehangolják tevékenységüket. Az időpontra nincs szabály, lehet napindító megbeszélésként tartani, ez a notóriusan késő tagokra tekintettel nem feltétlenül szerencsés. Népszerű időpont a státuszmegbeszélésre az ebéd utáni időszak. Az emberek gyakran elpillednek az ebédtől, tehát egy élénk állómeeting felfrissítheti őket, vélik egyes scrumszakértők. Azt is vélik, hogy mindenki dolgozott már ebéd előtt, ezért az emberek nem a privát dolgaikon gondolkoznak éppen, hanem a munkájukon. Számos egyéb szempont befolyásolhatja az időpont kiválasztását.

Futamtervező megbeszélés (Sprint planning)
Minden futam előtt futamtervező megbeszélést tartanak:
  • Elvégzendő feladatok kijelölése a termék teendőlistájáról (product backlog) a terméktulajdonos közreműködésével.
  • Futam teendőlistájának előkészítése, amely a teljes csapat figyelembevételével részletezi az egyes részfeladatok időszükségleteit.
  • Annak meghatározása és kommunikálása, hogy mennyi feladat elvégzése várható el az aktuális futam során.
  • 4 hetes futam esetén maximum 8 óra hosszúságú, rövidebb futam esetén ez az esemény is rövidebb.

A futam végén két megbeszélést tartanak: „Futamáttekintés” és „Visszatekintés”

Futamáttekintés (Demo vagy Sprint Review)
  • Annak áttekintése, hogy mely munkák készültek el és melyek nem.
  • Az elkészült munka bemutatása a terméktulajdonos és a fejlesztésben érdekeltek részére (demo).
  • Be nem fejezett munkát nem lehet bemutatni.
  • 4 hetes futam esetén maximum 4 óra hosszúságú, rövidebb futam esetén ez az esemény is rövidebb.
Visszatekintés (Retrospective)
  • A csapattagok véleményt alkotnak az elmúlt futamról. A vélemény lehet egy puszta benyomás is, nem kell kidolgozott, szilárd álláspontnak lennie.
  • Javaslatokat tesznek a folyamatok továbbfejlesztésére. A javaslatoknak nem kell kiérleltnek lenniük, a kidolgozás nem a visszatekintés része.
  • Két kérdés merül fel a megbeszélésen: Mi az, ami jól ment a futam alatt? Mi az, amit a következő futam során jobban lehetne csinálni?
  • 4 hetes futam esetén maximum 3 óra hosszúságú, rövidebb futam esetén ez az esemény is rövidebb.

Felhasznált eszközök, adatok (Scrum artifacts)[szerkesztés | forrásszöveg szerkesztése]

Az agilis fejlesztés a működő szoftvert előnyben részesíti az átfogó dokumentációval szemben. A scrum 3 műterméket ír elő, ezek a termék teendőlistája, a futam teendőlistája és a burndown chart [6].

Termék teendőlistája (Product Backlog)
A „termék teendőlistája” ez egész termékre vonatkozóan tartalmaz magas szintű követelmény leírásokat. A lista elemei lehetnek funkciók leírásai, kívánságok, ötletek, stb., amelyek prioritás szerint vannak rendezve. Tulajdonképpen azt tartalmazza, hogy mi a fejlesztés célja. A lista szabadon szerkeszthető bárki által, és becsléseket tartalmaz a bejegyzések üzleti értékére és ráfordításigényére vonatkozóan. A becslések abban segítik a terméktulajdonost, hogy meghatározza a bejegyzések sorrendjét és bizonyos mértékig a prioritásukat. Ha például a „helyesírás-ellenőrzés” és „repülőgép-szimulátor” funkcióknak azonos az üzleti értékük, akkor a kevesebb fejlesztési ráfordítást igénylő funkció fog magasabb prioritást kapni, hiszen annak jobb a megtérülése. A termék teendőlistája a terméktulajdonos kezelése alatt áll. Az üzleti értéket a terméktulajdonos, míg a fejlesztési ráfordításigényt a fejlesztők határozzák meg. A követelmények formátuma gyakran felhasználói történet.
Futam teendőlistája (Sprint Backlog)
A futam teendőlistája olyan dokumentum, amely azt tartalmazza, hogy a csapat hogyan fogja elkészíteni a futam során megvalósítandó funciókat. Ez egyes funkciókat részfeladatokra bontják. A felbontást célszerű úgy elvégezni, hogy egy részfeladat 4-16 óráig tartson. Ilyen szintű részletezettség mellett a csapat összes tagja pontosan érti, hogy mit kell elvégezni, és mindenki kiválaszthatja a neki legmegfelelőbb részfeladatot. A futam teendőlistájában levő részfeladatokat nem rendelik személyhez, inkább a csapattagok választják ki azokat a meghatározott prioritások, szükségletek és a csapattag képességeinek megfelelően.
A futam teendőlistája a csapat kezelése alatt áll. A becsléseket a csapattagok adják meg. Gyakran előfordul, hogy Feladatbizottságot (Task Board) állítanak össze, amely követi és beállítja a teendők állapotát („elvégzendő”, „folyamatban”, „elvégzett”, stb.) a futam során.
Burn down chart (egy fajta napi eredménykimutatás)
Mindenki számára elérhető grafikon, amely mutatja a futam teendőinek a listájából hátralevő munka mennyiségét. Minden nap frissítik, egyszerű módon jeleníti meg a futam állapotát.

A 3 fő fenti műtermék mellett a csapatoknak lehetőségük van továbbiakat is alkalmazni, amennyiben hasznosnak ítélik.

Homokzsák vagy homokozó (Sandbox)
A termék teendőlista kezelésére a terméktulajdonos jogosult, új tételeket csak ő vehet fel. Javaslatot azonban más is tehet, ezek kerülnek a homokozóba. A terméktulajdonos jóváhagyásával kerülnek a teendőlistára.
Burn up chart
A futam feladatlistáján szereplő feladatok számát és az elvégzett feladatok számát ábrázolja közös grafikonon, napi frissítéssel. Lényegében a burn down chart dekompozíciója.
Sebesség (Velocity)
A futam tervezésekor a csapat a termék teendőlista (product backlog) elemeihez a kivitelezés várható nehézségének függvényében számszerűsíthető értéket rendel. A becslésre több kidolgozott módszer is rendelkezésre áll. A futam során elkészített elemek összpontszáma a csapat sebessége. Új csapatok esetén a sebesség jellemzően futamról-futamra nő, tapasztalt csapatok esetén közel állandó. A sebesség segítségével jól becsülhető, hogy az adott pillanatban ismert termék teendőlista mikor fogy el.

Adaptív projektmenedzsment[szerkesztés | forrásszöveg szerkesztése]

  • A megrendelő a fejlesztő csapat részévé válik.
  • Gyakoriak a köztes szállítások működő funkcionalitással, a fejlesztés inkrementális. A köztes állapotokat is validálják és ellenőrzik, hogy ne csak a végén derüljenek ki a problémák, legyen idő kijavítani őket.
  • Gyakori kockázatelemzés a fejlesztőcsapat részéről.
  • Napi státuszmegbeszélés, ahol mindenkit megkérdeznek, hogy:
    • Mit csinált tegnap óta.
    • Mit tervez holnapra.
    • Vannak-e problémái, amik meggátolják a célja elérésében.
  • Átlátható tervezés és modularizáció, azaz lássa mindenki, hogy ki miért felel és milyen határidővel.
  • Gyakori találkozók, amelyeken figyelemmel kísérik a haladást.
  • Semmilyen problémát nem söpörnek a szőnyeg alá. Mindenkit meghallgatnak, aki felismer és ismertet egy váratlan problémát.
  • A munkahely és a munkaidő legyen hatékony. A több munkaóra nem feltétlenül vezet több eredményre.

Solo Scrum[szerkesztés | forrásszöveg szerkesztése]

A scrumot kis csapatokra tervezték. A csapattagok kommunikációját próbálja javítani. Sok szoftverterméket viszont egyetlen fejlesztő készít egyedül, de a scrum-elvekből ő is tanulhat, erre találták ki a módszertan Solo Scrum nevű változatát.

Kifejezések[szerkesztés | forrásszöveg szerkesztése]

  • story - a termék funkcióinak magas szintű, megrendelőközpontú leírása
  • product backlog - a projekt során megvalósításra váró teendők listája, fontossági sorrendben
  • sprint backlog - konkrét feladatok a következő futamra
  • backlog item - teendő
  • sprint (futam) - a futamtervezés során kiválasztott teendők megvalósítására szánt rövid iteráció (2-4 hét)
  • scrum - rövid napi találkozó, ahol megbeszélik az eredményeket, az akadályokat és a következő teendőket
  • sprint planning session - megbeszélés, amelyen a következő sprint teendőit definiálják
  • sprint retrospective - visszatekintés, célja a fejlesztési folyamat gyengeségeinek elhárítása, a hatékonyság javítása. Minden csapattag elmondja a véleményét az utolsó futammal kapcsolatban, és a csapat megegyezik hogy mit változtatnak a fejlesztési folyamaton következő futam során.
  • burn down chart - kimutatás a napi eredményekről a futam során

Források[szerkesztés | forrásszöveg szerkesztése]

Külső hivatkozások[szerkesztés | forrásszöveg szerkesztése]

Jegyzetek[szerkesztés | forrásszöveg szerkesztése]