Principi v ozadju Agilnega manifesta

Mnogi avtorji in promotorji agilnosti trdijo, da je agilna miselnost pomembnejša sistematičnega pristopa in orodij, pri čemer naj bi miselnost gradili na vrednotah (Agilni manifest), principih in (dobrih) praksah (glej sliko). Danes si podrobneje poglejmo principe in jih pokomentirajmo (citirani principi so napisana s poševno pisavo):

(1) Naša najvišja prioriteta je zadovoljiti stranko z zgodnjim in nepretrganim izdajanjem vredne programske opreme. Vsekakor se strinjamo, da je pomembno zadovoljiti naročnika, vendar pa ne na škodo lastnega zaslužka, zato moramo tu opozoriti na ustrezen pogodbeni odnos med naročnikom in izvajalskim timom. Seveda pa nas tukaj prepriča drugi del principa, kar lahko ocenimo kot največjo prednost agilnega pristopa – da je del razvite programske opreme že možno uporabljati na koncu prvega cikla, da vsak naslednji cikel prinese novo uporabno vrednost, in da več ciklov prinaša več koristi za naročnika. Žal pa je to možno le pri določenih tipih IT projektov, še težje pa pri drugih vrstah projektov.

(2) Sprejemamo spremembe zahtev, celo v poznih fazah razvoja. Agilni procesi vprežejo tovrstne spremembe v prid konkurenčnosti naše stranke. Spreminjanje programske opreme je praviloma veliko cenejše, kot spreminjanje izdelka ali stavbe, čeprav tudi pri določenih vrstah IT projektov nekaj sprememba lahko povzroči kar obsežno popravljanje dotedanje programske kode, pa tudi dodatne napake v delovanju programa, ki jih je težko odkriti in popraviti. Sicer pa pri vseh vrstah projektov velja, da se vsaka sprememba sprejme, v kolikor prinese zadosti koristi v primerjavi s stroški spremembe, ter seveda, da se tako stroški kot koristi ustrezno porazdelijo med naročnika in izvajalce.

(3) Delujočo programsko opremo izdajamo pogosto, znotraj obdobja nekaj tednov, do nekaj mesecev, s preferenco po krajšem časovnem okvirju. Tako, kot smo napisali že pri prvem – tudi temu principu, ki prikazuje način dela na projektu, ni oporekati. Vprašanje je le, ali je ta način dela možen na ostalih tipih projektov.

(4) Poslovneži in razvijalci morajo skozi celoten projekt dnevno sodelovati. Poslovneži? Žal ne vemo, ali to pomeni uporabnike (v originalu piše »business people«) ali managerje v podjetju izvajalca. Načeloma pa to razumemo tako, da razvijalci, z namenom popolne zadovoljitve želja naročnika in doseganja visoke kakovosti proizvoda, stalno in pogosto preverjajo, če so na pravi poti. To se nam zdi (do neke mere) smiselno. Po drugi strani pa – če nekomu delegiramo neko nalogo, potem pričakujemo, da nas ne bo vsakih nekaj ur spraševal, če je prav razumel zahteve in če je njegova ideja o rešitvi ustrezna. Način dela zna biti kar obremenjujoč za naročnika in vprašanje je, ali je res potrebno tako pogosto usklajevanje. Še posebej, ker se znajo ti projekti kar vleči.

(5) Projekte gradimo okrog motiviranih posameznikov. Omogočimo jim delovno okolje, nudimo podporo in jim zaupamo, da bodo svoje delo opravili. Kdor vsaj malo pozna motivacijske teorije in priporočila glede vodenja ljudi in (projektnih) timov, bo vedel, da brez tega ne gre tudi pri »tradicionalnem« pristopu. Vsekakor temu principu ni oporekati, a ni nikakršna novost.

(6) Najboljša in najučinkovitejša metoda posredovanja informacij razvojni ekipi in znotraj ekipe same, je pogovor iz oči v oči. Podobno kot pri prejšnjem principu moramo tudi tukaj opozoriti na priporočila stroke glede komuniciranja v projektu, ki poudarjajo visoko vrednost osebnega verbalnega komuniciranja. Teorije o vodenju, motiviranju in komuniciranju med sodelavci so se resneje začele razvijati v 60-tih prejšnjega stoletja, možno pa je, da jih tehnično izobraženi strokovnjaki prej niso poznali. Sicer pa je res, da je pogovor (vsaj po telefonu ali drugih medijih, če govorimo o virtualnih timih) najboljši način komuniciranja, tako za iskanje idej, usklajevanje dela, reševanje medosebnih nesoglasij, ustvarjanje visokega delovnega vzdušja, ipd. Moramo pa opozoriti, da preveliko število sestankov lahko ljudi spravlja v slabo voljo (ker jim velikokrat prekinjajo ustvarjalno delo), zato je za manj pomembne informacije smiselno koristiti tudi e-pošto ali projektni informacijski sistem.

