Odlicnu prezentaciju SCRUM-a mozete naci na:
http://www.softhouse.se/Uploades/Scrum_eng_webb.pdf
Obratite paznju na svaku recenicu jer je svaka bitna.
Najveci utisak na mene je SCRUM/Agile ostavio u pogledu
prihvatanja promena. Verovatno ste se svi susreli sa project plan-om koji jednu i po godinu unapred prikazuje sta ce tim da radi. Koliko puta je taj plan zaista sproveden? Umesto toga, u SCRUM-u se planira na relativno kratke staze (sprint traje mesec dana max) sta ce tim da radi i to se relativno cesto i ostvari.
Druga bitna stvar koja je na mene ostavila utisak u firmi u kojoj sam radio (F-Secure) je
prihvatanje realnog stanja stvari. Ne znam da li je ovo bas deo SCRUM-a, ali bi trebao da bude :-). Npr, kada se planira sprint, svaki programer uzima/prihvata deo stvari koje treba da se odradi u tom sprintu i odredjuje koliko mu vremena treba da ostvari svaki od zadataka. Pri tome:
- u firmi se smatra da programer efektivno radi 4.5 sata u toku dana. ovo je bitno, jer je i realno. ostatak vremena provodi se veoma cesto citajuci/odgovarajuci na e-postu, sastanci, itd.).
- u okviru zadataka za naredni sprint obavezno se rezervise vreme za bug-fixing, jer na kraju sprinta treba demonstrirati funkcionalni proizvod, a i odrzavanje kvaliteta aplikacije ima prednost nad novim funkcijama.
Forsiranje komunikacije u okviru tima u odnosu na pisanje ogromne dokumentacije je takodje odlicna stvar. Ako prihvatite promene kao normalnu stvar, zaista nema smisla pisati tone dokumentacije da bi se objasnilo nesto sto ce se promeniti mozda vec sledeceg meseca.
Dnevni kratki sastanci (uz kaficu :-) ne duzi od 10 minuta na kojima svako iznosi sta je radio i sta planira da radi do sutra (ne duze od 1 minuta svaki, samo par recenica) su dobri za motivaciju (nema mnogo zabusavanja :-) ali i sluze SCRUM masteru da u svakom trenutku zna pravo stanje stvari. Mnogo bolje resenje od nedeljnih sastanaka koji znaju da se oduze i na kojima polovina ljudi spava a druga polovina se dosadjuje.
Na kraju, sprint review je dobra praksa gde se prezentuje rezultat sprint-a. Bitna stavka je da se prezentuje
funkcionalan softver. Ovo je velika prednost u odnosu na klasicne metode gde se obicno 6 meseci do godina dana radi na necemu i onda se ocekuje da to bude gotovo - a cesce je to nesto puno bugova i problema i menadzment tek tada shvati da je potrebno jos x meseci da bi se proizvod stabilizovao...
Sprint retrospective je veoma bitan u smislu
prihvatanja promena (ovo stalno naglasavam, ali normalno je za organizacije da probaju nesto da promene, a posle par meseci sve se, po inerciji, vraca na staro). Ovde se analizira protekli sprint i sta je bilo dobro a sta lose. Treba komentarisati (zaliti se na...:-) sve - od razvojnih alata, metoda komunikacije (skype, irc), metoda pisanja/skladistenja dokumenata, suvise prekida, lose organizacije, nekvalitetne kafe itd, itd... Cilj je da se celo okruzenje stalno menja i unapredjuje a i da se eksperimentise sa novim stvarima (ne treba robovati navikama, pogotovu u dinamicnom svetu IT-a).
Ja se bas raspisao, ali to samo govori o pozitivnom utisku koje je SCRUM na mene ostavio. Najbitnija stvar je - SCRUM nekako prirodno legne programerima. Uz to, stvori se pozitivna dinamika u timu koja pozitivno utice na kvalitet/kvantitet/brzinu rada. Naravno, sve ovo treba da je dobro podrzano od menadzmenta koji takodje treba da prihvati ovu novu filozofiju.
Postoji jos cela filozofija kako raditi SCRUM kada se posao radi za musteriju koja zeli gotov proizvod za x meseci i zeli detaljan plan projekta, ali o tom mozda neki drugi put...
pozdrav.
Agile - SCRUM - Iskustva i Preporuke
Re: Agile - SCRUM - Iskustva i Preporuke
