Scrum
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 kihívás lehet mesteri szintre fejleszteni.
Kialakulása
szerkesztésAz 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ésA 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ésScrum Csapat
szerkesztésA 2020-as Scrum Útmutató módosítása [6] jelentős változtatást hozott a Scrum keretrendszerbe: kivették a Fejlesztőcsapat kifejezést, ami azt az érzetet keltette, hogy az egy kisebb csapat a csapatban. Az új változatban egy Scrum csapat létezik, aminek a Terméktulajdonos és a Scrum Mester is szerves része. Ők együttesen felelősek a létrehozott eredményekért.
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 felelős a termék értékének maximalizálásáé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ők á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ők legalább a munkavégzéshez szükséges szinten értsék a Termék Backlog egyes tételeit.
A Terméktulajdonos saját maga is elvégezheti a fenti teendőket, vagy a Fejlesztők is elvégezhetik 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őkkel a meghatározottól eltérő követelmény-rendszer szerint dolgoztasson, és a Fejlesztők sem fogadhatnak el utasításokat másoktól.
Fejlesztők (Developers)
szerkesztés- A Fejlesztők azért felelősek, hogy a termék elkészüljön. A csapattagok különféle képességei lehetővé teszik hogy a feladatot közösen megoldják (üzleti elemzők, UX tervezők, programozók, grafikusok, tesztelők, stb.)
A Fejlesztők olyan szakemberek, akik azon dolgoznak, hogy minden egyes Sprint végén leszállítható legyen a termék egy “Kész” potenciálisan kibocsátható növekménye. A növekmény elkészítésében csak a Fejlesztők vesznek részt. A Fejlesztők maguk szervezik és menedzselik a saját munkájukat. Az így létrejövő szinergia optimalizálja a Scrum csapat hatékonyságát és termelékenységét.
A Fejlesztők az alábbi tulajdonságokkal rendelkeznek:
- Önszerveződőek. Senki – még a Scrum Mester – sem mondja meg a Fejlesztőknek, hogy miként hozzanak létre a Termék Backlogból potenciálisan szállítható funkcionalitást tartalmazó növekményeket,
- A Fejlesztők, beleértve a teljes Scrum csapatot keresztfunkcionális, és csapatként minden olyan ismerettel és készséggel rendelkeznek, ami szükséges a termék növekmények elkészítéséhez,
- A Scrum a „Fejlesztő”-n kívül nem alkalmaz külön titulust az egyes tagokra, 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ők körében 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ők körében az egyes tagok speciális ismeretekkel, készségekkel és szakterületi tudással rendelkezhetnek, de a felelősség a teljes Scrum csapatra, mint egy egységre hárul.
Scrum Mester
szerkesztésA 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.[7]
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:[8]
- Támogató vezető, aki a csapat tagjaira és az általuk megteremtett ügyfél-érték megteremté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 keretrendszert 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ágozhatnak.
Más érintettek
szerkesztésAz 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ésSprint Tervezé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ésNevé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.
Sprint 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ésAz 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).[9]
Termék követelménylistája (Product Backlog)
szerkesztés- A „termék követelménylistája” ez egész termékre vonatkozóan tartalmaz magas szintű követelményleí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 követelménylistá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 az ún. user story (felhasználói történet).
Sprint teendőlistája (Sprint Backlog)
szerkesztés- 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 Feladattáblát (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ésA 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 növekmények értékének összessége. A Sprint végére az új növekménynek “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. A növekmény egy ellenőrizhető, “Kész” munkatermék, ami a Sprint végén az empirikus működést támogatja. A növekmény 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ésAz 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)
- 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 növekményes. 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ésA 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.
Scrum bullying
szerkesztésA munkahelyi zaklatás újszerű formája a Scrum bullying. A munkahelyi zaklatás nem újkeletű jelenség, a Scrum bullying ennek egy új válfaja, amit agilis szervezetek fejlesztése kapcsán figyelhető meg. A zaklatók jellemzően az agilis keretrendszert előíró dogmaként értelmezik. Ennek az a kockázata, hogy a jó szándék ellenére a kioktató/előíró stílus megfojtja a pszichológiai biztonságot,[10] elbizonytalanítja a letorkolt munkavállalót, így nem fog a továbbiakban bátran próbálkozni az újonnan elsajátított agilis szemlélet alkalmazásával.
Az agilis coach 12 pontja
szerkesztésAz Agilis Manifesztó szerzőinek 12 alapelvére reflektálva a Budapesti Metropolitan Egyetem[11] vezetésével 24 hazai agilis szakember megfogalmazta[12][13] ajánlásait a hatékony agilis coaching mellett, a scrum bullying visszaszorításának érdekében.
- Elégítsük ki ügyfeleink, az általunk támogatott szervezet munkavállalóinak agilitással kapcsolatos igényeit azáltal, hogy poroszos szigorral való letorkolás helyett a napi gyakorlatban mutatunk példát a mikéntekre.
- Legyünk mi, agilis coachok és szakértők is nyitottak a változásra, igyekezzünk az ügyfél igényeihez igazítani az agilis implementációt a keretek megtartása mellett.
- Sok, kis lépésben haladjunk, nagy big bang helyett, hogy az ügyfél értékteremtése folyamatos maradjon. Nem teremthetünk válságot a hirtelen bevezetett agilis eszközök által.
- Agilis coachként dolgozzunk közösen a támogatott csapattal a probléma megoldásán.
- Bízzunk azokban, akiket támogatunk, bátorítsuk őket, hogy próbálkozzanak, hibázzanak és tanuljanak a hibáikból. Hallgassunk és figyeljünk.
- Lehetőleg élőszóban adjunk visszajelzést, építő jelleggel, soha ne alázzuk meg a fogadó felet. Gyakran a jó kérdések segítenek leginkább abban, hogy a vezetők/csapatok maguk találják meg és magukénak érezzék a megoldásaikat.
- Sikerünk mércéje a működő agilis csapatok és szervezetek és azok értékteremtő képességének növekedése.
- Akkor dolgoztunk fenntarthatóan, ha támogatásunk következményeképp a csapatok és a szervezet önállóan képes tovább fejlődni.
- Tartsuk fenn az önfejlesztés iránti folyamatos igényünket, ismerjük tudásunk határait.
- Az egyszerűség nagyszerű – nem lövünk ágyúval verébre.
- Támogassuk az önszerveződést, ezért a csapatokat nem az egyes agilis gyakorlatokra tanítjuk be, hanem a szemléletet átadva fejlesztjük őket, így képesek lesznek egy idő után maguk megválasztani az eszközeiket. Minden helyzet és minden csapat más és más. Dolgozzunk a rutinunk alapján, de soha ne dolgozzunk rutinból.
- Kérjünk rendszeres időközönként visszajelzést a munkánkkal kapcsolatban; ügyféltől és szakmai közösségtől.
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 a következő sprint során.
- sprint burn down chart – kimutatás a napi eredményekről a sprint során
- DoD – Definition of Done – a megvalósításra irányuló ígéret a PO felé; lehet plain szöveg vagy ellenőrző lista
Források
szerkesztés- (PDF) Ken Schwaber, Jeff Sutherland (2011). The Scrum Guide - The Definitive Guide to Scrum: The Rules of the Game
- (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 2014. január 10.
- (video) Ken Shwaber in Scrum et al. Archiválva 2008. január 26-i dátummal a Wayback Machine-ben elérés 2008. január 19.
További információk
szerkesztés- Hivatalos Scrum Guide fordítá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.
- scrum.org
- International Scrum Institute
- iceScrum (Open Source Scrum Tool)
- Mi az a scrum?
- Az agilis coach 12 alapelve
- Mit tanultam a Scrumból Archiválva 2020. január 13-i dátummal a Wayback Machine-ben (angol)
Kapcsolódó szócikkek
szerkesztésJegyzetek
szerkesztés- ↑ Archivált másolat. [2019. április 5-i dátummal az eredetiből archiválva]. (Hozzáférés: 2019. november 19.)
- ↑ https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Hungarian.pdf
- ↑ Takeuchi and Nonaka: The New New Product Development Game (Harvard Business Review, Jan-Feb 1986)
- ↑ Wicked Problems, Righteous Solutions ([1])
- ↑ http://jeffsutherland.com/scrum/FirstScrum2004.pdf
- ↑ Scrum Útmutató 2020 magyar. (Hozzáférés: 2021. január 14.)
- ↑ https://scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Hungarian.pdf
- ↑ https://www.scrum.org/resources/8-stances-scrum-master
- ↑ Cite web-hiba: a title paramétert mindenképpen meg kell adni!
- ↑ A pszichológiai biztonság megeszi reggelire a stratégiát és a cégkultúrát (Móricz Emese, 2018. április 20.)
- ↑ Agilis Projektmenedzsment Kutató Központja Archiválva 2020. január 13-i dátummal a Wayback Machine-ben
- ↑ Csaba Zoltán-Mizsei Szabolcs: Kiáltvány az agilis módszertani zaklatás ellen (magyar nyelven). IT Business, 2019. [2020. január 13-i dátummal az eredetiből archiválva]. (Hozzáférés: 2019. szeptember 23.)
- ↑ Csaba Zoltán-Miszei Szabolcs: 12 alapelv agilis coachoknak. (Hozzáférés: 2020. január 13.)