Blog

Agilizacija u praksi

Za razliku od dobroga dijela našega okruženja koji o agilnim metodologijama samo priča (nažalost, moram naglasiti), u CROZ-u se aktivno bavimo širenjem tih znanja i praksi, kako kod korisnika tako i interno.
Objavljeno 17.11.2014.

Svi su ludi za agilizacijom! Dobro, ako nisu baš ludi, bar su čuli ponešto o ovoj metodologiji i pričaju o tome, kako je to najbolji način razvoja, i to ne samo softvera, kako su rezultati odlični, kako su ubrzanja isporuka strahovita. I kod nas u CROZ-u je ta tema vrlo popularna, uostalom dobar dio prošloga broja našeg časopisa FYI (broj 16) bio je posvećen upravo agilnoj transformaciji, Scrumu i vezanim cjelinama. Za razliku od dobroga dijela našega okruženja koji o agilnim metodologijama samo priča (nažalost, moram naglasiti), u CROZ-u se aktivno bavimo širenjem tih znanja i praksi, kako kod korisnika tako i interno.

Moguće je početi i iznutra

Razvojni projekti, iz različitih razloga, mogu krenuti krivim putem. Najčešće
 su to gubici uslijed preoptimističnih procjena ili nedovoljno jasnih zahtjeva, i unatoč tim poznatim problemima neki projekti i dalje srljaju u propast. Takvo što se ponekad dogodi svima, pa i nama, no ono po čemu se razlikujemo od većine ostalih softverskih kuća jest sposobnost prepoznavanja i, što je još važnije, reagiranja u takvim situacijama.

Nedavno je jednom našem iskusnom voditelju projekata (podaci poznati redakciji, op.a.) upala u krilo nezahvalna dužnost spašavanja jednoga posrnuloga projekta kod dugogodišnjega korisnika. Sve što može krenuti krivo na projektu već je debelo zagazilo u tom smjeru: niz neriješenih zahtjeva, ono što se 
radi znatno kasni, probijeni rokovi za isporuke, previše potrošenih dana u odnosu na procjene, nezadovoljni ljudi 
na projektu. Kako riješiti problem i kako spasiti projekt, odobrovoljiti korisnika i vratiti dobru reputaciju? Naš kolega je već iskusan projektni vuk, koji zna kako se ponašati u takvim neprilikama: nastaviti s dosadašnjim pristupom, samo brže, više i jače neće promijeniti baš ništa, osim što će još više povećati minus na projektu i učiniti korisnika još nesretnijim. Promjena stava, dakle.

I ne samo promjena stava, već i promjena organizacije unutar projektnoga tima, promjena načina komuniciranja s korisnikom, promjena u procjenjivanju, promjena u izvještavanju – u osnovi, agilizacija projekta i uvođenje Scruma.

Na početku treba riješiti najvažniju stvar, a to je u našem slučaju poljuljano korisnikovo povjerenje u nas. Zašto? Jer konstantno kasnimo i ne držimo se rokova. Zašto? Jer novi zahtjevi ulijeću po putu ili nisu dovoljno jasni već na samom početku, pa su prema tome i procjene 
o datumima isporuka vrlo otprilike. To, u svakom slučaju, nije dobro ni za korisnika, jer ima internu obavezu prema marketingu i prodaji, niti za nas, jer ne možemo planirati niti ljude niti cashflow. Treba odmah razjasniti jednu činjenicu, koja je vrijedila za baš svaki projekt na kojem sam sudjelovao, a usuđujem se reći da vrijedi i univerzalno: korisnici su vrlo razumni ljudi, koji shvaćaju da 
se stvari po putu mijenjaju, pa se tako mijenjaju i poslovni zahtjevi, mijenjaju se i mehanizmi implementacije, mijenja se i okruženje. Sve što treba je dovoljno rano prepoznati promjenu i pojasniti utjecaj na dinamiku projekta, a to nije ništa drugo nego poboljšati komunikaciju unutar cjelokupnoga tima, od vlasnika poslovnih zahtjeva, preko voditelja projekta s obje strane, pa do samoga razvojnoga tima. Kako poboljšati komunikaciju? Ništa lakše, reklo bi se: družite se češće, svaki dan ako treba, pa bilo to i samo 15 minuta da prođete što ste radili jučer, je li bilo kakvih nenadanih problema, i što planirate raditi danas – daily scrum meeting, dakle.

Projektna nadzorna ploča na IBM Jazz platformi daje brz uvid u status projekta iz nekoliko perspektiva i može se mijenjati i prilagođavati tijekom trajanja projekta

Projektna nadzorna ploča na IBM Jazz platformi daje brz uvid u status projekta iz nekoliko perspektiva i može se mijenjati i prilagođavati tijekom trajanja projekta

