Vasara – atostogų metas, tad mano blogas irgi truputėlį atostogavo ;) Tikiuosi jūs taip pat! Bet atėjo ruduo ir pradedu toliau dalintis savo patirtimi ir mintimis apie Agile, apie Scrum, apie programinės įrangos kūrimą. O iš Jūsų laukiu aktyvios reakcijos ir pasidalinimo mintimis/patirtimi komentaruose ;)
Vasarą teko ne kartą diskutuoti tema apie tarpfunkcinės Scrum komandas. Žmonėms atrodo, jog sudėti kelių sričių ekspertus į vieną komandą, yra labai neefektyvu. Standartiniuose projektų valdymo principuose yra teigiama, jog norint efektyvinti sistemą, reikia ją suskaidyti į dalis ir efektyvinti kiekvieną iš jų. Taigi norint kad komanda būtų efektyviausia reikia kiekvieną jos narį užkrauti jo ekspertinės srities darbais. Atrodo viskas logiška ir puikiai pagrindžiama aritmetika. Bet ar tikrai tai tiesa? Tai būtų tiesa jeigu programinės įrangos kūrimui tiktų viena prielaida: svarbiausios užduotys yra tolygiai pasiskirsčiusios pagal darbuotojų ekspertines sritis. Deja, ši prielaida labai retai galioja programinės įrangos kūrime. Taigi kaip tarpfunkcinė Agile komanda tampa efektyvesnė, kai jos nariai daro net ne savo ekspertinės srities užduotis?
Svarbiausias funkcionalumas sukuriamas greičiau
Realybėje išdėsčius darbus „optimaliai” pagal kiekvieno darbuotojo ekspertinę sritį visada bus taip, kad kažkuris resursas taps „butelio kakliuku”. Taigi projekto/funkcionalumo pabaigimas priklausys nuo to kaip greitai šis žmogus atliks savo užduotis. Tuo tarpu tarpfunkcinė Scrum komanda pasidalina užduotis. Nors komandos nariui eksperto užduotį atlikti užtrunka ilgiau, tai sutrumpina eksperto užduočių kiekį ir projektas/funkcionalumas bus pabaigtas greičiau.
Panagrinėkime pavyzdį. Tarkim funkcionalumui įgyvendinti mums reikia 2 ekspertų žinių. Vienas jų turi 4 vienos dienos užduotis, o kitas – 1 vienos dienos užduotį. Ne ekspertui atlikti eksperto užduotį užtrunka 2 kartus ilgiau. Supaprastinta schema tai būtų galima pavaizduoti taip (realybėje komanda užduočių turi daug daugiau tad sutaupymas tampa dar akivaizdesnis):
Aktyviai tarp komandos narių dalinamasi žiniomis ir patirtimi
Be abejo, dirbdama kartu, visa komanda mokosi skirtingų sričių žinių. Tai turi porą labai svarbių naudų. Pirma, kompanijoje plečiasi ekspertų ratas, kas yra labai naudinga ekspertui susirgus, atostogaujant ar paliekant kompaniją. Antra, skirtumas per kiek laiko ekspertas ar ne ekspertas padarys užduotį mažėja laikui bėgant. Komandos nariui ne ekspertui padaryti aukščiau pavyzdyje minėtą ne ekspertinę užduotį užtruks trumpiau ir trumpiau (tikrai ne dvi dienas). Taip komanda funkcionalumą kurs greičiau ir greičiau.
Kuriamas tik reikalingas (svarbiausias) funkcionalumas
Pavyzdyje pateiktame aukščiau labai aišku, kad pirmu atveju niekas neleis antram ekspertui sėdėti be darbo 4 dienas. Taigi jam dažniausiai duodamos kitos užduotys kurių gali ateityje prireikti. Įgyvendinant tas užduotis be abejo reikia ir eksperto 1 žinių ir pagalbos (pvz. susitarti dėl dizaino). Taigi realus pirmojo funkcionalumo laikas dar nutolsta (bus pvz. 5 dienos, o ne planuotos 4). Blogiausia, kad pabaigus pirmąjį funkcionalumą sekančio, kurį jau pradėjo daryti ekspertas 2 gali ir nereikėti, arba jo gamyba gali būti atidėta. Taigi dirbant kartu kuriamas tik reikalingas funkcionalumas, nešvaistant laiko tam ko ateityje gali ir nereikėti.
Geriau užtikrinama funkcionalumo kokybė
Dirbant trumpais sprintais (iteracijomis) darbo komandoje nauda dar labiau pasimato. Jeigu tarkim 4 programuotojai programuos 4 funkcijas kiekvienas atskirai, sprinto gale testuotojui visos jos bus pateiktos maždaug vienu metu. Taigi vienam testuotojui, neturėjusiam ką veikti didžiąją sprinto dalį, dabar per kelias likusias dienas reikės ištestuoti visas 4 funkcijas! Kaip manot ar kokybiškai tai bus padaryta?
Tuo tarpu pažiūrėkime kaip šiuo atveju dirba gerai susiorganizavusi tarpfunkcinė Agile komanda. Visi keturi programuotojai pradeda dirbti prie pirmos funkcijos. Kai ją pabaigia, atiduoda testuotojui ir imasi antros. Testuotojas gali ramiai testuoti ir jei yra kažkokių problemų programuotojai iš karto jas išsprendžia. Taip darbų pasiskirstymas sprinto metu tampa lygesnis, o funkcionalumo kokybė geresnė.
Išvada: komandos greitis svarbiau nei komandos nario greitis
Taigi sunkiausia mąstysenos dalis kurią mums reikia pakeisti yra ta, jog komandos greitis yra svarbiau negu kiekvieno komandos nario atskirai efektyvumas. Nereikia fokusuotis kaip kiekvieną žmogų atskirai išnaudoti efektyviausiai, nes tai nesukuria daugiausia vertės. Daugiausiai vertės sukuriama kai komanda kaip visuma yra efektyviausia. Scrum tarpfunkcinių komandų produktyvumas yra geriausias to pavyzdys!
Man šie paaiškinimai padeda kai reikia įtikinti komandų narius, kad jie turi bendradarbiauti ir padėti vieni kitiems. Kai jie bijo, kad bus nelabai efektyvūs jei kartais darys užduotis kur jie nėra ekspertai. Kai jiems padaryti šias užduotis užtrunka ilgiau nei kolegai. O kaip jums?