Scrum

A Wikipédiából, a szabad enciklopédiából
Ugrás a navigációhoz Ugrás a kereséshez
A Scrum folyamata. A 30 nap sprint hosszúság csak példa, bárhol lehet 1-4 hét között.

A Scrum egy összetett (komplex) problémák megoldására kifejlesztett általános keretrendszer. A szoftverfejlesztés területén gyakran használják az agilis szoftverfejlesztés egyik fontos összetevőjeként, de ugyanúgy megtaláljuk szolgáltatások fejlesztésénél, szervezetek irányításánál, még iskolákban is.[1] Nem kizárólag termékek létrehozására kitalált folyamat vagy technika; sokkal inkább egy olyan keretrendszer, melyen belül különböző folyamatokat és technikákat lehet alkalmazni. A Scrum láthatóvá teszi a termék menedzsmentjének és a fejlesztési gyakorlatainak relatív hatékonyságát, így elősegíti annak tökéletesítését.

A Scrum keretrendszer a Scrum Csapatokból, valamint a hozzájuk rendelt szerepekből, eseményekből, munkaanyagokból (artifacts) és szabályokból áll. A keretrendszeren belül minden egyes komponens meghatározott célt szolgál, és mindegyik alapvetően szükséges a Scrum sikeréhez és használatához. A Scrum szabályai kapcsolják össze az eseményeket, szerepköröket és a munkaanyagokat, meghatározva a köztük lévő viszonyokat és kölcsönhatásokat. A Scrum szabályait a Scrum Guide ismerteti [2]. A Scrum egyszerű, könnyen érthető ám igazi kihívás mesteri szintre fejleszteni.


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:[3] 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[4] 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.[5] 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 Mester”, aki a folyamatot felügyeli és a projektmenedzserrel ellentétben, a csapat önálló munkavégzését coachként segíti, a „Product Owner” (magyarul terméktulajdonos), aki a projektben érdekelt döntéshozókat képviseli, és a „Csapat” (Team) ami 3-9 főből áll és lefedi az összes munkafolyamatot.

Minden sprint során – amely 1 é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ő terméket (szoftvert vagy más eredményt) hoz létre. A sprint 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 sprint során a lista melyik elemei kerülnek megvalósításra, azt a sprint elején tartott „sprinttervező” 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ő sprint során meg tud valósítani, és ezek megvalósítására ígéretet tesz. A sprint folyamán a „sprint teendőlistáját” nem lehet megváltoztatni, a sprint során elvégzett tevékenységek rögzítettek. Amint a sprint 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]

Scrum Csapat[szerkesztés]

Terméktulajdonos (Product Owner)[szerkesztés]

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 igényekkel, ami rendszerint a "User story"-k keretében kerül megfogalmazásra (Ki, mit, miért szeretne).

A Terméktulajdonos (Product Owner) felelős a termék értékének maximalizálásáért és a Fejlesztőcsapat munkájáért. Ennek megvalósítása szervezeti formától, Scrum Csapatoktól és egyénektől függően nagyon eltérő lehet. A Terméktulajdonos az egyetlen személy, aki felelős a Termék Backlog (Termék Teendőlista - Product Backlog) kezeléséért, mely a következőket foglalja magában:

  • A Termék Backlog tételeinek egyértelmű leírása,
  • A Termék Backlogban szereplő tételeknek sorba rendezése aszerint, hogy azok a célok és
  • küldetések legjobb, leghatékonyabb elérését szolgálják,
  • A Fejlesztőcsapat által végzett munka értékének optimalizálása,
  • Annak biztosítása, hogy a Termék Backlog elérhető, könnyen áttekinthető és mindenki számára
  • világos legyen, továbbá egyértelmű legyen, hogy a Scrum Csapatnak mi lesz a következő
  • munkája, valamint
  • Annak biztosítása, hogy a Fejlesztőcsapat legalább a munkavégzéshez szükséges szinten érti a Termék Backlog egyes tételeit.

A Terméktulajdonos saját maga is elvégezheti a fenti teendőket, vagy a Fejlesztőcsapattal is elvégeztetheti azokat, viszont ez utóbbi esetben is a Terméktulajdonosé a felelősség. A Terméktulajdonos nem egy bizottság, hanem egyetlen személy. A Terméktulajdonos képviselheti egy bizottság kívánságait a Termék Backlogban, de ha a bizottság meg szeretné változtatni valamelyik Termék Backlog elem prioritását, akkor ezt csak a Terméktulajdonoson keresztül teheti meg.

Ahhoz, hogy a Terméktulajdonos sikeresen el tudja végezni a feladatát, a teljes szervezetnek tiszteletben kell tartania a döntéseit. A Terméktulajdonos döntései a Termék Backlog tartalmában és az elemek sorrendjében nyilvánulnak meg. Senki nincs felhatalmazva arra, hogy a Fejlesztőcsapattal a meghatározottól eltérő követelmény-rendszer szerint dolgoztasson, és a Fejlesztőcsapat sem fogadhat el utasítást senki mástól.


Fejlesztőcsapat (Scrum Developer Team)[szerkesztés]

