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 egy a rögbiből átvett szakkifejezés, jelentése: viaskodik, összecsap, dulakodik [19].
1986-ban Hirotaka Takeuchi és Ikujiro Nonaka írtak le egy módszert, amely nagyban felgyorsítja és flexibilisebbé teszi új termékek fejlesztését. A tradicionális vízesés módszert, 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
43
fut, és egymás között passzolgatják a labdát.
A Scrum fejlesztési módszertant nagyfokú adaptivitás jellemzi, főbb jellemzőit az alábbiakban foglalhatjuk össze:
− 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 a kockázatelemzés a fejlesztőcsapat részéről. Napi státuszmegbeszélést tartanak, 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 az előrehaladá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.
A Scrum egy keretrendszer, amely magában foglal bizonyos tevékenységeket és meghatározott szerepeket. A Scrum főbb szerepkörei:
− Scrum Master, aki a szoftverfejlesztési folyamatot felügyeli és munkája hasonlít a projektmenedzseréhez.
− Product Owner, aki a projektben érdekelt döntéshozókat képviseli.
− Team, amely 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 egy működő szoftveregységet hoz létre. A futam során megvalósítandó funkciók (Sprint Backlog) a termék teendőlistájából (Product Backlog) kerülnek ki, ami az elvégzendő munka magas szintű követelményeiből álló, fontossági sorrendbe állított listája (4.4.
ábra). 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).
44
4.4. ábra. A Scrum futam.
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ó hagyományos szoftverfejlesztési módszertanokkal. 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.
5.2.1 Scrum szerepek
− Terméktulajdonos. 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.
− Csapat. 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ő, tervező, tesztelő stb.)
5.2.2 Napi Scrum megbeszélés
45
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 Scrum-nak 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 Scrum szakértők. Fontos szempont, 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.
5.2.3 Futamtervező megbeszélés (Sprint planning)
Minden futam előtt futamtervező megbeszélést tartanak, amelynek céljai az alábbiak:
− 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”
5.2.4 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 46
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.
5.2.5 Visszatekintés
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?
A 4 hetes futam esetén maximum 3 óra hosszúságú, rövidebb futam esetén ez az esemény is rövidebb.
5.2.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ényleí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.
5.2.7 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ó funkciókat. Az 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.
5.2.8 Burn down chart
A „Burn down chart” egyfajta napi eredmény kimutatá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.
47
5.2.9 Burn up chart
A „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.
5.2.10 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.