„Mes naudojame Scrum“ – sako man įmonės vadovas. O tada prideda: „Tačiau Scrum komandos, nesugeba padaryti ką prisižadėjo per sprintą. O ir padaro labai mažai. Vaidai, gal gali mums pagelbėti pagreitinti mūsų Scrum komandų darbą?“. „Pasigilinkime į jūsų situaciją“ – pasiūliau.
Produkto šeimininkas produktui (sričiai) ar komandai?
Pradėjus gilintis į šios įmonės situaciją paaiškėjo, jog jie turi kelis produktų šeimininkus (product owners) rolę. Jie turi subūrę tris daugiafunkcines (cross-functional) Scrum komandas. Bet kuri komanda gali imtis praktiškai bet kokios funkcijos įgyvendinimo. Viskas atrodytu puiku, bet…
Jų produkto šeimininkai yra atsakingi už tam tikrą produktą (sistemos dalį). Taigi kasdienėje situacijoje gaunasi, jog komandos sprintuose dirba praktiškai su visais produktų šeimininkais. T.y. jie neturi savo komandos produkto šeimininko. Jau turbūt galite įsivaizduoti problemas kylančias su Scrum susirinkimais (visi produktų šeimininkai dalyvauja visų komandų susirinkimuose), prioritetų valdymu (neaišku kieno prioritetai svarbesni, ką informuoti jeigu darbai pasidarė greičiau ar lėčiau sprinto metu) ir apskritai su komunikacija (komunikacijos kanalų pasidaro labai daug).
Ką siūlo Scrum? Scrum metodika sako, jog komanda privalo turėti vieną ir tik vieną produkto šeimininką, kuris yra Scrum komandos dalis, kartu su Scrum meistru ir komanda. Tai jokiu būdu nereiškia, jog jis turi tapti visų sistemos dalių ekspertas ar kad komanda nebendraus su kitais produktų šeimininkais. Tai tiesiog reiškia, jog komanda turės vieną žmogų kuris priima sprendimus apie savo komandos darbų prioritetus ir apimtį. O jau šio žmogaus darbas ir atsakomybė yra pasirūpinti, kad jo komandos produkto darbų sąrašas būtų paruoštas ir prioretizuotas teisingai. Jis bendraus su kitais produkto šeimininkais, diskutuos su jais dėl prioritetų ir apimties. Pakvies juos detaliau papasakoti ir priimti jų kuruojamo produkto (sistemos dalies) funkcionalumą, kurį įgyvendins jo komanda.
Kaip mes organizavome produkto valdymą su daug komandų Adform‘e dalinausi pranešime “Agile Product Management With Product Developed By Many Teams”.
Sprinto planavimas
Scrum komandos supranta sprinto planavimo svarbą, organizuoja sprinto planavimo susirinkimą ir nuoširdžiai stengiasi darbus išsiskaidyti ir susiplanuoti. Viskas atrodytų puiku, bet…
Scrum komandos apie funkcijas kurias programuos šiame sprinte sužino tik atėję į sprinto planavimą. Be abejo, komandos nariams kyla daug klausimų, kurių dalies produkto šeimininkas iš karto atsakyti negali (turi pasitikslinti). Natūraliai, sprinto planavimas užsitęsia gan ilgai.
Dar blogiau, darbus komandoms bandoma paskirstyti sprinto planavimo metu. Pavyzdžiui, po komandos planavimo paaiškėjo, jog kažkoks labai svarbus įmonei darbas netilpo į jos sprinto planą. Taigi nors kita komanda jau praleido laiką detaliai planuodama jai paskirtas funkcijas, jas atideda ateičiai ir ima planuotis kitai komandai netilpusią funkciją.
Ką siūlo Scrum? Scrum metodika sako, jog produkto darbų sąrašas turi būti paruoštas ir fiksuotas iki sprinto planavimo susirinkimo. Jei yra kelios Scrum komandos įmonėje, produkto šeimininkai iš anksto tariasi ir numato kuri funkcija į kurios komandos produkto darbų sąrašą paklius. Tai daro kartu su vyriausiu produkto šeimininku. Tam, be abejo, reikia žinoti funkcijų apimtį, kokio dydžio yra užduotis. Čia pasitarnauja produkto darbų sąrašo smulkinimo susirinkimai (product backlog grooming meeting). Jie daromi reguliariai viduryje sprinto. Šiuose susirinkimuose komanda susipažįsta su artėjančiomis į gamybą funkcijomis, patiekia savo klausimus ir siūlymus ir svarbiausia, įvertina funkcijos dydį.
O ką daryti jei sprinto planavimo metu paaiškėja, jog funkcija visgi nėra visiškai aiški ir produkto šeimininkas negali atsakyti į daug klausimų apie detales kaip ji turi veikti? Tada Scrum meistras turėtų nepriimti tokio darbo į sprintą. Jis atidedamas į produkto darbų sąrašą ir galės būti paimamas tik kitame sprinte kai bus detalizuotas. O ką daryti jei aiškių darbų nėra, paklausite? Na, iš tikrųjų, nedaryti nieko, yra geriau nei daryti tai ko nereikės ar neaišku ar/kaip reikės. Ir aš su tuo sutinku. Be to, komanda visada turi gerų techninių užduočių sąrašą. Jie gali imtis jų kol produkto šeimininkas paruoš funkciją gamybai (detaliam planavimui).
Nekeisti sprinto plano sprinto metu
Scrum komandos susiplanavo sprintą, stengiasi įvykdyti savo prisiimtus įsipareigojimus, daro kasdienius stovimus susirinkimus, seka deginimo kreivėse kaip jiems sekasi. Viskas atrodytu puiku, bet…
Sprinto metu staiga atsiranda daug „neplanuotų“ darbų. Ir tai ne tik sistemos klaidos. Tai ir nauji užsakymai, mažos funkcijos, pataisymai, duomenų „ištraukimai“ ir pan. Natūraliai, tai ką susiplanavo komanda sprintui lieka nepadaryta arba padaryta ne iki galo. Kartais išleidžiama funkcija klientams ne visiškai išbaigta, kas įtakoja dar daugiau klaidų, pataisymų ir keitimų… ateinančiuose sprintuose.
Ką siūlo Scrum? Scrum metodika sako, jog komandos prisiima įsipareigojimą, ką padarys per dvi savaites ir tai turi būti nekeičiama. Scrum meistras turi stebėti ar „neatsiranda“ naujų darbų sprinte arba ar nesiplečia esamų darbų apimtis, susitarta per sprinto planavimą. Jei įmonėje kažkas labai rimtai pasikeičia, produkto šeimininkas turi teisę prašyti nutraukti sprintą (abnormal sprint termination). Tada visi padaryti šiame sprinte darbai tiesiog išmetami (juk jų nepabaigėme iki galo kokybiškai), o komanda sėda planuotis naujo sprinto. Kaip suprantate, tai turi būti labai reti ir išimtiniai atvejai.
Sakote taip neįmanoma? Įmonė negali neturėti neplanuotų darbų dviems savaitėms? Taip, jūs teisūs. Tačiau yra būdų kaip suvaldyti neplanuotus darbus taip, kad jie negriautų sprintų ir Scrum proceso. Apie tai pasakojau šiame pranešime “Starting Agile in a Company”.
Kaip pagreitinti gamybą?
Taigi mano patarimas šiai (ir daugeliui su panašiomis problemomis susiduriančių įmonių) yra paprastas: gamybos greitį padidinsite tada, kai susitvarkysite su projektų (darbų padavimo gamybai) valdymu, t.y. išmoksite planuoti bent porai sprintų į priekį. Tada gamybos komandos galės tikrai „sprintuoti be stabdžių ir trukdžių“. O tai leis labai greitai kilti gamybos greičiui.
Ar tai paprasta? Tikrai ne. Kodėl? Todėl, kad reikia ne tik noro, bet ir labai daug valios. Labai lengva pasakyti, jog komandos programuoja lėtai. Daug sunkiau pripažinti, jog mes neparuošiame gerų produkto darbų sąrašų, kurie atitinka su komanda susitartą „paruošta“ (ready) kriterijų.
Kaip liaudyje sakoma, pirmas žingsnis į pasveikimą yra ligos pripažinimas. Konkreti ši įmonė, vis dar mano, kad reikia greitinti komandų darbą. „Juk mes turime būti Agile, lankstūs, pas mus viskas greitai keičiasi“ – sako jie. Na, mano patirtis rodo, kad lanksčiu ir greitu galima būti tik griežtai besilaikant nors minimalių procesų. Kitaip, tai jau nebe Agile, tai tiesiog chaosas, kurį pavadiname Agile… tam kad save pateisinti?!..
Kokios jūsų patirtys? Ar turėjote/turite iššūkių su darbų paruošimu gamybai? Kaip juos sprendėte/sprendžiate?