A csapat azért felelős hogy a termék elkészüljön, legalább 3, legfeljebb 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 (programozók, grafikusok, tesztelők, ...)

A Fejlesztőcsapat olyan szakemberekből áll, akik azon dolgoznak, hogy minden egyes Sprint végén leszállítható legyen a termék egy “Kész” potenciálisan kibocsátható Inkrementuma. Az Inkrementum elkészítésében csak a Fejlesztőcsapat tagjai vesznek részt. A Fejlesztőcsapatokat úgy állítja össze és hatalmazza fel a szervezet, hogy ők maguk szervezzék és menedzseljék saját munkájukat. Az így létrejövő szinergia optimalizálja a Fejlesztőcsapat hatékonyságát és termelékenységét.

A Fejlesztőcsapatok az alábbi tulajdonságokkal rendelkeznek:

  • Önszerveződőek. Senki – még a Scrum Mester – sem mondja meg a Fejlesztőcsapatnak, hogy miként hozzanak létre a Termék Backlogból potenciálisan szállítható funkcionalitást tartalmazó Inkrementumokat,
  • A Fejlesztőcsapatok kereszt-funkcionálisak, és csapatként minden olyan ismerettel és készséggel rendelkeznek, ami szükséges a termék Inkrementumok elkészítéséhez,
  • A Scrum a „Fejlesztő”-n kívül nem alkalmaz külön titulust a Fejlesztőcsapat egyes tagjaira, függetlenül attól, hogy egyénenként milyen tevékenységet végeznek. Ez alól a szabály alól nincs kivétel.
  • A Fejlesztőcsapatokban nincsenek alcsoportok egyes célfeladatok – pl. tesztelés vagy üzleti elemzés – elvégzésére; ez alól a szabály alól nincs kivétel, illetve
  • A Fejlesztőcsapatban az egyes tagok speciális ismeretekkel, készségekkel és szakterületi tudással rendelkezhetnek, de a felelősség az egész Fejlesztőcsapatra, mint egy egységre hárul.

Scrum Mester[szerkesztés]

A Scrum Mester a Scrum népszerűsítéséért és támogatásáért felelős, a Scrum Útmutatóban foglaltaknak megfelelően. A Scrum Mesterek ezt az által érik el, hogy mindenkinek segítenek megérteni a Scrum elméletét, gyakorlati elemeit, szabályait és értékeit. A Scrum Mester a Scrum Csapat szolgáló-vezetője (servant-leader). A Scrum Mester segíti a Scrum Csapaton kívülieknek megérteni azt, hogy mely Scrum Csapattal való interakciójuk lesz hasznos és melyik nem. A Scrum Mester mindenkinek segít oly módon megváltoztatni ezeket az interakciókat azért, hogy azok a Scrum Csapat által létrehozott értéket maximalizálják.[6]

A Scrum mester szerepe többrétű. Ez egy támogató vezető szerepkör, fő célja a csapat teljesítményének növelése és a munkát akadályozó tényezők elhárítása, amelyek gátolják a csapatot abban, hogy a sprint célját megvalósítsa. A scrum mester nem a csapat vezetője, (a csapat önszerveződő), hanem a csapat és a külső tényezők közötti szereplő. Ü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 mester tartja mozgásban a csapatot (facilitátor), jelentős szerepet vállal az események lebonyolításában.

A Scrum mesterek nyolc feladatkörét Barry Overeem így fogalmazta meg:[7]

  • Támogató vezető, aki a csapat tagjaira és az általuk megteremtett ügyfél-érték megteremetésére összpontosít annak érdekében, hogy eredményeket érjenek el a szervezet értékeivel, alapelvekkel és üzleti célokkal összhangban.
  • Facilitátor, aki a keretek tiszta meghatározásával segíti az együttműködést. Ide tartozik a megbeszélések adminisztrációja, moderálása és dokumentálása is.
  • Coach, aki segít fejlődni az egyéneknek a gondolkodásmódra és a viselkedésre összpontosítva. A csapatot a folyamatos fejlődésben, míg a szervezetet a Scrum csapattal való valódi együttműködésben támogatja.
  • Menedzser, aki az akadályok kezeléséért, a pazarló folyamatok csökkentéséért, a folyamatokért és a csapat egészségének, az önszerveződés határainak kezeléséért és a kultúra támogatásáért felelős. Támogatást nyújt a projekten kívüli megrendelők számára a megfelelő riportok és eszkalációs anyagok összeállításában. Folyamatosan követi a sprint állapotát és a projekt állapotát. Időben észreveszi, ha a tervek veszélybe kerülnek és a csapattal közösen kitalálja, hogy megoldható a team-en belül a probléma vagy eszkalálni kell. Utóbbi esetben megoldási javaslattal együtt eszkalál.
  • Mentor, aki az agilis tudást és tapasztalatot átadja a csapatnak. Segít testreszabni a Scrum keretrendszer anélkül hogy a lényeges elemeket elhagyná vagy szembemenne azokkal. Támogatja a team-eket a módszertani elvek betartásában.
  • Tanár, aki biztosítja a Scrum és más vonatkozó módszerek megértését és bevezetését.
  • Akadálymentesítő, aki megoldja a csapat előrehaladását hátráltató tényezőket, figyelembe véve a problémát és a fejlesztőcsapat önszervező képességeit.
  • Változáskezelő, amely lehetővé teszi egy olyan kultúra kialakulását, amelyben a Scrum csapatok virágzhatnak.


