Agilni pristop je primeren za razvojne dejavnosti, kjer obstaja ohlapna vizija produkta ali storitve, pot kako jo realizirati, pa ni poznana.
Pogosto takšna vizija samo opisuje želeni učinek rešitve, kako se bo pa takšna rešitev obnesla v praksi, je prepuščeno razvojnim teamom, ki prakticirajo inkrementalni razvojni cikel.
To je pričakovano in želeno stanje, ki pod pravimi pogoji lahko polno aktivira ustvarjalni potencial razvojne organizacije.
Pozicioniranje
V literaturi se za pozicioniranje agilnega pristopa pogosto uporablja »Cynefin framework« prikazan spodaj.
Waterfall
Projekte, za katerih izvedbo obstajajo najboljše prakse (best practices) ali vsaj dobre prakse (good practices), izvajamo z »waterfall« pristopom. V waterfallu se celotno planiranje opravi pred pričetkom izvedbe. Ko je detaljni projektni plan odobren, se začne izvedba.
Spremembe plana v fazi izvedbe, niso zaželjene, so običajno precej drage in morajo skozi zahteven postopek odobritev (Integrated Change Control).
Stereotip »waterfall« projekta je lahko gradnja nove zgradbe. Investitor pričakuje, da bo v uporabo prejel objekt, kot ga je potrdil na začetku projekta.
»Waterfall« v »Cynefin« modelu torej pokriva probleme z očitnimi (obvious) in kompliciranimi (complicated) rešitvami.
Agile
Ko se srečamo s kompleksnimi problemi, kjer relacija med vzrokom in posledico ni sama po sebi umevna, je primernejši agilni pristop.
Lahko na primer razvijemo tehnično in funkcionalno odlično aplikacijo, ampak, če je trg ne želi, vloženih sredstev ne bomo povrnili.
Zato »Agile« temelji na cikličnem razvoju, kjer vsak nadaljnji cikel gradimo na spoznanjih prejšnjega. Ta feedback je lahko tehnične narave ali neposredno od stranke, ki je kontinuirano vključena v razvojni proces.
Probe-Sense-Respond v tem kontekstu pomeni, da razvijemo delno rešitev, jo preverimo s stranko in v naslednjem ciklu smer razvoja prilagodimo prejetim povratnim informacijam.
»Agile2 v »Cynefin« modelu pokriva kompleksne (complex) in delno komplicirane (complicated) probleme. Zadnje v primeru, ko je faza analize primernosti rešitve zahtevna glede zbiranja povratnih informacij in bi iz tega razloga bil primernejši inkrementalni razvoj.
Drugi način prikaza pozicije agilnega pristopa je Stacey-jeva matrika. Ta ne zahteva posebnega komentarja.
Stacey-jeva matrika
Kaj pa območje kaosa, ko ne obstaja niti konsenz glede zahtev, niti ni poznan tehnični pristop?
»Agile« v kaosu ne funkcionira. V takšnem primeru je iniciativo bolje razbiti na več podprojektov, ki bodo v večjem delu študije izvedljivosti (feasibility study). Rezultati teh podprojektov bodo idealno grobi modeli ali prototipi, ki bodo nato služili kot osnova za nadaljnje odločanje ter definiranje zahtev in tehnoloških pristopov.
Pogosto spregledani pogoji
»Agile« smo pozicionirali glede tipov rešitev, ki jih razvija. Kaj pa organizacijski faktorji?
Vsaka iniciativa, ki jo planiramo realizirati z agilnim pristopom mora po mojem prepričanju zadostiti naslednjim pogojem:
- Razvijamo rešitev kjer je cilj poznan, metode za dosego le tega pa ne. Ali:
- Razvijamo rešitev kjer je cilj ohlapno definiran in se lahko v času projekta spremeni v skladu z novimi spoznanji, ki se bodo pojavili v času razvoja.
- Predvidena rešitev je v obliki, ki dopušča inkrementalno realizacijo poslovne vrednosti.
- Pogodbeni odnos dopušča inkrementalno realizacijo rešitve.
- Razvojna organizacija dopušča in podpira uporabo agilnih pristopov.
- Stranka je pripravljena konstantno sodelovati v razvojnem procesu.
Z zagotovljenimi zgornjimi pogoji smo ustvarili okolje, ki dopušča agilni razvoj in realizacijo njihovega potenciala.
Če pa pogoji niso izpolnjeni, se je projekta bolje lotiti z linearnim waterall pristopom. To ne pomeni, da bo avtomatično neuspešen, le manj možnosti je za njegov popolni uspeh.
Odločitev za »Agile« ali »waterfall« se seveda zrcali tudi v tipu pogodbe med dobaviteljem in stranko. Več o tipih agilnih pogodb v kakšnem drugem članku.
Denis Curk
www.linkedin.com/in/denis-curk-b4bb5b18/
