Scrum szótár

77

A Scrum team


Egy Scrum csapat optimálisan 4-7 emberből áll, de a Scrum projektek nagyságától függően a csapat könnyedén bővíthető akár száz főre is. Felelős a kitűzött cél eléréséért, a termék leszállításáért. A csoport nem tartalmaz semmilyen, hagyományos szoftverfejlesztési szerepeket, mint pl.: programozó, tervező, tesztelő, vagy építész. Együtt dolgozik mindenki a kollektív elköteleződés szellemében, hogy egy-egy sprint határidőre lezáruljon. A Scrum csapat kialakításának elengedhetetlen feltétele a tagok egymás iránti tisztelete és megbecsülése, az ugyn. "We're All in This Together." érzés kialakítása.
Különböző szakterületeket lefedő képességekkel rendelkező emberekből ajánlott összeállítani a csapatot. Pl.: rendszertervező, fejlesztő, tesztelő, minőségügyi szakember.
A csapatépítés elsődleges módja a skálázás annak érdekében hogy, együtt tudjon működni a csapat, ezáltal összehangolja a csapattagokat . "Scrum a Scrums."
Ezzel a megközelítéssel mindenki, aki részt vesz egy ilyen találkozón, egy emberként hozzájárul a csapat teljesítményéhez. Ezáltal erősítve a csapat iránti lojalitást, másrészt pedig megkönnyíti a feladatok és felelősségek közti koordinációt.
A „Scrum a Scrums” találkozó hasonlít a Daily Scrum meetinghez, de a különbség, hogy nem kötelező és nem feltétlenül van minden nap. Számos szervezetben, hetente két-három alkalommal kerül megszervezésre.


Product Owner


A Product Owner képviseli a projektben az ügyfelek, forgalmazók, támogatók, üzleti elemzők és a kulcsfontosságú felhasználók érdekeit (Stakeholders). Ők azok, akik érdekeltek a végtermékben, esetleg a Scrum folyamatban, azonban nem vesznek részt a fejlesztésben. A termékgazda legtöbb esetben egy külső szakértő, vagy egy kulcsfontosságú felhasználó.
Feladata az ügyfél igények, specifikációk és az ügyfél nyelvezete alapján megfogalmazni és elkészíteni a Product Backlog-ot. Továbbá, biztosítja, hogy a Scrum Team üzleti szempontból a megfelelő feladatokon dolgozzon. A projekt sikeressége érdekében, folyamatosan figyelemmel kíséri a csapat munkáját, hogy a sprint elérje célját.
A megrendelőre és a Product Owner-re a sprint végéig nincs szükség, a csapat magában dolgozik. A sprint elején a kiválasztott user story-kat a csapat kisebb feladatokra bontja. Ez egy rendkívül részletes technikai lista lesz, ugyanis a feladatokat addig kell darabolni amíg minden egyes feladat legfeljebb pár órányi munkát igényel (ez egy idegtépő, lassú és hosszadalmas megbeszélés).
A csapat elkötelezettségéért valamint a kijelölt feladatok elvégzéséért cserébe, a Product Owner vállalja, hogy nem fog újabb feladatokat támasztani a csapat felé, míg tart a sprint.
A követelményeket viszont megváltoztathatja azaz javaslatot tehet a változtatásra, de csak a sprinten kívül.


Scrum Master


Ő gondoskodik arról, hogy a csapat folyamatosan eredményes legyen. 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ó. 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. (Pl.: Amennyiben az egyik csapattagnak sok projecten kívüli tevékenysége van, akkor elintézi, hogy mentesüljön ezek alól.) A másik fontos szerepe a Scrum folyamatot megfelelően alkalmazzák, valamint hogy a szabályokat a csapat tagjai betartsák.


Product Backlog


