Projektni management

Blog, debatni večeri, raziskave, knjiga…

Hibridni – agilno tradicionalni pristop

Naša majska raziskava je pokazala, da v Sloveniji redko najdemo agilne projekte v »čisti« obliki. Pri večini »agilnih« združb še vedno najdemo ostanke tradicionalnega necikličnega projektnega dela. Razlogi za to so različni – mogoče so še v fazi prehoda iz tradicionalnega v agilno, mogoče organizacijska kultura in navade ljudi zavirajo vpeljavo novejših pristopov, mogoče ljudje v praksi ne verjamejo povsem v agilnost (ali vsaj ne v vse agilne tehnike), ali pa so ugotovili, da je za njihove projekte najboljši neke vrste kombiniran pristop, hibrid.

Seveda Slovenija v tem pogledu ni nobena izjema, podobno se agilni pristopi uveljavljajo tudi drugod posvetu. Danes bomo zato pogledali, kaj o hibridnih pristopih pišejo drugi avtorji. Najpogosteje je hibridni pristop sestavljen iz tradicionalnih zaporednih faz (snovanje, priprava, izvedba, zaključevanje), pri čemer izvedba poteka ciklično (glej sliko).

Podrobna opredelitev zahtev (ki sicer lahko poteka ob koncu snovanja, na začetku priprave ali vmes) je razdeljena v dva dela, kar sicer velja tudi za sam Scrum pristop. V prvem »tradicionalnem« delu se opredeli le nabor zahtev, brez podrobnega opisa le-teh, npr. seznam funkcij (zahtevnik, ang. backlog). Na začetkih posameznih sprintov se te zahteve podrobneje opredelijo s pomočjo uporabniških zgodb. Včasih se na začetku izvedbe izdela zasnova izdelka (na sliki »zasnova (modela)«, npr. arhitektura programske opreme), ki jasneje opredeli strukturo končnega izdelka in skupaj z zahtevnikom predstavlja »ogrodje« nabora sprintov razvoja.

Hibridna izvedba projekta

Plan izvedbe projekta se v fazi priprave opredeli z mejniki in fazami (ki so sestavljene iz ciklov). Za razliko od »čistega« Scruma, kjer lastnik izdelka določa vsebino posameznega sprinta šele na začetku sprinta, se pri hibridnem načinu v fazi priprave določi okvirna vsebina sprintov in vrstni red le-teh, poleg tega pa se jih tudi razvrsti po fazah; ena možnost pa je tudi, da se jih določi šele na začetku posameznih faz. Ključna razlika glede na tradicionalni pristop pa je v tem, da se »mikroplan« aktivnosti sprinta izdela na začetku vsakega sprinta, pri čemer plan pripravijo sami člani tima.

Mimogrede, tudi naša raziskava je pokazala, da ima 85% cikličnih projektov izdelan plan izvedbe ciklov že na začetku projekta, kar bi lahko govorilo o tem, da so projekti v Sloveniji bolj hibridni, kot agilni. No, težko trdimo na podlagi enega podatka – potrebna bo podrobnejša analiza vseh kazalnikov agilne in tradicionalne izvedbe, več o tem pa v knjigi.

Sicer pa hibridni pristop ohranja »tradicionalni« način poročanja o napredku projekta (mesečno, ob fazah, SPI, CPI), ob koncu faz pa je možna dobava / uporaba vmesnih rezultatov (agilno!). Seveda ima hibridni pristop managerja projekta (kar ne velja za Scrum), pri čemer Strasser (2020) predlaga, da to vlogo prevzame Scrum mojster.

Ob iskanju informacij o hibridih na internetu pa smo odkrili tudi hibridni manifest (Hybrid project management manifesto), pod katerega sta se podpisala Robins in Ariel, sicer pa ni navedeno, koliko imata »podpornikov« (kot je to navedeno za agilni manifest). Zato tudi ne vemo, koliko ljudi se strinja s priporočili avtorjev, ki sicer med FAQ navajata, da je to »formalna metodologija, ki pridobiva vse več podpore, tako s strani akademskih kolegov, kot praktikov«. Glede na vsebino bi se strinjali, da je to  bolj metodologija, kot manifest, saj natančno opredeljuje hibridni proces izvedbe projekta in vloge sodelujočih, pri čemer se najbolj osredotoči na delitev odgovornosti med managerjem projekta in Scrum mojstrom.

Naj za konec omenimo še uporabo agilnih tehnik v tradicionalnih projektih, kar bi tudi lahko šteli kot neke vrste hibrid, čeprav menimo, da je neciklična izvedba še vedno predvsem »tradicionalna«. Kakorkoli, projektnim managerjem predlagamo sledeče agilne tehnike za učinkovitejšo izvedbo in večji uspeh projektov:

  • določanje pomembnosti zahtev (kaj se potrebuje prej, kaj kasneje) … seveda, če ne pridemo navzkriž s tehnologijo – to je možno pri razvoju programske opreme, pri gradnji pa bi težko zahtevali najprej sobo v prvem nadstropju, brez temeljev, zidov…
  • opredelitev zahtev z uporabniškimi zgodbami, predvsem, ko je govora o razvoju storitev, IT rešitev, reorganizaciji delovanja ali prenovi procesov
  • pogostejše vključevanje naročnika – za opredelitev prioritet zahtev, potrjevanje idej in usmeritev, testiranje in potrjevanje vmesnih rezultatov (obseg – funkcije in kakovost),
  • dnevne 15-minutne stoječe sestanke ob Kanban tabli
  • revizijo rezultatov in retrospektivo (so)delovanja ob mejnikih

Avtorji še omenjajo osredotočenost na poslovno vrednost (pri opredelitvi ciljev in obravnavi sprememb) ter večjo svobodo tima pri samo-organizaciji dela. Menimo, da naj bi bili obe »vrednoti« že del tradicionalnega izvajanja projektov, od organizacijske kulture in veščin managerjev pa je odvisno, ali se držijo priporočil stroke ali ne…

