Izmena zahteva u projektima kojima se upravlja u skladu sa SCRUM agilnom metodologijom

Postojeća literatura koja se bavi SCRUM agilnom metodologijom obično obrađuje idealizovan SCRUM proces razvoja softverskih rešenja u kome nisu jasno definisane aktivnosti i procesi koji su neophodni da bi se uspešno odgovorilo na izmene zahteva koje naručioc posla može da traži za vreme trajanja razvojnog projekta. Zbog toga se javlja potreba za definisanjem modifikovanog SCRUM procesa koji bi uključio i neophodne aktivnosti koje će omogućiti realizatoru projekta da uspešno odgovori na zahteve za izmenama (funkcionalnim i nefunkcionalnim) od strane naručioca posla.

Napomena: Na osnovu teksta koji sledi napisan je rad:

  • Milanov, G., Njeguš, A. (2012) “Upravljanje izmenama zahteva u skladu sa modifikovanim Scrum procesom”, 20. Telekomunikacioni forum TELFOR, Beograd, Dostupno na:Telfor2012-SCRUM Izmena zahteva

Uvod

Kao jedna od ključnih prednosti agilnih metodologija u odnosu na tradicionalne se u literaturi vrlo često pominje mogućnost izmene zahteva naručioca konkretnog softverskog rešenja u toku projekta tj. u periodu kad softverski tim već razvija konkretan softverski proizvod. Teorija SCRUM-a, predstavnika agilnih metodologija, predviđa mogućnost izmene zahteva između sprint-eva u kojima SCRUM tim radi na realizaciji određenog skupa funkcionalnosti konkretnog softverskog rešenja. Ipak problematika izmene zahteva za vreme trajanja projekta nije jednostavna i može mnogostruko uticati na dinamiku realizacije projekta, finansijske aspekte projekta i samim tim i na uspešnost projekta. Izmene zahteva (funkcionalnih i nefunkcionalnih) za vreme trajanja projekta posledično utiču na cenu projekta i kvalitet proizvoda. Zbog toga je veoma bitan proces ugovaranja projekta i model ugovora koji treba da omogućiti izmene zahteva na projektu u toku njegove realizacije. Takođe je veoma bitno da metodologija kojom se upravlja konkretnim projektom bude dovoljno plastična i da omogućava prilagođavanje izmenama koje su posledica izmene zahteva na projektu u toku procesa razvoja softverskog rešenja.

Cena proizvoda

Cena razvoja nekog softverskog rešenja sa definisanim skupom funkcionalnosti se, uopšteno govoreći, formira na osnovu angažovanih resursa i vremena njihovog angažovanja. Odnos varijabli projekta resursi, vreme realizacije ili zahtevane funkcionalnosti, može se prikazati trouglom (slika 1) koji se obično naziva čelični trougao (Iron Triangle). Ako se jedna od varijabli promeni, mora se promeniti jedna ili obe preostale varijable da bi se sačuvao njihov odnos u trouglu.

Čelični trougao

Slika 1. Čelični Trougao

U praksi, bez obzira na metodologiju kojom se upravlja projektom razvoja softverskog rešenja, obično su resursi, koji će biti angažovani na projektu, fiksirani tj. zna se koji će ljudi i koliko vremena će biti angažovani na konkretnom projektu. Kad je SCRUM u pitanju, pre svakog sprinta, na osnovu prioriteta stavki Product Backlog-a i na osnovu broja težinskih poena koje konkretan tim može da realizuje u jednom sprint-u, SCRUM tim sastavlja Sprint Backlog. Resursi na konkretnom sprint-u su fiksirani i ne menjaju se za vreme trajanja sprinta. Na osnovu stavki Sprint Backlog-a za konkretni sprint definiše se i vreme trajanja sprint-a (od 7 do 30 dana).

Drugačije rečeno, na projektima za razvoj softverskih rešenja kojima se upravlja u skladu sa SCRUM-om resursi su fiksirani, vreme trajanja projekta može biti izabrano i zahtevane funkcionalnosti je moguće menjati pre sprint-a kreiranjem Sprint Backlog-a. Ovo je možda očiglednije ako se prikaže Trade-off matricom (tabela 1).

