Od dokumentacije preko konverzacije do postizanja vrijednosti softverskog proizvoda
- Detalji
- Klikova: 9624
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.
Programeri nisu konobari
Dužnost razvojnog tima je da prije svega shvati svrhu razvoja neke funkcionalnosti. Kada razvojni tim treba da pristupi razvoju, prvo pitanje koje trebaju sebi postaviti je "Da li postoji očigledan razlog zašto je ova funkcionalnost potrebna klijentu?", pri čemu odgovor "zato što je klijent rekao da to treba tako uraditi" nije prihvatljiv.
Iako se iz perspektive uslužnosti, opcija „Samo recite, mi ćemo sve napraviti kako vi želite.“ čini atraktivnom, razvojni tim softverske kompanije se ne smije staviti u ulogu tima konobara koji su tu da spremno preuzmu i izvrše narudžbu klijenta, jer to jednostavno nije u njegovom najboljem interesu. U najboljem je interesu klijenta da razvojni tim razumije zašto je određena funkcionalnost potrebna. Da postavlja pitanja i dovodi u pitanje tvrdnje i zahtjeve klijenta. Ako nakon razumjevanja konteksta, niko od članova razvojnog tima ne vidi očigledan razlog zašto klijent traži određenu funkcionalnost, onda to treba reći klijentu. Možda će mu to pomoći da razumije da postoji i drugi, eksterni pogled na istu stvar. Možda će takvo sagledavanje stvari pomoći klijentu da reevaluira prioritet te funkcionalnosti, da je više ili manje izmjeni ili će se otkriti prilika za postizanje neke nove vrijednosti. Kroz ovakvu konverzaciju klijent treba osigurati dovoljno detalja da razvojni tim razumije svrhu, razvije opcije za tu potrebu, a zatim će timovi utvrditi koja je od opcija optimalna, vodeći se pri tome principom jednostavnosti (odnosno maksimiziranja posla koji nije potrebno uraditi) i tek poslije toga će pristupiti samom razvoju.
Dakle, uloga razvojnog tima nije uloga konobara koji primaju narudžbu klijenta već ko-kreatora (vrijednosti) softverskog proizvoda.
Važnost konverzacije
Nemoguće je postići uzajamno razumijevanje i uspostaviti model ko-kreacije softverskog proizvoda od strane klijenta i razvojnog tima softverske kompanije, koje bi bilo bazirano samo na SRS (Software Requirements Specification) dokumentu. Bez obzira koliko je taj dokument opsežan i koliko detalja je klijent naveo, on ne može biti dostatan za razvoj kvalitetnog softverskog proizvoda, jer je jednostavno nemoguće sve unaprijed osmisliti. Pored eventualnih promjena poslovnog konteksta (promjena pravila, zakona, uslova na tržištu i sl.), promjena će se najčešće desiti kao posljedica unaprijeđenog razumjevanja stvarne potrebe klijenta. To unaprijeđenje razumjevanja stvarne potrebe desiće se svaki put kada se o tome razgovara unutar tima klijenta, zatim kada klijent o tome razgovara sa razvojnim timom, bira opcije i na kraju, kada je u prilici da revidira razvijenu funkcionalnost. Zato mi klijenti ne treba da radimo veliki dizajn unaprijed (tkzv. BDUF – Big Design Up Front), već radije da pravimo opsežnu viziju proizvoda na višem nivou apstrakcije. Jednostavnije rečeno, želimo obuhvatiti sve inicijalno očekivane funkcionalnosti, sa objašnjenjem kom korisniku su potrebni i koja je njihova svrha (odgovor na pitanje zašto?), sa utvrđenim prioritetom, ali sa ograničenim brojem detalja odnosno kriterija prihvatljivosti, jer o detaljima želimo razgovarati onda kada budemo imali više znanja. [Koristim riječi "opsežna" vizija i "sve" inicijalno očekivane funkcionalnosti jer projekti razvoja softverskog proizvoda sa fiksnim budžetom, a to su projekti u kojima ja učestvujem, moraju imati čvrst temelj. Plan mora biti jako dobro promišljen i opsežan, kako bi se smanjile neizvjesnosti i nejasnoće kod softverske kompanije koja mora izaći sa ponudom sa fiksnom cijenom.]
Kartica – Konverzacija – Konfirmacija
Ako slijede principe agilnog razvoja softvera, osnovni zadatak klijenta i razvojnog tima vezan za korisničke zahtjeve odnosno potrebe, nije više njihova dokumentacija već razmjena mišljenja, ideja i opcija odnosno konverzacija. Njihova formalna manifestacija u vidu korisničkih priča (user stories) ima tri kritična aspekta koja je opisao Ron Jeffries, a to su Kartica, Konverzacija i Konfirmacija. Ukratko, Kartica znači da korisnički zahtjev treba biti opisan sa toliko detalja koliko može stati na jedan post-it note papir, dakle, kratko, sa jednom rečenicom koja ga identificira i služi kao podsjetnik da o toj potrebi odnosno budućoj funkcionalnosti trebamo razgovarati. Konverzacija je alat kojom se postiže unaprijeđenje razumjevanja stvarne potrebe klijenta a time i mogućnost specifikacije zahtjeva. Kroz razmjenu ideja i mišljenja utvrđuje se opcija koja ima najveću vrijednost za klijenta. Ona je manifestirana u tkzv. kriterijima prihvatljivosti korisničke priče. Na kraju dolazi Konfirmacija odnosno prilika za pregled ispunjenja kriterija prihvatljivosti i davanje feedback-a na razvijenu funkcionalnost, čime se zaokružuje proces identifikacije potrebe i realizacije funkcionalnosti koja zadovoljava tu potrebu na najbolji način.
Šta vi mislite?
Šta ovdje nedostaje ili je pogrešno ili dobro? Koji su izazovi sa kojima ste se vi susretali u komunikaciji sa članovima razvojnog tima odnosno predstavnicima klijenta? Koji način komunikacije se pokazao posebno uspješnim u vašem slučaju? Molim da podijelite svoja razmišljanja i komentare ovdje ili na pripadajućem LinkedIn postu.