Nexus, LeSS, SAFe, … agilni pristopi za obsežnejše projekte

Večina agilnih metod, ki smo jih predstavljali do sedaj, je namenjena predvsem manjšim timom, danes pa predstavljam nadgradnje agilnih metod, predvsem Scruma, ki se uporabljajo pri projektih, v katerih sodeluje več ljudi.

Najenostavnejša rešitev, ki je sicer zelo podobna tradicionalni organizaciji, je tako imenovan »Scrum of Scrums« (SoS) ali »meta Scrum«. Vsi sodelujoči se razvrstijo v Scrum time s 3 do 9 člani, koordiniranje dela med timi pa se izvaja prek tima, ki ga tvorijo predstavniki timov (Scrum of Scrums). Ko posamezni timi zaključijo dnevne sestanke, se predstavniki dobijo na usklajevalnem sestanku, a ne nujno vsak dan (priporoča se 2-3 sestanki tedensko), pri čemer usklajevalni sestanki niso omejeni na 15 minut. Vsebina sestanka je podobna vsebini predhodnih sestankov timov. V kolikor je sodelujočih še več, obstaja še en višji nivo (Scrum of Scrums of Scrums).

Neposredna nadgradnja Scrum metode je Nexus. Za koordniacijo med večjim številom timov skrbi usklajevalni tim (Nexus Integration Team, v nadaljevanju ga bom imenoval Nexus tim), v katerem so – poleg lastnika izdelka in Scrum mojstra – še člani tima, običajno sistemski inženirji, lahko pa tudi predstavniki timov. Sistemski inženirji nastopajo predvsem kot ključni strokovnjaki, ki usmerjajo delo timov in jih tudi učijo uporabe določenih orodij in praks. Nexus tim naj bi zagotovil, da vsak sprint prinese vsaj en uporaben rezultat.

Planiranje sprintov se izvaja v dveh korakih. Na prvem sestanku predstavniki timov, skupaj z Nexus timom, pregledajo in pokomentirajo aktualen zahtevnik (ang. Backlog) in za vsak tim določijo zahteve (funkcije, naloge) za tekoči sprint. Vsak tim nato samostojno splanira svoj sprint, pri čemer po potrebi sodeluje z drugimi timi. Skupni zahtevnik sprinta zagotavlja preglednost vseh izbranih postavk zahtevnikov timov in morebitne odvisnosti med njimi.

Nexus (Schwaber, 2018)

Na dnevnih sestankih Nexus tima sodelujejo predstavniki razvojnih timov, ki poročajo o napredku dela v svojih timih in kritično ocenijo dotedanji skupni (integriran) rezultat. Tega oceni Nexus tim tudi v reviziji sprinta (v razvojnih timih revizije ne izvedejo). Retrospektiva pa se izvede v treh korakih: na prvem sestanku predstavniki timov z Nexus timom izpostavijo težave, ki si jih imeli izven »meja« svojih timov, sledi retrospektiva po razvojnih timih, v tretjem koraku pa isti sodelujoči, kot na prvem, predlagajo korektivne akcije in spremembe (so)delovanja.

Tudi LeSS je zasnovan na Scrum metodi, kar pove že ime (Large-Scale Scrum). Ključna značilnost metode je, da za usklajevanje dela med timi ni formalno določenih koordinatorjev, ampak se timi po potrebi sestajajo sami, usklajujejo zahteve, delo in rezultate. Druga značilnost je pogostejše sodelovanje uporabnikov (poleg lastnika izdelka). Na polovici vsakega sprinta se timi namreč dobijo s končnimi uporabniki in pregledajo vmesne rezultate ter po potrebi podrobneje razjasnijo zahteve. Sicer pa se tudi pri tej metodi planiranje sprintov izvede v dveh korakih – v prvem si na skupnem sestanku vsak tim izbere naloge / funkcije, ki jih bo razvil v sprintu, po tem pa si vsak tim posebej splanira aktivnosti sprinta. Tudi revizija sprinta se izvede z uporabniki (in ne le z lastnikom izdelka): preveri se, če so rezultati skladni z zahtevami, željami in pričakovanji uporabnikov, odstopanja pa se odpravijo v naslednjem sprintu. Podobno, kot se planira, se tudi retrospektiva sprinta izvede v dveh korakih: najprej tim izvede svojo retrospektivo, potem pa se dobijo vsi sodelujoči in izmenjajo izkušnje, poleg tega pa ocenijo tudi sodelovanje med timi.

V kolikor v projektu sodeluje več kot 8 timov, se projektu priključijo še »področni lastniki izdelka« (APO – Area Product Owner). Govora je o strokovnih področjih, kar pomeni, da npr. en APO koordinira delo programerjev, drugi pa razvijalcev elektronike, itd…

LeSS (less.works)

SAFe v prevodu pomeni »Razširjen agilni okvir« (ang. Scaled Afile Framework). Metoda sistematično pokriva štiri ravni projektov. Na osnovni ravni – manj obsežnih projektih (in manjših timih) – sledi metodam Scrum in Kanban (ter Scrumban). Obsežnejši projekt na naslednji ravni imenujejo »Bistveno« (ang. Essential), projekt pa je razdeljen na programske cikle (ang. Program Increments), ki se običajno izvedejo skozi 5 dvotedenskih ciklov (ki jih ne imenujejo sprinti, ampak iteracije). Po koncu vsake iteracije se izvede skupen sestanek (ang. System Demo), kjer se ugotavlja stanje izvedbe, oceni dotedanje rezultate cikla, timi pa dobijo povratne informacije za izboljšanje rezultatov v nadaljevanju. V teh projektih sodeluje 5 do 12 timov (50 – 125 ljudi), timi pa so multi-disciplinarni. Vse time skupaj poimenujejo Agile Released Train (ART), koordinator pa je Release Train Engineer (RTE). Poleg njega so v ekipi še lastnik izdelka, Scrum mojster, sistemski arhitekt ter poslovni direktorji (ang. business owners).