Trade Off Matrix

Tabela 1. Trade-off matrix

Na osnovu izloženog, može se zaključiti da izmene zahteva direktno utiču na promenu planiranu cenu projekta zato što izmene funkcionalnosti zahtevaju izmene u vremenu trajanja projekta i izmene u planiranim resursima na projektu.

Kvalitet proizvoda

Kvalitet proizvoda i kontrolisanje kvaliteta proizvoda podrazumeva definisane metrike kvaliteta i načine njihovog merenja. Metrike kvaliteta nastaju na osnovu: zahteva internih ili eksternih standarda ili na osnovu zahteva klijenta za određenim kvalitetom proizvoda.

Kvalitet proizvoda je nešto što može da se definiše zahtevima naručioca ili ponudom potencijalnog realizatora posla što, naravno, može da utiče na cenu proizvoda. Naručilac posla ima pravo da striktno zahteva određeni kvalitet proizvoda u skladu sa definisanim metrikama kvaliteta i procedurama za kontrolisanje kvaliteta proizvoda. U tom smislu naručilac posla može da angažuje i treću firmu koja će kontrolisati i pratiti kvalitet proizvoda.

S druge strane, isporučivanje nekvalitetnog proizvoda od strane realizatora, dovodi do probijanja rokova, inicijalnog povećanja troškova, povećanja troškova održavanja, nezadovoljstva klijenta, negativnog marketinga itd… Zbog svega toga profesionalni realizator softverskog rešenja neće dozvoliti sebi da isporuči nekvalitetan proizvod koji ne ispunjava sve što je klijent zahtevao ali i sve ono što klijent nije zahtevao, ali je realizator u fazi ugovaranja posla prepoznao kao nešto što može da umanji kvalitet proizvoda.

Kvalitet proizvoda, koji se isporučuje, ne treba da zavisi od izabrane metodologije. Nekvalitetan proizvod nije opcija jer samo kvalitetan proizvod dovodi do zadovoljnog klijenta.

Sa kvalitetom softverskog proizvoda je direktno povezano testiranje. Kad je SCRUM u pitanju testiranje sprovode članovi SCRUM razvojnog tima tj. iste osobe koje i kodiraju. Ovo stanovište je u praksi, pogotovu kad su obimniji projekti u pitanju, nerealno pošto testiranje podrazumeva specifičnu organizaciju i dokumentaciju, određene alate i tehnologije i specifična znanja i veštine, a moglo bi se reći i specifičan mentalni sklop, od ljudi koji sprovode testiranje. Dobro definisano i sprovođeno testiranje i dobro definisan i sprovođen Bug tracking, od strane nezavisnog tima, je praksom potvrđena neophodnost i neminovnost.

Ugovaranje razvojnih projekata

Suština problematike izmene zahteva u toku projekta nije u pitanju da li razvojni tim može da prihvati i realizuje nove ili izmenjene zahteve već u ugovaranju između naručioca posla i realizatora tj. dokumentu ugovora na osnovu koga se konkretan projekat realizuje. Ugovor između najmanje dve zainteresovane strane se potpisuje na početku projekta. Bilo da se radi o ugovoru između dve firme ili o nekoj vrsti internog ugovaranja, unutar jedne firme, vrlo je bitno da realizacijom ugovora sve ugovorne strane budu zadovoljne.

U agilnom manifestu (K. Beck et al., 2001) njegovi autori kažu da više vrednuju “Saradnju sa klijentima od ugovornih aranžmana”. Poenta je ipak u tome da firma koja razvija i prodaje softverska rešenja mora da naplati svoj rad da bi mogla da plati svoje zaposlene i dođe do profita. Da bi to bilo moguće, o kakvom god modelu ponude i kupovine da se radi, mora da postoji neka vrsta ugovora između proizvođača softvera (razvojnog tima) i klijenta odnosno kupca softvera. Ugovor mora da definiše prava i obaveze obe ugovorne strane i mora da bude finansijski odgovarajući i za jednu i za drugu ugovornu stranu. Naravno da klijent mora da bude zadovoljan ali i proizvođač softvera ne sme da bude na gubitku tj. mora da ostvari određeni profit prodajom konkretnog softverskog rešenja.

