Scrum
A Scrum egy agilis keretrendszer, amely segít a csapatoknak rövid, iteratív ciklusokban, rögzített szerepek, események és artefaktumok révén megbirkózni a komplex munkával.
A Scrum egy agilis keretrendszer komplex termékek fejlesztésére és irányítására, amely eredetileg a szoftverfejlesztésben alakult ki, és ma már számos iparágban használatos. Az empirikus folyamatirányítás elvére épül: ahelyett hogy egy feladatot előre, elejétől végéig megterveznénk, a csapat rövid, rögzített időkeretekben, úgynevezett sprintekben dolgozik, amelyek jellemzően egy-négy hétig tartanak. Minden sprint egy használható munkaeredménnyel zárul, ami teret ad a visszajelzésnek, és lehetővé teszi a csapatnak, hogy igazítsa a következő lépéseit. Az átláthatóság, az ellenőrzés és az alkalmazkodás ilyen kombinációja teszi a Scrumot alkalmassá olyan munkára, ahol a követelmények bizonytalanok, vagy valószínűleg változni fognak.
A Scrum három rögzített szerepet határoz meg. A product owner felel a termék értékéért, és karbantartja a product backlogot, az elvégzendő feladatok priorizált listáját. A scrum master gondoskodik arról, hogy a csapat a keretrendszeren belül dolgozzon, elhárítja az akadályokat, és elősegíti az együttműködést anélkül, hogy közvetlenül osztana ki feladatokat. A fejlesztőcsapat önállóan tervezi és végzi el a munkát. Négy ismétlődő esemény adja meg minden sprint szerkezetét: a sprint tervezés az elején, a napi scrum a gyors egyeztetéshez, a sprint review a megépített dolgok bemutatásához, és a sprint retrospektíva a csapat együttműködésének javításához.
A Scrum akkor működik a legjobban, ha a terjedelem vagy a megoldás kezdetben nem teljesen tiszta, például terméktervezésnél vagy sok érintettel rendelkező komplex projekteknél. A Kanbantól a rögzített időkeretekben és a meghatározott szerepekben különbözik, míg a Kanban inkább egy folyamatos folyamra épít, rögzített iterációk nélkül. A klasszikus vízesés-tervezéshez képest az előnye a rendszeres ellenőrzés: a téves megítélések korán felszínre kerülnek, nem csak a projekt végén. A gyakorlatban a Scrum nem magától a keretrendszertől szokott elbukni, hanem a félszívű végrehajtástól, például amikor kihagyják a retrospektíveket, vagy a hátralékot nem tartják karban.
Gyakorlati példa
Egy középvállalati gépgyártó cég új szoftvert fejleszt a termelőberendezései felügyeletére. Az öt fős csapat kéthetes sprintekben dolgozik: minden sprint elején kiválasztja a tíz legfontosabb tételt a mintegy 40 nyitott hátraléktételből, és naponta egyeztet egy 15 perces napi scrumon. Tíz sprint, azaz öt hónap után elkészül az első használható verzió, ahelyett hogy a csapat eredetileg tervezett kilenc hónapos, közbenső eredmény nélküli fejlesztést végezné. A retrospektívek felfedik, hogy a tisztázatlan követelmények az első három sprintben a csapat kapacitásának mintegy 20 százalékába kerültek, ezért a product owner ettől kezdve élesebb hátraléktétel-leírásokat kezd írni.
Hogyan segít a Leanshift
A sprint retrospektíva a lényegét tekintve egy ismétlődő Kaizen-ciklus: a csapat megáll, őszintén megnézi az imént befejezett munkát, és tudatos javítást hajt végre a saját munkamódszerén, mielőtt továbblépne. Ez illeszkedik ahhoz a Leanshift-nézőponthoz, hogy a fejlődés nem egyszeri projekt, hanem a mindennapi munkába épített rendszeres szokás. Azok a csapatok, amelyek így élnek, nemcsak a terméket javítják, hanem több olyan embert is kinevelnek, akik tudják, hogyan fejlesszék maguk a dolgokat.
Gyakran ismételt kérdések
Csak a szoftverfejlesztésben hasznos a Scrum?
Nem. A Scrum a szoftverfejlesztésben indult, de ma már a marketingben, a terméktervezésben, az oktatásban és más területeken is használják, mindenhol, ahol a munka komplex, és a követelmények útközben változhatnak.
Miben különbözik a Scrum a Kanbantól?
A Scrum rögzített időkeretekben, úgynevezett sprintekben zajlik, meghatározott szerepekkel és eseményekkel, míg a Kanban a munka folyamatos folyamát vizualizálja rögzített iterációk nélkül, és arra összpontosít, hogy korlátozza, mennyi van egyszerre folyamatban.
Tényleg szüksége van egy kis csapatnak dedikált scrum masterre?
Nem feltétlenül teljes munkaidős szerepként. Kis csapatokban gyakran valaki a rendes munkája mellett látja el; az számít, hogy a facilitálás és maga a keretrendszer valóban fennmaradjon.