Naslednja raven projektov je »Večja rešitev«, kjer prej omenjeni ekipi pridružijo novi timi ter kreator rešitve (ang. Solution Manager). Celotno ekipo poimenujejo »Vlak rešitve«, ključni koordinator pa je Solution Train Engineer (STE). Četrta raven metode se imenuje »Portfelj« in obravnava vse projekte v družbi.

FDD, XP, DSDM, Kristalno

Scrum in Kanban sta, kot smo omenili v prejšnjih prispevkih, najbolj uveljavljeni agilni metodi, kar je pokazala tudi naša raziskava, pa čeprav Scrum pogosto in redno uporablja le 41% tistih združb, ki projekte izvajajo ciklično, 31% teh pa uporablja Kanban. Od preostalih poznanih metod se največ uporablja Razvoj osredotočen na funkcionalnosti (FDD, Feature driven development), katerega pogosto in redno uporablja 28% združb, ki projekte izvajajo ciklično, pa tudi 20% tistih, ki projekte izvajajo tradicionalno.

Naj še enkrat spomnim, da se je – ko je govora o agilnih pristopih – večino metod razvijalo na področju razvoja programske opreme, kar se še posebej kaže v metodah, ki jih predstavljam danes. Zato ne moremo govoriti o agilnem (projektnem) managementu, ampak bolj o agilnejših projektnih pristopih. Za razumevanje tega si lahko preberete moj prvi prispevek na blogu, kjer sem opredelil pojem management. V kolikor obstaja manager projekta (ki naj ne bi obstajal pri Scrum metodi), ta še vedno planira, organizira, vodi tim in kontrolira izvedbo … le da se pri agilnih pristopih to delo izvaja ciklično.

No, vrnimo se na agilne pristope, ki so omenjeni v naslovu. FDD je pristop, ki se uporablja za obsežnejše programske rešitve, pri čemer so – poleg managerja projekta in razvijalcev – »predpisane« še naslednje vloge: glavni arhitekt SW, vodja razvoja, glavni programer, odgovorni za razvoj dela kode (ang. class owner) in poslovni analitik (domain expert). Metoda določa način razvoja programske rešitve, ki se začne z razvojem celotnega modela, na podlagi katerega se izdela nabor vseh funkcij (ang. Feature list) in plan razvoja funkcij (glej prvo sliko). Sledi ciklična izvedba, vsak cikel pa vsebuje zasnovo in razvoj funkcije (nekateri avtorji pa svetujejo podrobnejše planiranje razvoja posamezne funkcije na začetku cikla). Pri tem so cikli različno dolgi, odvisno od zahtevnosti razvoja posamezne funkcije. Pristop vključuje tudi povratno zanko – celoten model se lahko dopolnjuje na podlagi rezultatov ciklov.

Razvoj osredotočen na funkcionalnosti, FDD (vir: aist.global)

Največkrat omenjena agilna metoda razvoja programske opreme, ki jo je razvil eden od soavtorjev agilnega manifesta Kent Beck, je ekstremno programiranje (XP), ki pa se v slovenskem prostoru (še) ni uveljavil. Po naši raziskavi ga redno nihče ne uporablja, 6% tistih, ki projekte izvajajo ciklično, pa je navedlo, da ga uporabljajo pogosto. Kot lahko vidimo na drugi sliki, so je metoda podobna Scrumu, koraki pa so tako vsebinsko, kot časovno dokaj natančno in sistematično opredeljeni.

Avtor priporoča razvoj manjših rešitev z veliko vrednostjo, zahteve se – podobno, kot pri Scrumu –  opredeljujejo s scenariji in zgodbami, pa tudi tu naj bi bil naročnik stalen član tima. Kot posebnosti je potrebno izpostaviti razvoj testnih procedur pred razvojem rešitve ter delo v parih – zaradi višje kreativnosti in takojšnjega odkrivanja morebitnih napak, poleg tega pa naj bi bil posameznik težko 100% skoncentriran 8 ali več ur programiranja. Omenimo pa naj še vrednote pristopa: pogum * povratne informacije * enostavnost * komuniciranje * spoštovanje!

Extremno programiranje, XP

Ostali dve metodi bom tokrat omenil le na kratko. Kristalne metode zahtevajo kar obsežno razlago, ključno pa je, da metoda sistematično nadgrajuje ekipo glede na obsežnost sprememb, ki jih vpeljuje in glede na poslovno škodo, ki bi jo povzročil morebitni neuspeh projekta. Metoda dinamičnega razvoja sistemov DSDM, pa spet na drug način opredeljuje cikle, potem ko se na podlagi študije izvedljivosti in poslovne študije razvoj izvede v treh fazah – a) razvoj funkcionalnega modela, b) zasnova in razvoj in c) uvedba. Vsaka od teh faz pa ciklično vsebuje štiri korake. Avtorji pa še posebej poudarjajo, da sta pri tem pristopu »fiksirana« čas in proračun, funkcionalnost rezultata pa je prilagodljiva, za razliko od tradicionalnega pristopa, ko določimo cilje in se projekt izvaja, dokler vseh ciljev ne dosežemo (in zato lahko zamudimo rok in povečamo stroške). Pri DSDM pa naj bi tim zaključil projekt po planu in v okviru proračuna, pri čemer manj pomembnih funkcij, ki do roka niso bile razvite, sploh ne bi razvili. Več o obeh pristopih pa si boste prebrali v knjigi.

Kanban in Scrumban