Más érintettek[szerkesztés]

Az egyéb érintettek 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 sprintek 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 sprintá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észt vevő szervezeti egységek munkakörnyezetét teremtik meg. Nem csak a funkcionális vezetőket jelenti.

Megbeszélések[szerkesztés]

Sprinttervező megbeszélés (Sprint planning)[szerkesztés]

Minden sprint előtt sprinttervező 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.
  • sprint 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 sprint során.
  • 4 hetes sprint esetén maximum 8 óra hosszúságú, rövidebb sprint esetén ez az esemény is rövidebb.


Napi Scrum-megbeszélés[szerkesztés]

Nevéből adódóan minden nap (a demó napja kivétel lehet) megtartott esemény, az angol szakirodalomban Daily Scrumnak vagy Daily Standupnak nevezik. 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.

A következők vonatkoznak rá:

  • Bárki részt vehet, de főszabályként csak a Scrum csapat tagjai 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).
  • Minden nap ugyanazon a helyen és ugyanabban az időpontban tartják.
A megbeszélés során minden résztvevő ehhez hasonló kérdéseket válaszol meg:
  • Mi az, amit a tegnapi megbeszélés óta csináltam? (vagy mit tanultam?)
  • Mi az, amit a mai nap tervezek csinálni?
  • Vannak-e akadályok, amik gátolnak a saját és a sprint célok elérésében?

Az akadályok elhárításában a Scrum Mester segít a csapatnak.

A sprint végén két megbeszélést tartanak: „Sprintáttekintés” és „Visszatekintés”


Sprintáttekintés (Sprint Review / Demó)[szerkesztés]

  • 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 sprint esetén maximum 4 óra hosszúságú, rövidebb sprint esetén ez az esemény is rövidebb.


Visszatekintés (Retrospective / Retró)[szerkesztés]

  • A csapattagok véleményt alkotnak az elmúlt sprintrő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 sprint alatt? Mi az, amit a következő sprint során jobban lehetne csinálni?
  • 4 hetes sprint esetén maximum 3 óra hosszúságú, rövidebb sprint esetén ez az esemény is rövidebb.

Scrum munkaanyagok (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 munkaanyag (artifact) meglétét írja elő, ezek a Termék teendőlista, a Sprint teendőlista és a Növekmény (Increment).[8]

Termék teendőlistája (Product Backlog)[szerkesztés]

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.

Sprint teendőlistája (Sprint Backlog)[szerkesztés]

Egy Scrum teendő lista
A sprint teendőlistája olyan dokumentum, amely azt tartalmazza, hogy a csapat hogyan fogja elkészíteni a sprint 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 sprint 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 sprint 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 sprint során.

Növekmény (Increment)[szerkesztés]

A Növekmény, más szóval Inkrementum a Sprintben leszállított Termék Backlog elemeknek és az összes megelőző Sprint során szállított inkrementumok értékének összessége. A Sprint végére az új Inkrementumnak “Kész”-nek, azaz használhatónak kell lennie, és meg kell felelnie a Scrum Csapat által meghatározott “Kész” definíciójának. Az Inkrementum egy ellenőrizhető, “Kész” munkatermék, ami a Sprint végén az empirikus működést támogatja. Az Inkrementum egy lépés egy vízió vagy cél felé. Felhasználható állapotban kell lennie független attól, hogy a Terméktulajdonos úgy dönt, hogy ténylegesen kibocsátja-e azt.

Haladás követése a Scrumban[szerkesztés]

Az alábbi eszközök támogatják a haladás mérését és az előrejelzések elkészítését. Használatuk nem kötelező, értelmezésük kellő szaktudás birtokában hasznos információ a folyamatokat érintő döntések meghozatalához.

Burn down chart (egyfajta 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 sprint teendőinek a listájából hátralevő munka mennyiségét. Minden nap frissítik, egyszerű módon jeleníti meg a sprint állapotát.
Burn up chart
A sprint 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 sprint 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 sprint során elkészített elemek összpontszáma a csapat sebessége. Új csapatok esetén a sebesség jellemzően sprintről-sprintre 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 megbeszé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ő sprintre
  • backlog item - teendő
  • sprint (futam) - a sprinttervezés során kiválasztott teendők megvalósítására szánt rövid iteráció (1-4 hét)
  • daily standup - 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ó sprinttel kapcsolatban, és a csapat megegyezik hogy mit változtatnak a fejlesztési folyamaton következő sprint során.
  • sprint burn down chart - kimutatás a napi eredményekről a sprint során

Források[szerkesztés]

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

Kapcsolódó szócikkek[szerkesztés]

Jegyzetek[szerkesztés]