Idealan slučaj procesa ugovaranja projekta razvoja softverskog proizvoda između naručioca i izvođača predviđa sledeće aktivnosti:

  • Naručilac posla (klijent) može na osnovu prepoznatih  internih poslovnih potreba ili na osnovu svog ispitivanja tržišta da se odluči da nabavi softverski proizvod tačno definisanih funkcionalnosti,
  • Pošto su zahtevi za funkcionalnostima softverskog proizvoda poznati,  firma realizator razvoja softverskog rešenja može okvirno da planira svoje troškove i potrebne resurse u planiranom periodu i samim tim može da definiše ugovor na osnovu koga klijent može da planira svoj budžet i da zna kad će dobiti naručeni softverski proizvod sa ugovorenim funkcionalnostima,
  • Normalna poslovna praksa je da se ponuda sa finalnom cenom realizacije i vreme isporuke konkretnog softverskog proizvoda definiše posle analize zahteva tj. posle procene od strane proizvođača koji resursi u kom vremenskom periodu će biti angažovani da bi se realizovao konkretan projekat i da se tek tad potpisuje ugovor između naručioca i izvođača,
  • Posle faze analize, naručilac posla može i da odustane od projekta i da firmi, proizvođaču softverskih rešenja, plati angažovanje u fazi analize. Naravno naručilac posla dobija dokumentaciju koja je nastala u fazi analize i može je koristiti da eventualno angažuje drugu firmu koja će realizovati projekat,
  • Nakon definisanja zahteva i potpisivanja ugovora sa proizvođačem, naručilac posla može da zna tačan datum dobijanja softverskog proizvoda na osnovu čega može da planira svoje interne poslovne promene ili svoj nastup na tržištu.

U praksi su ipak idealni slučajevi veoma retki. Uzroci zbog kojih obično dolazi do problema na projektima razvoja softverskih rešenja su (razmatran je uzorak od 5 projekata na kojima su nastali problemi zbog izmene zahteva):

  • Svaki kupac se trudi da proizvod kupi jeftinije a svi prodavci žele da prodaju proizvod po najvišoj mogućoj ceni. Takvi stavovi obično za posledicu imaju ugovaranje na štetu jedne od ugovornih strana,
  • Naručioc posla ne zna unapred sve funkcionalnosti koje treba da ima željeni proizvod a traži od potencijalnog realizatora projekta da definiše ponudu sa fiksnom cenom i fiksnim vremenom realizacije. Ugovori koji se na osnovu toga sklapaju obično se realizuju na štetu realizatora projekta,
  • Naručioc posla tek kad bude video gotov interfejs (posle nekog sprint-a) i na primeru korišćenja nekih funkcionalnosti bude stekao stekao utisak o softverskom proizvodu, dobija ideje o mogućim dodatnim funkcionalnostima softverskog proizvoda. Posledica su obično enormno velik broj zahteva za izmenama i doradama funkcionalnosti i ako ti slučajevi nisu prethodno predviđeni ugovorom obično za posledicu imaju nezadovoljne i naručioca posla i realizatora posla,
  • Viši menadžment naručioca posla se obično uključuje u projekat tek kad bude realizovano više od 80% projekta i tek onda počinje da daje primedbe i ideje svojim podređenima koji te primedbe i ideje pokušavaju da realizuju istim projektom po istoj ceni. Posledica su obično enormno velik broj zahteva za izmenama i doradama funkcionalnosti i ako ti slučajevi nisu prethodno predviđeni ugovorom obično za posledicu imaju nezadovoljne i naručioca posla i realizatora posla,
  • Kupac obično ne razume arhitekturu sistema i ne zanima ga da li svojim zahtevima pri kraju projekta remeti projektovanu arhitekturu softverskog sistema i samim tim direktno utiče na smanjenje kvaliteta softverskog proizvoda. Posledica je obično nekvalitetan proizvod i nezadovoljan kupac,
  • Kupac nema pravu meru uticaja zahtevanih izmena na cenu proizvoda. Kad realizator posla definiše cenu izmena kupac smatra da realizator želi da ga pokrade. Ovakvi slučajevi vrlo često dovode do nezadovoljnog kupca čak i u slučajevima kada je ugovorom predviđeno na koji način će se realizovati imene zateva u toku realizacije proizvoda,