Kanban je druga najpogosteje uporabljena agilna metoda, pri čemer se uporablja tudi izven projektov, poleg tega pa je občutno starejša od večine ostalih agilnih metod in Agilnega manifesta. V Agile practice guide (PMI, 2017) navajajo, da izhaja in principov vitke proizvodnje (ang. Lean Manufacturing), razvil pa naj bi jo Taiichi Ohno in prvič uvedel v proizvodnjo v Toyoti leta 1953. »Kanban« naj bi v prevodu pomenil »kartica«, v sklopu metode pa to pomeni, da so naloge vizualno prikazane s karticami na tako imenovani Kanban tabli. S pomočjo razdelkov na tabli pa prikazujemo stanje nalog v različnih korakih izvedbe (glej sliko).

Ključni stolpci na tabli so vedno »nabor nalog« (ang. To do), »v delu« (In progress) in »narejeno« (Done), lahko pa se statusi še podrobneje delijo, kar pomeni, da se dodajo npr. analiza, razvoj, testiranje, uvedba / predaja, ipd., vsak od teh korakov pa se še dodatno deli na »v delu / izvedbi« in »narejeno«.

Tipična značilnost Kanaban metode je možnost »pull« sistema izvajanja oz. izbire nalog. To pomeni, da izvajalcem naloge niso neposredno dodeljene, ampak jih izbirajo sami. Vsak, ki izvaja določen korak naloge, v predhodnem stolpcu izbere eno od nalog in jo začne izvajati, s tem pa naloga dobi status »V delu«. Ko zaključi, listek prestavi v naslednji stolpec (narejeno), kjer jo prevzame naslednji izvajalec. Seveda pa obstaja tudi možnost, da naloge dodeljuje vodja projekta, oddelka, tima, pri čemer še vedno ohranjamo bistvo metode – vizualizacijo napredovanja projekta / nalog.

Kanban tabla

Ker ima projekt na začetku lahko sto in več aktivnosti (zahtev, funkcij, uporabniških zgodb) izvajalci ne izbirajo nalog iz celotnega nabora, ampak se v tabelo doda stolpec »pripravljeno za izvedbo«, kamor vodja oddelka, projekta ali naročnik projekta (Product Owner) iz celotnega nabora prenese v danem trenutku najnujnejše naloge. V »Scrum« žargonu bi bil torej prvi stolpec »Product Backlog«, drugi pa »Ready«. Če so v prvem navedene predvsem funkcije oz. uporabniške zgodbe, se v drugem navedejo tudi naloge, ki so del neke zgodbe. Praksa kaže, da je vse skupaj bolj obvladljivo, če so naloge dolge največ en teden, zato se uporabniške zgodbe velikokrat delijo na več manjših nalog. Delitev naj bi bila naloga lastika izdelka in managerja projekta, ki skupaj tudi določata katere naloge naj bi šle v izvedbo. Poleg zgodb in nalog pa se v prvem ali drugem stolpcu lahko znajdejo tudi napake, ki se odkrijejo pri testiranju, ali popravki že dokončanih nalog. Tip naloge se običajno opredeli z barvo listka.

Da je celoten tim bolj osredotočen, se glede na velikost tima določi, koliko nalog na enkrat lahko čaka na izvedbo. Mejno vrednost je označena s kratico WIP (ang. work in progress). Pristojni torej dodaja naloge v stolpec do meje WIP in ko eden od izvajalcev začne izvajati eno od nalog (in se ta prestavi v stolpec »v delu«), se doda nova naloga. Naloge so lahko ovrednotene z ravnijo obsežnosti, kar posredno določa predviden čas izvedbe, vodja pa lahko tudi določi rok izvedbe. No, če pristojni res uspejo »razdrobiti« naloge do ravni, ko se lahko izvedejo v enem tednu, potem je obvladovanje časa dokaj enostavno.

Metoda je manj formalna od Scruma, zato zahteva uvedba v prakso občutno manj časa in formalnosti. Potrebujemo le tablo ter uveljavitev nekaj osnovnih pravil. Za razliko od ostalih agilnih metod, Kanban tudi ni ciklična metoda, pa tudi ne vključuje dnevnih sestankov ter analiz dela (retrospektiv).

Scrumban metoda je – kot pove že ime – kombinacija metod Scrum in Kamban. Večinoma metoda sledi priporočilom Scruma, pri čemer je spremljanje nalog sprinta vizualizirano s Kanban tablo. Na začetku sprinta se torej izbrane zgodbe / naloge dodajajo v stolpec »Pripravljeno«, WIP meja pa se ne opredeli s številom nalog ampak s maksimalnim številom točk sprinta (glej prispevek o Scrumu). Če se vse izvede po planu, naj bi bile na koncu sprinta vse naloge v stolpcu »Narejeno« (ali Uvedeno / Dobavljeno). Dnevni sestanki se pri tej metodi izvajajo ob Kanban tabli.

Seveda v sodobnem »virtualnem« svetu obstajajo tudi virtualne table – programske rešitve, kjer se vse skupaj obvladuje z računalniki in telefoni. V tem primeru tablo na sestanku gledamo s pomočjo projektorja, vseeno pa mnogi še vedno prisegajo na klasičen pristop s fizično tablo in listki. Vsaj tako bi lahko sodili glede na kopico fotografij na internetu…

Scrum mojster … in ostali ključni deležniki Scrum projektov

Poglejmo vloge in naloge ključnih sodelujočih pri izvajanju projektov po metodi Scrum. Naj takoj opozorimo, da metoda ne omenja projektnega managerja oziroma naj ga ne bi potrebovali, saj naj bi se tim sam organiziral, pri čemer naj bi jim pomagal Scrum mojster.

Scrum mojstru stroka pripisuje lepo število nalog, za katere bi moral imeti visoko razvite predvsem veščine vodenja – tako prirojene, kot priučene. V prvi vrsti skrbi, da se tim (in lastnik izdelka) držijo pravil metode, seveda s tem, da jih kot Scrum trener in mentor uči uporabe tehnik in da razumejo »filozofijo« metode.