A projekt során megvalósításra váró teendők és változtatások listája priorizált, azaz fontossági sorrendbe állítva.
A Product Backlog a Product Owner kívánságlistája, egy to-do list, azaz a projekt során megvalósításra váró teendők listája, priorizált sorrendben.
Egy projekt megkezdése előtt,mivel még nincs átfogó időkorlátozás, jellemzően jóval több feladat kerül megfogalmazásra, mint ami az első sprintbe tartozhat. A Product Backlog rendelkezik olyan lehetőséggel, hogy a felmerülő feladatok és a hozzá rendelt prioritások a fejlesztési folyamatban változnak. A projekt hatékonysága javul, ezáltal nő az ügyfélelégedettség.
A tervezés során a csapat kiválasztja azokat a feladatokat, amelyeket bevállalhatónak tart a fennmaradó időszakra. Az összetettebb feladatokat a termékgazdával egyeztetve részfeladatokra, kisebb fejlesztésekre bontják, amelyek beleférnek a viszonylag rövid sprint időszakba. Időnként a sprint-tervezési folyamat belassulhat - például az összetettebb feladatok szétbontása, az elvárások pontosítása miatt - ezért nem ritka, hogy egy sprint megtervezése akár két napot is igénybe vesz. A tervezés végére létrejön - közös megegyezés alapján - egy részletes, lebontott akciótervvel, időbecslésekkel ellátott feladatlista. Ez az úgynevezett "Sprint Backlog".
A csapat az összeállított priorizált feladatlista alapján, a legfontosabbal kezdődik a folyamatot, majd lépésről lépésre halad az alacsonyabb prioritással rendelkező feladatok megvalósítása felé.
A gyakorlatban többször előfordul, hogy a csapat az elsőre kiválasztott öt elem mellé a fontossági listán alacsonyabb prioritással rendelkező feladatokat is beilleszt és együttesen áll neki a megvalósításuknak.


Sprint planning meeting


Minden sprint elején van egy ugyn. Sprint Planning Meeting, melyen az egész csapat részt vesz és megtervezi a sprint céljait. Az alap a Product Owner kívánságlistája, azaz a korábban említett, tennivalókat tartalmazó lista (Product Backlog). A lista az újabb fejlesztési igényeket, illetve az előző sprint eredményében talált hibákat tartalmazza.


Sprint Backlog


A tervezés során a csapat kiválasztja azokat a feladatokat, amelyeket bevállalhatónak tart a fennmaradó időszakra. Az összetettebb feladatokat a Product Owner-rel egyeztetve részfeladatokra, kisebb fejlesztésekre bontják, amelyek beleférnek a viszonylag rövid sprint időszakba. Időnként a sprint-tervezési folyamat belassulhat – pl.: az összetettebb feladatok szétbontása, az elvárások pontosítása miatt – ezért nem ritka, hogy egy sprint megtervezése akár két napot is igénybe vesz. A tervezés végére létrejön – közös megegyezés alapján – egy részletes, lebontott akciótervvel, időbecslésekkel ellátott feladatlista.


Daily Scrum


A sprint alatt a csapat a munkára koncentrálva megvalósítja a célokat. A haladásról a naponta megtartott minden csapattag számára kötelelző 15 perces összejövetelen számolnak be egymásnak: ez az ún. Daily Scrum, ahol a fejlesztők kizárólag három kérdés megválaszolására szorítkoznak:



  1. Mit csináltál az előző Daily Scrum óta?

  2. Mit csinálsz ma?

  3. Akadályozza valami a munkádat?


A megoldási javaslatokat, részletekbe menő vitákat kerülni kell ezeken az összejöveteleken- ennek kivédése a Scrum Master feladata. A kérdések tisztázását a Daily Scrumot követő megbeszéléseken ajánlott megejteni, lehetőleg kizárólag az érintett felek bevonásával. Itt érvényesül a „szabad lábak” elve, azaz bárki távozhat, akit nem érint a tisztázandó témakör.


Sprint Review Meeting


