Scrum Master Essentials Course

Editor's Notes

• #3: Objasniti Parking lot,Ahaawall, no mobile&laptop.
• #4: WHY (motivation): Ovdje sam sa ciljem da vam otkrijem mogućnosti da postanete efikasniji, neovisniji, dio nečeg većeg u razvoju proizvoda, da vam posao bude zabavniji.HOW (method): Nešto više teorije, nešto malo radionica i vježbi, puno pitanja i diskusije...WHAT (product): Learningbacklog
• #7: Kako se koristi Empathy mapa?Jednostavna sesija mapiranjaempatija, može izgledati ovako:Skupite svoj tim a neka dođu sa informacijama o cilju – osobi koja će se tretirati na mapi.Odprintate, ili skečirateempathy mapu na veći komad papira ili na whiteboard-u.Dajte svakom članu tima sticky notes i marker.Svaki član tima bi trebao staviti barem jedan sticky u svako polje mape.Postavljajte pitanja, kao što su,šta bi taj korisnik mogao:- misliti & osjećati osvojim brigama i aspiracijama?- čuti, dok koristi naš proizvod, od prijatelja ili šefa?- vidjeti dok koristi naš proizvod u svom okruženju?- govoriti & raditidok koristi naš proizvod, i javno i privatno?- experiencing as a pain point or fear when using our product?- experiencing as a positive or gain when using our product?Have the team members speak about the sticky notes as they place them on the empathy map. Ask questions about deeper insights so that they can be elaborated for the rest of the team.To help bring the user to life, sketch out the characteristics this person may have on the center of the face.At the end of the session, ask the team members what insights they’ve learned. More importantly, ask them what hypotheses they now have about the users that they’d like to validate.
• #8: Imam puno posla, nemam vremena za ovo!Podignite ruku ako ste ikada:Probili rok za izvršenje projektaNiste zadovoljili očekivanja klijentaPremašili budžetDoživjeli promjenu korisničkih zahtjeva u toku projektaOstali bez članova tima u toku projekta
• #12: Osobine tradicionalnog pristupaWaterfall model je jednostavanPogodan je za projekte svih veličinaSvaka faza se zasebno izvršava i nije moguće preći u narednu fazuDokumentacija se proizvodi u svakoj fazi modela kako bi učesnici znali šta se uradilo do tadaPretpostavkeKrajnji korisnik zna šta hoćeDeveloperi znaju kako da to napraveNišta se ne mijenja u vremenu
• #13: U agilnom pristupu, počinje se sa pripremom productbacklog-a – prioritizirane liste funkcionalnosti i drugih osobina koje treba da ima budući razvijeni sistem. Vođeni productbacklog-om uvijek se radi na razvoju najvažnijih odnosno najprioritetnijih funkcionalnosti. Kada se resursi potroše (npr. vrijeme), svaki posao koji nije urađen biće manje važan od poslova koji su urađeni. Sami posao se radi u kratkim, vremenski ograničenim iteracijama, dužine obično od 1 sedmice do najviše jednog mjeseca. Tokom svake iteracije, samoorganizirajući, kros-funkcionalni tim radi sav potrebni posao (poput dizajna, razvoja i testiranja) koji je potreban da se proizvedukompletirane funkcionalnosti koje rade i koje se mogu staviti u produkciju.Količina posla u product backlog-uje obično puno veća nego što tim može uraditi u jednoj iteraciji. Tako na početku svake iteracije, tim planira koji podskup funkcionalnosti iz productbacklog-a će implementirati u toj iteraciji. Na primjeru sa slike, agilni tim je odlučio da može uraditi funkcionalnosti A,B i C. Na kraju iteracije, tim radi pregled urađenog posla zajedno sa zainteresiranim stranama, kako bi dobili povratnu informaciju (feedback) o inkrementu proizvoda iz te iteracije. Na osnovu takvih saznanja, kupac/vlasnik proizvoda (productowner) i tim mogu mijenjati plan narednih aktivnosti i načina na koji će raditi. Npr. na osnovu uvida u funkcionalnost razvijenu u netom završenoj iteraciji, vlasnik proizvoda (product owner-PO) može uvidjeti da mu je potrebna nova funkcionalnost koja do tada nije bila predviđena u product backlog-u (PB). PO tada jednostavno dodaje tu funkcionalnost, pravilno prioretiziranu u PB. Na kraju iteracije tim treba proizvesti potencijalno isporučiv inkrement proizvoda, a ako to zbog prirode sistema nije moguće, onda bi trebao isporučiti funkcionalan release proizvoda u nekoliko iteracija. Po završetku iteracije, prva aktivnost koja slijedi je planiranje nove iteracije. Pretpostavke iza Agilnog pristupaKrajnji korisnik otkriva šta želiDeveloperi otkrivaju kako da to napraveStvari se mijenjaju u vremenu
• #15: Agilni pristup nam dozvoljava da odustanemo od „predviđanja nepredvidivog“ u fazi sistemske analize; jer u agilnom pristupu radimo sa odgovorima, rješenjima i konkurirajućim idejama kako se one pojavljuju u razvoju. Da li je neka dobra ideja bila predviđena u fazi pisanja specifikacije zahtjeva sistema, ili tendera, postaje nevažno. Od zahtjeva sistema se više ne očekuje da budu ‚close to agreement‚ na početku projekta. Scrum prihvatakompleksnost i nesigurnost poslovnog aspekta razvoja software-a, činjenicu da se konačno uzajamno razumjevanje o tome „Šta“ software treba da radi postiže u fazi puštanja u rad. Pravljenje čestih funkcionirajućih verzija software-a i uključivanje feedback-a stvarnog korisnika kao novih zahtjeva je pravi pristup razvoju.
• #16: Pravljenje usporedbe agilnog razvoja sa tradicionalnim razvojem nije u cilju da se sekvencijalni, planom-vođeni razvoj proglasi lošim a da je agilni razvoj i Scrum jedino pravo rješenje. Oboje su alati profesionalnog IT menadžera, a ne postoji loš alat, već samo loša situacija za primjenu nekog alata.Planom-vođeni procesi se tako zovu jer pokušavaju planirati i predvidjeti unaprijed sve funkcionalnosti koje bi korisnik želio imati u proizvodu i da odrede koji je najbolji način da se dođe do tog proizvoda. Ideja je da što je bolje planiranje to je bolje razumjevanje i prema tome bolji razvoj. Ovo je dobar pristup ako se primjenjuje na probleme koji su dobro definirani, predvidljivi i sa malim šansama da se problemsko područje promjeni. Problem je u tome što je većina razvoja software-a daleko od predvidljivosti, barem u početku. Pa, iako planom-vođeni proces daje utisak uređenog, odgovornog, mjerljivog procesa, taj utisak samo daje lažan osjećaj sigurnosti.
• #18: U tačku B nas je doveo plan. U željenu tačku C, changerequest.
• #20: U tačku C nas je doveo empirijski razvoj proizvoda.
• #24: Scrum nije standardizirani proces u kojem se metodički slijedi serija sekvencijalnih koraka koji „garantuju“ proizvođenje, na vrijeme i u okviru budžeta, visoko-kvalitetnog proizvoda sa kojim će krajnji korisnici biti zadovoljni. Scrum je okvir za način organizacije i upravljanja poslom.
• #26: Product owner je odgovoran za to ŠTA će se razvijati i po KOM REDU.ScrumMasterje odgovoran za vođenje tima u kreiranju i slijeđenju vlastitog procesa baziranog na Scrum okviru.Razvojni tim je odgovoran za određivanje KAKO će se isporučiti ono što product owner traži.Ovdje ne vidimo ulogu „menadžera“ jer Scrum okvir ne traži tu ulogu, što ne znači da organizacija koja prakticira Scrum ne treba projektne menadžere.
• #27: Koje funkcionalnosti i kojim redoslijedom: Product owner ima obavezu da se uvijek radi posao koji ima najveću poslovnu vrijednost.Da bi tim rapidno razvijao ono što ProductOwner želi, mora ostvariti blisku i neposrednu saradnju sa ostalim članovima Scrum tima.
• #28: RazumjevanjeScrum-a: ScrumMaster je liderScrum procesa koji treba pomoći Scrum timu, i ostatku organizacije, da razvije vlastiti visoko-performansni, organizacijsko-specifičniScrum pristup. Njegova uloga je da pomogne organizaciji da savlada izazove koji usvanjeScrum-a donosi.Uklanjanje prepreka: Ako pojedinci samostalno ne mogu ukloniti poteškoće.ScrumMaster nije projektni ili razvojni menadžer, njegova uloga je liderska.
• #29: Krosfunkcionalan tim: članovi kolektivno moraju imati sve vještine potrebne da se razvije visoko-kvalitetnifunkcionirajućisoftware.
• #33: Product owner ima viziju šta želi da se napravi (velika plava kocka). Obzirom da je kocka velika, kroz aktivnost koja se naziva grooming razbija se na set funkcionalnosti koje su prioretizirane i nazivaju se product backlog.Sprint počinje sa planiranjem sprinta, podrazumjeva posao razvoja za vrijeme trajanja sprinta(izvršenje sprinta) i završava sa dvije kontrolne aktivnostidemoi retrospektiva. Broj i opseg funkcionalnosti u product backlog je vrlo vjerovatno puno veći nego što tim može razviti u jednom kratkom sprintu. Iz tog razloga, na početku svakog sprinta, razvojni tim mora odrediti podskup funkcionalnosti productbacklog-aza koji vjeruje da ga može implementirati u jednom sprintu—ova aktivnost se naziva planiranje sprinta.Ono što tim forecast-a ili commit-a da će uraditi u jednom sprintu naziva se sprint backlog. Sprint backlog opisuje, kroz set detaljno obrazloženih task-ova, kako tim planira da dizajnira, razvije, integrira, i testiraizabrani podskup funkcionalnosti u toku sprinta.Slijedi izvršenje sprinta, gdje razvojni tim implementira taskove koji vode ka implementaciji funkcionalnosti na koje se tim commit-ao. Svaki dan sprint-a, članovi tima održavaju sinhronizacijsku, inspekcijsku i adaptivnu aktivnost planiranja poznatu kao dnevni scrum. Na kraju izvršenja sprint-a, tim proizvodi potencijalno isporučiviinkrement proizvoda koji predstavlja neke, ali ne sve, funkcionalnosti iz vizije productowner-a.Scrum tim završava sprint obavljajući dvije inspect-and-adapt aktivnosti. U prvoj, koja se naziva Sprint review, svi učesnici projekta i Scrum timprovjeravaju razvijeni proizvod. U drugoj, koja se naziva sprint retrospective, Scrum tim ispituje svoj Scrum proces. Rezultati ovih aktivnosti su potencijalne korekcije/adaptacije koje će naći put do productbacklog-a ili će biti uključene kao dio razvojnog procesa tima.Proces se ponavlja, a nakon završetka odgovarajuće broja sprintova, vizija productownera će biti realizirana a rješenje će se moći pustiti u produkciju.
• #34: UScrum-u, uvijek prvo radimo najvrijednije stvari. Product owner, na osnovu ulaza koje dobija od svih učesnika na projektu, odgovoran je da odredi i upravlja sekvencom posla koji treba da se uradi i da to iskomunicirau formi prioretizirane liste koja se naziva product backlog.U slučaju razvoja novog proizvoda backlog čine funkcionalnosti koje će ispuniti viziju productowner-a. Za projekat koji je u razvoju, product backlog može sadržavati nove funkcionalnosti, ispravke postojećih funkcionalnosti, greške koje treba popraviti, tehnička poboljšanja itd.Konstantno evoluiranje: Item-i mogu biti dodati, obrisani i revidirani od strane product owner-a sukladno promjenama poslovnih okolnosti ili kako se razumjevanje vizije proizvoda mijenja kod Scrum tima (kroz feedback dobijen u sprint review-u).
• #36: Aktivnost kreiranja i rafiniranja stavki productbacklog-a, njihovog procjenjivanja i prioretiziranja se naziva grooming.Veličina stavke u PB je u relaciji sa cijenom, paproduct ownertreba da zna cijenu stavke kako bi na odgovarajući način odredio njen prioritet. Scrum ne diktira koji mjerni sistem, ako ćete ga uopšte koristiti, treba koristiti u PB. U praksi, mnogi timovi koriste relativni mjerni sistem poput poena priče (story points)ili idealnih dana.
• #37: Posao se u Scrum-u odvija u iteracijama ili ciklusima u maksimalnom trajanju od jednog kalendarskog mjeseca i treba rezultirati nečim što je od opipljive vrijednosti za klijenta odnosno korisnika.Sprintovi su vremenski ograničeni i uvijek imaju fiksni početni i datum završetka. Novi sprint slijedi odmah poslije završetka prethodnog sprinta. Pravilo je da nema promjene opsega posla i cilja sprint-a dok je sprint u toku, ali poslovne potrebe mogu biti takve da nekada nije moguće ispoštovati ovo pravilo.
• #38: Planiranje sprinta je identifikacija najvažnijeg podskupa stavki PB koji će se implementirati u narednom sprintu.U planiranju, product owner i razvojni tim se dogovaraju o cilju sprinta koji definira ŠTA naredni sprint treba da ostvari. Korištenjem ovog cilja, razvojni tim pregleda product backlog i određuje koje visoko-prioritetne stavke tim realno može implementirati u ritmu/brzinom koja je takva da da razvojni tim komforno može raditi duži vremenski period.Kako bi razvojni tim utvrdio svoje realne mogućnosti, oni obično razbiju ciljane funkcionalnosti na set taskova. Taskovi zajedno sa pripadajućim PB stavkama čine drugi backlog koji se naziva sprint backlog (-> Sljedeći slajd).
• #39: Razvojni tim procjenjuje (tipično u satima) koliko je posla potrebno za svaki od taskova.Većina Scrum timova koja implementira sprintove dužine dvije sedmice do mjesec dana provode u planiranju sprinta od 4 do 8 sati.Pristup 1: Odaberi PBI (ako je moguće, sljedeći najvažniji), razbij stavku na taskove, i utvrdi da li se stavka dužinom uklapa u sprint (u kombinaciji sa drugim PB stavkama predviđenim za sprint). Ako se uklapa i ima još mjesta u sprintu, ponavljaj ciklus dok razvojni tim ima kapaciteta da uradi još posla.Pristup 2: Product owner i razvojni tim izaberu sve ciljane PBI odjednom. Razvojni tim samostalno razbija stavke na taskove kako bi utvrdio da zaista može isporučiti sve odabrane PB stavke.
• #40: Jednom kada Scrum tim završi planiranje sprinta i dogovori sadržaj sljedećeg sprinta, razvojni tim, vođen ScrumMasterovimcoaching-om, obavlja sve taskove potrebne da se implementira dogovorena funkcionalnost. Funkcionalnost je završena „Done“ kada postoji visoki stepen pouzdanosti da je sav posao potreban da se proizvede funkcionalnosti dobre kvalitete, urađen.Kojim redom i kako će Scrum tim implementirati definisane taskove iz sprint backloga potpuno zavisi od Scrum tima. Članovi tima određuju vlastiti posao koji trebaju uradi i samoorganiziraju se na bilo koji način za koji cijene da je najbolji za postizanje cilja tog sprint-a.
• #41: Svakog dana sprinta, idealno u isto vrijeme, članovi razvojnog tima održavaju vremenski ograničeni (do 15 minuta) sastanak koji se naziva dnevni scrum. Ovainspect-and-adaptaktivnost se nekada naziva dnevnistand-upzbog uobičajene prakse da svi stoje u toku trajanja sastanka kako bi se promovirala konciznost i kratkoća sastanka.Uobičajeni pristup dnevnom scrum-u je da svaki član tima odgovori na sljedeća pitanja od koristi za sve ostale članove tima:• Šta sam uradio od zadnjeg dnevnog scrum-a?• Šta planiram uraditi do sljedećeg dnevnogscrum-a?• Koje prepreke ili smetnje me sprečavaju u radu?Odgovaranjem na ova pitanja, svi članovi razvojnog tima dobijaju jasnu veću sliku šta se dešava i kako tim napreduje u ostvarivanju cilja sprinta, da li ima nekih promjena u planovima i koja pitanja se moraju adresirati kako bi tim nesmetano nastavio ispunjavati preuzete obaveze. Dnevni scrum je ključan za uspješno i brzo upravljanje poslom u sprintu.Dnevni scrum nije problem-solving aktivnost već aktivnost sinhronizacije, inspekcije i adaptacije. Obično inicira naknadni sastanak na kojem prisustvuju zainteresirane osobe za one teme koje treba riješiti.
• #42: Rezultat rada razvojnog tima na kraju sprinta je potencijalno isporučiviinkrement proizvoda. „Potencijalno isporučivi“ podrazumjeva da je tim postigao određeni rezultat koji zadovoljava usvojenu definiciju završenog posla (Definition of Done). Definicija završenog posla može biti npr. u razvoju software-a, da je određena funkcionalnost dizajnirana, razvijena, integrisana, testirana i dokumentirana.
• #43: Inspect-and-adapt aktivnost sa ciljem da se:Svi upoznaju da upravo završenom funkcionalnošću u kontekstu razvoja cjelokupnog proizvoda,Dobije jasna slika i šansa da se u daljem razvoju biraju poslovno-najkorisnije opcije.
• #44: Kako je sprint review inspect and adaptaktivnost za razvijenu funkcionalnost odnosno proizvod, tako je retrospektiva sprintainspect-and-adapt aktivnost zaScrumproces. Cijeli Scrum tim učestvuje na sastanku čiji je cilj da se vidi šta je bilo dobro a šta ne u Scrum procesu, i kako ga tim može poboljšati da bi bolje i lakše radio svoj posao.
• #52: Ljude i njihove međusobne odnose nego procese i oruđa.Scrum se, kao i drugi agilni okviri i metode,direktno oslanja na povjerenje u timove, individualce u timovima, i način na koji oni komuniciraju. Timovi shvataju šta treba uraditi, timovi shvataju kako to uraditi i timovi to i urade. Timovi identificiraju šta im stoji na putu i preuzimaju na sebe odgovornost da riješe sve poteškoće u svom domenu posla. Timovi rade sa drugim dijelovima organizacije da riješe pitanja koja su van njihove kontrole. To je od kritične važnosti. Pokušavati primjenjivatiScrum a pri tome podcijeniti ovaj primarni fokus na odgovornost tima će generalno voditi ka problemu.Upotrebljiv softver nego iscrpnu dokumentaciju.Scrum se fokusira na upotrebljiv, završeni inkrement proizvoda kao primarni rezultat svakog sprinta. Svakako da će biti poslova analize, dizajna, testiranja, koji svi moraju biti dokumentirani. Ali softver koji radi, a ne dokumentacija, je ono što dozvoljava organizaciji da vodi projekat ka uspjehu. To je od kritične važnosti. Scrum tim mora proizvesti inkrement proizvoda u svakom sprintu.Saradnju s korisnicima nego pregovaranje oko ugovora.ScrumProductOwner je primarna kontakt osoba Scrum tima sa krajnjim korisnicima proizvoda i sa dijelovima organizacije koja treba proizvod. ProductOwner je član tima i radi kolaborativno sa timomo kako bi utvrdio šta treba da se uradi. U ovoj kolaboraciji, ProductOwner bira najvrijednije sljedeće funkcionalnosti, osiguravajući da proizvod ima najveću moguću vrijednost u svakom momentu razvoja. To je od kritične važnosti. ProductOwner mora graditi bogatu i raznovrsnu kolaboraciju sa članovima tima.Reagiranje na promjenu nego ustrajanje na planu. Sve u Scrum-u je dizajnirano tako da svako ima potrebnu informaciju da napravi dobre odluke u projektu. Progres proizvoda je demonstriran stvarnim, radnim, inkrementom proizvoda. Backlog stvari koje treba napraviti su dostupni svima da ih vide. Progres, sveukupni i po sprintovima, je jasno vidljiv. Problemi i brige se otvoreno diskutiraju i rješavaju odmah. To je od kritične važnosti. Scrum radi dobro sa timovima koji bez predrasuda „provjeravaju" šta se dešava i "adaptiraju" svoje akcije prema realnim potrebama. Scrum loše radi za timove koji na to nisu spremni.
• #54: Mi vjerujemo u poštovanje, pa ćemo se pojaviti na vrijeme na svakom sastanku.Mi vjerujemo u otvorenost,pa ćemo reći product owner-u„Ne“ kada ne možemo uraditi više posla u sprintu....
• #59: Scrum organizira posao u iteracijama ili ciklusima dužine do jednog kalendarskog mjeseca. Ključne karakteristike sprintova su da su oni vremenski ograničeni, imaju kratko i konzistentno trajanje, imaju cilj koji ne treba mijenjati kada se sprint pokrene i moraju završiti sa inkrementom koji zadovoljava Definition of Done koji je tim utvrdio.
• #60: Sprintovi su zasnovani na konceptu timeboxinga, tehnike upravljanja vremenom, koja pomaže bolju organizaciju rada i upravljanje opsegom rada. Timebox ima svoj početni i krajnji datum a od tima se očekuje sustainable pace rad u timeboxu.Timeboxing je važan jer:Uspostavlja limit na posao u radu (WIP) – Obzirom da će tim raditi samo na onim item-ima za koje vjeruje da ih može završiti u toku sprinta, neće doći do nekontroliranog počinjanja aktivnosti koje se izvršavaju duže od planiranog.Nameće prioritetiziranje posla – Timeboxing u Scrum-u nas primorava da radimo male (bytesize) količine posla koje najviše vrijede za klijenta. Ovo pooštrava naš fokus na brzo završavanje vrijednih stvari.Demonstrira progres – U usporedbi sa nepouzadnijom metodom praćenja progresa (praćenje ispunjenja vremenskog plana koji je teško unaprijed kvalitetno pripremiti) sprint daje odličan uvid u to šta je urađeno do kraja sprinta, pa čak i za item-e za koje je potrebno više sprintova da budu završeni. Izbjegava se nepotrebni perfekcionizam – Svi smo prije ili kasnije dolazili u situaciju da potrošimo previše vremena pokušavajući nešto napraviti „perfektnim“ a da smo mogli relativno brzo doći do „dovoljno dobrog“ rješenja. Timeboxing nam daje dobar uvid gdje se nalazimo i koliko nam vremena treba za preostale aktivnosti, što nas sprečava da provodimo previše vremena na nepotrebnom „pozlaćivanju“ nekog item-a.Motivira okončanje posla u radu – Sprint uvijek ima hard deadline jer je relativno kratak. U takvim uslovima, očekivati je od tima da se zaista posveti završavanju posla za koji su preuzeli obavezu. Kad nema osjećaja urgencije, svi radimo sporije.Poboljšava previđanje – Puno je lakše predviđati 2 ili 3 sedmice unaprijed nego npr. godinu dana.
• #61: Kratko trajanje sprinta doprinosi:Jednostavnost planiranja – Uvijek je lakše planirati kratkoročno nego dugoročno. Potroši se puno manje vremena na planiranje, a plan je puno precizniji. Usporediti sprint planning aktivnost sa aktivnošću dugoročnog planiranja i u smislu preciznosti plana i u smislu nivoa detalja.Brzi feedback - Tokom svakog sprinta tim proizvodi nešto što radi a zatim se otvara mogućnost ispitivanja i adaptiranja i toga što tim radi i kako to radi. Ovaj rani feedback nas sprečava da krenemo neželjenim putem razvoja proizvoda gdje će se na jednu lošu odluku vezivati naredne loše odluke.Ograničenje mogućih grešaka – Koliko možemo pogriješiti za dvije sedmice? Pa ako smo i sve pogrešno radili, pogrešno smo radili samo dvije sedmice.Bolji ROI -U Scrum pristupu razvoju sistema, moguće je da sistem stavimo u pogon i prije nego što je završeno sve što klijentu treba. U takvim situacijama ROI za klijenta je bolji.Zadovoljstvo rada - U ljudskoj je prirodi da nam interes i uzbuđenje opada što duže moramo čekati na priznanje rada.Česte tačke provjere – U odnosu na sekvencijalni razvoj, Scrum pruža puno više inspect-and-adapt checkpoint-a, što je posebno važno za razvoj inovativnih rješenja u kompleksnom okruženju.
• #62: U pravilu, tim treba odabrati konzistentnu dužinu trajanja sprinta i ne mijenjati je bez nekog izuzetno dobrog razloga. To može biti npr. da tim sa četverosedmičnog sprinta želi preći na dvosedmični radi ranijeg feedbacka i lakše kontrole nad procesom razvoja ili produžiti sprint za jednu sedmicu ako u jednoj sedmici ima veći dio neradnih dana zbog npr. praznika.Konzistentna dužina trajanje sprinta doprinosi:Ritmičan rad – doprinosi da sve Scrum aktivnosti prelaze u naviku, pa nema utroška vremena na organizaciju tih aktivnosti. Tako će i intezitet posla postati ujednačen iz sprinta u sprint, ne kao u sekvencijalnom razvoju gdje pred kraj projekta eksponencijalno raste količina posla u nastojanju da se ispuni plan. Ako u razvoju učestvuje više Scrum timova, ritmičan rad dozvolja sinhronizaciju različitih timova.Pojednostavljuje planiranje – Ako je dužina sprinta konzistentna onda je nakon nekoliko sprintova vrlo lako ustanoviti brzinu (velocity) pa je planiranje završetka release-a ili cijelog proizvoda jednostavno izračunati.
• #63: Svaki sprint se može rezimirati u vidu sprint cilja koji opisuje poslovnu svrhu i vrijednost sprinta. To je tipično jedna rečenica koja opisuje cilj ili više njih:• Podržati generisanje nove obuke.• Učitati i modificirati geografske podatke na karti Bosne i Hercegovine.• Demonstrirati sposobnost slanja personaliziranih SMS i e-Mail poruka krajnjim korisnicima sa podacima o statusu njihovog postupka.Cilj sprinta određuje PBI koje će tim preuzeti da implementira u tom sprintu. Uzajamno obvezivanje razvojnog tima i Product Owner-a – Razvojni tim preuzima obavezu da će implementirati određene PBI i time ispuniti cilj sprinta, a Product Owner se obavezuje da neće mijenjati cilj sprinta jednom kada razvojni tim krene u aktivnosti. Ovim se potiže balans između potrebe biznisa da ima mogućnost izmjene funkcionalnosti prema svojim stvarnim potrebama i potrebe razvojnog tima da se koncentira i efikasno upotrijebi svoj talenat na kreiranju vrijednosti u tom sprintu. Pojašnjenja vs. PromjenaPrimjer pojašnjenja: PO: Kada sam rekao da trebam izvještaj o svim zaposlenicima koji trenutno koriste bolovanje, zaboravio sam da mi treba sortiranje po trenutnoj dužini bolovanja.Primjer promjene: PO: Kada sam rekao da trebam izvještaj o svim zaposlenicima koji trenutno koriste bolovanje, zaboravio sam da mi treba vizualizacija svih bolovanja kroz kalendarski prikaz koji će imati mjesečni, sedmični, dnevni i timeline prikaz.Ovdje treba biti pragmatičan. „Nema promjene cilja“ je pravilo a ne zakon. Ako je sistem već u produkciji i desio se problem zbog kojeg je sistem nedostupan, naravno da će se tim posvetiti rješavanju tog problema na uštrb implementacije planiranih PBI. Što se tiče motivacije i povjerenja tima, one neće opasti ako Product Owner ima pošten i ekonomski fokusiran nastup u kojem objašnjava potrebu za promjenom dok sprint traje.Terminacija sprinta je moguća i vrlo rijetka. Mora se desiti nešto vrlo specifično da bi se sprint terminirao, npr. razvoj određenih funkcionalnosti se pokazao potpuno nepotrebnim zbog izmjene zakonske regulative ili što upravo objavljeni konkurentski proizvod bolje rješava te funkcije sistema i sl. Odmah počinje naredni sprint za koje je potrebno odrediti kolika će mu dužina trajanja biti.
• #64: Potencijalno isporučivije atribut koji opisuje stepen pouzdanosti da je ono što je u sprintu razvijeno zaista završen posao, dakle da nije preostao nikakav značajan neurađen posao koji mora biti završen da bi se inkrement pustio u rad, ako je to želja vlasnika proizvoda.Da bi znao da li je inkrement proizvoda razvijen u sprintu zaista isporučiv, Scrum tim mora imati dobro definisanu i usaglašenu definiciju završenog posla (Definition of Done).To je checklista poslova koje tim mora raditi da bi proglasio inkrement potencijalno isporučivim. Da bi checklista bila korisna za tim, generički definition of done mora biti razvijen prema potrebama razvoja konkretnog proizvoda. Svaki proizvod ima vlastite specifičnosti za npr. testiranje, pa ako to specifično testiranje nije uključeno u definiciju, ne može se reći da su inkrementi zaista potencijalno isporučivi. Treba razlikovati definition of done i acceptance criteria koji ima svaki PBI.Npr. „Kao korisnik želim plaćanje karticom da bih mogao kupiti proizvod“, može imati acceptance criteria „Radi sa Visa, MasterCard i American Express“ a definition of done „Integrisano na produkcijskom serveru“.
• #66: Scrum i tradiocionalni razvoj software-a tretiraju korisničke zahtjeve vrlo različito. Kod sekvencijalnog razvoja, ne može se pregovarati oko korisničkih zahtjeva, detaljno su utvrđeni prije početka razvoja i podrazumjeva se da su nepromjenjivi.U Scrum-u, detalji korisničkih zahtjeva se pregovaraju kroz konverzaciju koja se odvija kontinuirano u toku razvoja a isti se detaljno razmatraju u pravo vrijeme (just in time) i koliko je potrebno (just enough) za tim da počne raditi na razvoju te funkcionalnosti.
• #67: Inicijalno neke stavke u PB mogu biti velike (predstavljajući poslovne vrijednosti na višem nivou apstrakcije) i one imaju vrlo malo detalja. Vremeno, ove stavke prolaze kroz niz konverzacija između korisnika, Product Owner-a i članova razvojnog tima, koje ih rafiniraju u set manjih, detaljnijih PBI-ova.Potrebno je daproduct backlog itempostane dovoljno mali i dovoljno detaljan, kako bi se stavio u sprint gdje će biti dizajniran, testiran i razvijen.
• #70: Korisničke priče su zgodan format izražavanja poslovne vrijednosti za mnoge tipove PB stavki, posebno funkcionalnosti. Korisničke priče se pišu na način da su razumljive i poslovnim korisnicima i tehničkim odobama. Strukturalno su jednostavne i predstavljaju sjajan osnov za razgovor. Također, mogu se pisati na različitom niovu granularnosti detalja i lako ih je progresivno rafinirati.
• #73: Independent – Koliko god je to praktično, korisničke priče bi trebale biti ili nezavisne ili loosely coupled jedna sa drugom. Ako je korisnička priča jako ovisna o drugim, biće je teže procijeniti, prioreitizirati i planirati.Negotiable – Korisničke priče nisu pisani ugovor već placeholder-iza razgovor u kojem će detalji biti dogovoreni. Smisao je da jasno prezentiraju suštinu poslovne funkcionalnosti koja je potrebna i zašto je ona potreba, ali i da ostave prostora za dogovor oko detalja.Valuable – Korisničke priče trebaju biti vrijedne klijentu, korisniku ili oboma. Sve korisničke priče ne moraju biti nezavisne, niti moraju biti u potpunosti dogovorljive, ali sve moraju imati vrijednost za product owner-a, inače se ne trebaju nalaziti u product backlog-u i implementirati. Estimatable – Razvojni tim treba da zna veličinu korisničke priče da bi priču stavio u sprint ili radio na njenom daljnjem rafiniranju. Zato priča mora biti procjenjljiva. Sized Appropriately –Ako imamo dvosedmični sprint, onda ne želimo dvosedmičnu korisničku priču jer je rizik od neimplementacije takve priče velika. Zato nam trebaju korisničke priče večine do nekoliko dana. Bitan je faktor kada: korisničke priče na ulasku u sprint trebaju biti male, ali je dozvoljeno imati epic-e niskog prioriteta.Testable – Korisničke priče moraju bititestable u smislu da ili prolaze ili padaju na pridruženom testu. To znači da moraju imati dobre kriterije uspješnosti (acceptance criteria). Kriterij uspješnosti korisničke priče je njen definition of done.
• #74: Ciljuser-story-writing workshop-aje da se kroz zajednički brainstormingdođe do željenih poslovnih zahtjeva i kreiraju user story placeholder-iza ono što proizvod ili usluga treba da budu. Cilj nije da se generira puna i potpuna specifikacija korisničkih priča unaprijed, već da se radionica fokusira na određenu temu, npr. nešto što bi išlo u prvom narednom release-u. Prvi workshop bi krenuo od definicija korisničkih uloga, a onda bi se dodavale korisničke priče, gdje nema posebnih pravila.Story mappingje tehnika koja generiše skup korisnički priča iz perspektive korisnika. Osnovna ideja je da se radi dekompozicija korisničke aktivnosti set tema i korisničkih priča.
• #77: Detailed appropriately– PBIs su na različitim nivoima detaljnosti u različito vrijeme. PBIs na vrhu PB moraju biti mali sa puno detalja. Nema koristi od detaljisanja PBIs koji ne idu uskoro jer se može desiti da puno vremena potrošimo na detalje PBI-ja koji se na kraju neće ni implementirati. Emergent– Product Backlog nikada nije završen ili „zamrznut“. Stalno se ažurira kroz pristizanje ekonomski vrijednih informacija za kupca/korisnika. Estimated–Svaki PBIs ima svoju procijenjenu veličinu (size estimate) koja odgovara naporu koji je potrebno uložiti da se stavka razvije. Ako je na vrhu PB, PBI sa velikim size-om to je signal PO za refinement.Prioritized– Iako se kaže da je PB prioretizirana lista stavki koje treba implementirati, u realnosti se prioretizacija odnosi prije svega na stavke koje idu u nekoliko narednih sprintova.
• #79: Grooming product backlog-a je kontinuirani kolaborativni posao koji vodi product ownera koji uključuje značajno učešće internih i eksternih stakeholder-a kao i ScrumMaster-a i razvojnog tima. Samo je Product Owner odgovoran za donošenje informiranih odluka. Dobar PO će uzeti u obzir i snagu kolektivne inteligencije svih stakeholder-a i benefit u postizanju uzajamnog razumjevanja PB od strane svih uključenih u implementaciju projekta. Ovdje se pokazuje razlika između tradicionalnog pristupa utvrđivanju korisničkih zahtjeva i Scrum pristupa.Uobičajeno je da razvojni tim provede oko 10% svog vremena u svakom sprintu asistirajući product owner-u u groomingaktivnostima. Tim će koristiti ovo vrijeme da pomogne kreiranje ili review emergent PBIs odnosno da progresivno rafiniraju veće PBIs u manje korisničke priče. Tim će također koristiti ovo vrijeme na procjenjivanju veličine PBIs i pomažući PO da ih prioretizira na osnovu znanja o tehničkim zavisnostima i ograničenjima na resurse.
• #80: Scrum okvir kaže da se grooming mora desiti; on ne specificirakada će se desiti. U odnosu na sekvencijalni razvoj, gdje je sve up-front, ovdje se nešto dešava up-front u odnosu na razvoj, nešto kontinuirano po potrebi (npr. online kroz JIRA-u ili Confluence ili neki drugi alat), nešto u dogovorenoj aktivnosti (sedmičnoj, sprintovskoj), nešto poslije dnevnog Scrum-a ako je PO dostupan, nešto poslije sprint demo-a.Kada se grooming dešava je manje važno od osiguranja da je aktivnost dobro integrirana u Scrum razvojni tok, i da isporučuje poslovnu vrijednost na fleksibilan i efikasan način.
• #84: Kada planiramo i upravljamo razvojem proizvoda, moramo odgovoriti na važna pitanja kao što su „Koliko funkcionalnosti ćemo završiti?“, „Kada ćemo završiti?“ i „Koliko će razvoj koštati?“ Kako bi odgovorili na ova pitanja u Scrum-u, moramo procjeniti veličinu stavki koje radimo i izmjeriti brzinu kojom radimo. Sa ovim informacijama, možemo procjeniti vjerovatno trajanje razvoja proizvoda (a time i trošak) dijeleći procjenjenu veličinu seta funkcionalnosti sa brzinom tima.
• #86: Timska procjena razvojnog tima – U mnogim tradicionalnim organizacijama projekt menadžer, product menadžer, arhitekt, ili lead developer mogu uraditi inicijalnu estimaciju posla. U Scrum-u, slijedi se jednostavno pravilo: Ljudi koji će raditi posao raditi posao, rad procjenu. Pod ovim se ne podrazumjevaju ProductOwner i ScrumMaster, mada obje uloge moraju biti prisutne kada se procjena radi.Procjenjivanje nije obvezivanje - Objasniti relativni sizing
• #87: Planning Poker tehnika bazirana na koncezusu za procjenu obima posla (radnog napora). Ljudi koji znaju posao(eksperti) i trebaju implementirati PBI ulaze u intenzivnu diskusijukako bi objelodanilipretpostavke, stekli zajedničko razumjevanje, i odredili veličinu PBI. Planning Poker daje procjene relativne veličine kroz grupiranje/pridruživanjestavki iste veličine. Iskustvo stečeno u ranijem procjenjivanju PBI stavki pomoći će u narednom procjenjivanju.
• #90: Brzina razvoja je količina posla kompletiranog u toku sprinta. Mjeri se dodavanje veličine svakog PBI-ja koji se završi u toku sprinta. PBI je ili završen ili nije završen, a kakoproduct ownernema koristi od nezavršenih stavki, brzina razvoja (velocity) ne uključuje vrijednost veličine parcijalno urađenih PB stavki.Tim koji nastoji da se poboljša i koji je fokusiran na isporuku funkcionalnosti u skladu sa robustnim definition of doneće vrlo brzo postići veću brzinu, do neke tačke u kojoj će postići plato. Uz adekvatne mjere, npr. treninga, uvođenja novih alata i sl., može se očekivati ponovni rast, kao na trend 2. Nepravilna upotreba velocity-ja: point inflation.
• #92: Product owner je opunomoćena središnja tačka liderstva odgovorna za razvoj proizvoda. S jedne strane, product ownermora razumjeti potrebe i prioritete organizacijskih stejkholdera,klijenata, i korisnika dovoljno dobro da predstavlja njihov glas. U ovom smislu PO djeluje kao productmanager, brinući se da se razvije pravo rješenje.S druge strane, product ownermora razvojnom timu reći šta da razvije i u kom redoslijedu, koji suacceptancecriteria razvijenih funkcionalnosti, te da iste testira kako bi utvrdio da li je funkcionalnost razvijena onako kako stejkholderi očekuju. U tom smislu, PO je dijelom sistem analitičar, dijelom tester.
• #93: Upravlja ekonomskim aspektom projekta - Product owner konstantno trguje opsegom, datumima, budžetom i kvalitetom kako se niz ekonomski bitnih informacija otkriva u toku razvoja projekta. Money for nothing, change for free.Učestvuje u planiranju – Productowner je ključna osoba u planiranju proizvoda, release-a i sprint-a. Od osmišljavanja vizije proizvoda, preko planiranja release-a odnosno prve verzije proizvoda do utvrđivanja cilja sprint-a i pojašnjavanja PB stavki razvojnom timu.Radi refinementproductbacklog-a - Product owner nadgleda grooming product backlog-a, što uključuje kreiranje i rafiniranje, procjenjivanje i prioretiziranje PB stavki. On to ne radi sam, ali je na kraju odgovorna osoba koja treba da osigura da se groomingaktivnosti izvršavaju na način koji promovira stabilan tok isporuke vrijednosti u proizvodu.Definira kriterije prihvatljivosti i testira ih - Product owner je odgovoran za definisanje kriterija prihvatljivosti za svaku PB stavku. Kada PO ne bi imao kriterije prihvatljivosti, kako bi razvojni tim imao puno razumijevanje očekivanja PO? Zato je postojanje kriterija prihvatljivosti element ranije spomenutog PBI‘s definition of ready. Najbolje je da postoji mehanizam testiranja isporučenih funkcionalnosti još u momentu sprintexecution-a kako bi se u sprintreview-uprezentirale stavke koje su zadovoljile i acceptancecriteria i defionition of done.
• #97: Situacije u kojima PO možda mora reći„NE“:1. Kada tim pokuša natjerati klijenta da koristi tehnologiju, platformu, arhitekturuilidizajnza koji vjeruje da je „tehnički odgovarajući“ ali što nema nikakve vrijednosti za klijenta - I know what's best for you syndrome2. Kada klijent želi nešto što je jasno nemoguće sa datim vremenom i resursima - the dreamer syndrome 3. Kada Scrum Master predstavljajući tim želi promijeniti opseg projekta - two captains on one boat syndrome4. Kada tim sam odluči šta treba izbaciti iz projekta- tech decision without involving the business syndrome5. Kada developeri žele staviti „pozlatu“ na rješenje za problem - super engineer syndrome 6. Kada tim želi da u nekoliko sprintova istražuje probleme i rješenja bezgarantovanog praktičnog rezultata - researcher syndrome7. Kada tim ili Scrum Master žele da preskoče sprintreview - ostrich syndrome8. Kada tim želi isključiti PO sa svih sastanakajer vjeruju da već dovoljno dobro poznaju proizvod - come back when I'm ready syndrome9. Kada klijent želi da komunicira direktno sa timom zaobilazeći PO - serve yourself syndrome
• #104: Dok je product ownerfokusiran na efektivnost razvoja (building the right product)a razvojni tim je fokusiran na efikasnost(building the product right), ScrumMasterje fokusiran da pomogne svima da razumiju i prihvate Scrum vrijednosti, principe i prakse.
• #105: Coach – Analogno treneru sportskog tima, ScrumMaster promatra kako tim koristi Scrum i radi što god je moguće da tim, koristeći Scrum, postigne veći stepen performanse. ScrumMasternastoji da ukloni barijeru između PO i razvojnog tima kako bi product owner direktno drajvao razvojem.Servant lider – Kada djeluje kao coach tima, ScrumMasterje prije svega servant Scrum timu, brinući se da zadovolji potrebe tog tima.Procesni autoritet - ScrumMasterje opunomoćenda nametneScrum timu poštovanjeScrum vrijednosti, principa i praksi.Štit protiv uplitanja - ScrumMasterštiti razvojni tim od vanjskih uticaja tako da može biti fokusiran na isporuku poslovne vrijednosti svakog sprinta.Uklanja prepreke – Preuzima odgovornost da ukloni smetnje koje utiču na produktivnost tima kada sami tim ne može da uradi ništa po tom pitanju.Change agent – Uvođenje Scruma je velika promjena. ScrumMaster mora da djeluje na sve u organizaciji kako bi promjenili svoj mindset u svakodnevnom radu.
• #106: Posjeduje znanje – Odlično o Scrum-u, dovoljno dobro o tehnologijama koje će tim koristiti za razvoj proizvoda, ništa posebno o domenu proizvoda.Preispitivač – Koristi svoje coachingvještine da pita sjajna pitanja Scrum tim navodeći ih, ali nikad ne odgovarajući, na odgovore koji će pomoći timu da bolji usvoji Scrum.Strpljiv – Kako ScrumMasters preferira da ne daje odgovordajući vrijeme timu da dođe do svog odgovora, SM mora biti strpljiv. Pogotovo jer odgovor tima (kolektivna inteligencija)može biti bolji nego što bi ga SM dao. Spreman na saradnju – Mora posjedovati odlične komunikacijske / kolaboracijske vještine za saradnju sa PO i razvojnim timom.Zaštitnik – Često ovu ulogu poistovjećuju sa psom čuvarom koji štiti stado (razvojni tim) od svih organizacijskih i drugih smetnji, ali pazi i da koja ovčica ne odluta iz stada.Otvoren i transparentan – U Scrum-u nema mjesta za hidden agenda. Transparetnost mora postojati i unutar Scrum tima i u komunikaciji sa vanjskim stejkholderima.
• #108: Ko bi trebao biti ScrumMaster?ScrumMaster može doći sa pozicije projekt/produkt menadžera (iako potponju prije ide za PO), developera, testera, dakle može biti bilo ko ima osobine ScrumMastera o kojima smo govorili. Menadžeri u organizaciji mogu imati probleme je ScrumMaster ne upravlja timom i tim ne podnosti izvještaj niti za rad odgovara ScrumMasteru.Da li je ScrumMaster full-time pozicija?Vjerovatno ne. Scrum tim koji radi zajedno dugo vremena i koji je postao ekspertan u primjeni Scrum-a će vjerovatno trebati manje coaching-a od tima koji je nov sa Scrum-om.
• #110: Dok je product ownerfokusiran na efektivnost razvoja (building the right product)a razvojni tim je fokusiran na efikasnost(building the product right), ScrumMasterje fokusiran da pomogne svima da razumiju i prihvate Scrum vrijednosti, principe i prakse.
• #111: Tokom Izvršenja sprinta, članovi razvojnog tima obavljaju kreativni posao dizajniranja, razvoja, integrisanja i testiranja stavki iz Product backlog-a u inkremente potencijalno isporučivih funkcionalnosti. Da bi ovo uradili, samoorganiziraju se i kolektivno odlučuju kako će planirati, upravljati izvoditi i komunicirati potrebni rad.Od svih članova razvojnog tima očekuje se da učestvuju u svakom dnevnom Scrum-u, u toku kojeg članovi tima kolektivno provjeravaju (Inspect) progres u ostvarivanju cilja sprint-a i Adaptiraju svoj plan dnevnih radnih aktivnosti. Očekuje se od svakog člana razvojnog tima učestvovanje u aktivnostima, jer bi inače mogle biti propuštene korisne informacije.Razvojni tim treba alocirati oko 10% svog kapaciteta da u svakom sprintu asistiraju product owner-uu aktivnostima PB grooming-a.Na početku svakog sprinta, razvojni tim učestvuje u planiranju sprinta. U saradnji sa product owner-omi uz fasilitacijuScrumMaster-a, razvojni tim pomaže u definisanju cilja sprint-a. Tim tada određuje koji podskup stavki PB treba razviti da bi se postigao taj cilj.Na kraju svakog sprinta, razvojni tim učestvuje u dvije inspect-and-adaptaktivnosti: sprint reviewisprint retrospective.
• #112: Članovi razvojnog tima se trebaju samoorganizirati da odrede najbolji način implementacije cilja sprinta. Nema mjesta za projekt menadžera ili drugog menadžera koji će timu reći kako da radi svoj posao (iScrumMasternikad to ne smije uraditi). Samoroganizacijajebottom-up, emergentosobina jednog sistema—ne postoji vanjska dominantna snaga koja primjenjuje tradicionalni top-down, command-and-controlmenadžment. Profesionalni sistemi su uvijek takvi (fudbalski tim, slalomaš).Članovi razvojnog tima bi trebali biti krosfunkcionalno raznoliki; kolektivno bi trebali posjedovati dovoljan set vještina da urade svoj posao.Dobro formiran tim može uzeti bilo koju stavku sa PB i proizvesti radnu funkcionalnost dobre kvalitete koja zadovoljava od tima usvojeni Definition of Done. Dobro je u timu imati ljude koji razmišljaju na različit način, rješavaju probleme na različit način, različito inepretiraju podatke, imaju različite poglede na probleme i rješenja. Ovako nešto tipično vodi ka boljim rezultatima u smislu bržih i kvalitetnijih rješenja, boljih inovacija, i na koncu bolje poslovne vrijednosti za klijenta.Raznolikost tima se može osigurati kroz miješanjeseniorijuniorosoblja. Previšeseniorljudi može voditi ka turbulencijama,kao kada imamo puno profesionalnih kuhara u jednoj kuhinji. Previšejuniorosoblja, i tim možda neće imati dovoljno vještina da završi posao. Dobra izmješanost vodiće zdravoj, kolaborativnoj atmosferi koja promovira učenje i razvoj tima.T-Vještine je metafora koja opisuje osobu sa dubokim vertikalnim vještinama u nekom području (npr. UX-dizajn) i sa širokim, ali ne nužno vrlo dubokim vještinama u drugim relevantnim područjima (npr. testiranju i dokumentaciji). Članovi tima sa T-vještinama bolje će doprinjeti swarmingponašanju (zajedničkom napadu na isti cilj).U dobro funkcionirajućem Scrum timu, ne očekujem da bi iko mogao reći, “Ja sam uradio svoj dio posla, a taj i taj nisu, pa smo zato podbacili.” Ovakav stav znači da ta osoba ne shvata da uspijeh i neuspijeh pripadaju timu. Imati osobe sa T-vještinamapomaže timsko rješavanje taskova jer su ti ljudi osposobljeni raditi na više tipova zadataka. Članovi razvojnog tima moraju komunicirati jedan sa drugim, te sa Product Ownerom i ScruMasterom, na hagh-bandwith način, gdje se vrijedne informacije razmjenjuju brzo iefikasno sa minimalnim overhead-om. Agile manifesto kaže „Za najproduktivniji i najefikasniji metod prenosa informacije do i unutar razvojnog tima smatramo kontakt licem u lice. “ Međutim, u distibuiranim timovima (ako ništa, Product Owner može biti van lokacije razvojnog tima) mogu se koristiti alati poput Atlassian Confluence-a (demonstrirati priču o problematičnom e-mail-u).
• #113: Transparentna komunikacija omogućava jasno razumjevanje šta se tačno događa i spređava iznenađenja. Na taj način se gradi povjerenje između članova tima. Jednostavno rečeno, treba komunicirati na način da se minimiza mogućnost iznenađenja kod drugih. Ne sa cijelim timom kroz JIRA-u ili Confluence, a onda nekom privatno e-mail.Scrum preferira male timove. Opšte pravilo je da bi tim trebao imati od 5-9 ljudi. Postoje istraživanja da se preko broja 9 ne doprinosti efektivnosti tima zbog cijene koordinacije i komunikacije veće grupe.Razlozi mogu biti i sljedeći: ljudi neće pribjegavati „iščezavanju u pozadinu“ nadajući se da će neko odraditi posao, članovi manjeg tima su zadovoljniji, pretjerana specijalizacija će se teže desiti u malom timu. Ako imamo potrebu za većim brojem ljudi, jednostavno ih treba podijeliti u više Scrum timova (koordinacija se radi preko scrum of scrums – gdje svi članovi timova dođu zajedno na dnevni Scrum). Broj ljudi može biti i premali, ako nemamo sve potrebne vještine za realizaciju projekta. Tim mora biti fokusiran i posvećen ka ostvarenju cilja sprinta. Fokusiranost znači da je svaki član razvojnog tima angažiran, koncentrirajući se/dajući pažnju cilju koji tim treba implementirati.Posvećenost znači da i kada ide dobro i kada ide loše, svaki član tima je posvećen realizaciji zajedničkog cilja. (Pitati polaznike šta misle o radu na više projekata i o njihovom iskustvu sa tim. Odraditi vježbu cijene multitasking-a.)Jedan od principa vodilja u Scrum-u je da članovi tima trebaju raditi održivim ritmom. (Nema više Igmanskih marševa!) Ako se tako radi, tim će isporučivati world-class proizvode i održavati zdravu i zabavnu atmosferu. Efektivna upotreba Scrum-a zahtjva tim, a ne grupu. Tim je sačinjen od raznolike, krofunkcionalne, kolaborirajuće skupine ljudi koji dijele zajedničku viziju i zajednički rade na ispunjenju te vizije. Grupa je skupina ljudi sa zajedničkom labelom. Po pravilu, tim bi trebao biti dugoročan, jer razna istraživanja pokazuju da je to najbolje – da su takvi timovi produktivniji, efikasniji i proizvode kvalitetnije rezultate. Ekonomika pomjeranja dobro formiranih timova sa projekta na projekat je superiornija od ekonomike pomjeranja ljudi.
• #119: U planiranju sprinta, Scrum tim se dogovara o cilju sprinta, a razvojni tim određuje koje specifične productbacklogstavke, koje doprinose ispunjenju tog cilja, realno može isporučiti do kraja tog sprinta. Da bi stekao pouzdanje u procjenu šta može isporučiti, razvojni tim kreira plan kako da implementira stavke iz productbacklog-a. Te PB stavke i plan čine zajedno sprintbacklog.Vrijeme – Planiranje sprinta je ponavljajuća, just-in-time aktivnost koja se dešava na početku svakog sprinta, kada su nam na raspolaganju najbolje moguće informacije pomoću kojih odlučujemo šta ćemo raditi u sprintu koji predstoji.Trajanje – Za dvosedmični do jednomjesečni sprint, u pravilu, planiranje sprinta ne bi trebalo biti duže od 4 odnosno 8 sati.
• #120: Učesnici – Cijeli Scrum tim sarađuje u planiranju sprinta. Product ownerdijeli svoje razmišljanje o inicijalnom cilju sprinta, prezentira prioretizirani productbacklogi odgovara na bilo koje pitanje koje razvojni tim može imati o PBI-ju. Razvojni tim se fokusira na određivanje šta može isporučiti a zatim pravi realistično obvezivanje (commitment) na kraju planiranja sprinta. ScrumMaster, djelujući kao trener Scrum tima, prati activnosti planiranja, pita probingpitanja, i pomaže kako bi se postigao uspješan rezultat aktivnosti.Ulazi u planiranje sprinta - PBI na vrhu trebaju biti u ready stanju, historijski velocity podatak je indikator koliko PBI je praktično da tim može završiti u sprintu, poslovna ili tehnička ograničenja koji mogu uticati na to šta tim može isporučiti, dostupnost i kapacitet članova tima i inicijalni poslovni cilj koji bi productowner volio da se implementira u sprintu.Angažirani product owneriu sprint ulaze sa dobrom idejom šta žele da tim isporuči do kraja sprinta: “Na kraju ovog sprinta volio bih da tipični korisnik može uraditi prijavu na objavljenu obuku”. Činjenica daproduct ownerzna šta želi, ipak ne znači da je razvojni tim sposoban to isporučiti do kraja sprinta. Realistično obvezivanje(commitment)se postiže kroz kolaboraciju (i pregovaranje) između članova razvojnog tima i productowner-a.Da bi stekao pouzdanje u to šta može završiti, razvojni tim kreira plan kako će postići cilj sprinta. To radi tako što svaki PBI razbija na niz taskova, ni jedan veći od 8 sati, kako bi postigao nivo granularnosti poslova koji će reći šta se stvarno treba uraditi i koliko je stvarno vremena za to potrebno. Ovaj plan se zove Sprint backlog. Zajedno sa ciljem sprinta, predstavlja izlaze i aktivnosti planiranja.
• #123: Jedan od načina da steknemo pouzdanje da tim može isporučiti productbacklog funkcionalnosti je da iskoristimo podatke o velocity-ju tima i procjene veličine PB stavki. Međutim, i procjena veličine i velocity su samo procjene – bez detaljnije analize nije moguće utvrditi tačnost oba podatka. Većina Scrum timova stiče ovaj neophodni nivo pouzdanja razbijajući PB stavke na taskove koje je potrebno uraditi kako bi se stavke uradile u skladu sa dogovorenim Definition of Done.Ovi zadaci se obično procjenjuju u effort-satima a procjena se onda uspoređuje sa kapacitetom tima. Razbijanje stavki poductbacklog-a je vrsta dizajna i just-in-time planiranja kako implementirati PB stavke. Rezultat je Sprint backlog.
• #125: Izvršenje sprinta je kao mini projekat – potrebno je uraditi sav neophodni posao kako bi se razvio potencijalno isporučiviinkrement proizvoda.Vrijeme – Većina vremena u sprintu se provede na izvršenje sprinta, koji počinje nakon okončanja planiranja sprinta a završava sa početkom Sprint review sastanka. U dvosedmičnom sprintu, izvršenje sprinta traje tipično 8 dana.
• #126: Učesnici – Razvojni tim se samoorganizira i određuje najbolji način da realizira cilj sprinta postavljen u planiranju. ScrumMaster učestvuje kao trener, neko ko olakšava realizaciju i uklanja probleme koje tim ne može riješiti, radeći sve što je moguće da pomogne timu da bude uspješan. Product ownermora biti dostupan tokom izvršenja sprinta da pruži potrebna pojašnjenja, da testira posao urađen u toku sprinta, da dogovora prilagodbu cilja sprinta ako se neki uslovi promijene, i da verificira da su ostvarene acceptance kriteriji za PB stavke.
• #127: Jedinstveni alat za planiranje i praćenje za cijeli timTim razbija PB stavke na taskove i tim ažurira procijenjeni ostatak posla (effort-sate). Tim osjeća da je vlasnik plana i posla.Taskovi predstavljeni u burndownchart-u predstavljaju opseg (scope) sprinta.Sve što nije u listi taskova je van opsega sprinta. Također, kako tim na dnevnoj bazi ažurira podatke o preostalomeffort-u, tim zna da li je na dobrom putu da ispuni svoj commitment ili ne.Burndownchart je poput semafora sa svim podacima za fudbalski tim. Izbjegavanje rizika sa informacijama na dnevnoj baziSchedule overrun and cost overrun are two important metrics that get tracked in traditional project management. Mostly they're tracked on a weekly basis. The burn-down chart, on the other hand, provides daily feedback on effort and schedule, thereby mitigating the risks and raising alarms as soon as something goes wrong. For example, if actual progress line (the blue line) goes flat and hovers high above ideal line (the red line), the team knows it is in trouble. Mitigations can be planned right then, rather than waiting till the end. Komunikacijski alat za klijente i druge stejkholdereBurn-down charts are an effective communication tool for customer and stakeholders. This can be printed and placed in an Agile room or shared with relevant stakeholders every day. This provides visibility of project progress on a daily basis. In the absence of an online tool, burn-down can be physically represented using a whiteboard/chart paper and placed in the team area. Placeholder za praćenje implementacije akcija poboljšanja proisteklih iz retrospektive sprintaIt's a good practice to include retrospective action items from the previous sprint as "nonfunctional requirements" in the task breakdown for the current sprint. This way, the team keeps a focus on those action items, and they are also tracked as the sprint progresses.
• #132: Pregled – je kick-offsprintreviewsastanka koji započinje obično productowner (a može i neki drugi član Scrum tima). On predstavlja cilj proteklog sprinta, productbacklogstavke vezane za cilj sprinta, i pregled šta je od planiranog zaista urađeno tokom sprinta. Ako plan nije ispunjen, Scrum tim obično objasni zašto je to tako. Ovo nije blame-pointing događaj; naprotiv sastanak protiče u duhu Scrum vrijednosti: hrabrosti, otvorenosti i poštovanja.Demonstracija – sprintreviewse često pogrešno naziva sprintdemo-om, jer je demonstracija samo jedna od aktivnosti sprintreview-a a ne sama sebi cilj. Jedna ili više članova tima će detaljno objasniti i prezentirati šta je urađeno (može svaki developer zasebno svoj odrađeni posao).Diskusija – Demonstracija inkrementa proizvoda postaje fokalna tačka oko koje se razvija detaljna diskusija. Opservacije, komentari i realne diskusije su poželjne na ovakvim događajima. Naravno, dozvoljeno je da se sve kaže – pa makar ne bilo prijatno za sve uši, jer se ne može uticati na poznavanje Scrum-a od svih učesnika događaja. Sve diskusije samo mogu pomoći Scrum timu da stekne dublje razumjevanje poslovne vrijednosti proizvoda kojeg razvijaju.Adaptacija – Kroz demonstraciju i diskusiju, razvojni tim će biti u prilici da odgovara i postavlja pitanja,poput: Da li se stejkholderima sviđa ono što vide? Da li su potrebne neke promjene? Da li nedostaje neka važna funkcionalnost? Da li radimo overdeveloping odnosno investiramo u razvoj funkcionalnosti koje nisu potrebne?Na ovaj način se radi productbackloggrooming, te ažurira release plan. Kako su svi prisutni i upoznati sa statusom razvoja, može se desiti da klijent odluči promijeniti scope projekta, datum release-a ili budžet. Ovo je pravo mjesto da se identificira potrebna adaptacija proizvoda, kada je to i najjeftinije.
• #133: Retrospektiva sprinta je jedan od najvažnijih ali najmanje prakticiranih praksi iz Scrum framework-a. Važan je jer daje šansu timu da kastimizira Scrum svojim jedinstvenim okolnostima, a istovremeno slabo cijenjen jer neki ljudi misle da im to oduzima vrijeme od obavljanog „stvarnog“ posla dizajna, programiranja, testiranja...Za vrijeme retrospektive, tim ima slobodu da propita šta se dešava, analizira način svog rada, identificira moguća poboljšanja i napravi plan kako da implementira iste. Sve što utiče na način na koji tim kreira proizvod je otvoreno za ocjenu i diskusiju, uključujući procese, pakse, komunikaciju, okruženje, dokumente koje koristi, alate itd.
• #134: Učesnici - Obzirom da je retrospektiva tima vrijeme kada se analizira proces, cijeli Scrum tim treba prisustvovati istom. Ponekad kod razvojnog tima postoji bojazan zbog učešća product owner-a, što može spriječiti tim da bude potpuno iskren u otkrivanju vlastitih „slabosti“, ali potrebno je da u razvoju postoji atmosfera uzajamnog povjerenja, a nekad je problem u procesu upravo do product owner-a, pa je to prava šansa da se product owner-u ukaže na određene prakse u procesu koje se moraju mijenjati. Stejkholderi i menadžeri koji nisu dio tima mogu prisustvovati retrospektivi, samo ako imaju poziv od Scrum tima. Tim mora imati sigurnost da bi otvoreno iskazao primjedbe na trenutni proces, bez straha da će to autsajderi iskoristiti. U protivnom, ako se susteže, gubi se smisao retrospektive.Ulazi u retrospektivu može biti generički (analiza svih aktivnosti) ili unaprijed-dogovoreni fokus (analiza pojedinačne teme, npr. nedostaci u komunikaciji), kao i sve tehnike (brainstorming, grouping and voting) koje će tim koristiti u diskusiji. Dodatno, retrospektiva će vjerovatno tražiti neke objektivno izmjerene podatke (argumente) ali će svaki učesnik vjerovatno doći i sa nekim subjektivnim podacima. Na kraju tu je i backlog insight-a proizvedenih u prethodnim retrospektivama.Izlazi iz retrospektive sprinta uključuje set konkretnih mjera za poboljšanja koje je tim dogovorio da implementira u narednom sprintu.Izlaz može biti i backlog insight-a prikupljenih tokom retrospektive koje tim neće implementirati u narednom sprintu, ali zadržava se mogućnost razmatranja u nekom od narednih. Članovi tima mogu očekivati povećanje uzajamnog povjerenja i timskog duha.
• #135: Postaviti atmosferu znači razvitiblame-free okruženje, jer se ovdje nastoje uočiti greške u procesu a ne tražiti ljudske greške, dodatno se očekuje aktivna participacija od strane svih učesnika.