Technologas: Kaip SCRUM’as veikia realiame gyvenime?

Atsakyti kokiu principu šiandien dirba IT kompanija labai paprasta – žinoma, kad „Agile“, o nuo jo neatsiejamas SCRUM projektų valdymo modelis. Bet kas iš tikrųjų slepiasi po šiuo terminu? Žiūrint tiesiai, atrodo, kad reikalas paprastas: planuojiesi darbus dviem savaitėms, adaptuojiesi prie pokyčių, o tarpuose keletas susitikimų atsiranda. Bet iš tikrųjų į šią idėją telpa kur kas daugiau, todėl šiandien noriu pasidalinti mūsų patirtimi įgyvendinant SCRUM’ą praktikoje.

Tikrojo SCRUM paieškos

Teorija sako, kad SCRUM modelis padeda komandoms (dažniausiai, programuotojų) efektyviai dirbti kompleksinėse ir nuolat kintančiose situacijose. Aukštesnė vertė sukuriama tada, kai komanda darbus organizuoja trumpais laiko etapais (sprintais) ir adaptyviai reaguoja į esamą situaciją, o ne seka iš anksto nustatytą griežtą planą.

Tokia vadovėlinė idėja skamba gana paprastai – žinau visus teorinius niuansus ir suprantu, kaip ji mums gali padėti dirbti geriau. Ar bent taip pasirodė, kol nepradėjome bandyti „teisingojo“ SCRUM taikyti praktikoje. Pradžioje bandėme įvairiais būdais tvarkingai sudėti užduotis, bet vis išlįsdavo nesuplanuoti darbai. Bandėme darytis retrospektyvas, bet ir iš jų galiausiai išėjo šnipštas.

Ir šiaip, ir taip galvojau, kaip pajudėti iš šio taško, kol prisiminiau, kad turiu kolegę, SCRUM'o guru, kuri padėjo grąžinti ir mane patį į tikėjimo juo kelią. Išklausiusi kasdienį/sprintų planavimą, ji išryškino pagrindines mūsų problemas: užduočių aprašymo trūkumas, laiko vertinimo nebuvimas, kasdieniai susitikimai jai pasirodė kaip atsiskaitymas prieš mokytoją, o klaidų atsiradimas projekte buvo netinkamai kontroliuojamas.

Kadangi visi supratome, kad revoliucijomis netikime, o pasikliaujame nuoseklia evoliucija, pradėjome nedideliais žingsniais: pasistengėme į retrospektyvas įsinešti ne problemų sąrašą, o atsakymus, kaip jas išspręsti, ėmėmės efektyvesnių planavimų ir grooming’ų.

Bet, jei atvirai, vis dar nujaučiau, kad vis dar turime, kur tobulėti. Aišku, moksle sakoma, kad kvaila daryti tą patį ir tikėtis kitokių rezultatų. Bet pasipildę naujomis žiniomis nusprendėme įlipti į tą pačią balą ir su kitais projektais – pavyzdžiui, statant vieną didžiausių elektroninių knygynų Lietuvoje.

Darome taip, kaip daro „Spotify“

Pradėjome nuo retrospektyvos – ką galėtume padaryti geriau? Nors girdėjome, kad „Spotify“ squadai nelabai veikia praktikoje, šie milžinai turi ir nemažai gerųjų praktikų, viena iš jų – „Spotify Health Check“ modelis. Tai įvairių tematikų klausimynas, pvz., kaip lengva išleisti kodą į produkcinę aplinką? Kokio dydžio yra mūsų techninė skola? Ar gerai suprantame projekto misiją? Toks modelis puikiai veikia bandant susigaudyti, kokioje situacijoje yra komanda ir kur ji mato problemas.

Retrospektyva pavyko puikiai ir prisirašėme daug užduočių. Kelios iš jų:

• Pirma – testukai. Iš pradžių testai nebuvo rašomi. Tai nepatiko nei programuotojams, nei projektų vadovui, nei man. Nusprendėme keisti tai. Kaip? Paprastai – daryti palyginimą kodo padengimo (code coverage) development šakos ir pull-request’o. Jeigu pull-requestas turi didesnį jį – praleidžiame, jeigu ne – teks padirbėti.
• Antroji – parengti išleidimo į produkcinę aplinką gidą, nes iki šiol visa tai vykdė vienas programuotojas.
• Trečia – teisingo SCRUM’o įgyvendinimas. Norėjome pasidaryti tokį groom’ingą, sprinto planavimą ir kasdienius susitikimus, kokie yra apibrėžti teorijoje. Dar prieš atkeliaujant sprintui nepriskirti užduočių konkrečiam asmeniui, o taip pat apšildyti klientą ties užduočių planavimu, kad nuo šiol pagrindinė projekto valiuta bus „story points“. Kitas svarbus aspektas – papildomai įsivesti dvisavaitinius sprintus ir nepriskirti programuotojų ties užduotimis. Tai labai svarbu, nes jei užduotyje nėra priskirtas niekas, vadinasi, gali būti ir taip, kad jai būsi priskirtas tu pats. O tada ir rūpiniesi ta užduotimi taip lyg ji būtų tavo ir atidžiau vertini, ar tai kas parašyta yra logiška.

