„Mes norime turėti gerą produkto darbų sąrašą, tad kartu su visa komanda kas savaitę po 4 valandas ruošiame jį“ – pasakoja man viena Scrum komanda. „Ar tikrai efektyviai jūs išnaudojate savo laiką“ – paklausiau aš. „Ar nėra čia pasislėpusi kita problema kurią reikėtų spręsti?“ – pridūriau.
Tikslas
Visa komanda turi žinoti artėjančius darbus produkto darbų sąraše, turėti galimybę pateikti savo nuomonę ir komentarus, juos įvertinti. Taip visa komanda įsitraukia į projektą, prisideda savo ekspertiniais patarimais ir tiksliai gali prognozuoti kada vieną ar kitą funkciją pagamins.
Priemonė
Tam dažniausiai daromas produkto darbų sąrašo tvarkymo susirinkimas (product backlog grooming). Jis turėtų trukti ne ilgiau kaip valandą poros savaičių sprintui. Tai kaip nutiko kad jis trunka 4 valandas? Ir kas savaitę, o ne kas dvi kaip turėtų būti dviejų savaičių sprinte?
Problema
Taip nutinka tada, kai produkto šeimininkas nepadaro savo darbo – neparuošia gerai produkto darbų sąrašo. Kad neatrodytų taip blogai, jis susirašo kelias „idėjas“ į produkto darbų sąrašą. Dar net spėja kartais vartotojo pasakojimus (user stories) joms parašyti. Žiūrint tik į produkto darbų sąrašą nieko neprikiši, jis paruoštas.
Problema paaiškėja, kai prasideda diskusija su komanda. Jie užduoda daugybę klausimų, vartotojo pasakojimas pasirodo labai didelis, jį pradedame skaldyti, gilintis į mažesnes dalis ir t.t. Valandos efektyvus susirinkimas virsta nekonstruktyvia kelių valandų diskusija.
Sprendimas
Bet juk, sakysite, produkto šeimininkas negali vienas paruošti gero produkto darbų sąrašo. Jam reikia techninių atsakymų, pasiūlymų, patarimų. Visiškai teisingai. Jis juk žino kas šituos klausimus gali atsakyti. Kas gali papildyti. Su kuo yra svarbu pasitarti. Todėl dirbdamas prie produkto darbų sąrašo, produkto šeimininkas privalo bendrauti su daug žmonių, nuolat rašyti, taisyti ir tobulinti kiekvieną funkciją ir jos aprašymą.
Atėjęs į produkto darbų sąrašo tvarkymo susirinkimą, jis pristato norimą pagaminti funkciją, ką ji turi atlikti, kokią verslo naudą atneš. Apie funkciją trumpai padiskutuojama ir komanda vertina jos dydį. Taip komandos spėja išsidiskutuoti, susmulkinti ir įvertinti reikiamas funkcijas per vieną valandą (dviejų savaičių sprintui).
Noriu pabrėžti, jog čia kalbame apie jau įsibėgėjusį projektą ar komandą kuri jau turi produkto darbų sąrašą ir prie jo dirba. Jeigu prasideda naujas didelis projektas, be abejo, pradiniam produkto darbų sąrašui paruošti reikės daugiau laiko, gal net kelių dienų. Tačiau visos komandos į visą paruošimo procesą įtraukti nebūtina. Būtina komandą supažindinti su jau “apkramtytu” produkto darbų sąrašu, kad jie turėtų galimybę su juo susipažinti, pateikti savo pastabas ir, svarbiausia, įvertinti darbų dydžius. Keletas patarimų čia tema rasite straipsnyje “Kaip vyko Agile projekto starto susitikimas“.
Šalutinis poveikis
Kas gali nutikti jeigu dirbtinai produkto planavimo susirinkimus darysime trumpus? Vertinsime ne iki galo išsiaiškintas ir suprantamas funkcijas? Be abejo, pirmiausiai kentės sprinto planavimas. Jis užsitęs ilgai, nes visus neatsakytus klausimus reikės atsakyti tada. Mačiau ne vieną sprinto planavimą kuris nesibaigia per dieną. Atsakymas aiškus – produkto darbų sąrašas nebuvo gerai paruoštas ir aptartas produkto darbų sąrašo tvarkymo susirinkime. Kaip tai spręsti rašiau straipsnyje „Darom Scrum, bet… neturim laiko paruošti produkto darbų sąrašą“
Koks kitas galimas sprendimas problemai? Kadangi produkto darbų sąrašo tvarkymo susirinkimas vyksta ilgai, tai į jį kviečiame ne visą komandą, o tik kelis „išrinktuosius“. Problema? Taip, nes kiti nežinos apie ką jūs kalbėjote, kokie darbai jų laukia. Prasidės komandoje trintis ir nesutarimai. Taigi VISA komanda turi dalyvauti produkto darbų sąrašo tvarkymo susirinkime. Tačiau jam turi būti pasiruošta iš anksto, kad visų kartu praleistas laikas būtų išnaudotas efektyviai.
Priežiūra
Taigi liko paskutinis klausimas: kas atsakingas, jog šis procesas veiktų? Be abejo, Scrum meistras. Jis turi rūpintis ar produkto šeimininkas dirba prie produkto darbų sąrašo, ar spės jį tinkamai jį paruošti iki tvarkymo susirinkimo. Gal jam reikia padėti? Gal reikia atsakyti į techninius klausimus? Gal surasti žmones kurie galėtų atsakyti?
Taigi atsakomybę paruošti gerą produkto darbų sąrašą turi produkto šeimininkas. Tačiau Scrum meistras turi didesnę atsakomybę – pasirūpinti, jog produkto šeimininkas atlieka savo darbą :)
Įdomu, ar yra Scrum meistrų, kurie aktyviai padeda augti savo produktų šeimininkams? Labai norėtųsi išgirsti tokių Scrum meistrų patarimus ką jie daro. Pasidalinkite komentaruose.