Month: December 2010

Vloga managementa pri iterativnem razvoju

Posted on

Vemo, da je vsaka posamezna iteracija videti kot en mini projekt. S stališča programerja – razvoja – vsebuje vse aktivnosti RADIT (Requirements, Analysis, Design, Implementation, Test). Kaj pa s stališča managementa? Kakšna je njegova vloga pri iterativnem razvoju?

Ponavadi se razmišlja v naslednji smeri:

  • management samo zaustavlja birokracijo (oz. neke ovire), da ne pride do razvojne ekipe, ta pa dejansko (edina) naredi celotno delo;
  • management skrbi samo za budget in za spremljanje načrta dela;
  • management dejansko ni potreben;

Takšno razmišljanje ponavadi privede do neuspeha. Management mora storiti več.
Razmišljamo lahko dvoravensko. Na nižji ravni mora management poskrbeti, da bo vsaka iteracija imela:

  • jasne cilje (koliko novih funkcionalnosti bo razvitih, koliko manj bugov glede na prejšnjo iteracijo bo proizvedenih, koliko nalog iz t. i. risk list bo rešenih ipd.). Glej tudi OPOMBO 1.
  • merljive kriterije za oceno uspešnosti
  • ekipo, ki se zaveže, da bo dosegla cilje
  • definiran začetek in konec ter njena umestitev v razvoj celotnega projekta
  • začrtane dejavnosti glede na resurse
  • ocenjevanje uspešnosti ob njenem koncu

OPOMBA 1: Česar nismo omenili zgoraj (ker je samoumevno), je naslednje: osnovni cilj vsake iteracije je release – delujoča različica programske opreme. Ta je v osnovni obliki lahko samo t. i. Proof of Concept, lahko je delujoč prototip, različica beta ipd.

Zgornje bi lahko ponazorili s ciklom: Agree – Execute – Assess.

Na višji ravni pa mora management prevzeti vlogo leadershipa. Tako mora:

  • poskrbeti mora za dolgoročno osredotočanje in usmerjanje ekipe. Tu ne gre za usmerjanje znotraj posamezne iteracije, ampak za usmerjanje glede na celoten projekt. Razvoj ne sme potekati po naključni poti. Treba je vedeti, koliko resursov bo še potrebno do konca in kdaj bodo ti resursi potrebni.

To lahko ponazorimo s ciklom: Monitor – Control Direction – Focus. Velja, da se oba omenjena cikla ponavljata nenehno skozi celotni razvoj.

Zaradi opisane pomembnosti managementa lahko njegovo dejavnost dodamo med iterativne dejavnosti. Zato ne govorimo več o dejavnostih RADIT, ampak o dejavnostih MRADIT (Management, Requirements, Analysis, Design, Implementation, Test).

 

Odnos med zbiranjem funkcionalnosti in njihovim razvojem

Posted on

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

Posted on Updated on

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

Slika 1: Prakse tradicionalnih metod v primerjavi z agilnimi (VIR: http://www.alistapart.com/articles/gettingrealaboutagiledesign/)

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…