Zanimivo pa je, kako avtorji opisujejo vlogo Scrum mojstra v primerjavi s projektnim managerjem. Scwaber, ki naj bi metodo razvil (skupaj s Sutherlandom), pravi, da projektni managerji »le« delegirajo naloge (po tem, ko sami izdelajo plan) in kontrolirajo, ali se člani tima držijo njegovega plana. S tem avtor ignorira dejstvo, da je vodenje ljudi (ang. leadership) del managementa. Ali pa ameriški managerji nimajo občutka za vodenje ljudi? In zato potrebujejo Scrum mojstra, ki naj bi imel vse potrebne »mehke veščine« – mentorstvo, spodbujanje sodelovanja in inovativnosti, motiviranje…

Scrum mojster

Veseli me, da agilni pristopi dvigujejo zavedanje o pomembnosti voditeljstva, a moram opozoriti, da se stroka za to relativno (ne)uspešno trudi že pol stoletja –  poznan je npr. mrežni model avtorjev Blake in Mouton (1965), kjer so ugotavljali, da so najboljši managerji odlični organizatorji in vodje ter svoje oddelke vodijo “timsko”. Ali managerji napačno razumejo svojo voditeljsko vlogo ali pač niso rojeni za to, sedaj ne bomo razglabljali, a dejstvo je, da imamo na tem področju še veliko rezerv. No, vrnimo se nazaj na Scrum mojstra.

Scrum projekt naj ne bi imel managerja, tim naj bi bil samo-organiziran. To pomeni, da člani tima sami planirajo delo in si ga razdelijo med sabo, poleg tega pa naj bi tudi sami reševali težave, nesoglasja, različno učinkovitost in motiviranost posameznikov… To je dokaj utopično razmišljanje, kot nadgradnja nerealnih predpostavk, da smo vsi ljudje enaki, ko je govora o samo-motiviranosti, vrednotah, ustvarjalnosti, sodelovanju, znanju … in posledično enako učinkoviti pri delu. No, za vsak slučaj (ker tim nima vodje), je tu Scrum mojster, da rešuje nesoglasja in skrbi za ustrezno motiviranost članov tima.

Ob vseh teh pozitivnih lastnostih in vlogi Scrum mojstra, pa je zanimivo, da je le posredno odgovoren za uspeh projekta. Ključno odgovornost naj bi imel naročnik oz. lastnik izdelka (ang. Product owner), ki naj bi usmerjal izvedbo projekta z določanjem obsega nalog na začetku vsakega sprinta, preverjal kakovost in ustreznost rezultatov, skrbel za potrebne dopolnitve (neustreznih ali nekakovostnih) rezultatov sprintov, predlagal spremembe zahtev, ipd.

Da bi kakovostno usmerjal delo razvijalcev, mora zelo natančno poznati zahteve (proces, izdelek, potrebe posameznih uporabnikov), kar pomeni, da mora pripraviti podrobno analizo zahtev / potreb pred projektom (nabor funkcij, ang. product backlog), pred začetkom sprintov pa pripraviti uporabniške zgodbe ali pa po potrebi na planske sestanke povabiti konkretne uporabnike. Če nekako povzamemo naloge: priprava uporabniških zgodb na podlagi analiz in intervjujev, sodelovanje pri planiranju, dnevnih sestankih in reviziji / retrospektivi, pa seveda sodelovanje pri kreiranju rešitev in potrjevanje rezultatov, testiranje  … potem bi lahko rekli, da mora posvetiti projektu vsaj 50% svojega časa, če ne še več.

Za konec se še enkrat vrnimo k Scrum mojstru in primerjajmo njegovo vlogo s priporočili glede odličnosti projektnega managementa (ICB 4.0). Lahko ugotovimo, da naj bi imel Scrum mojster podobne voditeljske veščine, kot projektni manager, pri čemer ne prevzema odgovornosti (razen za dobro vzdušje in metodološko ustrezno izvajanje projekta). Formula bi bila:

Scrum mojster = projektni manager – (planiranje + organiziranje + kontroliranje + odgovornost)

Mogoče jim s tem delam krivico, a res mi ni jasno, zakaj ob vsej svoji »veličini« ne upajo (nočejo) prevzeti odgovornosti za uspeh projekta.

In še minuta za slovenski jezik. Kot ste opazili, sem uporabil pojem »mojster« in ne angleškega – master, kot se naslavlja večina slovenskih Scrum mojstrov. Zavoljo »oživljanja« mojstrstva bi rad spomnil, da je mojster direktni prevod besede master, pogostejša uporaba v projektnem okolju pa bi najbrž pomagala k »ohranitvi« mojstrske vloge. Zdi se mi, da so mojstri nekako ogrožena vrsta v sodobnem svetu. Čeprav me po drugi strani skrbi, da je za »moderne« managerje mojster preveč zastarel izraz in raje uporabljajo nekakšne slengovske tujke (npr. »na sestanek smo povabili tri Scrum mastre).

Scrum (skram, gruč)

Najbolj poznana in uporabljana agilna metoda je Scrum, skladno z opredelitvijo cikličnih življenjskih ciklov projektov tako ponavljajoča, kot postopna. Poimenovanje, Scrum, izhaja iz prijema / postavitve pri ragbiju (po prekrških), s čemer avtorji metode poudarjajo sodelovanje in močno timsko vzdušje, ki je pogoj za učinkovito izvedbo in uspeh projekta.

Cikle imenujejo »sprint«, običajno pa trajajo od 1 do 4 tednov (nekateri avtorji pa omenjajo 2-4 tedne). Obseg, cilji in zahteve projekta so navedeni v seznamu funkcij proizvoda (ang. features, Product backlog), a niso podrobno opredeljeni – navedeno je le, kaj je treba narediti, ne pa, kako naj deluje ali izgleda. V »projektnem žargonu« bi rekli, da so zahteve opredeljene s strukturo ciljev (PBS – product breakdovn structure). Nekateri avtorji poudarjajo, da so funkcije sortirane po pomembnosti.

