Sprint je počeo, tim se okupio, Product Backlog je pun, energija i motivacija na zavidnom nivou.
Dva dana kasnije – potpuni haos. Bring it on!
Tiketi stoje, ne zna se šta je prioritet, QA tim već vidi katastrofu na horizontu, a developeri balansiraju između “ovo nije spremno” i “moramo da završimo sprint”.�

Been there, done that. Mnogo, mnogo puta.
Onaj osećaj kada je treći dan sprinta, a ti već znaš da nećete stići ni blizu onoga što ste zamislili?
Ili kad ti QA kasno u sprintu vrati 80% tiketa sa komentarom “ovo ne radi kako treba”? Classic. Melodrama.

Kako da sprečiš ovaj scenario?
Ključ je u jasnim ciljevima (malim, a značajnim), dobro pripremljenim zadacima i – šokantno – realnom kapacitetu tima.
U ovom blogu pričamo kako da sprint ne bude maraton bez cilja (ili još gore, maraton kroz močvaru sa preprekama), već jasna, iterativna pobeda za tim i proizvod.

Zašto sprintovi često postanu haotični?

Koristim reč “često” iz čiste pristojnosti. Zapravo, statistički gledano, više sprintova završi u haosu nego u redu. Ali to zvuči depresivno za blog post, pa ću ostati pri “često”.

Postoje tri glavna razloga zbog kojih sprintovi često izmaknu kontroli:

1.
Sprint backlog je prepun – tim preuzima previše posla jer niko nije hteo da bude “partybreaker”.
Zvuči poznato?
“Ma stižemo 100%, nemoj biti negativna…”

2.
Zadaci nisu dovoljno definisani – Definition of Ready ne postoji.
Ili još gore – postoji, ali se tretira kao ona sigurnosna uputstva u avionu koja svi ignorišu. “Ne smaraj više, znam šta treba da se uradi, samo mi daj tiket!”

3.
Nema jasnih kriterijuma kada je nešto završeno – Definition of Done je fleksibilan (ili ne postoji).
A kad kažem “fleksibilan”, mislim na to da je u rangu “to je više smernica nego pravilo”. Zbog toga je “gotovo” obično “gotovo osim testiranja, dokumentacije i 18 bagova”.

Četvrti razlog, možda i najvažniji, ali koji se obično šapuće samo uz kafu nakon sastanka i nikada ne dospeva u zvanične Scrum vodiče je – nekada prosto imate nezainteresovan tim. (Šokantno, znam. Ko bi rekao da ljudi nisu uvek 100% posvećeni sprint cilju?)�

Ne moraju uopšte biti nezainteresovani za proizvod, ali mogu biti demotivisani na neki od drugih načina: ne napreduju dovoljno brzo koliko bi želeli, smatraju da je njihov rad podcenjen i neprepoznat, imaju lične izazove sa nekim drugim članovima tima, ili neki od: “samo mi napiši šta hoćeš” – dobar tim ne može da funkcioniše na ovom principu; apsolutna nezainteresovanost za industriju, biznis, korisnike, a odlična ekspertiza, nedostatak biznis mindseta…�

Kada si i u ovakvoj situaciji, veruj mi, nije ti primarna stvar da dobro uradiš sprint planing. Dobar sprint planing je ishod dobre saradnje u timu, i tima sa ostatkom organizacije. Pa prvo počni od toga. Jer, iskreno, svi ti Scrum i Kanban boardovi i burndown chartovi sveta neće popraviti tim koji nije zainteresovan za ono što pravi. Ali će ukazati na to da nešto ne funkcioniše – use it wisely. Znam, nije najudobnije rešenje, ali je jedino koje stvarno radi.�

Ali, ne zaboravi, i tebi se može desiti da budeš demotivisan/a ili nezainteresovan/a iz istih, sličnih, ili potpuno drugačijih razloga. U tom slučaju, kontaktiraj me i razradićemo detaljno tvoj requirement. 😉

Pogledaj i: Kako izbeći beskorisne sprint ciljeve – jer bez jasnih ciljeva, sprint lako postaje samo niz zadataka koje niko ne povezuje sa većom slikom.

Kako sprint može biti efikasan i kontrolisan?

Čekaj, je l’ to uopšte moguće? Šalim se… malo.
Naravno da je moguće, samo je potrebno malo više discipline nego što većina timova želi da prizna.

1. Sprint Planning – Ključni trenutak za red, a ne haos

Sprint Planning nije samo sastanak gde se uzima što više zadataka iz backlog-a i dodaje u sprint, dok Product Owner ne počne nervozno da se vrpolji i preznojava. To je trenutak kada tim zajedno definiše šta je realno moguće završiti i šta donosi najveću vrednost korisnicima.

Da citiram jednog developera: “Dakle, dodaćemo sve ove tikete i još ove, i ove… hmm, valjda ćemo stići.” I onda ja odgovaram: “Ako se to desi, ja ću lično da vam kupim po kilogram ćevapa svima.“
Nikad nisam morala da kupim te ćevape, što je tužno iz više razloga.

– Kako izgleda loš Sprint Planning?