(7) Delujoča programska oprema je primarno merilo napredka. Ta princip je nadgradnja prvega in tretjega in je ponovno povezan z glavno prednostjo agilnega pristopa (možnost koriščenja delnih rezultatov), zato mu ni oporekati. Tudi kontroliranje projekta je enostavneje, čeprav je vprašanje, ali je sploh smiselno, saj taki projekti načeloma nimajo nedvoumno določenega končnega roka – resneje se lahko kontrolira le izvedba posameznega cikla.

(8) Agilni procesi promovirajo trajnostni razvoj. Sponzorji, razvijalci in uporabniki morajo biti zmožni konstantnega tempa za nedoločen čas. Ta princip pa je najbolj sporen z vidika projektnega pristopa. Ena od osnovnih definicij projekta je, da je le-ta časovno omejen – če ni vnaprej opredeljenega končnega roka, potem to ni projekt! Lahko pa bi rekli, da je vsak cikel svoj projekt (saj ima jasno določen končni rok, podrobne specifikacije, plan aktivnosti po izvajalcih…), pri čemer naročnik in projektni tim na začetku sodelovanja podpišeta pogodbo (namero) o dolgoročnem sodelovanju in se dogovorita, da se stroški in plačila obračunavajo za vsak cikel posebej, ter da se sodelovanje lahko zaključi po kateremkoli ciklu. Pa še ta dilema: kako naj se izvajalsko podjetje dogovarja za nov posel, če ne ve, kdaj se bodo zaključili trenutni projekti in bodo njihovi zaposleni spet prosti za prevzem novih aktivnosti?

(9) Nenehna težnja k tehnični odličnosti in k dobremu načrtovanju izboljša agilnost. Tale stavek bi lahko razumeli v obe smeri – da tehnična odličnost izboljša agilnost (= prilagodljivost, kar nam nekako ni razumljivo) ali da agilno razmišljanje prispeva k tehnični odličnosti. Kakorkoli že, tehnična odličnost je osnova kakovosti dela in končnih proizvodov, kar velja tudi za »tradicionalni« pristop. Opozorimo pa naj na »previsoko« kakovost – iskanje tehnične dovršenosti lahko zelo podaljša in podraži projekt (nekateri razvijalci vedno mislijo, da bi nekaj lahko naredili še bolje in se lahko izgubijo v spirali nenehnih izboljšav svojih rezultatov)! Učinkovit tim naj bi naročniku zagotovil le tisto, kar ta zahteva – vsa nadgradnja bi lahko bila izguba časa in denarja, če naročnik ni pripravljen plačati višje kakovosti.

(10) Preprostost — umetnost zmanjševanja količine nepotrebnega dela — je bistvena. Ta princip bi bil lahko deloma kontradiktoren s prejšnjim, vendar pa glade na proučevanje drugih virov predpostavljamo, da avtorji tu mislijo na preprostost pri planiranju načina izvedbe cikla (kako čim bolj učinkovito doseči zastavljene cilje cikla). Delno pa bi se ta princip nanašal tudi na poenostavljanje zahtev naročnika – da mu projektni tim glede na namen in potrebe lahko predlaga enostavnejšo rešitev. Oba vidika seveda nista tuja »tradicionalnim« timom, a vsekakor se strinjamo, da je zadnja dva principa smiselno večkrat izpostaviti, da zagotovimo ustrezen način razmišljanja in delovanje udeležencev projekta.

(11) Najboljše arhitekture, zahteve in načrti izhajajo iz tistih ekip, ki so samo-organizirane. Bi lahko rekli, da »tradicionalni« projektni tim ni samo-organiziran, ne glede na to, kako kompleksen je projekt in o katerem nivoju tima govorimo? No, malce sumimo, da avtorji tukaj govorijo o tem, da timi ne potrebujejo managerja, saj si znajo sami organizirati svoje delo. Predpostavljamo, da vemo, od kod ta predlog: pogoj za odličnost managementa je tudi (ali predvsem) odličnost njegovega vodenja, problem pa seveda nastane tam, kjer je manager odtujen od tima, dela svoje plane ne glede na mnenje članov tima, se ukvarja predvsem z administracijo … ampak to je problem posameznikov, ne pa »tradicionalnega« pristopa. Sicer pa ideja mogoče ni tako neumestna, pri tem pa bi opozorili na ugotovitve raziskav, da se v vsakem timu, kateremu se na začetku ne določi vodje, sčasoma spontano uveljavi »neformalni« vodja, ki prevzame večino siceršnjih nalog managerja (vodi planske sestanke, usklajuje delo, opozarja sodelavce na zamude, ipd).

(12) V rednih časovnih razdobjih ekipa išče načine, kako postati učinkovitejša ob rednem prilagajanju svojega delovanja. Temu principu seveda ni oporekati – to naj bi bilo vedno vodilo projektnih timov in menimo, da bi si timi tudi v sklopu daljših »tradicionalnih« projektov morali večkrat vzeti čas, da se pogovorijo o svojem delovanju in poiskati kakovostnejše in učinkovitejše pristope.

Opomba: principe smo brez spreminjanja prepisali z uradne strani Principi v ozadju agilnega manifesta, zato so mogoče nekateri izrazi (prevodi) drugačni, kot jih sicer uporabljamo v prispevkih tega bloga.