– Backlog refinement i Sprint planiranje  –

Tokom mnogobrojnih retrospektiva, sa različitim timovima, u različitim firmama i okruženjima, često sam čula od developer-a: treba nam više refinement-a, bolja priprema za sprint, story nije bio spreman… Ovo me je navelo da razmislim o temi iz naslova. O tome, kakav uticaj priprema za sprint ima na implementaciju i na koje problematične situacije možemo da utičemo i kako da ih izbegnemo.

Za ovaj tekst bih htela da napravim sledeću podelu: Na jednoj strani se nalaze refinement i sprint planiranje, kroz koje se definiše šta treba da se uradi u sprintu i kako će posao biti urađen. Dok se na drugoj strani nalazi implementacija. Iako je po definiciji planiranje na samom početku sprinta, a refinement je deo nekog od prethodnih sprintova, mislim da su ova dva sastanka usko povezana i ovom podelom možemo jasno da vidimo uticaj refinement-a i planiranja na implementaciju.

Pre nego što krenemo u analizu sastanaka i njihovog uticaja na implementaciju, podsetimo se definicija. Refinement obuhvata rad na zahtevima. Lider sastanka je product owner koji ima zadatak da predstavi novi scope developer-ima, kroz nove  story-je i razjašnjavanje zahteva. Sledeći korak je rad celog tima na dodavanju detalja ili novih acceptance criteria, podelu velikih story-ja i na kraju estimiranje. Sprint planiranje po definiciji ima za cilj definisanje sprint backlog-a na osnovu prioriteta story-ja. Tokom planiranja developer-i sa product owner-om dodaju u sprint story-je koji u tom momentu donose najveću biznis vrednost, i diskutuju kako odabrani story-ji mogu biti implementirani. Na kraju sastanka tim je spreman da počne sa implementacijom.

Koje benefite možemo imati od dobre pripreme? Refinement i planiranje nam služe za pripremu backlog-a i tima za naredni sprint. Sa jedne strane tim mora biti upoznat sa poslom koji dolazi u narednim sprintovima. Sa druge strane product owner mora da radi na backlog-u zajedno sa ostalim članovima tima kako bi pojasnio zahteve, odgovorio na pitanja i dileme developer-a. Na ovaj način story-ji postaju bolje definisani i jasniji timu.

Još jedan bitan element pripreme je taj da developer-i mogu da ukažu na tehničku stranu nove funkcionalnosti, što može imati direktan uticaj na život story-ja. Pa tako, story može biti podeljen, novi story-ji mogu biti dodati, spike-ovi ili tehnički zadaci mogu biti kreirani ukoliko postoji dosta nejasnoća.

Šta se dešava kada nemamo dobru kolaboraciju i pripremu za sprint? Koliko često se dođe u situaciju u toku implementacije, ili još gore na samom kraju, da product owner ili kolega daju sugestiju da bi nešto trebalo izmeniti ili da je zaboravljen neki acceptance criteria. Samo da pojasnim, naravno da nije moguće uvek unapred sve toliko isplanirati da u toku sprinta nemamo nikakvih izmena. Baš zato je product owner deo tima, jer je time rad na zahtevima konstantan, i developer-i uvek mogu da provere razumevanje i da li su razvili baš ono što se zahtevalo. Kroz ovaj tekst htela bih da ukažem na neke tipične situacije koje je moguće predvideti tokom pripreme.

Koje sve posledice možemo da imamo ukoliko se od nas traži izmena nakon urađenog posla? Može da dođe do konfliktne situacije i preprike šta je neki acceptance criteria podrazumeva i ko je u pravu. Ovo ima direktan uticati na odnose u timu i može da unese nesklad. Ukoliko se ova situacija ne sanira na vreme jaz izmedju product owner-a I developer-a će se sa vremenom povećavati. Iz ugla implementacije ovo takođe moze da predstavlja problem, ne zato što će nov kod biti dosta teži i kompleksiniji od trenutnog, već samo zato što je na početku sprinta definisan dizajn funkcionalnosti i sad bi trebalo da se vratimo u fazu planiranja i to izmenimo. Izmena dizajna može biti kompleksna i uticati na širi deo funkcionalnosti, ovo dalje može uticati da izrada funkcionalnosti traje duže. Neke od ovakvih situacija mozemo da izbegnemo sa malo više pažnje i posvećenosti tokom pripreme:

