Archive for May, 2016

May 12 2016

Agiilsus kui kaubakultus ja laiskuse vabandus

Published by Targo under Projektijuhtimine

Kui sa osaled tänapäeval mingis tarkvaraprojektis, on selle osalejad või juhid tõenäoliselt kusagil öeldud, et see on agiilne* projekt. Ütlemise kohaks võivad olla müügimaterjalid, värbamiskõned või muu koht, kus vaja end popi ja tublina näidata.

Võid selle väite kontrolliks teha väikese testi:

1. Kas teil on igapäevased standupid?

Sõltumata vastusest saad 0 punkti. Rituaalsed protseduurid, nagu kindla formaadiga koosoleku pidamine, ei oma mingit tähtsust.

2. Kas teie loodud kood on viimase 2 kuu jooksul päris kasutajateni jõudnud? Tellija projektijuht ei loe, loeb ainult reaalne kasutamine!

Kui jah, lisa 1 punkt. Pidev tarne (ja ka kasutusele võtmine) on agiilse arenduse üks tugisambaid.

3. Kas teie projekti liikmed on sertifitseeritud agiilsete meetodite praktiseerijad?

Vahet pole, punkti ei saa. Sertifitseerimine on sama kõva äri kui kokaiini müümine ja paljudel tublidel inimestel on mitmesuguseid sertifikaate. Ükski paber ei vii aga projekti ellu

4. Kas te saate (vajadusel) muuta nii töö skoopi kui ka tähtaega?

Kui jah, saad punkti. Kui tuuakse vabandusi, nagu „leping/projektiplaan ei luba“, siis pole tegemist agiilse arendusega. Plaani muutmine  vastavalt oludele on agiilse arenduse põhitunnus.

5. Kas teie töö on organiseeritud 2–4-nädalasteks sprintideks?

Taas 0 punkti. Tööd võib organiseerida kuidas iganes, kasvõi nõnda, et iga arendaja tarnib erineval päeval ja erineval viisil. Oluline on vaid see, et tarnimine oleks lühikeste vahedega. Sprintideks jagatud projekt, kus tegelikult antakse üle iga viies ja juurutakse iga viieteistkümnes sprint, ei ole agiilne.

6. Kas te olete saanud viimase 2 nädala jooksul lõppkasutajate tagasisidet (loeb ka automaatsete vahendite abil saadav tagasiside)?

Kui jah, liida veel 1 punkt. Projekti tuunimine  vastavalt kasutajate tagasisidele on üks peamisi vahendeid paindlikkuse ja efektiivsuse saavutamisel.

7. Kas teil on paigas rollid, nagu Scrum Master ja Product Owner?

See on ka nulli-küsimus. Selged rollid projektis tõstavad üldiselt õnnestumise tõenäosust, sest inimestel on selgem pilt, mida teha. Samas see, millised need rollid täpselt on ja kuidas me neid nimetame, ei anna inimestele kompetentsust ja olude mõistmist juurde.

8. Viimaseks kõige olulisem küsimus – kas projekti liikmed saavad vajadusel kehtestatud protsesse eirata ja asju teisiti teha?

Kui jah, pane 1 punkt juurde. Veel üks agiilsuse põhitunnus on see, et ei muututa reeglite orjaks, vaid vajadusel tehakse neid ümber või minnakse neist mööda.

Liida nüüd punktid kokku. Kui said 4 punkti, siis sinu projektis on agiilne arendus. Kui kogusid 2–3 punkti, siis sinu projektis kasutatakse agiilse arenduse olulisi elemente. Kui tulemuseks oli 0–1 punkti – sinu projekt ei ole agiilne. On võimalik, et selles mängitakse agiilsust.

Tegelikult on testimine veel lihtsam – vt http://agilemanifesto.org/ ja kontrolli, kas sinu projektis järgitakse reaalselt neid printsiipe või mitte. Olen aga näinud mitmeid projekte, kus arvestatakse  hoopis neid „põhimõtteid“: http://www.halfarsedagilemanifesto.org/. Riigihangetel ütlevad tänapäeval vist kõik pakkujad, et nad on agiilsed, seda isegi juhul, kui hanketingimused nõuavad fikseeritud skoopi, hinda ja tähtaega.

Mida täpsemalt tähendab agiilsuse mängimine? Klassikaline võrdlus on juba seitsekümmend aastat vana.

Pärast II maailmasõda, kui USA väed olid lahkunud, ehitasid mitmete Vaikse ookeani saarte elanikud puust maandumisradu ja lennukimakette. Rajati ka puust onne, kus sees istus mees, kaks kookospähklikoort kõrvaklappideks, millest bambustorud antennidena välja turritasid. Maandumisraja ääres süüdati lõkketuled ja jäädi ootama lennukeid valgete meeste ja imeliste kaupadega… Samamoodi teevad tarkvaraprojektides tuhanded inimesed entusiastlikult standup’e ja pügavad backloge ning ootavad siis suurepäraseid tulemusi.

Tulemusi aga mõistagi ei saabu, sest just nagu pärismaalased ei mõistnud lennukite saabumise põhjust, ei mõista ka paljud projektijuhid tarkvaraprojektide õnnestumise või ebaõnnestumise põhjuseid.

Reaalselt on hea tarkvara jaoks vaja kliendi vajaduste mõistmist või edukat tundmaõppimist, oma töövahendite ja platvormi head mõistmist, kõrget tööeetikat ning ootamatustega arvestamist. Kui need omadused on olemas (ehk me oskame lennukiga lennata), siis võime kasutada ükskõik millist metoodikat (ehk võime maanduda igal lennuväljal). Ja kui neid ei ole, siis kukume iga metoodikaga puruks või ei tõuse isegi mitte õhku.

