Kas produktyviau: individualūs ekspertai ar tarpfunkcinė Scrum komanda?

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?

Tagged with: , , ,
Posted in Agile, Fokusavimasis, Komanda, Scrum
11 comments on “Kas produktyviau: individualūs ekspertai ar tarpfunkcinė Scrum komanda?
  1. Tomas says:

    Patiko. Tiesos yra.

  2. Irmantas says:

    Del visko sutinku, del kokybes nelabai. Kokybe tikrai buvo geresne, kai pas musu nebuvo scrum, dabar kokybe kritusi, reik tiketis laikui begant viskas susitvarkys

  3. Dekui Tomai ir Irmanatai uz komentarus.

    Irmantai, as speju tu lygini kokybe kai zmonės darė tik savo ekspertinės srities užduotis ir dabar kai visi dalinasi darbais. Be abejo, prieš tai visi žinojo labai gerai ką daro ir darė tai kokybiškai. dabar komanda turi mokintis dirbit kartu, mokintis naujų įgūdžių, naujų užduočių vykdymo. Jei tai daroma per greitai, nepadedant komandai to išmokti ar spaudžiant vadovams, kokybės trumpalaikis kritimas tikėtinas. Kaip ir tikėtinas visos sistemos (organizacijos) nestabilumas keičiant procesą.

    Tačiau žiūrint ilgalaike prasme manau tikrai pasivysit buvusią kokybę ir ją išlaikyti bus daug lengviau. Pvz pagavok kaip būtų kokybė nukentėjus jei vienas iš tavo ekspertų anksčiau būtų palikęs įmonę? kas būtų daręs jo darbą ir pan? Jau nekalbant apie patį komandos efektyvumą: kūrimą to ko tikrai reikia dabar greičiausiu būdu kas buvo pagrindinė šio straipsnio mintis.

    Sėkmės Scrum kelyje!

    Vaidas

  4. Vilius says:

    Visi keturi programuotojai pradeda dirbti prie pirmos funkcijos. Kai ją pabaigia, atiduoda testuotojui ir imasi antros. …

    Teorijoje taip, bet praktikoje toli gražu ne visada User Stories/Tasks gali būti lygiagretinami kaip patinka ir 4 programuotojai dažniau bent jau iš patirties dirba ties 2-3 User Stories lygaigrečiai ir vistiek jų deliverinimas nusistumia į sprint’o pabaigą. Žinau, kad US turi būti atominiai ir vienas kito neblokuojantys, bet ar tikrai dažnai tai gaunasi?

    Kita vertus su cross-functional team koncepcija sutinku ir prasmės yra tiek palaikant bendrą produkto žinojimą, tiek žmonių pakeičiamumą, tiek bendrą komandos kvalifikacijos augimą.

  5. Viliau tu visiškai teisus kad 4 programuotojai praktikoje prie vienos užduoties (jei ji pakankamai maža) nelabai galės produktyviai dirbti.

    Aš specialiai bandžiau vartoti žodį funkcija (angl. feature) ne vartotojo istorija(User Story) ar užduotis (task), kad pabrėžti jog tai didesnis darbas. Mes paprastai stengiamės reikalavimus Produkto užduočių sąraše skaidyti taip, kad į sprintą pakliūtų 3-5 funkcijos (~7 žmonių komandai). Savo ruožtu, sprinto planavimo metu funkciją komanda suskaido į daugiau vartotojų istorijų ar užduočių. Kaip komanda skirstosi užduotis sprinto metu tarpusavyje, jau jie patys turi organizuotis. Scrum mestras tik prižiūri, kad laikytųsi funkcijų prioritetų sprinte, ir nesiimtų antros funkcijos, kol pirmos kartu neužbaigė.

  6. Naujakurys says:

    Siulau visa tai isbandyti ant praktikos.
    Tu nori greiciau isikraustyti i buta, kuriame neirengta virtuve, truksta plyteliu suklotu.
    Visi plyteliu klojejai uzimti, ir atsilaisvins tik po menesio.
    Tu reikalauji ish darbu vykdytojo kad plyteles butu suklotos jau po dvieju savaiciu.
    Kadangi statybos imone dirba pagal Scrum, Darbu vykdytojas atsiuncia Santechnika kloti plyteles. Santechnikas niekada nebuvo klojes plyteliu, todel ji reikes apmokinti. Apmokinimui reikes 1 darbo dienos plyteliu klojimo ekspertui, kuris per ta laika tik sugebes parodyti kaip atrodo plyteles, kokie yra klijai, kaip jiemaisomi, kaip tepami ant sienos ir dar papasakos keleta teoriniu dalyku.
    “Perkvalifikuotam” santechnikui atlikti darba uzktruks 2 kartus ilgiau nei Ekspertui plyteliu klojejui. t.y. 2 savaites. Plius medziagu iseiga irgi bus didesne (daugiau plyteliu sugadins, kliju sunaudos nes perklijuoti reikes ir t.t.)
    Kadangi santechnikas yra ekspertas savo srityje, jam alga reikes moketi tokia kokia jis gauna kaip ekspertas, nors dare darba kur nera ekspertas. T.y. sumoketi uz 2 savaites +2 dienos (apmokymam) eksperto darbo laiko, Vietoj 1 savaites tikro eksperto dabo laiko.
    Kadangi uzsakovas pats skubino tuos darbus, jis turi padengti tas islaidas.
    Kai atsikraustysi i buta, galesi grozetis plyteliu “bangomis” ir kitais dziaugsmais… nors uzduotis bus ivykdyta, visos plyteles bus suklijuotos, ne viena nenukritusi.
    Ar patiktu tau isikraustyti i toki buta, sumokejus uz darba 2,5 karto daugiau, ir netureti tikrai ekspertinio rezultato, ar geriau vis tiek palaukti dar 1 menesi ir gauti tikrai gera rezultata uz mazesne kaina.
    Zinoma, kaina gali buti nevarbi, jei reikai priduoti buta per tas 2 savaites ir jei butas nebus priduotas gresia bauda kokius 10 kart didesne nei padaryti “perkvalifikuoto” specialisto nuostoliai.

  7. Pacientas says:

    Ash turiu problemu su sirdimi, reikalinga suntavimo operacija.. be jos gal pragyvensiu metus, o gal po savaites numirsiu.
    Visi kardio chirurgai uzimti 9 menesiams i prieki, bet yra laisvas labai geras plastikos chirurgas, kuris galetu atlikti operacija net rytoj.
    Peskaicius sita straipsni, ash tikrai apsisprendziau operuotis ryt, neesme kad operacija uztruks 2 kartus ilgiau, vistiek busiu po narkoze. Bet as bijau kad tu metu neisgyvensiu ir sekancia savaite numirsiu be operacijos.
    P.S. Idomu ar pacientas su lauks porytdienos?

  8. Gytis says:

    Nelabai teisingas postas.
    Evoliucija atvede zmonija prie specializaciju. Jei daiktas retai naudojamas, arba naudojamas megejiskai, bei reikalinga daug fukciju karts nuo karto – tai perkamas kombajinas (pvz virtuvinis). Jis atlieka darba ne efektyviai, bet pakenciamai. Jei darbai atliekami pastoviai, ir reikalinga kokybe bei konkretaus darbo alikimo greitis – perkamas konkretus irankis tai uzduociai. Bet net kombajine kol tarkuoji bulves negali imesti morku tarkuoti, o tai gausis ne koks efektas.
    Taip ir Scrume, sis dalykas yra IDEALIZUOTAS ir UTOPINIS.
    Kaip minejai atsakyme Irmantui, Jei ekspertas susirgs ar isheis is darbo, tai ta ekspertine vieta bus tuscia. Daug yra metodiku kur aiskinama kad kiekvienas ekspertas turi tureti backupa. Bet tai nereiskia kad turi tureti 10 ar 100 backupu, nes tai jau bus tikras resursu svaistymas.
    Kaip minejai atsakyme Irmantui, jei pastoviai bus dalinamasi darbais ir nebeliks ekspertines srities, tai rezultatas bus vienas – neliks EKSPERTU, o bus kruva vidutinioku kurie kazka lyg ir moka, bet nieko dorai nemoka.. visi darbai bus atliekami ilgiau ir su prasta kokybe. Cia savaime aisku – jei nera Eskpertiniu sriciu – nera Ekspertu. Jei sita aksioma netinka, galiu pateikti pavyzti. PVZ yra Eskpertas A kurio sritis sA, ir ekspertas B kurio sritis sB bei ekspertas C kurio sritis sC.
    Visi jie dirba savo srityse, darbai vykdomi per laika X ir su kokybe Y. Tarkime, kad sprinte (bet backloge yra visu sriciu darbu) yra vien tik darbu sA srities, visi ekspertai dirba prie tos srities. Neekspertai Dirba 2x leciau, plius Ekspertas A turi juos apmokinti, gaisti laika ju prieziurai ir t.t. todel jis irgi dirba 2x leciau (nes turi 2 kitos srities specialistus apmokinti ir rezultatus perziureti). Kaip buvo aprasyta straipsnyje, gavome norima rezultata 1,5 sprinto darbas buvo atliktas per 1 sprinta, VALIO! bet paziurekime globaliau, BackLogo itemai nusikele, nes 1,5 sprinto darbui buvo sunaudota 3ju sprintu resursai, tai reiskia kad sio sprinto featurai kainavo 2x brangiau…Ar tai racionalu?
    Na tikiuosi del kastu ishsiaiskinom, ir tai kad vieno featuro paskubinimas nors ne daug, labai stipriai nukelia kitu featuru isleidimus, o atejus sprintui kur bus daromi nauji featurai jie irgi bus LABAI LABAI SVARBUS).
    Ziurime toliau, kaip viskas turetu atsistoti i vezias po N iteraciju. Kaip minejau pirmame sprinte visi dirbo ties sritimi sA, tarkime antrame sprinte visi dirba su sritimi sB, treciajame sprinte visi puola dirbti su sritimi sC. Paziurekime kas cia darosi: ekspertas A ir B turetu dirbti 2x leciau, ekspertas C turetu dirbti normaliai. Bet ne. Ekspertas C per 2 sprintus (menuo ar daugiau), jau primiso savo ekspertine sriti, ypach jei toje srityje kas nors dar kapstesi be jo. Todel rezultate Ekspetas C dirbs maziausia 2,5 karto leciau, nes jam reikes prisiminti savo ekspertine sriti, plius apmokinti ekspertus A ir B. Tuo paciu Ekspertai A ir B irgi dirbs leciau nes ju apmokymas truks ilgiau, tarkime 2,5 karto leciau. Koki rezultata gauname? o tai kad per viena sprinta bus padaryta 1,2 sprinto darbas ir sunaudota 3 sprintu resursai. Kuo daugiau komandoje nariu (tarkime visi jie ekspertai) ir kuo ilgiau ekspertai atlikineja ne savo srities uzduotis, tuo ju kvalifikacija prasteja. Cia kaip sportininkui, paimk geriausia pasaulio begika, pasodink i foteli porai menesiu ir girdyk ji alumi ir prideginek cigaretes, tai po dvieju menesiu jis savo sportine forma atgaudines laaaaabai ilgai jei isvis atgaus.
    O dabar paziurekime i featurus. Pirmas featuras, kuris normaliai butu atliktas per 1,5 sprinto) buvo atliktas per 1 sprinta – VALIO! visi laimingi. Antras featuras, kuris galejo buti atliktas normalia eiga per 1,35 sprinto, buvo atliktas per 1 sprinta- VALIO!! vel padareme greiciau. Trecias featuras, kuris buvo galima atlikti per 1,2 sprinto, buvo atliktas per trecia sprinta – Vel gerai, padarem greiciau. Atlikti siems featurams uztrukome 3 sprintus.. visai neblogai? O jei specialistu nebutumem mete po visas sritis, visi tie featurai butu atlikti per 1,5 Sprinto, ir dar 0,45 sprinto kazkurie ekspertai ilsetusi arba darytu kitus smulkesnius featurus. Tai kur aritmetika? Jei uzsakovas visus 3 featurus gautu 2 kart greiciau darant be ekspertu metymo tarp sriciu? Manau cia gaunasi optine apgaule pavadinimu “Gyvename vienu sprintu”.
    Reziume, Metant ekspertus po skirtingas, jiems nebudingas, sritis:
    1) Islosiama “momentinio” virtualaus performanco.
    2) Prarandama Ekspertu kvalifikacija
    3) Sunaudojama daugiau kastu, featurai gaunasi brangesni.
    4) Ilgalaikeje perspektyvoje featurai iseina su pavelavimu, t.y. ilgalaikeje perspektyvoje performancas yra daug mazesnis.
    5) Darbu kokybe visada bus blogesne nei jas atliktu tos sritiesEskpertas.
    6) Pagal 3 ir 4 punktus gauname kad rodyklis Price/Performance zenkliai prastesnis nei Ekspertai dirbtu prie savo sriciu
    7) Pagal 3 ir 5 punktus gauname kad kitas rodiklis Price/Quality irgi suprastejes.

    Toks ekspertu metymas po kitas sritis galimas turi buti atliekamas TIK LABAI RETAIS ATVEJAIS, kai daromo Featuro generuojamas pelnas bus DIDESNIS nei patiriamos VISOS papildomos islaidos, Ekspertu profesiniu ziniu atstatymo islaidos, nera kritiskai svarbi featuro kokybe, ir ATPIRKS kitu uzvelintu featuru prarasta pelna, del velyvesnio ju isleidimo.

  9. O kiek daug nauju komentaru. Puiku!

    @Naujakurys: taip, jei santechnikas vienas klos plyteles kokybės galima nesitikėti. Bet jei santechnikas bus plytelių klojėjo experto padėjėjas manau situacija bus visai kita. Siaip dazniausiai gyvenime taip ir buna: meistras su pameistriu dirba 😉 Tas pats ir Scrum komandoje: bet abejo vieno ne experto palikti negalima. Jis turi PADĖTI ekspertui, o ne viską daryti vienas.

    @Pacientas: tu visiškai teisus. Yra sričių kur tik expertai turi atlikti užduotis, nes jos yra kritinės žmonių sveikatai. Pvz. manau NASA tikrai turi expertų komandas programinės įrangos kūrimui! Tad viskas su sveiku protu!

    @Gytis: tavo skaičiavimai yra visiškai teisingi su dviem prielaidom. Pirma: visos projekto užduotys yra tiksliai suplanuotos ir apibrėžtos projekto pradžioje ir vykdymo metu jos nesikeičia. Antra, tos suplanuotos ir nekintančios užduotys padengia kiekvieną ekspertą lygiai 100% (t.y. visi ekspertai turi vienodai užduočių ir jų suma lygi jų darbo valandų sumai). Mano patirtis rodo kad šios dvi prielaidos NIEKADA negalioja programinės įrangos kūrime. Taip, tradiciniai projektų valdymo metodai bando mokyti kaip viską tiksliai suplanuoti užduotimis (pvz pusės metų projektą), bet praktika rodo kad tai neveikia. Todėl ir atsirado Agile metodai, kurie pripažįsta kad pokytis yra natūralus ir neišvengiamas dalykas. Jie siūlo kaip efektyviausiai dirbti realiose salygose.

  10. Naujakurys says:

    Vaidai, ar sutiktum moketi pameistriui meistro alga, kuri yra 3-6 kartus didesne nei tikro pameistrio?
    Nes jei meistras dirbs pamestrio darba, jis nores gauti savo kvalifikacija o ne atliekama darba atitinkanti atlygi.

  11. @Naujakurys: kaip ir rašiau straipsnyje, paprasta aritmetika čia nelabai veikia 🙂 Jei aš turėčiau 2 darbuotojus savo butų remonto kompanijoje (meistrą plytelių klojėją ir meistrą santechniką) aš visada į objektą siųsčiau abu kartu. Kol santechnikas tvarkytų santechniką plytelių klojėjas būtų jo pagalbininkas. O klojant plyteles rolėmis jie apsikeistų. Praktika rodo kad dirbant dviese daug darbų pasidaro greičiau ir kokybiškiau nei dirbant po vieną. Ir tikrai mokėčiau jiems atlyginimą pagal kvalifikaciją, o ne pagal tai kiek laiko jie iš tikrųjų pradirba būtent savo kvalifikacijos darbą.

    Bet gal paliekam butų remontus šalia ir grįžtam prie programinės įrangos kūrimo 🙂 Čia darbų pasidalinimas dažniausiai yra žymiai lengvesnis, tad ir problemų mažiau.

