Šįkart blogo įrašas apie vadinamuosius žmonių „minkštus” įgūdžius (soft skills). Tai buvo pagrindinis akcentas mūsų pranešime MIDI IT konferencijoje. Dėkojam visiem atėjusiems ir uždavusiems tikrai daug klausimų. Jei jų dar turite, rašykit!
Čia ištrauka iš rodytų skaidrių: 4 mitai apie reikalavimus darbuotojams
Kadangi skaidrėse daug paveiksliukų ir mažai žodžių (juk tai vaizdas, ne tekstas), tad pabandysiu surašyti trumpą santrauką apie ką mes kalbėjome. O kalbėjome apie 4 mitus. Mūsų mitai – tai įgūdžiai, kurių tradiciškai reikalaujama iš darbuotojų. Mes bandėme šiuos mitus sugriauti, parodydami ko gi iš jūsų tikisi judrios kompanijos.
Mitas: geriausi darbuotojai – siauros srities ekspertai!
Tradiciniuose projektuose darbuotojai skirstomi į padalinius (skyrius, grupes) pagal įgūdžius (pvz.: analitikai, .NET programuotojai, SQL programuotojai, testuotojai). Natūralu, kad visi tikisi kad tie specialistai bus savo ir tik savo srities ekspertai.
Pradedant dirbti judriais metodais, vienas iš pagrindinių reikalavimų yra funkcionalumą skaldyti vertikaliai, per visus techninius sluoksnius. T.y., kad po kiekvieno sprinto turėtume visiškai pabaigtą iš vartotojo požiūrio funkcionalumą. Jei turime 3 sluoksnių architektūrą ir tris žmones komandoje kurie yra tų sluoksnių ekspertai, atrodo viskas būtų idealu. Tačiau realiame gyvenime dažniausiai būna taip, kad pabaigti skirtingą funkcionalumą reikia kiekvienos srities ekspertų skirtingo kiekio ir laiko. Ką daryti?!
Ogi mums reikia, kad mūsų judrios komandos būtų tokios kaip A-TEAM! Visi šios komandos nariai yra savo srities ekspertai, tačiau jie visada padeda vienas kitam kada reikia. Jie niekada nesakys „negalime baigti šios misijos laiku nes reikia vairuoti du automobilius, bet tik vienas iš mūsų yra geriausias vairuotojas”. Ne, jie padės vienas kitam, kad pasiekti bendrą tikslą. Jų atveju – misijos tikslą. Scrum atveju – Sprinto pabaigimo (Done) kriterijų. Taigi Scrum metodikoje ši ekspertų problema sprendžiama kuriant komandas, kurios turi visus reikalingus įgūdžius darbui atlikti (tarp-funkcinė) ir kurie patys organizuojasi ir padeda vienas kitam pasiekti komandos tikslą (savi-organizuojanti).
Taigi, geriausi darbuotojai – tie kurie gerai išmano savo pagrindinę sritį, BET žino ką ir kaip daro kiti jų komandos nariai ir yra visada pasiruošę jiems padėti. Pavyzdžiui SQL programuotojas turi žinoti, kad sprintų metu jis darys ir vadovaus pagrindinėms SQL programavimo užduotims, bet dažnai jam teks padėti kitiems pvz. programuojant kitus sluoksnius ar padedant analizuoti/testuoti.
Mitas: geriausi darbuotojai – detaliai planuojantys!
Kai mes einame į darbo pokalbį vieni iš dažniausiai užduodamų klausimų yra: „Ar moki planuoti laiką? Ar moki tiksliai vertinti kiek užturks įgyvendinti užduotis? Ar turi tokios patirties?”. Kodėl taip yra? Todėl kad visi standartiniai projektai būna detaliai aprašyti, įvertinti, ir tiksliai „aišku” kiek kokių resursų reikės ir kada projektas bus baigtas. Bet būkime atviri, iš tikrųjų, šie įvertinimai yra tik geriausi mūsų spėjimai šiai dienai, t.y. projekto pradžioje, kai iš tikrųjų turime mažiausiai informacijos apie projekto detales. Jos realiai paaiškės tik pradėjus jį įgyvendinti.
Geriausias atvirkštinis tokio detalaus planavimo (arba tiksliau spėjimo) pavyzdys yra Vilniuje esantis statomas pastatas. Nežinau ar buvo taip planuota, ar jiems taip gavosi, bet šis statinys yra idealus iteracinio proceso pavyzdys. Projekto autoriai turėjo viziją ir bendrą koncepciją koks statinys turėtų būti. Tačiau apie galutines detales (pvz. kokie baldai, sienų spalva) sprendė vėliau ir tik tai daliai kuriai tuo momentu reikia. T.y jie pabaigė vieną vertikalią dalį ir tada ėmėsi kitos. Taigi pirmoji jau buvo baigta (IT terminais kalbant būtų: paleista arba angliškai released), pradėjo nešti vertę (pinigus), o projektas toliau tęsiamas. Tikriausiai užpuolus krizei projektas sustojo. Tačiau ir tai ne bėda. Jie jau gauna pajamas iš to ką spėjo pastatyti. O kas būtų jei būtų bandę pabaigti visą pastatą iš karto? Būtų viskas nepilnai pabaigta, tai reikštų jokio paleidimo (release), jokių pajamų.
Taigi, judriose kompanijose mums reikia, kad darbuotojai suprastų projekto viziją ir tikslus. Jie turi žinoti, kad projektas gali keistis priklausomai nuo aplinkybių, tad detaliai mums reikia planuoti tik ateinančio sprinto darbus. Bendras projekto planas turi būti lankstus pokyčiams. Scrum tai užtikrina per produkto užduočių sąrašą (Product Backlog). Jame visas projekto funkcionalumas surašomas funkcijomis iš vartotojo pusės. Įvertinamas šių funkcijų dydis ir vertė kurią jos atneš. Pagal šį santykį, produkto užduočių sąrašas prioretizuojamas taip, kad naudingiausias funkcionalumas atsidurtų sąrašo viršuje. Aukščiausiai sąraše esantį funkcionalumą komanda ims įgyvendinti per artimiausią sprintą. Tuo metu, likęs produkto užduočių sąrašas gali būti keičiamas ir papildomas pagal esamą situaciją ir rinkos poreikį.
Taigi, geriausi darbuotojai – tie kurie sugeba suprasti projekto prie kurio jie dirba viziją ir tikslus. Jie priima pokyčius kaip natūralų dalyką ir kuria programinę įrangą žinant, kad naujas funkcionalumas gali būti kitoks negu galvojam šiandien. Detaliai planuoti, t.y. tiksliai fokusuotis reikia tik į šio sprinto darbus.
Mitas: geriausi testuotojai – programuotojo priešai!
Kada testuojas laimingiausias? Kai randa klaidą!!! J O kodėl? Todėl, kad kažkas pasakė kad toks jų darbas – ieškoti klaidų. Dar daugiau, jiems leidžiama tai daryti tik projekto pabaigoje, projekto pradžioje juk nieko veikiančio nebūna. O jeigu ir būna, tai tas funkcionalumas dar tikrai nebaigtas ir testuoti jo neapsimoka. Taigi projekto gale visada turime ilgą testavimo arba dar ir stabilizavimo fazę.
Betgi judriuose projektuose mums reikia jog testavimas, taip kaip ir detali analizė, dizainas, programavimas būtų daroma kiekvieno sprinto metu, kiekvienam funkcionalumui. Taigi mums reikia, jog testavimu, arba tiksliau kokybės užtikrinimu, užsiimtų visa komanda. Visa komanda ir kiekvienas jos narys atskirai paėmus yra atsakingi už produkto kokybę. Jei kažko neišsiaiškinom kartu analizuodami, kurdami dizainą, užmiršom programuodami, tai mūsų visų atsakomybė! O jei tai suradome, tai geriau pagalvokime kaip daryti taip, jog dar kartą tokia pati situacija nepasikartotų.
Scrum procesas tokią komandinę kokybės atsakomybę užtikrina reikalaudamas, kad po kiekvieno sprinto komanda paruošų pilnai pabaigtą funkcionalumo pjūvį. Dar daugiau, sprinto peržiūros (Sprint Review) metu, šis veikiantis funkcionalumas parodomas produkto šeimininkui (Product Owner) ir klientams. T.y. jie priima ar tai ką komanda padarė yra iš tikrųjų tai ko jie prašė. Dar kartą atkreipiu dėmesį jog tai turi būti veikiantis funkcionalumas, ne dokumentai. Aišku, šis funkcionalumas turi būti be klaidų (bent jau žinomų).
Taigi, geriausi testuotojai – kurie užsiima kokybės užtikrinimo procesu ir įtraukia į jį visą komandą. Jie nuolat testuoja labai mažus funkcionalumo pjūvius ir jei randa klaidų, kalba su komanda kaip gerinti analizės/programavimo procesą komandoje kad klaidos nesikartotų. Taip pat jie aktyviai įsitraukia į testavimo automatizavimą patys rašydami automatizuotus testus arba pvz. paruošdami automatizuotų testų scenarijus (testavimo atvejus) programuotojams.
Mitas: geriausi darbuotojai – naktiniai herojai!
Daugelis IT kompanijų turi darbuotojus, kurie „išgelbėja” projektus. Kažkokių antgamtinių savybių dėka, jie yra tie, kurie baigiantis projektui susiima, padirba po darbo ir savaitgaliais, ir projektus ištempia. Aišku, prasidėjus kitam projektui jie turi pakankamai laiko atsipūsti, atgauti jėgas. Kai kitas projektas artėja į pabaigą ir projektų vadovas pradeda panikuoti kad yra visiškai blogai su datomis, jie vėl herojiškai stengiasi. Ir pripažinkime, nors projektai ir pabaigiami, labai dažnai ta pabaigos data būna vėliau negu tikėtasi pradžioje.
Tuo tarpu judriose kompanijose, funkcionalumas kuriamas sąlyginai trumpais sprintais. Taigi „deadline‘ai” yra pastovūs. Nuolat reikia palaikyti ritmą ir pabaigti funkcionalumą. Žmonės čia turi būti maratono bėgikai, ne sprinteriai. Jie turi nuolat palaikyti stabilų ritmą, stabilų kūrimo greitį ir neperdegti. Juk įmanoma dirbti viršvalandžius savaitę, galbūt dvi. Bet jei taip tęsti nuolat, tai žmogus pervargs. O kai žmonės pervargsta kenčia vienintelis dalykas: kokybė!
Scrum taisyklės reikalauja kad sprintai būtų 1-4 savaičių ilgio. Per trumpesnį laiką nei savaitė iš tikrųjų komandai nelabai įmanoma kažką apčiuopiamo padaryti. O per daugiau nei mėnesį užsiimsime per dideliais darbais ir negalėsime numatyti detalių reikalingų efektyviam sprinto darbui. Scrum komanda susirenka kasdieniame Scrum susirinkime ir pasitikrina statusą kaip jiems sekasi vykdyti tai ką susiplanavo. Jie brėžia sprinto deginimo kreivę, kuri aiškiai rodo kiek dar darbo liko sprinte ir ar jų greitis yra pakankamas įgyvendinti funkcionalumą iki pažadėto pabaigto (Done) kriterijaus.
Taigi, geriausi darbuotojai – kurie sugeba nuolat palaikyti gerą darbo tempą ir nuolat pabaigti funkcionalumą po kiekvieno sprinto. Jie turi visada rūpintis kuriamo produkto kokybe ir nedaryti kompromisų kai pradeda spausti laikas (net ir sprinto metu). Labai svarbu nesistengti būti herojumi, nes svarbiausia yra tai, kad komanda kartu pabaigtų darbus. Be to, kaip jau ir minėjau, persitempus norėsis atstatyti jėgas, o laiko tam nėra. Sprintas seka sprintą.
Motyvacija
Svarbiausia diegiant judrius metodus arba einant dirbti į kompaniją kuri juos naudoja yra suvokti, jog tai turi būti vertybės ir principai, kurie artimi tau. Tu turi norėti dirbti būtent taip. Tau tai turi būti priimtina. Žmonių neįmanoma tiesiog motyvuoti, juos galima tik demotyvuoti. Žmonėms arba patinka ką jie daro ir kaip jie tai daro arba ne. Tad jei Agile/Scrum idėjos, tikslai ir priemonės tau „ne prie širdies”, nebandyk jų! Jei manai kad tai tau, pradėk jas taikyti.
Aš tikrai noriu atvirai pasakyti: dirbti pagal Agile/Scrum yra sunku. Daug sunkiau nei pagal standartinius metodus. Ir ne todėl kad reikia dirbti daugiau ar sunkiau. Dažniausiai dirbama tiek pat, tačiau rezultatai pasimato daug geresni ir dirbti pasidaro linksmiau. Bet sunkiausia, pakeisti nusistovėjusią mąstyseną, pačiam prisiimti atsakomybę, už ją atsakyti, dirbti komandoje, būti atviram ir nuoširdžiai patikėti dalykais, kurie ne visada iš pirmo paskaitymo atrodo įmanomi.
Nieko nėra neįmanomo. Tai tiesiog reiškia, jog užtruks truputį ilgiau!
Comments