Minden sprint végén a csapat bemutatja, hogy milyen eredményeket értek egy demó illetve egy bemutató keretén belül. Ez az alkalom az úgyn.: Sprint Review Meeting. Több szempontból is hasznos ez a megoldás, mivel látszata van a közös munkának, a megrendelő figyelemmel kísérheti a termék alakulását. Ezáltal nem csak a projekt késői szakaszában (legrosszabb esetben a végén) derül ki, hogy egyáltalán nem azt hoztuk össze, amit a vevő eredetileg szeretett volna.


Burndown Charts


A Scrum projektekben, minden sprint befejezése után elkészül a Burndown Chart. Ez egy olyan grafikon, amely az elvégzett és az elvégzendő feladatokat mutatja az eltelt idő függvényében. A vízszintes tengely a sprint iterációkat, a függőleges tengely a fennmaradó munka mennyiségét mutatja.


A csirke és a disznó


Van egy régi vicc, amelyben a csirke és a disznó beszélget:
„Csináljunk egy éttermet!” – veti fel a nagy ötletet a csirke
„Jó, ötlet, de mi legyen a neve?” – kérdezi a disznó
„Mondjuk Sonka és Tojás!” – válaszolja a csirke
„Kösz, nem” – mondja a disznó – én tuti mindent beleadnék, te pedig csak éppen részt vennél benne.
A vicc célja, hogy rámutasson a különbségre azok között akik mindent beleadnak egy projektbe és azok között akik csak részt vesznek benne. A Scrum során kiemelt szerep jut az elkötelezett résztvevők számára, amelyet számos olyan szabály is támogat – mint például az, hogy az elkötelezettek megszólalhatnak a napi scrum gyűléseken. A csirkék számára pedig nem engedélyezik a projekt hátráltatását.


Sprint review:


Még egy állandó meeting van a Scrum-ban, mégpedig az ún. Retrospective, a sprint végén, amikor egy hosszabb beszélgetés keretében a sprint tapasztalatait beszélik meg a résztvevők és bemutatnak egy lehetőleg működő, látványos terméket (amolyan "demózás" a megrendelő számára). Ez az úgynevezett "sprint review". Több szempontból is hasznos ez a megoldás, hiszen:- látszata van a közös munkának, - a megrendelő figyelemmel kísérheti a termék alakulásátEzáltal nem csak a project késői szakaszában (legrosszabb esetben a végén) derül ki, hogy egyáltalán nem azt hoztuk össze, amit a vevő eredetileg szeretett volna (biztosan sokan ismeritek a hintás analógiát). Ilyesmi pedig sűrűn előfordul, a megrendelő ködös igényeinek vagy a tervezők, UI-designerek tévedései miatt.
Ennek alapján javaslatokat tesznek a későbbiekre. A sprint során összegyűlt nehézségekre (impediment list) a Scrum Master feladata ellenlépéseket kidolgozni.
A retrospektív elemzés azt szolgálja, hogy az esetleges hibákból okulva leszűrjük a következményeket. Három lényeges kérdésre válaszolnak ilyenkor a csapat tagjai:- Mi volt jó a sprint során?- Mik voltak a negatívumok?- Hogyan lehet javítani a problémás területeken?
Nem az ujjal egymásra mutogatás a cél, hanem a fejlődés!
Mivel a SCRUM előfeltétele a szabad információáramlás, nagyon ajánlott a csapattagokat egy közös térbe szervezni. A fejlesztés eredményeit követhetővé kell tenni; ehhez szükséges a folyamatos integráció és a tesztelés. Ezzel biztosíthatjuk, hogy az alkalmazás nem romlik el, és emiatt ajánlott - bár talán inkább kötelező - a tesztvezérelt szoftverfejlesztés (Test Driven Development) alkalmazása
Elsőre úgy tűnhet, hogy a Scrum másból sem áll, mint permanens meetingelésből, de ennek épp az ellenkezője igaz. A sprint során, ami akár egy hónap is lehet, a napi negyedórás DSM-en kívül kötelező elem egyáltalán nincs, a DSM-et egy összeszokott csapat pedig akár öt perc alatt is lezavarja.