Prvi dan sprinta je namenjen podrobni opredelitvi ciljev in planiranju aktivnosti sprinta. Predstavnik naročnika, imenovan »Lastnik izdelka« (ang. Product Owner) iz nabora funkcij izbere eno funkcijo, ki se mu v danem trenutku zdi najpomembnejša, in jo opredeli s tako imenovano uporabniško izkušnjo (ang. User story). Na podlagi tega opisa člani tima ocenijo zahtevnost razvoja, pri čemer velikokrat uporabljajo točke zahtevnosti (ang. Story points) namesto potrebnega časa. Sledi naslednja funkcija, pa naslednja … kar se ponavlja toliko časa, da imajo vsi člani tima zapolnjen delovni čas sprinta (oziroma dosežejo maksimalno dovoljeno število točk sprinta). Nabor funkcij sprinta poimenujejo »Sprint Backlog«.

Scrum proces

Avtorji navajajo, da postopno izbiranje funkcij iz nabora lahko proti koncu pripelje do tega, da naročnik ugotovi, da nekaterih funkcij sploh ne potrebuje, s čemer naj bi se projekt skrajšal, stroški pa znižali.

Po dnevu planiranja sledi izvajanje aktivnosti sprinta. Člani tima neformalno sodelujejo po potrebi, formalno pa se dobivajo vsak dan na jutranjem 15-minutnem »stoječem« sestanku (ang. Daily Scrum). Na sestanku vsak član tima pove, kaj je naredil prejšnji dan, ali je imel kakšne težave in če rabi kakšno pomoč (nasvet, ipd.). Potem pove še, kakšne plane ima za tekoči dan, izpostavi morebitne dileme, nejasnosti, ter po potrebi povpraša za nasvet ostale člane tima.

Zadnji dan sprinta se izvedeta revizija in retrospektiva sprinta. Revizija je usmerjena v rezultate – preveri se, ali so bili vsi cilji sprinta kakovostno doseženi ter ali so skladni s pričakovanji naročnika. V primeru neustreznosti se popravki in dopolnitve izvedejo v naslednjem sprintu. Retrospektiva se nanaša na način dela in sodelovanja. Tim oceni, ali so bili uporabljeni pristopi, metode in tehnike ustrezni ter ali so imeli kakšne težave pri timskem delu. Pridobljene izkušnje se seveda koristijo pri naslednjem sprintu.

Kaj je glede uveljavljenosti metode pokazala naša raziskava? Od 62 anketirancev, ki so navedli, da projekte izvajajo ciklično (to je četrtina vseh anketirancev), jih 10% redno dela po metodi Scrum, 31% pa pogosto (24% redko, 35% pa nikoli). 58% rednih / pogostih uporabnikov prihaja iz IT podjetij, drugi »največji« koristnik pa so banke in zavarovalnice (18%), predvidoma zaradi tega, ker so njihove storitve zelo povezane z IT rešitvami.

Za konec pa še »minuta za slovenski jezik«. V prevodu Sutherlandove knjige Scrum: The Art of Doing Twice the Work in Half the Time (2014) je prevajalka Črničeva, predvidoma po nasvetu kolega Pahorja, uporabila pojma skram in gruč, pojem skram pa uporabljajo tudi igralci ragbija. Žal pa nobenega od omenjenih pojmov še ni v SSKJ. Po drugi strani pa – čeprav se trudim uporabljati slovenske izraze – imam ob tem poslovenjenju dilemo, saj so nas učili, da se imen metod ne sme prevajati. Ko smo usvajali metodo Six Sigma, so nam najprej razložili, da je to edini način navajanja, ne 6 sigma, Šest Sigma ali 6σ. So nas učili narobe ali…? Če kdo več ve o teh »pravilih«, naj to prosim pojasni v komentarju…

Ciklični projekti

Poglejmo malce podrobneje, kako se v praksi izvajajo cikli, pri čemer mislimo predvsem na vsebino, zaporedje in morebitno prekrivanje ciklov. Za osnovo si najprej vzemimo opredelitev življenjskih ciklov Wysockega, ki postopen cikel uvršča med tradicionalne, ponavljajočega pa med agilne. Drugi agilni je po avtorjevem mnenju prilagodljivi (ang. adaptive), ki je enak ponavljajočemu, le da pri slednjem cikle poimenuje iteracije.

Kot vidimo, je razlika med tradicionalnim in agilnem v tem, kdaj se planira izvedba – tradicionalno pred začetkom izvedbe, agilno v sklopu cikla. To bi pomenilo, da je postopen proces zelo podoben tradicionalnemu, le da je razdeljen v cikle, v katerih razvijamo posamezne sklope (rešitve, funkcije, dele obsega). V praksi bi temu lahko rekli tudi fazni pristop, sploh če veljajo trditve avtorjev, da so ti cikli v povprečju dolgi od 1 do 3 mesecev.

Različni projektni cikli, prirejeno po Wysockem, 2014

O značilnostih prvih tipov smo govorili prejšnjič, zato tokrat poglejmo le, kako Wysocki opredeljuje ekstremni pristop. Če se agilni pristopi uporabijo za projekte, kjer rešitve niso popolnoma znane, se projekta lotimo »ekstremno«, kadar – poleg rešitev – tudi cilji niso jasno opredeljeni. Navedeno je le želeno končno stanje, ki je dosegljivo ali pa tudi ne (glede na trenutno znanje). Na podlagi doseženih rezultatov in spoznanj enega cikla se opredelijo cilji in aktivnosti naslednjega, kar se ponavlja, dokler se ne doseže cilja, ki je lahko celo drugačen od prvotno postavljenega. Lahko bi rekli, da je ekstremni projektni pristop tipičen za raziskovalne projekte.

