Greitas produkto darbų sąrašo tvarkymo susirinkimas

„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.

http://www.dreamstime.com/-image17027933

(Iliustracija iš http://www.indieagile.com/backlog_files/stacks_image_258.jpg)

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.

 

Tagged with: , , , , , ,
Posted in Agile, Produkto darbų sąrašo smulkinimas, Scrum

Leave a Reply

Your email address will not be published. Required fields are marked *

*

Artimiausi mokymai
Data Mokymai - Lektorius
2017 m. spalio 2-3 d. Certified Scrum Master (CSM) - Tomas Björkholm (EN)
2017 m. spalio 3-4 d. Management 3.0 Change and Innovation Practices - Ralph van Roosmalen (EN)
2017 m. spalio 3-4 d. Certified Agile Leadership CAL1 - Angel Diaz-Maroto (EN)
2017 m. spalio 9 d. Reikalavimų valdymas Agile projektuose - Vaidas Adomauskas (LT)
2017 m. spalio 10 d. Agile projektų valdymo pagrindai - Vaidas Adomauskas (LT)
2017 m. spalio 11 d. Better Retrospectives - Jeff Campbell (EN)
2017 m. spalio 10-11 d. Kanban System Design (KMP I) - Gaetano Mazzanti (EN)
2017 m. spalio 10-11 d. Certified Scrum Product Owner (CSPO) - Lasse Ziegler (EN)
2017 m. spalio 10-11 d. ICAgile sertifikuotas profesionalas (ICP) - Vaidas Adomauskas (LT)
Visi mokymai
Archives
Categories
Kontaktai

Viešos mokymų klasės:
E-paštas: mokymai (at) agilecoach.lt
Mob. tel.: 8 686 32487

Konsultacijos ir mokymai įmonėms:
E-paštas: vaidas (at) agilecoach.lt
Mob. tel.: 8 686 32487