I tu su se stvari počele otpetljavati. Alat IBM Rational Team Concert omogućio je bolju vidljivost zadataka – otvorenih, u najavi, u testiranju, zatvorenih; također je omogućio mjerenje brzine kojom tim isporučuje gotove komade softvera pa prema tome i bolje planiranje. Omogućio je i da se nadopuna poslovnih zahtjeva jasno vidi kao skok na grafu koji pokazuje količinu posla, a prema tome i prema dinamici razvojnoga tima uvijek se može vidjeti kad će posao biti gotov – nema više ljutnje zašto isporuka kasni dva tjedna, a dodan je samo jedan novi ekran. Cjelokupni tim, uključujući i vlasnike poslovnih zahtjeva, odlučit će što je važnije: isporuka prema unaprijed dogovorenom roku ili dodatna funkcionalnost, ali nešto kasnije. Ili možda dodatna funkcionalnost umjesto neke druge, ali u unaprijed dogovorenom terminu? Takvi se detalji rješavaju odmah na početku, čim je problem nastao, a ne na kraju, kod testa prihvaćanja. I tako se gradi povjerenje kod korisnika.

IBM Jazz platforma: Burndown chart automatski se generira i pokazuje odnos preostaloga posla i raspoloživoga vremena do kraja projekta

IBM Jazz platforma: Burndown chart automatski se generira i pokazuje odnos preostaloga posla i raspoloživoga vremena do kraja projekta

Fokusirajte se na bitno!

Financijska agencija (FINA), naš dugogodišnji korisnik, s kojim imamo vrlo uspješnu suradnju u nekoliko različitih domena, od sistemskoga održavanja, preko razvoja softvera, do konzaltinga, također ima i značajan interni razvojni tim, koji je u stanju isporučiti kompleksne projekte u različitim tehnologijama. Metodološki su također poprilično potkovani, no kako se cjelokupna 
IT industrija razvija, tako se i u tom području događaju pozitivni pomaci, što su prepoznali u FINA-i i zatražili pomoć od nas. Zaključili smo da je za FINA-u odgovarajući CROZ-ov konzultantski proizvod koji nazivamo Agile Kickstart – skup nekoliko tečajeva, savjetovanje, praćenje i nadgledanje konkretnoga tima na konkretnom projektu kako bi se vještine agilnoga upravljanja projektom ugradile u samu srž organizacije, kako bi se na kraju mogle i dalje širiti.

Darko Špoljarić, jedan od članova našega konzultantskoga tima, lijepo je sažeo cijeli angažman: ”Učimo se fokusirati na bitno, kako bismo u ograničenom vremenu napravili baš ono što će imati najveću uporabnu vrijednost i kako bi se uloženo čim prije počelo vraćati.”

Što znači da je tim fokusiran na bitno? Darko nastavlja: ”Prvo je bilo nužno ponovno definirati tim, odnosno uvući unutra sve osobe koje sudjeluju u razvoju produkta – ne samo softvera, ne samo specifikacija, već cjelokupnoga proizvoda koji se sastoji od tih cjelina. Tek kad smo prihvatili činjenicu da softver bez dobrih specifikacija ne vrijedi puno, niti da specifikacije ne postoje zbog samih sebe, mogli smo početi planirati redoslijed aktivnosti, tako da čim prije počnemo isporučivati vrijednost krajnjem korisniku.”

U razgovoru s Dariom Belićem iz FINA-e saznajemo da su prvi dojmovi odlični, ali ne samo dojmovi, već i tvrdi brojevi: već nakon prvoga ciklusa uvođenja agilnih metodologija vidi se ubrzanje od 30% do 50% u isporukama funkcionalnosti u odnosu na tradicionalni pristup, no što je još važnije, isporučene su one funkcionalnosti koje su stvarno i trebale biti, jer je tijekom projekta zaključeno da su bitne, odnosno bitnije od nekih drugih, pa su i isplivale na vrh liste za razvoj.

Brzina isporuka, na kraju krajeva, i nije tako važna ako uzmemo u obzir stvarni učinak ovakve promjene u pristupu. Svaki razuman sponzor projekta (a takvi su svi) pristat će na onih 20% funkcionalnosti, koje pokrivaju 80% korisničkih potreba, i s tim zaključiti projekt, a ne inzistirati na stopostotnom peglanju svih zahtjeva, znajući da se te opcije nikad neće koristiti.

Projektna nadzorna ploča za vlasnika produkta može se konfigurirati prema specifičnim potrebama, tako da su ključne informacije uvijek nadohvat ruke: aktivnosti u tijeku, gdje je potrebna intervencija, pregled po iteracijama...

Projektna nadzorna ploča za vlasnika produkta može se konfigurirati prema specifičnim potrebama, tako da su ključne informacije uvijek nadohvat ruke: aktivnosti u tijeku, gdje je potrebna intervencija, pregled po iteracijama…

A što ako razvijamo embedded softver?


U našem časopisu FYI, broj 16, pisali smo o uspješnoj implementaciji Rational Requirements Composera i Rational Quality Managera u Iskratelu, slovenskoj kompaniji koja djeluje na međunarodnom tržištu i izrađuje poprilično kompleksne telekomunikacijske uređaje i softver. Treći dio toga projekta uključivao je i uvođenje agilnih metodologija i alata u razvojni ciklus, prvenstveno Scruma. Ta je cjelina zamišljena i provedena ”prema knjizi”, odnosno baš onako kako se i preporučuje: nakon tečaja o detaljima agilnoga razvoja, specifičnostima ovakvoga pristupa iz perspektive organizacije tima, načina komuniciranja tijekom razvoja i same prioritizacije posla, odabran je pilot-projekt. Dobro odabran pilot-projekt ponekad je ključan za uspjeh cijeloga pothvata: osim što zadatak mora biti realan i ostvariv, mora biti i dovoljno reprezentativan, odnosno mora predstavljati uobičajeni projekt kakav se i inače implementira u tom okruženju. Ukratko, ne smije biti trivijalan.