Iako se obično podrazumeva da je za uspešnost projekta bitno da naručioc i izvođač projekta imaju poverenje u poštenje, stabilnost i predvidivost rutina i procesa kompanije sa kojom posluju na konkretnom projektu (Mary Poppendieck, 2006), ipak je takvo poverenje veoma teško razviti i za njega je potrebno iskustvo stečeno u višegodišnjoj poslovnoj saradnji dva konkretna poslovna sistema. Bez obzira na poverenje, veoma je bitno da se ugovorom predvide sve situacije koje mogu nastati na konkretnom projektu.

Tipovi ugovora mogu biti različiti (Peter Stevens, 2009) ali se može reći da su uopšteno rečeno u praksi najčešći sledeći modeli ugovora:

  • Ugovori sa definisanom fiksnom cenom projekta,
  • Ugovori sa definisanom fiksnom cenom koji podrazumevaju proširivanje ugovora aneksima ugovora ako se u toku projekta javi potreba za time,
  • Ugovori koji nemaju fiksnu cenu već se cena ugovara za svaki sprint,
  • Ugovori koji se dobijaju na tenderima,
  • Interni ugovori.

Ugovori sa definisanom fiksnom cenom

Sam pojam fiksne cene projekta može da znači i to da nema izmena na projektu u toku razvoja, ali je nerealno to očekivati. Zahteva za izmenama će sigurno biti. Neki od mogućih razloga su:

  • U procesu ugovaranja nije bio dovoljno uključen neki viši menadžer koji će uključivši se u projekat zahtevati izmene prema svojim idejama,
  • Promenili su se uslovi na tržištu i naručioc posla zahteva izmenu funkcionalnocti,

Pošto je cena projekta fiksirana ugovorom onda će se morati raditi zamena nekih ranije zahtevanih funkcionalnosti novim funkcionalnostima. Problem koji se javlja u takvim slučajevima je kako proceniti cenu novih funkcionalnosti u odnosu na stare koje će biti izuzete iz projekta. Najsvrsishodnije je da se u takvim slučajevima dogovorom između Product Owner-a kao zastupnika izvođača i ovlašćenog predstavnika naručioca posla (Client Representative), pre konkretnog sprinta u kome izmene treba da budu realizovanje, dogovore izmene i sastavi zvanični zapisnik koji će potpisati obe ugovorne strane. Ako njih dvojica ne mogu da se dogovore onda se problem rešava u proširenom sastavu gde konkretnom sastanku treba da prisustvuje i menadžer prodaje izvršioca i neko od odgovornog menadžmenta naručioca posla. Treba imati u vidu da problem treba da se rešava u što kraćem roku tj. u najviše par sastanaka jer svako odlaganje sprinta dovodi do gubitka novca tj. povećava cenu projekta a pošto se radi o ugovoru sa fiksnom cenom projekta na gubitku bi bio samo izvođač posla.

Ugovori sa definisanom fiksnom cenom i podrazumevanim aneksima ugovora