Kõik need oskused tulevad enamasti kogemuse ja suures osas ka andega. Kui esineb telekokk Jamie Oliver, tundub hea toidu tegemine imelihtne ­– sortsuke seda, näpuga toda, tuli alla ja valmis. Kui aga mina prooviks lihtsalt tema efektseid liigutusi järele teha, poleks tulemus tõenäoliselt suurem asi. Ma oskan küll üsna hästi mõnesid tarkvara alaseid probleeme lahendada, aga toidu jaoks on minusugusel tarvis detailset retsepti, kus kraadid, grammid ja minutid täpselt kirjas.

Tarkvaraarenduses nimetatakse selliseid retsepte metoodikateks. Kirjutatakse näiteks ette spetsifikatsioonide formaat, koodistandardid ja tööde üleandmise-vastuvõtmise vormid. Kulinaarses maailmas on selle vasteks McDonald’s, kus iga liigutus on spetsifitseeritud, et ka ilma eelneva kogemuseta inimene hakkama saaks. Mingis ulatuses see asi töötab, aga võib erijuhtudel osutuda kohutavalt ebaefektiivseks ja osalised võivad teha palju asjatut tööd. Ja tulemus on ka nagu McDonald’s Jamie Oliveri kõrval – täidab ennustatavalt kõhtu, aga pole mingi kõrgtasemel elamus.

Mõni inimene ei taha aga McDonald’sis mööda nööri käia või range metoodika järgi tarkvara arendada. 15 aastat tagasi leidsid mõned hakkajad mehed, et tarkvaraarenduses on bürokraatiat liiga palju ja võiks saada lihtsamalt. Nende protesti tulemusena sündiski ülalviidatud agiilse arenduse manifest.

Paljud teised tublid inimesed võtsid õppust ja saavutasid häid tulemusi. Veel rohkem oli aga neid, kes vaatasid toimuvat nagu mina vaatan telekokk Oliveri. Nägid, et tehakse mingeid liigutusi, kuid ei osanud neid järele teha ning küsisid retsepti. Vastusena sellele küsimusele tekkisidki agiilse arenduse metoodikad ja eeskirjad. Konsultandid rääkisid, milline on hea koosoleku formaat, kui kaua peaks kestma iteratsioonid, millised rollid peavad olema defineeritud jne. Selline lähenemine on aga juba oma olemuselt vildakas, sest agiilne mõtteviis vastandub just nimelt detailsetele, fikseeritud metoodikatele. Ehk siis mida täpsemalt me oma „agiilset metoodikat“ järgime, seda vähem agiilsed me tegelikult oleme. Ja retsepte järgides ei saaks minust iialgi Jamie Oliveri, selleks peaks mõistma toiduvalmistamise olemust hoopis teisel tasemel.

Vahel tehakse asja isegi halvemaks. Vana ja tuntud waterfall ja sellest tulenevad metoodikad näevad ette mitmesuguseid dokumente. Nõuded, spetsifikatsioonid, testjuhtumid jne. Kõigi nende kirjutamine pole kuigi lõbus, koodi kirjutada on lahedam. Nüüd on aga lihtne vabandada laiskust agiilsusega. Me oleme agiilsed ja meil pole spekke vaja!

Tarkvara korralikult tegemine nõuab aga endiselt arusaamist, mida, miks ja kuidas tehakse. Selle teadmise hoidmiseks võib agiilses maailmas paberdokumentide asemel kasutada teisi vahendeid, nt TDD/BDD, aga enamik mängult agiilseid projekte jätab sellised ebamugavad asjad tegemata. Lõppkokkuvõttes saame halvima mõlemast maailmast: halva kvaliteediga puudulikult dokumenteeritud koodi, mille kohta keegi ei tea, miks ja mida seal tehti ning mis läheb eelarvest ja tähtajast üle.

Milles siis asi? Agiilsus ei ole metoodika, vaid mõtteviis. Kahjuks jõutakse agiilsuse vajaduse mõistmiseni alles pärast paljude kogemuste ja teadmiste omandamist. Agiilse manifesti autorid olid kõik kogenud, targad inimesed ja nad ei tulnud ehk selle peale, et kõigil tarkvaraarendajatel pole võrreldavat pagasit.

Mida aga teha? Vajalike reeglite hulk on pöördvõrdelises seoses inimeste kogemuse ja pädevusega. Kui sul on kompetentne meeskond, siis saad olla agiilne ja head koodi tuleb nagu Jamie Oliveri potist putru. Kui sul on aga vähem kogenud meeskond, siis pead asju tegema täpsete reeglite järgi, nii nagu mina pean piiluma retseptiraamatusse. Sel juhul ei tohiks sa aga nimetada oma tegevust agiilseks arenduseks. Parem on mitte lolli mängida, tunnistada, et oled pigem McDonald’si tüüpi koht, kookoskõrvaklapid peast võtta ning mitte inimesi püstijalakoosolekule kamandada.

*„agiilne“ on eesti keeles paras värdsõna, aga saanud de facto standardiks. Parema puudumisel ja üldise arusaamise huvides kasutan seda ka siin. Tähendusväljalt sobivad vasteteks nt sõnad „väle“, „osav“, „paindlik“, “nobe”.

PS Bondoras me skoorime minu hinnangul praegu 3,5 punkti neljast, töötan ise muuhulgas selle viimase poole punkti saavutamise kallal. Kui sinu sooviks on töötada dünaamilises, kiirelt tegutsevas ja reageerivas ettevõttes ning sul on tugev .NET arenduse kogemus, võid minuga ühendust võtta.

2 responses so far