Posebnost Iskratela, u odnosu na recimo CROZ, jest u vrsti softvera koji se razvija. Iskratel naime razvija i embedded softver, odnosno softver koji je usko vezan uz pripadajući hardver na kojem će se izvršavati. U krugovima koji nisu dovoljno upoznati s agilnim metodologijama razvoja često se smatra kako je vrlo teško, gotovo nemoguće razvijati embedded softver tako da se na kraju svakoga sprinta isporučuje radeća verzija, a pogotovo da nije moguće tako razvijati sam hardver. Ni prva ni druga tvrdnja ne stoje, što pokazuje ovaj projekt.

Kao i kod svake agilne inicijative, počeli smo s tečajevima upoznavanja
 s principima agilnoga razvoja svih uključenih u projekt, s tim da je društvo iz Iskratela već imalo dobru podlogu. Samo savjetovanje i praćenje razvojnoga tima imalo je jednu zanimljivu specifičnost. Naime razvoj se odvijao u Mariboru, kojih 120 km od Zagreba. Putovati svaki dan
 do Maribora i natrag nije dolazilo u obzir, a boraviti tamo 6 tjedana, koliko smo planirali za pilot-projekt, još i manje. Našli smo se na sredini: inicijalno planiranje (backlog grooming), planiranje sprinteva (iteracija) i retrospektive imat ćemo zajedno, u Mariboru, a dnevne ćemo stand-upe voditi putem Skypea.

Ivan Krnić, naš glavni konzultant na projektu, smatra da je takav pristup sasvim prihvatljiv. ”Bitno je da smo zajedno, na lokaciji, tijekom backlog groominga i planiranja sprinteva. Tako smo mogli izravnije korigirati ponašanja sudionika na projektu i navigirati ih u pravom smjeru, što je uostalom i cilj našega angažmana – naučiti korisnika kako samostalno voditi projekte na agilni način. Pomogli su i tečajevi prije početka pilota, kad smo se bolje upoznali. Skype je za dnevna druženja sasvim okej: iako fizički nismo bili zajedno, uspjeli smo tijekom druženja zadržati fokus na tekućim zadacima unutar sprinta.”

Janez Krušič iz Iskratela, product owner tijekom pilot-projekta, i sam hvali takav pristup. ”Pokretanje projekta, odnosno prikupljanje svih potrebnih informacija za početak implementacije vidljivo je skraćeno. Nekad nam je trebalo i do dva tjedna da procijenimo veličinu projekta i redoslijed implementacije. Dok svi pročitaju e-mail, pa odgovore, pa dok se sve to skupi na jedno mjesto… Sada smo sve to odradili za jedan dan. Skupili smo se za backlog grooming i ostali sve dok nismo razjasnili što, kako i kad treba napraviti. Naravno, ovo je bilo samo početno druženje, nismo definirali baš sve detalje, ali smo već sljedeći dan mogli početi s implementacijom.”

Uz vidljivo ubrzanje na početku, dnevna su druženja omogućila da se zadrži fokus na poslovnoj vrijednosti koju će projekt isporučiti, odnosno ugradili smo mehanizam promjene prioriteta u implementaciji željenih funkcionalnosti. Razumljivo je, pa čak i poželjno, da se vlasnici poslovnih zahtjeva predomisle tijekom projekta oko nekih zahtjeva; bitno je da se te promjene uoče na vrijeme i odmah ugrade u projektni plan. Hoće li to utjecati na vrijeme implementacije ili će se izbaciti neki manje bitni detalji ostaje na vlasniku produkta da odluči. U svakom slučaju, neće biti neugodnih iznenađenja na kraju.

Sve bitne informacije, vizualizirane na jednom mjestu, olakšavaju praćenje statusa projekta: otvoreni zadaci, kritičan put, opterećenost razvojnoga tima i drugo

Sve bitne informacije, vizualizirane na jednom mjestu, olakšavaju praćenje statusa projekta: otvoreni zadaci, kritičan put, opterećenost razvojnoga tima i drugo

Još mi se jedan detalj s ovoga projekta jako svidio: korištenje fizičke ploče, obješene u projektnoj sobi za planiranje i praćenje napretka na projektu. Da, raznorazni softveri za Kanban i slične vizualizacije odlična su stvar – jednom kad znaš što radiš. Ako počinješ s nečim novim, uzmi bijelu ploču od dva metra, gomilu post-ita i navali. Ovako ne samo da će svi članovi tima imati oko čega stajati tijekom dnevnih druženja, već će i drugi kolege vidjeti šareni zid i početi se zanimati što se događa. A osmoza je moćna sila.

Tagovi:
Povratak