„Agile“ – LEAN principai IT sektoriuje: praktiniai aspektai

Interviu su „Deloitte“ Jungtinės Karalystės programuotojų vadovu Martinu Aspeliu.

Šaltinis: lrytas.lt, 2016-08-25, 14:18

LEAN principai sėkmingai taikomi ir IT sektoriuje. Viena labiausiai populiarėjančių metodikų yra „Agile“ – tam tikra LEAN interpretacija ir pritaikymas IT sektoriuje.

Vis daugiau organizacijų perima Agile valdymo principus, didėja poreikis objektyviai palyginti komandas, įvertinti efektyvumą ir kokybę. Bet ar tai suderinama su „Agile“ mąstysena? Ar tai iš viso įmanoma?

Apie „Agile“ matavimus pasakoja „Deloitte“ Jungtinės Karalystės programuotojų vadovas Martinas Aspelis.

– Kokiomis priemonėmis įprastai matuojamas produktyvumas ir kaip turėtų atrodyti „geros“ priemonės? Pavyzdžiui, koks turėtų būti programuotojų ir kitų komandos narių santykis komandoje?

– Mes turime pasiūlymų, kaip turėtų atrodyti „gera“ komandos struktūra. Įprastai kiekvienoje komandoje turime 4-8 programuotojus, techninį vadovą, funkcinį vadovą ir dar 1-3 neseniai bakalauro studijas baigusius kolegas, kurie prisideda prie kokybės užtikrinimo procedūrų.

Taip pat dažnai suformuojame skirtingų sričių, tokių kaip SIT (integruotas testavimas) ir NFT (nefunkcinis testavimas), testuotojų komandą, kuri, prireikus, atlieka nepriklausomą patikrinimą. Šios funkcijos įgyvendinimui mūsų klientai dažnai pasitelkia trečiąją šalį. Vis dėlto svarbu pabrėžti, kad pagrindinės kokybės užtikrinimo procedūros atliekamos „gamykloje“, kaip dalis įprastinio darbo, įtraukiant tokias funkcijas kaip porinis programavimas, kodų peržiūros, automatizuoti testavimai.

Matavimo rodikliai gali skirtis priklausomai nuo projekto, taigi šiuo pagrindu negalima lyginti komandų, nebent jos veikia visiškai tokiomis pačioms sąlygomis ir visiškai tokiais pačiais įvesties reikalavimais, tačiau taip beveik niekada nebūna. Visgi, galima išskirti tam tikrus galimus naudoti indikatorius:

• Kiek pradėto, bet dar nebaigto darbo yra įgyvendinimo procese (angl. WIP, Work-in-process)?

Jeigu tokio darbo dalis yra neproporcinga atskiros komandos atžvilgiu (t.y. komanda turi santykinai daug „neuždarytų“ užduočių), tokiu atveju nukenčia efektyvumas dėl dviejų priežasčių. Viena jų – eikvojamas komandos laikas ir pajėgumai, kadangi yra mėtomasi nuo vienos užduoties prie kitos. Kita – ilgėja viso proceso trukmė, nusikelia grįžtamojo ryšio gavimo etapas ir visa tai sumažina proceso rezultatyvumą ir efektyvumą.

• Kaip laikui bėgant keičiasi darbo našumas (Scrum komandos sparta)?

Įprastai proceso pradžioje darbo našumas yra žemas ir vėliau pradeda augti. Pavyzdžiui, jeigu kiekvieną savaitę būtų žymimas užbaigtų vartotojų istorijų skaičius (arba kitu produktyvumo matavimo parametru), našumą būtų galima įsivaizduoti kaip S raidės formą: mažesnis augimo tempas pradžioje, didesnis link vidurio ir vėl sumažėjęs link pabaigos.

Komanda, kuri netobulėja, yra arba visiškai efektyvi nuo pradžios (mažai tikėtina), arba nesiima jokios veiklos, kuri lemtų nuolatinį tobulėjimą (prarasta galimybė).

Klaidos, t. y. pakartotinis darbas, kurį reikia atlikti dėl nesėkmingo bandymo sukurti gerą produktą. Tai trukdo sklandžiam darbui,  kadangi programuotojai turi grįžti prie darbo, kuris jau turėtų būti pabaigtas. Kartu tai sudaro problemų prognozuojant tikrąjį darbo našumą, nes darbas nėra pilnai padarytas, jeigu jame yra trūkumų.

Taip pat galima išmatuoti aptiktų trūkumų skaičių konkrečiame testavimo cikle bei vidutinį jų amžių. Daug „senų“ trūkumų reiškia, kad komanda kuria netikrą vertę: nors darbas yra padarytas, tačiau dėl defektų jis neatlieka savo funkcijos. Ši problema dažniausiai kyla dėl programuotojų, kurie vadovaujasi požiūriu, kad kokybė yra „kieno nors kito problema“.

Gera „Agile“ komanda gali užtikrinti, kad sukurta vertė būtų matoma ankstyvoje projekto įgyvendinimo stadijoje, o ne pasiekus projekto pabaigą. Kuo efektyvesnė, greitesnė ir labiau į verslą orientuota kūrimo komanda, tuo geriau ji sukurs verslui reikalingą produktą, perpras jo veikimą ir panaudos žinias, siekiant sukurti dar didesnę naudą.

Tam reikalingos efektyvios priemonės darbų prioretizavimo, grįžtamojo ryšio rinkimo ir planavimo trumpuoju laikotarpiu srityse.

– Kur plačiąja prasme reikėtų dėti daugiau pastangų, siekiant užtikrinti sėkmingą IT projekto įgyvendinimą?