Ovakvi tipovi ugovaranja podrazumevaju veću dozu razmevanja procesa razvoja softverskih proizvoda i od naručioca posla i stav obe ugovorne strane da se želi da se projekat realizuje na zadovoljstvo obe ugovorne strane. To znači da je naručioc posla unapred svestan da zahteva za izmenama funkcionalnosti mora biti u toku projekta i da je spreman da realno sagleda eventualne dodatne troškove projekta i da ih plati kroz definisanje aneksa ugovora. Aneks ugovora se najčešće definiše komunikacijom Product Owner-a, Client Representative, menadžera prodaje realizatora i odgovornog mamadženta naručioca posla. U ovakvim slučajevima nesuglasice obe ugovorne strane oko toga šta i koliko treba da se plati su retke i veoma se brzo rešavaju pošto u njihovom rešavanju učestvuju osobe koje definišu aneks ugovora. Ovakvi ugovori ne isključuju zamenu nekih ranije zahtevanih funkcionalnostima novima ako se za to odluči naručioc projekta.

Ugovori koji nemaju fiksnu cenu već se cena ugovara pre svakog sprint-a

U ovakvim tipovima ugovaranja obe ugovorne strane potpisuju ugovor o nameri učešća u projektu realizacije konkretnog softverskog sistema ali ugovor ne sadrži definisanu cenu projekta. Na osnovu dokumenta analize izvođač posla je dao punudu naručiocu posla tako da su obe ugovorne strane svesne projektovane cene i vremena trajanja projekta. Pošto ugovor ne sadrži cenu projekta, pre svakog sprinta se na osnovu skupa funkcionalnosti koje treba da budu njime realizovane definiše ugovo ili aneks ugovora koji sadrži cenu realizacije konkretnog sprint-a. Aneksi ugovora se najčešće definišu komunikacijom Product Owner-a, Client Representative, menadžera prodaje realizatora i odgovornog mamadženta naručioca posla. Ovakvi ugovori obično u praksi daju najoptimalnije rezultate pošto se neophodne aktivnosti za definisanje aneksa ugovora mogu ugraditi u SCRUM proces.

Ugovori koji se dobijaju na tenderima

Ugovori koje firme, koje se bave razvojem softverskih proizvoda, dobijaju na tenderima su po svojoj prirodi ugovori sa definisanom fiksnom cenom. Uzroci mogućih problema na projektima koji razvojne firme dobijaju na tenderima mogu biti (razmatran je uzorak od osam projekata):

  • Na osnovu nepotpune tenderske dokumentacije obim posla ne može biti realno sagledan i samim tim ponuđena cena projeta i neophodno vreme za razvoj mogu biti podimenzionisani,
  • Nedovoljna detaljnost tenderske dokumentacije daje prostora naručiocu posla da zahteva izmenu i realizaciju funkcionalnosti za koje on smatra da su podrazumevane tenderskom dokumenatcijom a koje povećavaju cenu projekta,
  • Menadžer prodaje potencijalnog realizatora projekta kod davanja ponude na tenderu ne uzima u obzir mogućnost izmene zahtevanih funkcionalnosti u toku projekta sa ciljem davanja najniže ponude i dobijanja posla na konkretnom tenderu, i provizije koju obično menadžeri prodaje imaju od svakog potpisanog ugovora,
  • Projekti koji se dobijaju na tenderima ne predviđaju detaljnu analizu zahteva pre davanja ponude pa su samim tim izmene zahteva u toku projekta neizbežne. S druge strane ovakvi projekti predviđaju samo fiksnu cenu kod ugovaranja. Zbog toga svi dodatni troškovi koji nastaju zbog izmene i proširenja zahteva padaju na teret samo realizatora projekta.

Ovakva vrsta ugovaranja može da bude veoma finansijski nepovoljna po realizatora projekta pošto po definiciji sve rizike na projektu ugovorom prihvata realizator projekta. S druge strane naručioc posla može biti u mnogo boljem položaju pošto i u slučajevima veoma nepotpune tenderske dokumentacije realizatori projekta potpisuju ugovore verujući unapred da će se ipak moći dogovoriti sa naručiocem posla oko dodatnih troškova.

Interni ugovori

Kad su u pitanju razvojni timovi koji razvijaju rešenja za interno korišćenje u poslovnom sistemu u kome su zaposleni, oni se obično tretiraju kao servis osnovne delatnosti poslovnog sistema i njihovi troškovi se planiraju budžetom. To znači da je, u periodu za koji se planira budžet,  fiksirana veličina tima (resources), fiksirano je vreme (schedule), tako da je samo spisak funkcionalnosti, koje može da realizuje konkretan tim,  promenjivog karaktera.