Wysockijev prikaz življenjskih ciklov sem malce priredil. Avtor »izvedbo« namreč deli na začetek cikla, spremljanje in kontroliranje (ang. monitor & control) ter zaključek cikla, kar je nekoliko begajoče. Jasno je, da ima cikel začetek in konec, a vmes se izvajajo aktivnosti (zasnova, razvoj, testiranje), kontroliranje pa je del nalog managerja projekta (in ne del procesa izvedbe, kot sta začetek in konec). Sem pa iz tega razloga raziskal, katere vsebinske dele procesa (aktivnosti) vključujejo različni avtorji, kar sem prikazal na drugi sliki.

Aktivnosti ciklov

Kot vidimo, cikli običajno vsebujejo analizo zahtev, zasnovo rešitve, razvoj le-te in testiranje. Kot smo omenili že prejšnjič, je ključna razlika med postopnim in ponavljajočim v tem, da je pri prvem možno koristiti rezultate ciklov, pri drugem pa se rezultati cikla popravljajo dokler naročnik ni zadovoljen. Prilagodljiv življenjski cikel je kombinacija obeh prej opisanih, torej se cikel ponavlja toliko časa, da je naročnik zadovoljen z rezultatom, ki ga po koncu cikla lahko začne takoj koristiti.

Omenimo pa naj še možnost delnega prekrivanje postopnih ciklov: ko nekdo zaključi z zasnovo prvega sklopa in prvi cikel preide v razvojni del, se loti zasnove drugega sklopa (cikel 2). Torej se drugi cikel začne občutno pred koncem prvega cikla, kar je skladno s principi sočasnega inženiringa. S tem pohitrimo izvedbo projekta, izvajalci pa so ves čas polno zaposleni.

Kaj pa dolžina ciklov? Zasledil sem, da naj bi bili agilni cikli krajši (2 – 4 tedne, kot je pokazala tudi naša raziskava), med tem, ko naj bi bili postopni in ponavljajoči cikli daljši – med 1 in 3 meseci.

Tradicionalni in ciklični projektni življenjski cikel

V naslovu sem namenoma uporabil besedo “tradicionalni”, namesto “slapovni” (ang. waterfall), katerega sicer uporablja večina promotorjev agilnih pristopov. Razlog je v tem, da v podjetju, v katerem sem delal v času »informacijske revolucije«, že v zgodnjih 90-tih nismo več uporabljali klasičnega slapovnega pristopa, ampak (delno) sočasnega, kar pomeni, da so se sicer zaporedne faze prekrivale. Lahko bi rekli, da je bil v slovenski praksi klasični »waterfall« že zdavnaj »iz mode«, ko se je pojavil agilni manifest…

Dilemo glede poimenovanja »ne-agilnega« pristopa pa so razčiščevali tudi avtorji priročnika Agile practice guide (PMI, 2017). Ti poleg slapovnega omenjajo še pojme, kot so plansko usmerjan (ang. plan driven) in serijski (ang. serial), priporočajo pa uporabo pojma predictive, s katerim pa imam sam nekaj težav glede prevoda. Napovedni, predvidljivi…? V komentarju bi bil vesel kakšnega vašega predloga 😊.

Sicer pa literatura poleg agilnega in tradicionalnega življenjskega cikla projekta (PMLC, project management life cycle) omenja še dve vrsti, o čemer sem nekaj pisal že pred leti. Takrat sem povzel Wysockega (2009), tu pa se ponovno naslonimo na Agile practice guide, ki omenja še:

  • ponavljajoč pristop (ang. iterative), ki omogoča oziroma zagotavlja povratne informacije o nedokončanem delu za izboljšanje in spreminjanje le-tega, ter
  • postopen pristop (ang. incremental), ki vsakem ciklu zagotovi delujoč delni izdelek, ki ga je že mogoče uporabiti.

Agilni pristop pa naj bi bil tako ponavljajoč, kot postopen – pristop, ki s pomočjo povratnih informacij stalno dostavlja uporabne (pol)izdelke.

Kontinuiteta življenjskih ciklov projektov

Življenjski cikli projektov (Agile Practice Guide, PMI, 2017)

Poglejmo še, v katerih primerih bi bila najbolj smiselna uporaba posameznih pristopov. Kot je prikazano na sliki, naj bi izbira slonela na dveh dejavnikih: možnosti dobav oziroma uporabnosti vmesnih rezultatov (oz. pogostosti dobave le-teh) ter stopnji spremembe oz. novosti, ki jo prinaša projekt.

Tradicionalni pristop naj bi se tako uporabljal, ko so rešitev in zahteve dokaj jasno določene in se naj ne bi veliko spreminjale, pri tem pa delnih rezultatov uporabniki ne morejo koristiti. Wysocki (2009) še navaja, da so projekti rutinski in ponovljivi, uporabljajo pa se preizkušene metode. Vse navedeno bi vsekakor veljalo za gradnjo in druge inženiring projekte.

Ponavljajoč pristop je uporaben za projekte, ko rešitev in zahteve niso jasno dorečene, glede na izkušnje iz preteklih projektov pa tim lahko pričakuje tudi kar nekaj sprememb. Wysocki dodaja, da tim pri tem dokaj dobro pozna možne alternative rešitev. Tudi pri tem pristopu pa delnih rezultatov ni mogoče koristiti. Glede na navedeno, je pristop primeren za razvoj izdelkov z malo neznankami (kjer ni potrebnih raziskav), sploh pri prilagajanju izdelkov po željah kupca.

Postopen pristop naj bi se koristil, ko je možno koristiti delne rezultate, zahteve pa so dokaj jasno določene in se naj ne bi veliko spreminjale. Lahko bi rekli, da je je uporaben za izobraževanje, razvoj (nekaterih) storitev.

