Kas bendro tarp Agile naudojimo Lietuvoje ir paauglių sekso?

Diskusija LinkedIn „Lithuanian IT Professionals” grupėje vėl man priminė seniai girdėtą linksmą (bet dažnai Lietuvos įmonei tinkantį) posakį: „Agile naudojimas yra kaip paauglių seksas. Visi sako, kad juo užsiiminėja, bet tik 10% iš tikrųjų tai daro. O ir tie kurie tai daro, daro tai neteisingai” 🙂

Liūdniausia, kai tie kas daro „kažką” vadina tai Agile. Pateikiu keletą „perliukų” iš diskusijos

Agile sekta, bažnyčia ar mitologinė dievybė?

„Kas dėl Agile – kiek teko susipažinti tai vėl kažkas mistifikuoto ir kitaip pavadinto” , “Bandyti pamatuoti Agile šventovę tas pats kad Galilėjui kritikuoti bažnyčią, čia Agile sekta” , “Jei Agile kaip bažnyčia tai lieka tik nešti pinigus ir tikėtis apvaizdo”.

Aš puikiai suprantu, jog tai kas yra mažai žinoma visada atrodo baugu ir klastinga. Tačiau tie kas susipažįsta giliau supranta, jog Agile projektų metodai nesiūlo jokios magijos ar burtų. Skėtinis terminas „Agile” apibūdina geriausiai praktikoje veikiančių principų rinkinį aprašytą Agile manifeste (http://www.agilemanifesto.org/). Konkretūs Agile projektų valdymo metodai (Scrum, Kanban, Extreme Programming ir kiti) aprašo aiškias (ir gan griežtas) roles ir taisykles. Jų laikantis, suplanuojamas, ir suvaldomas projektas, pasiekiama laukiama nauda. Taigi jokios vudu magijos čia nei per plauką nerasime 🙂

Jokios kontrolės

„Mažos, lanksčios, judrios, kūrybingos ir niekam neatskaitingos komandos. Kaip Scrum masteris nuspręs taip ir bus.”

Kaip be rizikų valdymo, atskaitomybės, tikrinimų suvaldyti projektus? Daugelis atsakys – tai neįmanoma. Agile sako ta patį – net nebandykit. Todėl visi Agile metodai turi aprašytus labai aiškius patikrinimo taškus. Vienas pagrindinių – iteracijos pabaiga ir pagaminto produkto inkremento pridavimas. Kas geriau parodys ar komanda teisingai suprato užduotį, sugeba ją įgyvendinti su reikiama kokybe per apsibrėžtą laiką, jeigu ne parodymas ką jie padarė per iteracijos peržiūrą? Jeigu nepadaro, turi būti sekamos metrikos kodėl nepadarė, ką galime daryti kitaip, kad iteracijos pradžioje duotas pažadas būtų įvykdytas.

Scrum meistras (Scrum metode), tiesiog rūpinasi jog rezultatas būtų pasiektas ir pridavimas įvyktų sėkmingai. Jis identifikuoja galimas rizikas (išorines ir vidines) ir jas šalina. Jis jokiu būdu nesprendžia už komandą. Scrum meistras yra lyderis, tarnaujantis komandai. Ir pagal apibrėžimą – jis negali nebūti oficialus komandos narių vadovas. Šio apribojimo tikslas – kad tikrasis vadovas galėtų užkurti gerą pirtį komandai, kai ši nepadaro ką pati prisižadėjo :). Na, yra dar ir daugiau gerų priežasčių, bet šita linksmiausia.

Programuotojai dirba pardavėjais ir rinkos specialistais

“Agile prieštarauja rinkos ekonomikai, vertinimą atlieka (tuo pačiu nustato kainą) produkto gamintojas (programuotojas) o ne rinka (pardavimu skyrius).”

Aš pirmą kartą išgirdau, kad gamybos skyriaus vertinimai diktuotų sąlygas produkto ar paslaugos kainai. Taip, visi Agile metodai turi tiek paleidimo (release) tiek iteracijos planavimo veiklas, kuriose reikalingo darbo įvertinimus daro tie kas darys patį darbą. Tai suteikia galimybę realiai žinoti kiek užtruks padaryti šią funkciją/produktą/projektą. Tačiau tai niekaip neįtakoja pardavimo kainos. Pardavimo kaina turi būti nustatoma remiantis rinkos dėsniais ir Agile darbų vertinimo praktikos čia ne prie ko. Tiesiog jos suteiks tikslesnę informaciją. O tiksli informacija leis verslo pusei daryti strateginius sprendimus: apsimoka mums vykdyti šį projektą ar ne, koks jo tikrasis atsiperkamumas (ROI) ir pan. Tikslesni vertinimai taip pat leidžia lengviau prioretizuoti funkcijas paleidimams.

Bet to, Agile siūlomos užduočių dydžių praktikos pasinaudojant istorijų taškais, planavimo pokeriu ar balto dramblio metodu, leidžia projektų/užduočių dydį įvertinti daug greičiau, išlaikant tą patį (o dažnai net didesnį) tikslumą. Taip sutaupoma daug brangaus laiko, kurį galime praleisti produkto kūrimui.

Svarbiausia suprasti – „kodėl veikia”

Taigi norėčiau dar kartą visus paraginti arba pradėti gilintis į tai kas yra Agile ir kuo pagrįstas šiuo metodų veikimas. Tikrai verta prieš pradedant taikyti Agile kompanijoje perskaityti bent vieną knygą (nesiremti vien blogų straipsniais ar forumų diskusijomis) ir sudalyvauti mokymuose (ne vien konferencijose ar naudotojų susitikimuose). Visi Agile metodai ir visos praktikos turi labai aiškų, mokslu bei praktika paremtą paaiškinimą.

Būtent todėl beveik ketvirtadalis mano „Agile projektų valdymas naudojant Scrum” kurso yra skirtas praktiniams užsiėmimams ir diskusijoms „kodėl Agile metodai veikia” (dar turite kelias dienas laiko suspėti į jį užsiregistruoti). Supratus tai, taikyti gan paprastas Agile metodų taisykles pasidaro daug lengviau. Tada gal nustosime Agile metodų naudotojus vadinti „sektantais” ir „šarlatanais”, o Agile projektų valdymas bus pradėtas pripažinti taip pat kaip yra pripažįstamas PMBOK, Prince2 ar ITIL.

Tagged with: ,
Posted in Agile, Scrum
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