Buvau pakviestas padėti komandai startuoti projektą, kurį įmonė vykdys naudodama Scrum projektų valdymo metodiką.
Projektas nemažas, devynių mėnesių. Planuojama, jog prie jo skirtingu metu dirbs 6-14 žmonių. Projekto komandos nariai yra dviejuose miestuose skirtingose šalyse: Vilniuje ir Kopenhagoje. Komanda programuos naują gan didelės sistemos versiją. Tai, be abejo, reiškia, jog turės dirbti su dideliu kiekiu esamo (legacy) sistemos kodo.
Planavimas
Susisiekęs įmonės vadovas papasakojo, jog jie planuoja atskraidinti visą komandą į Vilnių, į dviejų dienų projekto starto susitikimą (project kick off meeting). Jis paklausė ar aš galėčiau giliau papasakoti apie Scrum ir padėti pravesti Sprinto planavimo susirinkimą.
Aš pasiteiravau ar jie jau turi pasiruošę produkto darbų sąrašą (produkto backlog), kad tikrai galėtume pasidaryti efektyvų sprinto planavimo susirinkimą. Mane patikino, kad ruošia ir projekto starto susitikimui jis bus paruoštas.
Sutarėme, jog pirmos dienos ryte jie visai komandai pristatys projektą ir jo tikslus. Aš prisijungsiu po pietų ir papasakosiu apie Scrum. Antrą dieną komanda planuos sprintą (sprint planning meeting). Aš padėsiu moderuoti iki pietų, o po pietų jie užbaigs planuotis vieni.
Klausimų apie Scrum lavina
Atvykus pas juos pamačiau, jog pirmoje dienos pusėje jie diskutavo, kodėl jie pasirinko Scrum metodiką šiam projektui. Labai apsidžiaugiau, nes tikrai dar reta komanda užduoda sau ši klausimą.
Paprašius jie mielai pasidalino, kad pagrindiniai motyvai yra: greitas grįžtamasis ryšys tam, kad išsiaiškinti ar funkcijos kurias pagamino tikrai atitinka lūkesčius; aiškus projekto eigos kontroliavimas, matant nuolat pridedamas pabaigtas funkcijas; nuolatinis kokybės užtikrinimas, nepaliekant visos rizikos testavimo fazei projekto gale.
Kadangi komandos nariai apie Agile ir Scrum teorines žinias jau turėjo, mano planas buvo pravesti Scrum simuliaciją. Simuliacijos metu komanda kurdama paprastą produktą praktiškai išbando visus Scrum susirinkimus ir procesą.
Tačiau vos pradėjus kalbėti apie Scrum roles, komanda pažėrė laviną praktinių klausimų. Per tas kelias valandas trumpai pristačiau Scrum roles ir procesą. Tačiau daugiausiai laiko skyrėme atsakinėjimui į kylančius klausimus bei dalinimuisi savo patirtimi ir pavyzdžiais. Simuliacijos nedarėme.
Ar paruoštas projekto planas – produkto darbų sąrašas (product backlog)
Antros dienos ryte, produkto šeimininkas (product owner) trumpai apžvelgė visą produkto darbų sąrašą ir pradėjome sprinto planavimo susirinkimą. Paėmėme pirmąją funkciją, pradėjome ją aiškintis detaliau.
Man padedant, komandos nariai vis drąsiau uždavinėjo klausimus. Produkto šeimininkas kelis kartus netgi pasakė „labai geras klausimas, apie šitą reikės pagalvoti“. Tai ką susitarėme rašėme ant lentos, o prie tų vietų kur atsakymų iš karto nežinojome, pasižymėjome, jog atidėsime kitam sprintu (sprendimą kaip daryti tas dalis ar visai praleisti).
Detalizavimas ką turės daryti pirmoji funkcija užtruko apie porą valandų. Nors darbų ką komandai daryti buvo tikrai nedaug. Taip visa komanda kartu su produkto šeimininku pamatė, kaip svarbu produkto darbų sąrašo funkcijas pasiaiškinti detaliau iki sprinto planavimo. Na, bent jau tas kurios yra sąrašo viršuje. Visi sutarė, jog ateinančio sprinto metu, jie tikrai turės produkto darbų sąrašo smulkinimo susirinkimą (product backlog grooming meeting), kuriame aukščiausio prioriteto užduotis pasiaiškins giliau.
Čia aš juos palikau, o planavimo susirinkimą, toliau moderavo jų Scrum meistras.
Įžvalgos ir pasiūlymai
Konkrečių klausimų gausa apie Scrum praktinį taikymą aiškiai parodė, jog vien teorinių žinių komandai nepakanka. Be abejo, puiku, kad komanda turėjo galimybę užduoti turimus klausimus, tačiau jautėsi, jog tam skirtų kelių valandų buvo mažoka. Na, bet jų Scrum meistras tikrai rimtai domisi metodika, tad manau turės galimybę užpildyti šias spragas sprinto retrospektyvų ir kitų susirinkimų su komanda metu.
Dar kartą įsitikinau, jog tikrai verta produkto darbų sąrašo paruošimą (su aukščiausio prioriteto funkcijų detalizavimu) organizuoti dar prieš projekto starto susirinkimą. Produkto sąrašo sudarymo dirbtuvėms nebūtinai reikia visos komandos. Užtenka, kai dalyvauja produkto šeimininkas, Scrum meistras ir keli skirtingų sričių komandos nariai. Esant vienoje vietoje, per porą dienų pavyksta sudaryti pakankamai detalų produkto darbų sąrašą net ir tokio dydžio projektui.
Labiausia produkto darbų sąraše man pritrūko funkcijų įvertinimų. Mane patikino, jog įvertinimai buvo padaryti inicijuojant projektą. Taip jie nustatė projekto apimtį ir laiką. Tiesiog įverčių neliko prie sudaryto produkto darbų sąrašo. Patariau jiems detalizavus produkto darbų sąrašą, naudojant palyginamąjį vertinimą, dar kartą įvertinti visas funkcijas kartu su komanda. Tada, matydami kiek darbų jie padaro per sprintą (t.y. koks komandos greitis), jie galės gan tiksliai prognozuoti kaip sekasi vykdyti projektą. Produkto šeimininkui labai patiko ši idėja ir jie sakė būtinai tai padarys.
Ar jūs esate organizavę projekto starto susitikimą projektui? O Agile projektui? Ar verta jį daryti? Kokį formatą taikėte tokiam susirinkimui? Pasidalinkite komentaruose.