A Scrum története
Winston Royce "Nagy szoftverrendszerek fejlesztésének menedzselése" című jelentésének 1970-es megjelenése óta sokan próbáltak olyan módszertant találni, amely kiküszöbölheti a Waterfall fejlesztési modell hátrányait. A „vízesés” alternatívája a Scrum módszer volt, amelyről most lesz szó.
A Scrum nevét 1986-ban Takeuchi és Nonaki The New Rules for New Product Development című munkájáról kapta. Ez a dokumentum azzal érvel, hogy a cél elérésének leghatékonyabb módja az, ha világos cselekvési tervet adunk a fejlesztőknek.
1995-ben egy másik útmutató jelent meg, Sutherland és Schweiber "Szoftverfejlesztés a Scrummal". Ezt a kiadványt azóta többször frissítették. Most ez tekinthető a módszer fejlesztésének fő útmutatójának. A Scrum Guide jelenlegi verziója 2020-ban frissített információkat tartalmaz.
A Scrum Guide főbb rendelkezései azt sugallják, hogy a projektmenedzsment-sablont azon a tényen kell alapul venni, hogy a fejlesztők a készterméket a megbeszélt időkereten – sprinteken belül – szállítják. A Scrum sikeres megvalósításához több elemből álló struktúra használata javasolt: szerepek, események, szabályok és műtermékek.
Szerepek a Scrumban
A Scrumban három szerep van, amelyek mindegyike egy Scrum csapatot alkot:
A szoftvertermék vásárlója a legfontosabb személy a projektben, mert csak ő érti teljesen annak értékét a vállalkozás számára. A megrendelő ismerteti a fejlesztőkkel a leendő termék felhasználóinak igényeit, de a fejlesztési folyamat technikai részéért nem vállal felelősséget. A vevő határozza meg a prioritást a termék egyes elemeinek vagy funkcióinak létrehozásakor is.
A fejlesztőket olyan műszaki feladatok végrehajtásával bízzák meg, amelyek keresztfunkcionalitása az alkalmazási körtől függ. A fejlesztők a sprint hátralék létrehozásával, a kód írásával, a projekt sprint célhoz való igazításával és egyéb feladatokkal vannak elfoglalva.
A Scrum Master a Scrum csapat facilitátora. Segítséget nyújt az ügyfeleknek és a fejlesztőknek. Egyszerűen fogalmazva, a Scrum Master elfoglalt a kommunikációval azok között, akik nem vesznek részt a projektben, és a kódot író emberek között. Néha ugyanabban a nagy cégben különböző kódolócsapatok kommunikálnak és koordinálnak e csapatok scrum mestereinek közgyűlésén.
Események a Scrumban
5 típusú scrum esemény létezik:
A Sprint a Scrum legjelentősebb része. Tartalmazza a sprint tervezését, a napi stand-upokat (napi scrum), a sprint áttekintését és visszatekintését.
Sprint tervezés. A Scrum csapat minden tagja részt vesz a jövőbeli sprint tervének kidolgozásában. Itt kerül bemutatásra a termékötlet, és minden csapattag elmondhatja véleményét, mit gondol erről. Ezt követően az ülésen meghatározzák a prioritásokat és kihirdetik a határidőket.
A Daily Scrum egy napi rövid scrum esemény, amely legfeljebb 15 percig tart. Általában azért történik, hogy a kódolók munkáját mára vagy holnapra tervezzék. A Daily Scrumban aktuális kérdéseket vitathatsz meg. Minden, a projektben részt vevő fejlesztőnek részt kell vennie egy ilyen workshopon. A Scrum Master jelenléte megengedett, de nem kötelező.
Sprint áttekintése (demó) – A sprint során létrehozott eredmények megjelenítése. Általában erre az eseményre a végső szakaszban kerül sor. Minden érdeklődő részt vesz benne.
Sprint Retrospektív - a sprint eredményeinek megvitatása. A csapattagok elmondják véleményüket arról, hogyan birkóztak meg a rájuk bízott feladatokkal, és hogyan javíthatják a jövőben a munka eredményét.
Ezen kívül időnként lemaradás finomításra is sor kerül - Hátralék finomítás. Megtárgyalja a hátralékos tételeket, a következő sprintre való felkészülést és az aktuális feladatok rangsorolását.
Műtárgyak
A Scrum műtermékek olyan munkák, amelyek egy projekt vagy sprint végén történik. Három műtermék van – a termékhátralék, a sprint hátralék és a növekedés. Mindegyikre szükség van a szoftverek időben történő eljuttatásához a felhasználókhoz. Vannak kiegészítő műtermékek is (leégési diagramok és egyebek).
A sprint műtermékek összetevői:
Termékhátralék – felület és háttérszolgáltatások.
A sprint hátralék az iteráció során elvégzendő feladatok listája. A sprint rajtja előtt megegyeznek.
Növekedés – A sprint során létrehozott szoftverhátralék tételek teljes száma és az előtte végrehajtott növekmény értéke. A kész új növekményt a sprint vége előtt fel kell mutatni. Ez azt jelenti, hogy van egy működő verziója, amely megfelel a scrum csapat követelményeinek.
Termék hátralékos tétel – a sprint iterációja során kell teljesíteni. Az elem általában több kis feladatra van felosztva.
A sprint cél az elvégzendő feladatok (hátraléktétel vagy egyéb feladat létrehozása).
A sprint leégése a sprint vége előtt hátralévő munka. A kiégési diagram vagy növekvő vagy csökkenő. Minden attól függ, hogy a csapat tagjai milyen nehézségekkel szembesülnek munka közben. Ez nem a haladás mutatója, hanem csak a problémák megoldásának módja és ösztönzése.
A termékkiadási/termékleégési diagram a Scrum Master által a következő sprint vége előtt készített diagram. A vízszintes tengely a sprintek, a függőleges tengely a hátralévő munka mennyisége.
Scrum keretszabályok
A szerepek, események és műalkotások a Scrum alapját képezik, de ezen kívül vannak más szabályok is. Mindegyik növeli a munkafolyamat hatékonyságát. Íme a szabályok listája:
- A scrum csapat tagja a szoftverügyfél, a scrum mester és a fejlesztők.
- Minden sprintnek azonos hosszúságúnak kell lennie.
- Egy sprint teljesítése után azonnal megkezdődik a munka egy újon.
- A sprint mindig egy tervvel kezdődik.
- A csapattagoknak a munkanapjuk kezdetén reggeli súrlódás van.
- Minden sprintet minden sprint során felülvizsgálnak. Ez javítja a kommunikációt a csapat és az érintettek között.
- Nem javasolt a sprint lemaradás módosítása a sprint során.
A Scrum korlátozásai
A nyilvánvaló előnyök mellett a Scrumnak vannak hátrányai is:
- A Scrum gyakran az elvégzett munka mennyiségének csökkenéséhez vezet a közös határidő hiánya miatt.
- A projekt résztvevőinek alacsony részvétele vagy együttműködési hajlandósága esetén jelentős az esély az eredmény kudarcára.
- A Scrum struktúrát nehéz használni nagy csapatokban, de mégis lehetséges. Ehhez vannak méretezési keretrendszerek: LeSS, SAFe, Nexus és mások.
- Egy vagy több tag távozása a csapatból a projekt közepén nem nagyon befolyásolja a projektet.