Scrum
Scrum este un cadru agil care ajută echipele să abordeze munca complexă în cicluri scurte, iterative, prin roluri, evenimente și artefacte fixe.
Scrum este un cadru agil pentru dezvoltarea și gestionarea produselor complexe, conturat inițial în dezvoltarea de software și folosit acum în multe industrii. Se bazează pe ideea controlului empiric al proceselor: în loc să planifice o sarcină de la început până la sfârșit din timp, o echipă lucrează în intervale scurte, fixe, numite sprinturi, care durează de obicei una până la patru săptămâni. Fiecare sprint se încheie cu o creștere utilizabilă a lucrului, ceea ce creează spațiu pentru feedback și permite echipei să își ajusteze pașii următori. Această combinație de transparență, inspecție și adaptare face din Scrum o potrivire bună pentru munca în care cerințele sunt incerte sau susceptibile să se schimbe.
Scrum stabilește trei roluri fixe. Responsabilul de produs (product owner) deține valoarea produsului și menține backlogul de produs, o listă prioritizată a tot ce trebuie făcut. Scrum masterul menține echipa lucrând în cadrul stabilit, elimină obstacole și facilitează colaborarea, fără a atribui direct sarcini. Echipa de dezvoltare planifică și execută munca pe cont propriu. Patru evenimente recurente dau structură fiecărui sprint: planificarea sprintului la început, daily scrum-ul pentru aliniere rapidă, revizuirea sprintului pentru a arăta ce a fost construit și retrospectiva sprintului pentru a îmbunătăți modul în care echipa lucrează împreună.
Scrum funcționează cel mai bine pentru sarcini în care scopul sau soluția nu sunt complet clare de la început, precum dezvoltarea de produse sau proiectele complexe cu mulți factori interesați. Se deosebește de Kanban prin intervalele de timp fixe și rolurile definite, în timp ce Kanban se bazează mai mult pe un flux continuu, fără iterații stabilite. Comparativ cu planificarea clasică de tip cascadă, avantajul lui este inspecția regulată: greșelile de judecată ies la iveală din timp, nu doar la finalul proiectului. În practică, Scrum tinde să eșueze nu din cauza cadrului în sine, ci din cauza execuției pe jumătate, de exemplu atunci când retrospectivele sunt sărite sau backlogul rămâne neîntreținut.
Exemplu practic
O companie de dimensiune medie din construcția de mașini dezvoltă un nou software pentru monitorizarea echipamentelor de producție. Echipa de cinci persoane lucrează în sprinturi de două săptămâni: la începutul fiecărui sprint, alege cele mai importante zece elemente din aproximativ 40 de intrări deschise din backlog, sincronizându-se zilnic într-un daily scrum de 15 minute. După zece sprinturi, în cinci luni, o primă versiune utilizabilă este gata, în loc de cele nouă luni de dezvoltare fără rezultat intermediar pe care echipa le planificase inițial. Retrospectivele dezvăluie că cerințele neclare au costat echipa aproximativ 20 de procente din capacitate în primele trei sprinturi, așa că responsabilul de produs începe de atunci să scrie descrieri mai clare pentru backlog.
Cum ajuta Leanshift
În esență, retrospectiva sprintului este doar un ciclu Kaizen recurent: echipa se oprește, privește onest munca tocmai încheiată și face o îmbunătățire deliberată a modului în care lucrează, înainte de a merge mai departe. Asta se potrivește cu viziunea Leanshift că îmbunătățirea nu este un proiect unic, ci un obicei regulat, integrat în munca zilnică. Echipele care trăiesc astfel nu îmbunătățesc doar produsul, ci creează mai mulți oameni care știu să îmbunătățească lucrurile singuri.
Intrebari frecvente
Este Scrum util doar pentru dezvoltarea de software?
Nu. Scrum a început în software, dar este folosit acum în marketing, dezvoltare de produse, educație și alte domenii, oriunde munca este complexă și cerințele se pot schimba pe parcurs.
Prin ce se deosebește Scrum de Kanban?
Scrum se derulează în intervale de timp fixe numite sprinturi, cu roluri și evenimente definite, în timp ce Kanban vizualizează un flux continuu de muncă, fără iterații stabilite, și se concentrează pe limitarea a cât de multă muncă este în desfășurare la un moment dat.
Are o echipă mică cu adevărat nevoie de un scrum master dedicat?
Nu neapărat ca rol cu normă întreagă. În echipele mici, cineva își asumă adesea acest rol pe lângă munca obișnuită; ce contează este ca facilitarea și cadrul în sine să fie respectate cu adevărat.