• Tim bira zadatke po osećaju, bez procene kapaciteta. “Osećam da možemo ovo da uradimo za dva dana.” (Da li je bitno da naglasim – nisu mogli.)
• Nema jasne definicije cilja sprinta, osim maglovitog “uraditi što više”.
• Ne proverava se da li su zadaci zaista spremni za rad. “Ma razumem ja šta treba, samo mi daj tiket.”

+Kako izgleda dobar Sprint Planning?

• Tim procenjuje realni kapacitet na osnovu istorijskih podataka (npr. velocity).
  I onda, zapanjujuće, planiramalo manje od toga.
• Koristi se Definition of Ready (DoR) – svaki zadatak ima jasne informacije, opis, dizajn, kriterijume prihvatljivosti. I da, svi su to zaista pročitali i razumeli.
• Postavlja se Sprint cilj – fokus nije na pojedinačnim zadacima, već na vrednosti koju sprint donosi. (Ne, “završiti sve tikete” nije cilj.)

2. Definition of Ready – Da li su zadaci uopšte spremni?

Sprint propada ako tim uzme zadatke koji nisu dovoljno definisani. To je kao da kreneš da kuvaš ručk, bez da znaš šta spremaš ili koje sastojke imaš. Definition of Ready je checklista koja osigurava da su zadaci spremni za razvoj.

Kako znati da je zadatak spreman?

• Postoji jasan opis problema i očekivanog rešenja. Ne samo “dodaj dugme”.
• Svi potrebni dizajni, API specifikacije i zavisnosti su rešeni.�
• Tim razume zadatak i nema neodgovorenih pitanja. Ili barem nemamnogo neodgovorenih pitanja.

–Loš primer: „Implementirati filter za pretragu proizvoda” – bez dodatnih informacija, ali sa visokim očekivanjima.

+Dobar primer: „Implementirati filter po ceni u pretrazi proizvoda. Korisnici mogu birati raspon cena, a rezultati se ažuriraju u realnom vremenu. Dizajn je priložen, API endpoint definisan. Testni slučajevi opisani. Skala za cene je od 0-10000 sa koracima od 1000. I tako dalje.”

# Pogledaj i:Kako da Backlog Refinement bude efikasan– jer sređen backlog znači manje haosa za sprint planning, ergo manje haosa u sprintu. Ko bi rekao da je prevencija bolja od lečenja?�

3. Definition of Done – Kada je nešto zaista završeno?

Nema ništa gore od toga “skoro gotovo” – kada se zadatak „završi”, ali nije testiran, nije dokumentovan ili nije usklađen sa ostatkom sistema.
Definition of Done (DoD) sprečava da tim stalno vraća „završene” zadatke na doradu.

Moja omiljena konverzacija:

• “Je l’ gotovo?”
• “Da!”
• “Jesi testirao?”
• “Ne.”
• “Onda nije gotovo, je l’ tako?”
• “… tehnički nije.”

(Mimove na ovu temu možete naći…svuda. Ali za najbolju zabavu, od srca preporučujemo tl:dv.io)

Kako izgleda dobar DoD?

• Kod je prošao code review i testiranje. I ne, nije “prošao” tako što su svi ćutali u nadi da će neko drugi pregledati.
• Funkcionalnost je testirana od strane QA tima. Testirana, a ne samo “šta? ovo je za QA? nisam znao!“
• Dokumentacija je ažurirana. Da, znam, dosadno, ali neophodna.
• Deployovano je na staging okruženje i spremno za produkciju.
  Jer stvari koje “rade na mom kompjuteru“, nisu gotove.

–Loš primer: „Kod je napisan, pa valjda radi. QA će već da nađe ako nešto ne valja.”

+Dobar primer: „Kod je testiran, dokumentovan i deployovan, a korisnici su obavešteni o novoj funkcionalnosti. Svi testovi prolaze, pokrivenost koda je preko 80%, UI izgleda kako treba na svim uređajima.”

# Saznaj više: Kako retrospektive pomažu u osiguravanju kvaliteta – jer analiza sprinta pomaže timu da sledeći put bude bolji. A bićemo bolji, zar ne? Zar n? Zar?…

Zaključak

Sprint može biti haotičan ili može biti strukturiran – ključ je u dobrom planiranju, jasno definisanim zadacima i preciznim kriterijumima završetka.
I naravno, malo iskustva koje obično dolazi kroz bol i patnju prethodnih neuspelih sprintova.

(Govorim iz iskustva. Mojih ožiljaka sa prethodnih projekata ima dovoljno da ih pokazujem na Halloween.)

Šta sada možeš uraditi?

• Koristi alate poput Sprint Planning Canvas da bolje definišeš sprint.
• Postavi Definition of Ready kako bi zadaci bili spremni pre nego što ih uzmeš u sprint.
• Primeni Definition of Done da bi znao/la kada je nešto zaista završeno.

Sledeći korak: U sledećem blog postu bavimo se kako da lansiranje proizvoda ne bude samo trenutak panike, već strukturiran proces sa jasnim metrikama uspeha. Stay tuned!

Kako tvoj tim osigurava kvalitet u sprintovima? Da li ste ikad imali sprint koji je prošao potpuno glatko? (Ako jeste, javi mi se – moram da vidim to čudo uživo.)