Agile or not? (here we come) – 2. del
V prejšnjem zapisu smo ugotovili, da potrebujemo drugačen pristop k razvoju programske opreme. Rešitev smo našli v t. i. agilnih metodah razvoja. Temelj je dokument oz. manifest iz leta 2001, ki so ga sestavile nekatere največje avtoritetete na področju razvoja programske opreme (npr. Martin Fowler, Ken Schwaber idr.). Govori o štirih temeljnih vrednotah (values), ki jih bomo poskusili prenesti v slovenski jezik:
- Posamezniki in sodelovanje so pomembnejši od procesa in orodja.
Treba je vedeti, da agilne metode (razen izjem) ne podajajo natančnega recepta, postopka izdelave programske opreme, ampak vzpostavijo samo okvir (framework), podrobnosti pa so prepuščene posameznikom. Ti se morajo sami odločiti (za vsak projekt posebej in glede na okoliščine), katere procese in orodja bodo uporabljali – ti zato niso definirani. Lahko na primer uporabljamo navadno tablo (white board), na katero rišemo (poljubne) diagrame, v drugi skrajnosti pa diagrame ustvarjamo s kakšnim od orodij UML, in sicer strogo v skladu s specifikacijo UML. Zato je izbira posameznikov in njihovo dobro sodelovanje pomembnejše od izbire orodja in natančno opredeljenega procesa.
- Delujoča programska oprema je pomembnejša od natančne dokumentacije.
Če upoštevamo prejšnje načelo, je raven t. i. ceremonije (tj. kako natančna je specifikacija) prepuščena posameznikom. Ne pozabimo, da je primarni cilj izdelava delujoče programske opreme, ne pa izdelava natančne dokumentacije.
- Sodelovanje z naročnikom je pomembnejše od pogajanja o pogodbi.
Ker se razvoj začne “takoj”, v pogodbo ni mogoče napisati natančne specifikacije (dejansko tudi če bi jo hoteli, to ni mogoče, kar smo prikazali v prejšnjem blogu). Zato je z naročnikom treba vzpostaviti zaupanje, ki je osnova za tesno sodelovanje. Iz prakse je slednje lahko zelo težko, še zlasti na samem začetku, saj so na našem balkanskem območju naročniki zelo nezaupljivi. Če se oceni, da zaupanja ni mogoče vzpostaviti takoj na začetku, se zopet vrnemo k prvemu načelu in uberemo malce drugačno, “mešano” pot, kjer v pogodbi vseeno dovolj podrobno opišemo funkcionalnosti, tako da damo naročniku moč morebitnega kasnejšega pogajanje glede pogodbe. Po določenem času po začetku razvoja pa se zaupanje kljub temu vzpostavi, in sicer z dovolj veliko transparentnostjo poteka razvoja – naročnik (ali njegov proxy) tako postane del razvojne ekipe in ima (med drugim) dovolj velik vpogled v to, kako se nalaga (in ne zapravlja) njegov denar.
- Odziv na zahteve po spremembah je pomembnejši od sledenja načrtu.
Veliki vnaprej določeni načrti delujejo samo v nadzorovanih okoljih (spremembe so tam predvidljive), kar pa konkurenčni trg gotovo ni (vse, kar je mogoče predvideti, je to, da spremembe bodo). Zato se veliko razvoja za javni sektor vseeno izdeluje po “starih načelih”, ker je okolje nadzorovano. Ampak to ne pomeni, da nimamo velikega načrta. Ta obstaja, vendar mora v njem biti dovolj prostora za spremembe, zato tudi nima smisla izgubljati preveč časa z njegovo natančno izdelavo. Kot bomo videli kasneje, se izdela natančni načrt samo za naslednjo iteracijo. Sprememba ni slaba, treba jo je sprejeti kot nekaj običajnega. Strah pred spremembo je običajno samo opomnik na to, da je programska oprema izdelana slabo in bodo zaradi sprememb nastale velike težave. S pravimi praksami kodiranja (npr. integracijskimi testi, ki jih omogoča npr. Arquillian http://www.jboss.org/arquillian) postanejo spremembe obvladljive.
Za bolj poglobljeno razlago o tem, kaj je agilnost, so avtorji manifesta sestavili tudi seznam dvanajstih načel (principles), ki si jih je vredno natančneje ogledati:http://agilemanifesto.org/principles.html
Sedaj ko imamo predstavo o vrednotah in načelih, si poglejmo še prakse (practices) agilnih metodologij. Poleg skupnih praks, doda vsaka posamezna metodologija (npr.: eXtreme programming, SCRUM) še svoje prakse. Poglejmo si najprej skupne prakse:
- Iterative & incremental development
Celoten življenjski cikel je razdeljen na več iteracij, ki si sledijo. Razvoj poteka inkrementalno, v vsaki iteraciji se razvijejo dodatne funkcionalnosti. Iteracija je zaključena celota, kar pomeni, da se v njej dogajajo vse aktivnosti – tudi testiranje in predstavitev naročniku.
- Evolutionary & adaptive development
Gre za to, da nimamo velikega načrta za celoten razvoj, ampak se načrt sproti spreminja. Natančen načrt se sestavi samo za naslednjo iteracijo. Ker vsebuje iteracija tudi predstavitev naročniku in ker je ta del razvojne ekipe, ta poda svoje povratne informacije, ki se upoštevajo pri naslednjih iteracijah. Nujen je tudi skupen pregled opravljenega dela v posamezni iteraciji s celotno ekipo, da se ugotovi, kaj je potekalo pravilno in kaj ne, da se pridobljeno znanje prilagodi razvojnemu ciklu in upošteva pri nadaljnjem razvoju.
- Risk-driven & client-driven iterative planning
Za funkcionalnosti v naslednji iteraciji se odločimo na podlagi želja naročnika in na podlagi ocene ekipe glede na to, kako zahtevna (in posledično tvegana) je posamezna funkcionalnost.
- Evolutionary requirements analysis
Vsaka iteracija ima na začetku t. i. requirement workshop. Število analiziranih funkcionalnosti narašča iz iteracijo v iteracijo. Tako pri prvi iteraciji ponavadi analiziramo arhitekturno pomembne funkcionalnosti, ki predstavljajo cca. 10 % skupnih funkcionalnosti. V naslednji iteraciji analiziramo nove funkcionalnosti, tako da je skupno pokritih približno 30 % funkcionalnosti. Odstotek narašča do 90 %, kar pomeni naslednje: če je razvoj dolg 10 iteracij, je 90 % funkcionalnosti obdelanih v prvih 3 do 4 iteracijah. Naslednje iteracije so namenjene kodiranju in prilagajanju.
- Timeboxing
Gre za to, da je dolžina posamezne iteracije določena vnaprej – na končno število dni (npr. 20), ki se ne spremeni. Morebitne nove, sproti odkrite želje naročnikov, se premaknejo v naslednje iteracije.
- Adaptive planning
Kdaj je naročniku sploh mogoče podati dovolj dobro oceno, kako dolgo bo projekt trajal? Ponavadi je to mogoče oceniti že po prvih dveh iteracijah. Kaj pa če naročniki želijo to oceno že takoj na začetku? V takem primeru je mogoče uporabiti t. i. “two fixed-price contract”, kjer se poda ocena za prvi dve iteraciji, po njunem zaključku pa se postavi cena še za preostali del.
Podrobnosti in lastne izkušnje o posameznih praksah bodo natančneje opisane v naslednjih zapisih. Stay tuned…
milanpevec 