Detalji

Poslovni ljudi i razvojni inženjeri moraju svakodnevno zajedno raditi, 

tokom cjelokupnog trajanja projekta.

Jedno od dvanaest načela agilnog razvoja softvera kaže da uspjeh projekta zavisi od aktivne dnevne saradnje tima klijenta i razvojnog tima softverske kompanije. Obje strane su tu sa zadatkom da kreiraju pravu vrijednost za klijenta. Kada već ulažemo napor u razvoj nekog softverskog proizvoda, hajde da razvijemo pravu stvar. Da bi ovo postigli, dužnost klijenta i razvojne kompanije je da sarađuju na dnevnoj osnovi. Tako će klijent u toj dnevnoj komunikaciji kontinuirano objašnjavati svoja očekivanja u pogledu poslovne vrijednosti proizvoda, kao i svake pojedinačne funkcionalnosti. Njegov zadatak je da održava jasnom poslovnu viziju odnosno svrhu razvoja tog proizvoda. Zato klijent mora biti dostupan da odgovori na svako pitanje zašto se razvija to što se razvija i da pruži dovoljno detalja razvojnom timu – kako bi tim mogao promisliti opcije, prodiskutovati ih sa klijentom i potom pristupiti razvoju opcije koju timovi procjene optimalnom.

Klikova: 9264

Opširnije: Od dokumentacije preko konverzacije do postizanja vrijednosti softverskog proizvoda

Detalji

Projekat razvoja softverskog proizvoda ima četiri dimenzije: novac, vrijeme, funkcionalnosti i kvalitet. Ako su novac i vrijeme fiksirani, a kvalitet proizvoda ne želimo dovesti u pitanje, onda se moramo dogovarati oko - funkcionalnosti. U nastavku prezentiram jedan takav pristup.

Mnogi klijenti žele IT proizvode sa fiksnim budžetom i unaprijed utvrđenim krajnjim rokom za realizaciju. U idealnom slučaju, dosljedna primjena agilnog pristupa razvoju softvera bi optimizirala radni proces i učinila transparentnom vrijednost koju klijent dobija za uloženi novac; pa tačno poznavanje budžeta i vremenskog okvira unaprijed ne bi bilo nužno da se i klijent i softverska kompanija osjećaju sigurno. Međutim, takav poslovni aranžman sa otvorenim budžetom i vremenskim okvirom često nije ostvariv:  nekada nedostaju znanja i vještine agilnog upravljanja projektima i agilnog pristupa razvoju softvera na strani klijenta ili softverske kompanije ili na obje strane; vrlo često klijent želi da zna cijenu softverskog proizvoda unaprijed jer ne prepoznaje razliku između kupovine usluge razvoja informacionog sistema i kupovine neke robe (npr. računara); a neki klijenti poput organa uprave, javnih preduzeća i javnih ustanova primjenjuju zakonske propise iz oblasti javnih nabavki gdje najniža cijena tehnički zadovoljavajuće ponude odnosno cijena kao podkriterij ekonomski najpovoljnije ponude mora biti fiksna. Ako se u toku razvoja proizvoda otkrije potreba za novim funkcionalnostima, pa time i povećanjem cijene, ovi propisi ne dozvoljavaju pravljenje aneksa (dodataka) osnovnog ugovora već se mora provesti novi postupak nabavke. Privatne korporacije i međunarodne organizacije imaju vlastite propise o nabavkama u kojima je na sličan način riješeno pitanje cijene ugovora.

Dakle, u velikom broju slučajeva, fiksni budžet za razvoj softverskog sistema je datost. To ipak ne znači da u ovom slučaju ne možemo prakticirati agilni pristup razvoju softverskih proizvoda.

Klikova: 11309

Opširnije: Prioretizacija korisničkih zahtjeva za agilne projekte sa fiksnom cijenom

Detalji

Scrum vodič kaže da je "Product Owner jedna osoba, a ne komisija". Moje razumijevanje ovog pravila je da su autori Scrum-a željeli osigurati takvo projektno okruženje gdje razvojni tim ima jedan izvor znanja o problemu koji treba da riješi. Ne bi trebalo da imamo komisiju (komitet, projektni tim) u ulozi Product Owner-a jer bi to onda moglo voditi do konflikata interesa i razlika u mišljenjima članova tog tima. Vjerovatno bi takvoj komisiji bilo potrebno više vremena da postigne koncenzus, a ako su razlike u mišljenju velike, mogli bi početi praviti kompromise u donošenju odluka vezanih za softverski proizvod, a pravljenje kompromisa oko karakteristika (features) softvera nije način da se postigne optimalna  vrijednost krajnjeg proizvoda (što je po Scrum-u osnovni zadatak Product Owner-a). Moguće je da bi različiti članovi te komisije počeli nezavisno pristupati programerima sa svojim zahtjevima, što bi vodilo u novi krug nerazumijevanja i gubitaka vremena i napora razvojnog tima. Zvuči jako razumljivo da je potrebno imati samo jednog lidera proizvoda.

Klikova: 10183

Opširnije: Treba biti samo jedan Product Owner (Tim)

Detalji

Mnogi tradicionalni projekti počinju sa Software Requirements Specification (SRS) dokumentom. Onda se u nekom momentu implementacije projekta donese odluka o primjeni agilnog pristupa. Postavlja se prirodno pitanje: Da li SRS dokument može služiti kao product backlog agilnog projekta? Razmišljanja nekih timova idu tako daleko da bi kompletan SRS dokument pretvorili u product backlog sa korisničkim pričama (user stories). Hajde da razmotrimo da li je to potrebno.

Prije nego se posvetim odgovoru na ovo pitanje, želim pojasniti šta ja podrazumjevam pod specifikacijom zahtjeva software-a odnosno SRS-om. Uvidio sam da ovaj tip dokumenta izrazito varira u sadržaju i formatu od kompanije do kompanije. Ipak, generalno pod ovim podrazumjevam dokument pun izjava tipa "Sistem treba...".

Ovdje možete zamisliti bilo koju vrstu tradicionalnog dokumenta sa zahtjevima i moji savjeti bi trebali biti primjenjivi. Ovo se posebno odnosi na bilo koji dokument sa pobrojanim, ugniježdenim zahtjevima, bez obzira da li je svaki zahtjev zaista počinje sa "Sistem treba ...". 

Klikova: 18364

Opširnije: Da li tradicionalni SRS dokument treba pretvarati u format korisničkih priča?