Teisingas užduočių paruošimas ir peržiūra

Šios dalies tikslas – sistemingai groom’inti užduotis ir atvaizduoti jas sprintų planavime. Kitaip tariant, tai užduočių paruošimas, išsiklausinėjimas apie jas, neaiškumų pašalinimas ir, jeigu viskas aišku, užduoties įvertinimas. Šiam veiksmui turi būti tinkamai pasiruošta, o už tai turi būti atsakingas žmogus, kuris gerai žinos apie kiekvieną iš tų užduočių.

Įsivedėme tokią paprastą tvarką:

1. Perskaitoma užduotis ir pasiteiraujama, ar programuotojai turi klausimų.
2. Jeigu yra neaiškumų ir reikia, kad klientas atsakytų, tai pasižymi projektų vadovas.
3. Jeigu nėra, daromas balsavimas kortomis.
4. Jeigu yra dideli skirtumai tarp balsavimo, paaiškinama, kodėl balsuota viena ar kita korta.
5. Judama prie kitos užduoties.

Pradžioje šiek tiek strigome, nes nebuvo aišku, kiek vertas tas vienas story point’as, bet greitai įsivažiavome. Tai buvo dėl kelių priežasčių: darbų sąrašas buvo teisingai išrikiuotas bei buvo tinkamai pasiruošta groom’ingui: apie visas užduotis žinojo bent vienas žmogus. Žinau, kad pagal visą teoriją čia turėtų dalyvauti ir klientas, bet pradžioje, norėjome viduje išbandyti, ar veikia toks planavimas.

Kasdienių susitikimų svarba

Standup’as – trumpas, kasdien įvykstantis komandos susitikimas, kurio tikslas yra pereiti per pradėtas, besitęsiančias ir baigtas užduotis. Per jį ne daugiau nei 5 min kiekvienas pasidalina:

• Prie ko dirbsiu šiandien;
• Prie ko planuoju sėsti po to;
• Su kokiomis kliūtimis susidūriau, kurios trukdo užbaigti darbą.

Svarbu įsiminti, kad tai – ne mokykla ir ne atsiskaitymas už vakarykštes pamokas. Tai pasidalinimas tuo, kuo gyveni. Gal ir nusižengiu oficialioms taisyklėms, bet man smagu pasidalinti ir vakar dienos įvykiais iš asmeninio gyvenimo.

Sprinto planavimas

Šios dalies tikslas – susiplanuoti, ką ateinantį sprintą komanda nudirbs ir kaip ji pasieks šio rezultato. Šitai pasiekiama pakankamai paprastai – imi pirmą sprintą, pasižiūri, kiek story pointų įvykdė komanda ir suplanuoji kitą sprintą tokiam pačiam kiekiui. Didesnė bėda ištinka, kai klientas nusprendžia įpiršti papildomą užduotį į savo/mūsų suplanuotą sprintą. Čia gali būti sunkoka įrodyti, jog sprinte laikas yra ribotas ir dažnai vienintelis sprendimas – iš jo išimti kitą užduotį.

Gyvenimas yra sunkesnis už teoriją

Iš pažiūros teorinis SCRUM modelio grafikas atrodo nesudėtingai, tačiau taip dirbant nuolat, veikti yra ką. Pavyzdžiui, tokia Burndown diagrama parodo, kad suplanuotos užduotys neuždaromos laiku. Panašių kreivių galima pamatyti ir mūsų pačių projektuose.

Ko gero nustebsite pamatę tokį grafiką, bet taip kartais nutinka, kai dalį testavimo atsakomybės neša kliento komanda, tad natūraliai visas procesas gali prailgėti ar atsilikti. Tai jiems, žinoma, užtrunka gerokai ilgiau nei mūsų pusėje. Panašių praktikos neatitikimų su lūkesčiais galima surasti ne vieną.

Nors SCRUM’o įvedimas ir gali atrodyti kaip baigtinis procesas, kurį įmanoma „išmokti“ iki galo, dirbdami juo supratome, kad nebūtinai yra. Nuolat tobulėjame tiek ties suvokimu, kaip ši metodologija veikia praktiniuose darbuose, tiek taikomės prie aplinkos pokyčių, tiek keičiasi turimų komandų sudėtys.

Tai, kas skamba lengvai teorijoje, realiame gyvenime dažnai priverčia suprasti, kad iš balos sausam išlipti sunku, o ta efektyvesnio darbo idėja nėra tokia jau lengvai pasiekiama. Tuomet grįžti prie lentos, braižai planus iš naujo ir bandai dar kartą. Bet juk nuolatinis tobulėjimas ir yra vienas pagrindinių Agile principų ir yra, ar ne?

Vaidas Mikalauskas yra „Adeo Web“ technologijų vadovas. Daugiau autoriaus darbų yra socialiniame tinkle „LinkedIn“.