1 Pings/Trackbacks for "Kas produktyviau: individualūs ekspertai ar tarpfunkcinė Scrum komanda?"
  1. […] suburti kompanijos darbuotojus į stabilias tarp-funkcines komandas. Apie tai buvo straipsnis „Kas produktyviau: individualūs ekspertai ar tarpfunkcinė Scrum komanda?“. Šio straipsnio tikslas panagrinėti noro, jog komandos dirbtų prie kelių projektų vienu […]

Artimiausios mokymų klasės
Data Mokymai - Lektorius
2017 m. gruodžio 14-15 d. Certified Scrum Master (CSM) - Alexey Krivitsky (anglų kalba)
2017 m. gruodžio 14-15 d. Certified Agile Leadership CAL1 - Angel Diaz-Maroto (anglų kalba)
2018 m. sausis 18-19 d. Certified Scrum Product Owner (CSPO) - Lasse Ziegler (anglų kalba)
2018 m. sausio 26 d. Agile projektų valdymo pagrindai - Vaidas Adomauskas (lietuvių kalba)
2018 m. vasario 8-9 ICAgile sertifikuotas profesionalas (ICP) - Vaidas Adomauskas (lietuvių kalba)
2018 m. Management 3.0 Change and Innovation Practices
2018 m. Reikalavimų valdymas Agile projektuose - Vaidas Adomauskas (lietuvių kalba)
2018 m. Better Retrospectives - Jeff Campbell (anglų kalba)
2018 m. Kanban System Design (KMP I) - Gaetano Mazzanti (anglų kalba)
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