Scrum

A Wikipédiából, a szabad enciklopédiából
Jump to navigation Jump to search
A Scrum folyamata.

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]

Az 1986-os cikkükben Takeucsi Hirotaka és Nonaka Ikudzsiró leírnak egy módszert, ami nagyban felgyorsítja és rugalmasabbá 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 rögbis szakkifejezés, ami már Takeucsi é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 Corporationnél.[3] Sutherland és Schwaber közös cikkben mutatták be a Scrumot az OOPSLA ’96-on Austinban. 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]

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 a projektmenedzserrel ellentétben, a csapat önálló munkavégzését edzőként segíti, a „Product Owner” (magyarul terméktulajdonos), 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]

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, de 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]

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.
Fejlesztőcsapat (Scrum Developer Team)
A csapat azért felelős hogy a termék elkészüljön. 3-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]

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]

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 percre korlátozott
  • 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. 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 (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).
  • A legkisebb, értéket adó, működő terméket már be lehet mutatni (a létrehozott termék a stakeholder kívánalmainak már funkcionálisan megfelel) A még nem működő elemeket 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 (angolul Scrum artifacts)[szerkesztés]

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)
Egy Scrum teendő lista
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. 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 (angolul 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)
Példa a burn down chart egy teljes iterációjára, mutatja a hátralevő erőfeszítéseket és a teendőket az egy hónapos iterációnak mind a 21 munkanapjára
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.

Homokozó (angolul 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]

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

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]

  • 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.
  • sprint burn down chart - kimutatás a napi eredményekről a futam során

Források[szerkesztés]

További információk[szerkesztés]

Jegyzetek[szerkesztés]