Odnos med zbiranjem funkcionalnosti in njihovim razvojem
V kakšnem razmerju sta zbiranje funkcionalnosti (dejavnosti Requirements, Analysis) in njihov razvoj (dejavnosti Design, Implementation, Test) ? Poglejmo si štiri modele.
1.) Vse funkcionalnosti so zbrane pred začetkom razvoja.
Pri tem modelu lahko sklepamo, da bo zbranih nekaj funkcionalnosti, ki nikoli ne bodo razvite ali ne bodo razvite tako, kot si to predstavlja naročnik. Zakaj? Ker je ekipa, ki zbira funkcionalnosti, izolirana od ekipe, ki jih bo razvila – slednja ne podaja povratnega mnenja. Namreč lekcije, ki se jih naučijo pri razvoju ene iteracije, se ne upoštevajo pri zbiranju funkcionalnosti za naslednje iteracije. Ta pristop tako ustvari nerealna pričakovanja in posledično razočaranja naročnika (in tudi celotne ekipe).
Ta model delovanja ponavadi opazimo v organizacijah, kjer ekipa, ki razvija, želi uporabljati agilne metodologije, vendar te (še) niso sprejete na ravni managementa in naročnika. Pojavi se tudi v primeru, ko se razvoj outsourca ali ko management ne zaupa podanim mnenjem in odločitvam razvoja. V skrajnem primeru se lahko zgodi celo to, da je ekipa, ki zbira funkcionalnosti, nagrajena (“Ustvarili ste odlične dokumente s funkcionalnostmi.”), ekipa, ki razvija, pa kaznovana (“Zakaj ne morete razviti zadeve točno tako, kot piše v dokumentaciji?”).
2.) Nekaj funkcionalnosti je zbranih pred začetkom razvoja, ostale se zbirajo med razvojem.
Gre za izboljšavo prvega modela, kjer se množica dovolj stabilnih funkcionalnosti začne razvijati, predenj se zberejo vse funkcionalnosti. Ampak model še vedno ohranja slabost, da sta ekipa, ki zbira funkcionalnosti, in ekipa, ki jih razvija, ločeni s strani managementa (spet lahko pride do nagrajevanja enih in kaznovanja drugih).
3.) Celotna vzporednost zbiranja funkcionalnosti in razvoja.
Gre za še dodatno izboljšavo drugega modela, kjer ekipa zbira funkcionalnosti za naslednjo iteracijo, ekipa za razvoj pa jih razvija, takoj ko je zbiranje za izbrano iteracijo končano. Pri tem modelu lahko pride do težave v zvezi z izgubo fokusa, namreč ena ekipa je z mislimi že pri naslednji iteraciji, medtem ko je druga ekipa še pri prejšnji iteraciji. Ker sta ekipi zopet (delno) ločeni, ni takšnega uspeha, kot bi lahko bil. Treba je paziti tudi na to, da se razvija samo ena iteracija hkrati.
Običajno se tak pristop izbere (kot nujno zlo) v primeru, ko so resursi omejeni (ker primanjkuje razvijalcev, poteka razvoj prepočasi, ekipo za zbiranje funkcionalnosti pa želimo čim bolj uporabiti in zato začne z delom za naslednjo iteracijo).
4.) Zbiranje funkcionalnosti in razvoj sta v celoti prepletena.
Ta model je najbolj fleksibilen in najbolj ustreza iterativni in inkrementalni praksi. Ekipi nista ločeni, fokus je velik, do rezultatov se pride hitreje, manj je konfliktov, saj obe ekipi tesno sodelujeta za dosego istih ciljev ene iteracije. Ni prelaganja odgovornosti, skupaj so dogovorni za uspeh iteracije. Dejansko se končna verzija zbranih funkcionalnosti ustvari ob koncu iteracije, skupaj z releaseom (izdelano, stestirano, integrirano programsko opremo). Gre za t. i. zbiranje funkcionalnosti just-in-time. Sedaj tudi razumemo, zakaj je pomebno, da je naročnik del ekipe.
Prikazali smo pomembnost tesnega odnosa med zbiranjem funkcionalnosti in njihovim razvojem ter dodatno tudi med naročnikom. Še več, tudi management mora testno sodelovati. Kakšna je njegova vloga, pa si bomo pogledali v enem od naslednjih zapisov.
milanpevec 