Főoldal » Scrum kialakulása, és jellemzői

Scrum kialakulása, és jellemzői

MEGOSZTÁS

Ha tetszett a cikk, akkor nyugodtan oszd meg ismerőseiddel, valószínű ők is örülni fognak neki.

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 tradícionális módszert (vízesés model), 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

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 projekt menedzseré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ő szoftver egységet hoz létre. A futam során megvalósítandó funkciók a “Project Backlog”-ból (termék teendő lista) 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 “futam tervező” 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á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[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á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.

Futam tervező megbeszélés (Sprint planning)
Minden futam előtt (15-30 naponta) futam tervező megbeszélést tartanak:

  • Elvégzendő feladatok kijelölése
  • Futam teendő lista 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)
  • 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ő lista (Product Backlog)
A “termék teendő lista” 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ás igé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ő lista a terméktulajdonos kezelése alatt áll. Az üzleti értéket a terméktulajdonos, míg a fejlesztési ráfordítás igényt a fejlesztők határozzák meg.
Futam teendő lista (Sprint Backlog)
A futam teendő lista 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á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ő lista a csapat kezelése alatt áll. A becsléseket a csapattagok adják meg. Gyakran előfordul, hogy Feladat bizottsá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ény Kimutatás)
Egy 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.
  • Semmi 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.

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 futam tervezés során kiválasztott teendők megvalósítására szánt rövid iteráció (2-4 hét)
scrum – egy 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

Felhasznált szakirodalom:

Forrás: Wikipédia

MEGOSZTÁS

Ha tetszett a cikk, akkor nyugodtan oszd meg ismerőseiddel, valószínű ők is örülni fognak neki.