– Pastangos įdėtos kuriant naujus funkcionalumus versus egzistuojančio funkcionalumo tobulinimui skirtos pastangos, turėtų būti proporcingos kiekvienos iš šių sričių sukuriamos vertės atžvilgiu.

Tai gali apibūdinti sąvoka „vėlavimo kaina“ (angl. cost of delay). Nors tai gali būti sunku įvertinti tikslia pinigine išraiška, tačiau galima pastebėti tam tikras tendencijas. Taigi, elementai gali turėti keletą požymių.

Vienas jų – lėtai kylanti vėlavimo kaina („kiekvieną dieną neturėdami tam tikro funkcionalumo atsisakome šiek tiek pajamų, taigi būtų gerai šį funkcionalumą turėti kuo anksčiau“.

Kitas  – greitai kylanti vėlavimo kaina („tai kenkia mums dabar ir kenks ateityje, kol to nepadarysime“). Trečias – į ateitį orientuota vertikali vėlavimo kaina („jeigu mes nepatenkinsime šio reikalavimo iki termino pabaigos, būsime pašalinti iš verslo, taigi vėlavimo kaina – ypač didelė“).

Dar vienas – algoritmine skale paremta vėlavimo kaina („šiuo metu tai nekenkia mums, bet kažkuriuo momentu gali labai pakenkti“).

Remiantis pateiktu skaidymu galima prioretizuoti darbus.

Investicijos (pavyzdžiui, gerinti pagrindinę infrastruktūrą) yra algoritminės ir jauni verslai niekada neprioretizuos tokių investicijų, kol neprasidės krizė („turėjome atnaujinti mūsų platformą prieš 4 metus ir to nepadarėme, tačiau dabar ji yra nebepalaikoma, taigi reikia viską mesti ir tvarkyti šią problemą“).

Tokiu atveju komanda yra mėtoma nuo vienos krizės prie kitos ir tokie svyravimai kenkia efektyvumui. Todėl mes dažnai skatiname komandas pasilikti tam tikrą nedidelį pajėgumų rezervą (tarkime, 10%), kuris būtų panaudotas tokiam „investiciniam“ darbui. Toks rezervas taip pat leidžia lanksčiau reaguoti atsiradus skubiai ar nenumatytai užklausai.

Analogišką situaciją galima pastebėti ir pereinant prie nedidelių pokyčių bei aukšto lygio specialistų rezervo išlaikymo: jeigu komanda yra pasilikusi tam tikrą pajėgumų rezervą, tačiau neįvyksta joks reikšmingas incidentas, rezervą galima panaudoti atliekant kitus darbus, pavyzdžiui, dokumentacijos tvarkymą ar asmeninį mokymąsi, kas taip pat sukurtų tam tikrą pridėtinę vertę.

Kita vertus, išaugęs pajėgumų poreikis verčia permąstyti pirminio sprendimo dėl darbų paskirstymo kokybę ir pasimokyti iš to: yra daug efektyviau nustatyti problemą proceso metu negu jam pasibaigus. Dažniausiai tai yra ženklas, kad iki termino pabaigos komandos krūvis yra per didelis ir verta sumažinti darbo krūvį, o ne pratęsti terminą.

– Kokius organizacinės struktūros modelius jau esame matę? Pavyzdžiui, grupavimas pagal įgūdžius (testuotojai, programinės įrangos inžinieriai, UX ir t. t.) arba grupavimas pagal sprendimo komponentus.

– Scrum požiūriu, reikia turėti daugiafunkcinę komandą su platesnio specialistų pritaikymo kitose srityse galimybe. Kiti metodai šiuo požiūriu yra labiau skeptiški: jeigu vienai komandai yra priskiriama daug funkcijų, tai reikalauja papildomos komunikacijos bei tam tikros išteklių valdymo ir stebėsenos sistemos, o tai lemia laiko bei pajėgumų eikvojimą. Visgi, kuo daugiau viena komanda ar netgi vienas žmogus gali prisiimti atsakomybės, tuo efektyviau vyks procesas.

Mūsų komandose „gamyklą“ (t. y. ką mes valdome) laikome vienu vienetu, kuriame nors ir egzistuoja tam tikra specializacija (projektų vadovas, programuotojas, studentas), tačiau dažniausiai visas procesas nuo idėjos iki kodo sukūrimo yra priklausomas nuo visos komandos kaip vieneto. Proceso metu dažniausiai taip pat atliekame ir nepriklausomą patikrinimą (vykdomą kliento), kurio metu atliekami testavimo darbai (pvz. SIT/UAT/NFT). Visgi tokio patikrinimo metu netikslumų skaičius turėtų būti žemas, kadangi procesas būna testuojamas ir prieš tai.

Vykdydami į klientų aptarnavimą orientuotus projektus (angl. front-end focused projects) turime atidžiai permąstyti, kaip geriausiai suderinti dizainerių, UX (angl. user experience) dizainerių bei programuotojų darbus, kitaip tariant – turime suporuoti juos. Daug geriau, jeigu programuotojas gali iš karto dirbi kartu su (UX) dizaineriu ir eksperimentuoti realiuoju laiku, nei dirbti atskirai ir gaišti laiką laukiant rezultato po kiekvienos užklausos.

Žinoma, tai turi poveikį išteklių perskirstymui. Jeigu veikia bendri paslaugų centrai, tokioms sritims kaip dizainas ar testavimas, reikia suvokti, kad tam tikras laukimas yra neišvengiamas. Tokiu atveju paslaugų centrai suprantami kaip tiekėjai, o komandos, kurioms reikia centro paslaugų – klientai. Taip pat yra sukuriamos aiškiai apibrėžiamos taisyklės, pagal kurias komandos galėtų planuoti savo darbą ir laiką.

Straipsnį galite perskaityti portale lrytas.lt