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.