Kad su interni razvojni projekti u pitanju bitno je da se konkretni projekat realizuje na zadovoljstvo korisnika ali takođe je bitno da se ne dođe u poziciju da se izmenama zahteva i zahtevima za doradama u okviru istog projekta blokira razvojni tim a samim tim i zahtevi drugih organizacionih delova istog poslovnog sistema. Zbog toga je neophodna neka vrsta internog ugovaranja po projektima gde se na osnovu prethodne analize definiše interna cena i vreme trajanja projekta. Vremenom trajanja projekta moraju da se predvide i zahtevi za izmenama funkcionalnosti. Ako zahtevi za izmenama funkcionalnosti premašuju predviđeno vreme trajanja projekta onda se sa daljim povećanjem vremena trajanja projekta a samim tim i povećanjem cene projekta mora da složi neki viši menadžment koji ima mogućnosti da sagleda i potrebe ostalih delova poslovnog sistema i preuzme odgovornost za produženje vremena trajanja projekta.

Modifikacija SCRUM procesa

Na osnovu izloženog se može zaključiti da SCRUM proces onako kako je definisan u teoriji (Ken Schwaber, 2007) ne može podržati procese koji se u praksi javljaju kao posledica izmena zahteva (funkcionalnih i nefunkcionalnih) na projektima razvoja softverskih proizvoda (slika 2).

Scrum process

Slika 2. Teorijski SCRUM proces

Da bi SCRUM proces odgovorio realim zahtevima prakse (obrađivan je uzorak od 6 uspešnih projekata), neophodno ga je modifikovati tako da podrži neophodne procese i aktivnosti koji prate obradu i realizaciju zahtevanih izmena. S jedne strane to su aktivnosti analize novih zahteva i posledica koje oni mogu da imaju na arhitekturu rešenja, sastav SCRUM tima, vreme trajanja projekta i cenu projekta. Sa druge strane neophodno je da SCRUM proces obuhvati i neophodne aktivnosti svih rola koje učestvuju u informisanju, dodatnom pregovaranju i eventualnom definisanju ugovora ili aneksa ugovora kojim će se definisati obaveze ugovornih strana da bi se zahtevane izmene realizovale. Pored toga što predstavnik klijenta može da traži i definiše nove zahteve i samom tim da utiče na definisanje stavki Product Backlog-a, veoma bitno je da on bude na dnevnom nivou upoznat sa statusom konkretnog sprint-a i realizovanim stavkama Sprint Backlog-a da bi eventualno mogao da prekine sprint ako to budu zahtevale izmene na zahtevima koje se planiraju (slika 3).

Modified Scrum process

Slika 3. Modifikovani SCRUM proces

Zaključak

Kad je SCRUM u pitanju, zahtevi za funkcionalnostima, mogu biti promenjeni na početku svakog sprint-a. Ako je potpisan ugovor sa fiksnom cenom, to može da predstavlja problem pošto obe ugovorne strane treba da procene kako izmene zahteva mogu da utiču na vreme završetka projekta i cenu projekta i da se saglase da će te izmene biti ili neće biti realizovane. To obično zahteva i reviziju dokumentacije koja definiše zahtevane funkcionalnosti. S druge strane, naručilac posla i izvođač mogu da se dogovore da potpisuju ugovor, ili aneks ugovora, posle faze analize na početku svakog sprint-a a u skladu sa planiranim budžetom projekta. Sve pomenute aktivosti oko realizacije izmene zahteva u toku projekta moraju biti predviđene SCRUM procesom tj. definisane nekom modifikacijom SCRUM procesa koja će odgovarati potrebama konkretnog razvojnog projekta. Stim u vezi SCRUM ne treba posmatrati kao metodologiju strogo zacrtanih aktivnosti već pre kao framework koji treba i može da odgovori svim zahtevima poslovanja.

Literatura:

Leave a Reply

%d bloggers like this: