Panagrinėkime Scrum taikymą mažose kompanijose naudojant realią situaciją, kurią iš savo patirties man aprašė VU MIF magistrantas. Manau tokių situacijų Lietuvoje yra tikrai ne vienoje įmonėje:
“Situacija buvo tokia: 5 programuotojai, dauguma jų dirba atskiruose projektuose. Vyko Scrum meet’ai, kas-savaitinis (aptariami savaitės darbai) ir kasdieninis. Pagrindinė problema – nebuvo jokios izoliacijos tarp programuotojų ir klientų. Neretai būdavo ir taip, kad programuotojui skambintų paprastas sistemos vartotojas ir prašydavo (vos ne) pasiaiškinti, kodėl sistema veikia ne taip, kaip kad jo manymu turėtų. To pasėkoje apie terminų ir resursų laikymąsi nėra jokios kalbos – projektai neretai vėluoja kelis mėnesius, o kartais ir metus. O piniginiai resursai sutartyje apibrėžti, taigi neretai įmonė tiesiog negali mokėti darbuotojams atlyginimų.. Tokia tad mano asmeninė patirtis :)”
Scrum taikymas
Kolegos teigimu , įmonė turėjo kasdienius ir kas savaitinius Scrum susirinkimus. Tai aišku yra labai gerai ir manau tikrai padėdavo kompanijai sinchronizuoti darbus. Tačiau, tai yra viena iš dažniausiai daromų „savi apgaulių”. Galvojama, jog paėmus kelias geras idėjas iš judrių metodikų, visas procesas taps judrus. Norint būti tikrai judriems, reikia įgyvendinti visas esmines tos metodikos taisykles. Tik tada gausite aiškią matomą ir pamatuojamą vertę. Scrum taisyklių yra tikrai nedaug. Visos jos telpa į 21 puslapio Scrum gidą: http://www.scrum.org/storage/scrumguides/Scrum%20Guide.pdf. Truputį pasistengus visos gan lengvai taikomos. Tad nedarykim „ScrumBut”, darykim Scrum! Daugiau apie ScrumBut galite pažiūrėti mano prezentacijoje: http://scrum.blogas.lt/pirmas-blynas-iskeptas-27.html, 38 skaidrėje.
Scrum rolių taikymas
Kita aprašyta aiški problema yra nuolatinis srautas klientų skambučių trukdantis programuotojams fokusuotis prie to ką dirba (multitasking). Aiškiai apsibrėžus kas komandoje atlieka Scrum aprašytas roles, tai būtų galima išspręsti. Žmogus kuris atlieka produkto šeimininko rolę turėtų tiesiogiai bendrauti su klientais dėl naujo funkcionalumo ar egzistuojančio funkcionalumo paaiškinimo. Kitas žmogus atliekantis Scrum meistro rolę, būtų atsakingas prižiūrėti, kad šios ir kitų Scrum taisyklių būtų laikomasi. Tai leistų izoliuoti programuotojus nuo pastovių trukdžių.
Vertėtų paminėti du dalykus. Pirma, Scrum rolėms atlikti nereikia atskirų/naujų darbuotojų. Tokioje mažoje kompanijoje kaip aprašyta situacijoje, direktorius ar pardavėjas galėtų puikiai atlikti Produkto šeimininko rolę, o tech. lyderis ar vyr. programuotojas Scrum meistro rolę. Svarbu kad būtų aišku visiems kas tas roles atlieka! Antra, reikia šito nesupainioti su kita labai gera agile praktika: artimu bendradarbiavimu su klientu. T.y., kai komanda sprinto planavimo metu paima įgyvendinti užduotį, jie turi bendrauti su klientu betarpiškai ir interaktyviai, kad pagamintų tai ko klientas tikrai nori, o ne tai ką programuotojas sugalvoja ko klientas gali norėti ;). Taigi apibendrinant: dėl naujo funkcionalumo, esamų išplėtimų/keitimų klientai bendrauja su produkto šeimininku ir registruoja tai į produkto užduočių sąrašą. O kai komanda paima funkcionalumą įgyvendinti per sprintą, jie bendrauja su klientu tiesiogiai jei tik tai įmanoma.
„Degančios” užduotys
Dažniausi trukdžiai komandai susidaro dėl „degančių” užduočių, t.y. kai kažkas staiga nutinka, ar klientas prašo įgyvendinti funkcionalumą „vakar” :). Su šia problema susiduria daug kompanijų. Iš savo asmeninės patirties galiu pasakyti, jog svarbiausia čia pradėti aiškintis kas tie „degantys” reikalavimai yra ir juos skirstyti į dvi grupes: 1 – naujas funkcionalumas ir esamo pakeitimai; 2 – tikrai svarbūs maži pakeitimai ir kritinės produkto (jau paleisto) klaidos.
Pasirodo, kad dauguma „degančių” užduočių iš tikrųjų yra tiesiog norimas funkcionalumas. Klientai (o dažnai ir kompanijoje dirbantys pardavėjai) iš patirties žino, kad bus įgyvendinta tik tai, ko labai karštai reikalausim ir sakysim, jog čia aukščiausias prioritetas (taip taip.. tokia jau ta realybė ;). Taigi paprasčiausias būdas pripratinti juos nustoti tai daryti yra registruoti kiekvieną prašymą į produkto užduočių sąrašą. Norint užduotį įtraukti į šį sąrašą reikės suprasti jo prioritetą kitų užduočių atžvilgiu. Praktika rodo, kad pamačius kitas užduotis laukiančias šiame sąraše, „deganti” užduotis staiga patampa ne tokia deganti ir labai retai atsigula pačiame užduočių sąrašo viršuje. O jei ir atsigula pačiame viršuje, visi žino, kad tam reikės savaitės ar dviejų kol komanda pradės naują sprintą ir ji greitai bus paimta įgyvendinti. Taigi šis paprastas įrankis, produkto užduočių sąrašas, padeda labai paprastai suvaldyti naujų poreikių gavimą, jų prioretizavimą, ir svarbiausia, stabilų jų padavimą programuotojams nuolat jų netrukdant.
O ką daryti su tomis užduotimis kurios yra antroje grupėje, t.y. jas būtina padaryti nedelsiant? Jei jos iš tikrųjų yra svarbesnės nei visa kita ką daro kompanija ir jeigu jos negali laukti savaitės ar dviejų iki sprinto pradžios, jas tiesiog reikia padaryti. O kas jas darys, turi nuspręsti kompanija. Galbūt galite palikti pvz x% komandos laiko nesuplanuoto, kuris bus skirtas tokioms užduotims (remiantis praktika kiek laiko vidutiniškai tokioms užduotims reikia atlikti). Galbūt jums patogiausia paskirti vieną žmogų iš komandos, bet tada nepamirškit jį nuolat keisti, nes dažniausiai programuotojai nebūna motyvuoti tokia role :). Jei kompanija didesnė, ji gali nuspręsti turėti atskirą komandą, kuri dažniausiai vadinama palaikymo (support) komanda. Kas šias užduotis atliks, nėra taip svarbu. Svarbiausia, matuoti kiek laiko iš tikrųjų sugaištama tokiom užduotim ir ieškoti būdų kaip šį laiką mažinti. Juk visiems aišku, kad būtent šios užduotys yra didžiausia problema neleidžianti susikaupti prie svarbių darbų ir neleidžianti tiksliau planuoti sprintų. Geresnis bendravimas su klientais dėl užduočių pateikimo, dažniausių klaidų išskyrimas ir sutvarkymas, gali būti pirmosios vietos kur reikėtų atkreipti dėmesį.
Komandinis darbas
Paskutinis klausimas kurį diskutavome šios situacijos kontekste: kodėl kompanijoje kurioje yra 5 programuotojai, visi dirba prie atskirų projektų?! Sakysite, kad kompanija turi daugiau nei vieną projektą! Taigi kitaip neįmanoma! O aš paklausiu: ar tikrai? :) Gal tai tik istoriškai nusistovėjusi tvarka, kuri mums labiau trukdo nei padeda?..
Visi kalbame kaip yra svarbu dirbti komandoje. Keli žmonės dirbdami prie vienos užduoties gali diskutuoti, sukurti geresnį dizainą, greičiau pastebėti klaidas. Iš esmės, praktika rodo, kad keli žmonės susikoncentravę prie vienos problemos sprendimo ją išsprendžia greičiau ir kokybiškiau negu visi dirbdami atskirai! Taigi kaip šią gerą praktiką būtų galima taikyti mūsų situacijos atveju? Ogi suformuokime komandą iš visų 5 programuotojų. Aišku galima suformuoti ir 2 komandas iš 2 ir 3 programuotojų, jei projektai iš tikrųjų tokie maži ir mums atrodo per daug drastiška turėti vieną komandą. Nutarkime kad vieną sprintą (pvz.: savaitę ar dvi) dirbam prie vieno projekto. Pasiekiam pabaigtą (Done) kriterijų, t.y. įgyvendiname pasirinktą vartotojo funkcionalumo kiekį. Tada žiūrim į kito projekto produkto užduočių sąrašą ir dirbam visą sprintą prie to projekto visa komanda kartu. Ir taip tęskime. Iš pradžių tai gali atrodyti neįprasta ir nepatogu, bet kai pamatysit kaip funkcionalumas projektuose pridedamas greičiau, kai išmoksite dirbti kaip tikra komanda, nesuprasite kaip galėjote dirbti kitaip prieš tai :)
Svarbiausia suprasti jog pradėti projektą/užduotį anksčiau, tikrai nereiškia kad ją anksčiau baigsite. Pažiūrėkite į pavyzdį žemiau. Situacija paprasta: turime 3 projektus/užduotis ir 3 žmones jiems atlikti. Ir turime 2 variantus: 1 žmogus dirba prie 1 projekto/užduoties arba visi 3 žmonės dirba prie projekto/užduoties, jį baigia ir imasi kito. Aiškiai matyti, kad dirbant komandoje padarytume projekto/užduoties 1 ir 2 klientus laimingesnius, nes pabaigtume jų projektus/užduotis greičiau, nei pradėjus visas užduotis iš karto. Čia jau nekalbant apie kokybės kilimą, žinių pasidalinimą (rizikos sumažinimą kai tik vienas žmogus žino konkrečią sistemos vietą) ir galų gale, juk dirbti komandoje linksmiau!
Tikiuosi šie keli patarimai padės ar bent jau suteiks minčių diskusijoms tiems kas dirba mažesnėse kompanijose. Komentuokit jei turit klausimų/minčių/pasiūlymų.
Comments