Scrum

The Scrum process.

A Scrum a szoftverfejlesztés egy fokozatos, iteratív módszere, amit gyakran használnak az agilis szoftverfejlesztés eszközeként.

Bár a scrum eredetileg szoftverfejlesztési projektmenedzsment módszertannak készült, szoftverkarbantartási projektek vezetésére vagy programmenedzsment-megoldásként is alkalmazható.

Kialakulása

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: A tradícioná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 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. 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

A scrum egy folyamat váz, 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 "Project 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

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ó viccre alapul:

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álallalnak 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.

"Disznók"

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 (vagy Facilitator)

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 ScrumMaster 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 (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

A csirkék nem részei a scrum folyamatnak, de figyelembe kell venni őket. 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.

Üzleti szereplők (Stakeholder)

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.

Igazgatók

A fejlesztésben résztvevő szervezeti egységek munkakörnyezetét teremtik meg.

Megbeszélések

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...)
• Bárki részt vehet de csak a "disznók" beszélhetnek.
• A megbeszélés ideje 15 vagy 20 percre van korlátozva, a csapat méretétől függően.
• A résztvevők állnak a megbeszélés során (ez elősegíti, hogy a megbeszélés ne húzódjon el)
• 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. (Ezeket az akadályokat a Scrum Master feljegyzi.)

Népszerű időpont a státuszmegbeszélésre az ebéd utáni időszak. A reggeli időpont problémás lehet. Ezek a megbeszélések rövidek, gyakran tábla előtt, állva tartják meg őket. Az emberek gyakran elpillednek az ebédtől, tehát egy élénk állómeeting felfrissítheti őket, vélik a 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.

Futamtervező megbeszélés (Sprint planning)

Minden futam előtt (15-30 naponta) futamtervező megbeszélést tartanak:

• Elvégzendő feladatok kijelölése
• 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
• Maximum 8 óra hosszúságú

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 befektetők részére (demo)
• Be nem fejezett munkát nem lehet bemutatni
• Maximum 4 óra hosszúságú

Visszatekintés (Retrospective)

• A csapattagok véleményt alkotnak az elmúlt futamról
• Javaslatokat tesznek a folyamatok továbbfejlesztésére
• 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?
• Maximum 3 óra hosszúságú

Felhasznált eszközök, adatok

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 "táblat támogatás" 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.

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" (Napi eredménykimutatás)

Mindenki számára elérhető táblázat, 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.

Adaptív projektmenedzsment

• 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

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

• 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

• (PDF) Rising, L., Janoff, N.S. (2000). The Scrum Software Development Process for Small Teams elérés 2007. március 15.
• (PDF) Schwaber, K. Advanced Development Methods. SCRUM Development Process elérés 2006. augusztus 15.
• (PDF) Dr. Sutherland, J. (October 2004) Agile Development: Lessons learned from the first scrum elérés 2006. augusztus 15.
• (video) Jeff Sutherland in Scrum Tuning: Lessons learned from Scrum implementation at Google elérés 2007. december 15.
• (video) Ken Shwaber in Scrum et al. elérés 2008. január 19.

Külső hivatkozások

• Scrum in five minutes - elérés 2008. február 7.
• Scrum Alliance - elérés 2008. február 7.
• Scrum et al - Google-ös interjú Ken Schwaber-rel. - elérés 2008. február 7.
• Scrum and XP from the Trenches - elérés 2008. február 7.
• Scrum articles directory - elérés 2008. február 7.
• Agile Alliance's Scrum library - elérés 2008. február 7.
• Agilo For Scrum (Open Source Scrum Tool) - elérés 2008. február 7.