1. Nedovoljna pažnja prilikom čitanja i analiziranja acceptance criteria – ovim se lako može zaboraviti na neki detalj iz story-ja koji treba da bude implementiran.
2. Lična interpretacija pojedinca – ukoliko ne postavljamo pitanja product owner-u i ne diskutujemo sa developer-ima o story-ju, već prihvatimo acceptance criteria onakve kakvi su, kada započnemo implementaciju imaćemo ličnu interpretaciju istih, koja ne mora uvek da bude tačna.
3. Product owner želi da doda „malu“ izmenu u funkcionalnost jer jedan slučaj nije uočen pre nego što je story dodat u sprint. Neke od ovakvih slučajeva je moguće predvideti tokom pripreme kada se story sagleda iz različitih uglova i kada svi članovi tima zajedno diskutuju.

Zašto je važno odraditi dobru pripremu i kako ona može da olakša implementaciju? Pogledajmo kako teče proces pripreme za sprint i tokom implementacije. Prvi korak je analiza acceptance criteria, zatim provera razumevanja sa product owner-om i ostatkom tima. Nakon toga, ukoliko je story kompleksan, sledi dizajn sesija i zatim se prelazi na kodiranje. Što znači da postoji nekoliko faza i koraka. Vrlo je teško raditi sve to u paraleli – proveravati acceptance criteria, proveravati dizajn koji je definisan na početku i pisati kod. Iz ovih razloga se vidi zašto je važno biti koncentrisan tokom refinement-a i planiranja i iskoristiti vreme na sastancima za kvalitetnu pripremu. Tokom planiranja je sve moguće, mogu se iskonstruisati različiti scenariji, sagledati funkcionalnost iz različitih uglova, postaviti mnoga „šta ako“ pitanja. Dobra priprema će obezbediti da developer-i imaju celu sliku story-ja u glavi, što će dalje obezbediti lakši rad na funkcionalnosti i mogućnost sagledavanja uticaja na ostale delove koda. Naravno, ovo je idealna situacija, ali može se biti vrlo blizu te idealne situacije ukoliko su story-ji na kojima se radi mali i jasni. Iz tog razloga kolaboracija između developer-a i product owner-a  tokom refinement-a i planiranja mora da bude dobra.

Kako održati diskusiju aktivnom i efikasnom tokom pripremnih sastanaka? Refinement i planiranje su po definiciji sastanci. Šta se radi na (dobrim) sastancima – diskutuje, razmišlja, analizira, zaranja dublje u temu. Što znači da su kolaboracija, komunikacija, preispitivanje odluka, raspravljanje sa kvalitetnim argumentima veštine i alati koji su nam potrebni tokom sastanka. Diskusija mora da teče i sastanak mora imati svoj tok.

Bila sam na dosta refinement-a i planiranja, nekada su ljudi vrlo tihi, nema pitanja, sve izgleda jasno i sastanak se završi gotovo za 15 minuta. U drugim prilikama ljudi počnu previše da zalaze u detalje i neracionalno troše vreme sastanka. Takođe se mora voditi računa o različitim tipovima ličnosti koje su uključene u sastanak. Neki ljudi vole da se slože sa svim što drugi predlože, neki vole da se raspravljaju, neki su tihi, a drugi dominanti. Sve su ovo aspekti o kojima scrum master, kao fasilitator sastanka, mora da vodi računa i da pokuša da isprati dinamiku tima i usmeri diskusiju. Ono što još može da pomogne je da sami članovi tima preuzmu odgovornost za neke od situacija koje mogu da se dese tokom sastanka. Ukoliko tim za kratko vreme završi planiranje jedan član tima može da preispita odluku i razumevanje story-ja. Da proveri da li je zaista sve jasno, da li su nove zahteve sagledali iz više različitih ugova. Ako diskusija ode previše daleko i ne vodi donošenju odluke, drugi član tima može da preuzme odgovornost i da prekine bespotrebnu raspravu i vrati sastanak na pravi put. Na ovaj način tim korak po korak postaje nezavistan od scrum master-a i samoorganizovan tokom planiranja.

Za kraj bih rekla da je odgovornost za uspešnost sastanka na svim učesnicima. Zajednički rad developer-a, product owner-a i scrum master-a će obezbediti da refinement i planiranje budu kvalitetni i da svi uđu spremi u sledeći sprint.