development
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.
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…
Agile or not? (here we come) – 1.del
If agile methods have a motto, it is embrace change. If agile methods have a strategic point, it is maneuverability. (Vir: Agile and Iterative Development: A Manager’s Guide)
Razvoj programske opreme je kompleksen proces, je zelo nepredvidljiv. Uspešno predvidevanje je praktično nemogoče, tveganje je ogromno. Kakšno metodologijo razvoja izbrati, katere prakse implementirati in katere vrednote upoštevati za čim večjo uspešnost projekta?
Predstavljajmo si, da smo pred začetkom razvoja projekta. Poskusimo odgovoriti na naslednja vprašanja:
- Ali je mogoče že vnaprej natančno opredeliti specifikacije, ki se pod nobenim pogojem ne bodo spremenile?
- Ali je mogoče že na začetku podati natančen datum konca razvoja?
- Ali je mogoče že na začetku opredeliti, organizirati, prioritizirati vse dejavnosti celotnega razvoja?
Odgovor je jasen: ne, ni mogoče. Razlogov je več, pa jih naštejmo nekaj:
- stranke redko natančno vedo, katere funkcionalnosti želijo;
- stranke težko razložijo, kaj želijo;
- ko jih vprašamo o podrobnostih, stranke ne vedo natančno, kaj bi naj funkcionalnost, ki jo želijo, počela;
- stranke si med samim razvojem (upravičeno) premislijo glede določenih funkcionalnosti.
Nekdo bo rekel, zakaj potem skupaj s stranko ne pripravimo natančnih odgovorov na zgornja vprašanja oz. zakaj si ne vzamemo nekaj mesecev za pripravo natančnih specifikacij (t. i. waterfall principle)?
Takšno razmišljanje je zastarelo. Čas je predrag, da bi ga porabili (samo) za omenjeno dejavnost. Kot bomo videli v kasneje, je dejavnosti mogoče paralelizirati in tako bolje izkoristiti čas. Poleg tega se v močno konkurenčnem okolju funkcionalnosti sproti tako hitro spreminjajo, da se tudi želje strank med razvojem bistveno razlikujejo od tistih pred začetkom projekta. Le zakaj? Postavimo si še dodatno vprašanje:
- Kaj je sploh uspešen razvojni projekt? Ali je to projekt, kjer se razvoj zaključi pravočasno (in brez hroščev), kjer smo razvili vse na začetku zastavljene funkcionalnosti?
Lahko se zgodi, da razvoj projekta uspešno zaključimo, vendar takoj ob koncu ugotovimo, da je projekt neuspešen. Zakaj? Zaradi poslovnega vidika, zaradi katerega se je razvoj sploh začel: zahteve trga so se spremenile in naš projekt jih več ne pokriva (npr. na trgu se je pojavila konkurenca, nova tehnologija, zakonodaja se je medtem spremenila …), ni se pravočasno prilagodil.
Zato je potreben drugačen pristop, in sicer na vseh ravneh, ne samo na ravni razvijanja – kodiranja, ampak tudi na nivoju menedžmenta in pri odnosu do stranke. Rešitve so v iterativnih in evolucijskih metodah, katerih podmnožica so agilne metode razvoja.
milanpevec 