Prethodnog mjeseca sam imala priliku da prisustvujem jednoj od najvećih Agilnih i IT konferencija u regionu, 3-oj Serbia Agile Konferenciji koja je održana 27. Aprila u Beogradu.

Najvažnije teme na konferenciji za ovu godinu su bile Agilne metodologije, liderstvo i razvoj softvera. Prilikom registracije se mogla prepoznati veličina konferencije po pitanju broja učesnika, tako da je zbog premalog vremenskog slota za registraciju Uvodno predavanje kasnilo 30 minuta, iako se svi učesnici nisu uspjeli registrovati do tada (produžena je mogućnost registracije za vrijeme pauze). Konferencija je otvorena prezentacijom "Zašto su u 21. vijeku liderstvo i agilnost blisko povezani" Boba Hartmana (poznatijeg kao Agile Bob) – člana Scrum Alliance odbora. U svom predavanju Bob je govorio o menadžmentu i liderstvu, objašnjavajući značaj liderstva ispred menadžmenta i skrenuo pažnju da bi ne samo timovi, nego i kompletne organizacije trebale biti Agilne.

Opširnije: Moje impresije sa treće Agile Serbia konferencije

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.

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

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.

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

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.

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

 

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 ...". 

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

Prethodni događaji

Naše usluge

Kontaktirajte nas

Bosnia Agile
Milana Preloga 12, Sarajevo 71000
Bosna i Hercegovina

Ova e-maila adresa je zaštićena od spambotova. Omogućite JavaScript da biste je vidjeli.
www.agile.ba

spbutoto spbutoto spbutoto spbutoto spbutoto spbutoto spbutoto spbutoto spbutoto spbutoto spbutoto spbutoto spbutoto spbutoto spbutoto spbutoto spbutoto spbutoto spbutoto spbutoto spbutoto spbutoto spbutoto spbutoto spbutoto 10 situs togel terpercaya bo togel terpercaya 5 bandar bo togel terpercaya bo togel terpercaya bo togel terpercaya 10 situs togel terpercaya