[quote=ernad_husremovic]> Amar i ja smo obojica u svabija firmama koje rade po Agile development modelu …
Da li ste imali neku formalnu obuku, ili ste to usvajali u hodu.
Kako ste usvajali agilne principe ? Koje uloge unutar vašeg tima postoje ?
Koju od agilnih metodologija koristite ?
Da li bi vi, na osnovu tih iskustava, da pravite svoju firmu organizovali radne procese u skladu sa agilnim principima ?
Sorry što ti postavljam ovoliko pitanja. Samo preskoči što ti je zahmet, a što možeš odgovori.[/quote]
Ma samo ti pitaj, forum i jeste za to.
Dakle, ja sam u DE vec 5 godina a unazad 3 mjeseca sam u novoj firmi koja koristi Agile Development. Dakle, za mene je to 01.11.2012 bila potpuno nova tema o kojoj sam cak i teoretski znao jako malo. Medjutim, iznenadio sam se kako sam se lako i brzo uklopio u citav proces. Sto ce reci da je Agile Development jednostavno i precizno struktuiran i lako razumljiv cak i pocetnicima.
Ja nisam imao nikakvu formalnu obuku, sve je islo u hodu. Naravno, u pocetku sam postavljao bruku pitanja, ali je citav proces toliko logican da sve da u hodu nauciti. I ne zahtijeva puno vremena. Ja sam vec od drugog Sprinta aktivno i ravnopravno ucestvovao u cijelom procesu.
U principu koristimo Scrum metodologiju, uz neki okvir FDD-a (Feature Driven Development). Znaci sve pocinje od nekog zeljenog Feature-a koji uglavnom definise Project Owner (jedna od uloga u timu). Project Development definise zeljeni feature, u nasem slucaju koristimo Jiru, ali se jednako dobro moze raditi i sa opensource alatima, tipa Redmine-a. Definisani zeljeni feature se u ovom trenutku nalazi u Backlogu.
Slijedeci korak je Estimates iliti procjene. U principu, ovom koraku obicno prethodi bar jedan pod-korak - analiza samih developera koji bi konkretno mogli biti zaduzeni za feature, ali kako ovaj pod-korak ne ukljucuje citav tim (sto je neka filozofija Agile Developmenta), onda ga i ne stavljam kao poseban.
Dakle, prilikom Estimates-a, Project Owner bira feature iz Backloga (po prioritetima koje je on utvrdio) i o tim featurima se raspravlja i na kraju se sam feature procjenjuje, odnosno, svaki feature dobija odredjen broj Scrum poena. Scrum poeni trebaju unaprijed biti definisani i opisuju slozenost implementacije odredjenog feature-a. Dakle, ne konkretno vrijeme koje potrebno da se feature implementira. Jer moze se desiti da implementacija zavisi od mnogo faktora na koje developer sam ne utice i slicno. Svaki Feature dobije po jedan tzv. Ticket. Moze se naravno desiti i da jedan feature dobije vise ticketa.
Dalje, u slijedecem koraku se pravi Sprint. Sprint je obicno definisan kao odredjeno vrijeme u kojem se treba zavrsiti odredjen broj Scrum poena. Trajanje Sprinta se ranije definise, obicno su to dvije sedmice. Broj Scrum poena je tesko unaprijed znati, recimo mi trenutno imamo sesti Sprint a jos nismo tacno utvrdili koliko se Scrum poena moze odraditi u jednom Sprintu. Naravno to zavisi i od velicine tima, preciznosti procjene i slicno. Ali bitno je naglasiti da se broj Scrum poena definise uglavnom na osnovu iskustva, odnosno da je potrebno par Sprintova da se to definise. Znaci, Scrum Master (jos jedna od uloga) prebacuje tickete iz Backloga u Ready for Work i na taj nacin kreira Sprint.
Sprint se realizira tako sto svaki developer povlaci njemu/njoj zanimljiv Ticket iz Ready for Work polja u Work in Progress polje. Onoga trenutka kada je posao gotov, isti taj developer povlaci ticket iz Work in Progress polja u Work Done polje. Tada neki drugi Developer povlaci taj isti ticket iz Work Done polja u Review in Progress polje i kada zavrsi Review code-a, povlaci taj ticket u Review Done polje. Onda na scenu stupa QA koji povlaci taj ticket u QA in Progress polje i kada zavrsi u QA Done polje. Na kraju kada su svi defecti popravljeni i kada je feature fully tested, povlaci se ticket iz QA Done u zeleno DONE polje. Na samom kraju pravi se Release i deploya se feature sa Stage-a na live sistem.
Naravno, jako bitan detalj su Dailies, odnosno dnevni kratki sastanci na kojima se ukratko kaze sta se postiglo od proslog dailya i sta se planira za taj dan. Na taj nacin izbjegava se situacija u kojoj dva developera rade na istom ticketu a usput su svi up to date ko sta gdje radi.
Sprint se zavrsava analizom, dakle sta je uradjeno i u kojem vremenu. Nakon svakog Sprinta odradi se jos i Retrospective, znaci sastanak na kojem se prica o iskustvima tokom samog sprinta, i to o dobrim iskustvima jednako kao i o losim. Ako se definise neko lose iskustvo, onda se ujedno definise nacin kako se to moze popraviti sto se pretvara u Action Point, znaci konkretan zadatak koji se treba implementirati do tokom slijedec Sprinta.
Od uloga u timu imamo slijedece:
- Project Owner - Tito nas. Znaci lik koji ima zelje, cestitke i pozdrave koje mi treba da implementiramo. Project owner ne smije biti jedan od developera i ne smije biti Scrum master.
- Scrum Master - zaduzen za moderaciju prilikom Estimates-a i Sprint planinga. Lijepo bi bilo da Scrum Master takodjer nije jedan od developera, u svakom slucaju ne smije biti Project Owner.
- Project Lead - za svaku programersku oblast (u nasem slucaju Java, DB2, XHTML/CSS) ima po jedan project lead koji je zaduzen da nadgleda proces. Ovo je manje vise neformalna uloga, ali eto, mi je imamo.
To su neke tri definisane uloge, uz to imamo Developere, mene kao Admina i jednu tetu koja radi QA. Arminova firma ima jos i Tester-e koji se cesto koriste kod Agile Developmenta.
To je ukratko kako mi radimo, mozda pomogne.
Ja sam prije ove firme radio u jednoj drugoj firmi koja nije koristila Agile Development i mogu primjetiti ogromnu razliku. Prvo, nema problema sa kasnjenjem i probijanjem rokova. Naravno, zna se desiti da se procjena lose odradi, zna se desiti da se neko razboli i slicno, ali u poredjenju sa metodom bez Agile Developmenta, odstupanje od planiranog je znatno manje.
Druga prednost su Daily Meetings. Iako nekome zvuci previse da tim svaki dan sastanci. moje je iskustvo da je ovo neophodan korak u software developmentu. Taj kratki sastanak (u teoriji, svaki ucesnik ima 3 minute da kaze sta je radio od posljednje daily i sta ce raditi danas) je odlicna mogucnost da se a) najave moguca kasnjenja (i razlozi za to), b) potrazi pomoc ako se gdje zapelo, c) dobije kontinurani pregled situacije gdje se trenutno nalazimo.
Sve ovo zajedno je bar u mom slucaju rezultiralo masovnim reduciranje work-related stresa. Cak i ako se desi da nesto totalno pogresno procijenim, i project owneru a i svima ostalima je mnogo draze kada ih o tome informisem na vrijeme :).
I jos oko agilnih principa, teorija Agile Developmenta kao takvog je jako mala. Sve ostalo su ustvari potrebe tima, pa se tako principi predlazu i usvajaju u hodu. Tako je bar kod nas slucaj. Neko iz tima skonta da je u samom procesu potrebna neka izmjena ili potrebno nesto novo. Predlozi to na Dailyju, napravi se kratki sastanak o tome i prijedlog se usvoji ili ne usvoji, zavisno od odluke tima. Bitno je napomenuti da takve odluke donosi iskljucivo tim, a ne Scrum Master ili Project Owner.
Eto, to bi bilo ukratko, ako imas jos pitanja, samo pucaj.
P.S. zaboravih, uz sve ovo ide jos i Continuous Development sa Jenkinsom (koji se ubrzo biti prosiren i na Continuous Deployment) kao i FitNesse testovi umjesto standardnih unit testova.