Glede na vse navedeno naj bi torej agilen pristop uporabili, ko rešitev in zahteve niso jasno dorečene, delne rezultate pa lahko koristimo, poleg tega pa mogoče niti vnaprej ne vemo, katere metode bomo uporabili pri delu. To je vsekakor značilno za raziskovalne projekte, v novejšem času pa seveda za razvoj programske opreme (kjer so se agilni pristopi tudi razvili in uveljavili), predvsem spletnih rešitev in aplikacij za telefone. Vsekakor je v tem primeru možno koristiti rešitve z osnovnimi funkcijami, dodatne pa se razvijajo postopno, glede na želje (in ideje) uporabnikov.

Ali je povsem agilen pristop uporaben tudi za razvoj izdelkov? Mogoče delno kombiniran, v začetku tradicionalni, nato agilen? Več o tem bom napisal v knjigi, kjer bom predstavil tudi rezultate raziskave, ki sem jo izvedel v maju. Vse skupaj nas najbrž tudi zanima, kateri pristop bi bil pravi za druge vrste projektov … organizacijske (interna reorganizacija ali tista, povezana s prevzemi in združitvami), kateri za organizacijo dogodkov. Tu so še marketinški projekti, pa produkcija televizijskih oddaj, snemanje filmov…

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.

Miselnost PMBOK
Agilna miselnost (Agile practice guide, 2017)

(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.

Agilno!?! … prihodnost ali modna muha?

O začetkih agilnih pristopov pri razvoju programske opreme sem pisal že leta 2011, kjer sem tudi omenil Agilni manifest (2001), ki ga mnogi smatrajo za začetek agilnega pristopa. No, v resnici so mnogi agilno delovali že prej (najbrž poznate pojme, kot so vitka proizvodnja, vzporedni inženiring, Kanban, ipd.), Gibbs (2006) omenja, da so pionirji agilnega pristopa z iterativnim razvojem programske opreme sledili vzoru Toyotine vitke proizvodnje, njihov namen pa je bil znižanje stroškov nepomembne administracije in krajšanje zamudnih procesov načrtovanja. Vendar pa so avtorji manifesta začeli pristop promovirati in uveljavljati bolj načrtno in predvsem celovito (glej sliko). Seveda jim je pri tem »pomagal« hiter razvoj tehnologije, svetovnega spleta, platfortm, ipd., kar je imelo za posledico neskončno število sprememb (in želj po spremembah), in ker so spremembe ena največjih groženj učinkoviti izvedbi in uspešnosti projektov, je bila želja po drugačnem projektnem pristopu še toliko močnejša. Seveda so se z »agresivnejšim marketingom« gorečih zagovornikov pojavili tudi prav tako goreči nasprotniki – prvi bi agilno gradili tudi hiše, drugi pa trdijo, da je agilno le potuha (samo, da ni potrebno planirati) in sinonim za nedorečeno in neorganizirano. Najbrž je resnica nekje vmes, odvisno od vrste dejavnikov: tipa in obsežnosti projekta, velikosti tima, števila vključenih strok, več-projektnega okolja, pogodbenih razmerij… Zanimiva pa je tudi trditev zagovornikov, da v prihodnosti ne bo več projektnih managerjev in da se bodo timi organizirali sami. Dokaj »bogokletna« trditev, kajne, sploh če ob tem omenimo še to, da naj bi bil za uspeh projekta odgovoren naročnik projekta (angl. Product Owner) in ne tim ali kdo od odgovornih za izvedbo. Kar veliko tem za raziskavo, kajne.

Pregled literature pa je pokazal, da stroka še ni povsem poenotena glede koristi, ki jih prinaša agilnost na ravni izvajanja projektov. Še več, raziskave kažejo, da se navkljub prepričanosti zagovornikov agilnosti stopnjuje predvsem uporaba hibridnih pristopov (Walenta, 2017). Komus je s sodelavci (2016/17) raziskoval razvitost pristopa v evropskih združbah, pri čemer so ugotovili, da le dvajset odstotkov anketiranih organizacij sledi povsem agilnemu pristopu, oseminšestdeset odstotkov ima razvite hibridne pristope kombinacije agilnih in tradicionalnih konceptov, dvanajst odstotkov pa še vedno uporablja »slapovni« pristop.

“Agilno” je splošni izraz za številne pristope
(Agile Practice Guide, PMI, 2017)

Načeloma ni dvoma o tem, da pristop zagotavlja višjo kakovosti rezultatov in da končni proizvodi bistveno bolje zadostijo željam (in ne le zahtevam) naročnika, vendar pa raziskave še niso nedvoumno potrdile (ali ovrgle) trditev zagovornikov agilnosti – da pristop zagotavlja učinkovitejšo izvedbo projekta, da so projekti krajši in cenejši. Bistveno prednost agilnega pristopa vidimo na prihodkovni strani, ker naj bi bili – če se združbe držijo priporočil stroke – uporabni tudi že delni proizvodi posameznih ciklov projekta.

Naj na koncu dodam še kritiko mlajšim »strokovnjakom«, ki ob predstavitvah agilnih pristopov vehementno zavračajo vse, kar je bilo prej. S svojim načinom bolj škodijo uveljavitvi pristopa, pri tem pa pridno ustvarjajo goreče nasprotnike. Sploh izkušenejši projektni managerji (ki so se tudi pri tradicionalnem projektnem pristopu že mnogokrat srečali z agilnostjo) se sprašujejo, kako lahko nekdo, ki nečesa ni nikoli izkusil v praksi, ocenjuje tisto kot neprimerno. Na podlagi člankov in izkušenj drugih? Pa še nekaj, kot sem omenil na začetku – v prvem desetletju »novejše agilnosti« se je vse nanašalo le na IT projekte in zato sprašujem IT strokovnjake – bi verjeli gradbenikom, ki bi trdili, da morate popolnoma spremeniti način dela, da je vse od prej za v staro šaro? To se namreč dogaja v obratni smeri. In tudi zaradi tega sem se lotil obravnave agilnih pristopov v svojem blogu.

Page 2 of 11

Powered by WordPress & Theme by Anders Norén