Koraci za razvoj aplikacije i njeno instaliranje

Jedan od mogucih nacina, koji se pokazao odlican sa timovima koji ga pravilno koriste je agilno planiranje:

1. Ispisi user stories - kratke price od par redaka koje kompletno definiraju funkcionalnost aplikacije

2. Igraj planning poker sa developerima i oznaci te price sa bodovima tezine

3. Svaka dva tjedna uzmi story, razbij ga u minijaturne taskove, taskove oznaci potrebnim vremenom (ako task treba vise od 3 dana, razbij ga u manje dijelove) i podijeli taskove ljudima dok svatko nema 8 dana posla (2 tjedna * 5 radnih dana - dan planiranje - dan debugiranje)

4. Napisi testove za svoj task i pisi kod dok ne zadovoljis testove

5. Loop od 3-5

Cisti XP. XP ne postoji bez TDD-a, koji je okosnica stvarne produkcije. Agilno planiranje (da se zadovolje suits je drugi dio).

Provjereno, radi vec preko 5 godina za mene, a manageri se ukljucuju koliko ih volja ili nije - ja pisem unit testove kao i svaki drugi kod i jednostavno to ni ne spominjem kao nesto posebno. Testovi su kod kao i svaki drugi.

Prakticno, moram priznat da su i manageri sretni jer napokon sa svojim prposnim debeljuskastim rucicama svaka dva tjedna mogu birati sto im je prioritetnije za izraditi, mogu na osnovu statistike bodovi/iteracije izracunati velocity i odrediti koliko-toliko tocan launch-window i sve ostale divotarije na koje su navikli putem industrijske revolucije, a nikako da shvate da programiranje nije egzaktna znanost kao gradnja mosta.

Ja zadovoljan, oni zadovoljni, ostali devovi zadovoljni... bilo bi mi dovoljno samo to sto napokon devovi odlucuju koliko ce trajat izrada nekog taska.

Objasnit  cu u vise detalja ako treba.

Trajanje se odredjuje onda kad se story razbije u taskove, odnosno kad dodje vrijeme da team implementira storye. Sve se radi timski, pa tako i odluke o tome koliko nesto moze trajati. S obzirom da se ciljaju taskovi koje vise-manje svatko moze procjeniti da li ih moze rijesiti u dan ili dva, malo je mjesta za pogresku. Normalno, nepredvidjene situacije se adresiraju kao takve svako jutro, tako da se moze odluciti sto dalje... npr. isplati li se jos vremena odvojiti za task, da li je potrebno popricati s nekim drugim devovima, u timu ili u firmi, upariti dva deva u pair za taj task, proslijediti task nekome drugome. Ovako nalistano sve to zvuci dosta birokrativno, ali se u principu odvija dosta prirodno. Ja bi volio vise prirodnije, ali project director i project manager su, well, manageri, a oni dobro rade s rutinama pa eto... neki kompromis.

.

Kad odredjujes tezinu nekog user storya planning pokerom, onda devovi kratko razgovaraju o storyu (ali kratko), i onda svatko odabere kartu (alla fibbonaci niz od 1 do 24) i spusti je prema dolje. Kad svi okrenu karte, onda se vidi ili slicnost ili razlika, i obicno je odgovor negdje u sredini. Npr. ako od 5 devova njih 3 spuste 8icu, jedan spusti 3 a drugi 14icu, to najvjerojatnije znaci da ovaj koji je spustio 3 nije razmislio o nekom bitnom segmentu taska i da ovaj koji je spustio 14 ima u glavi nesto sto nitko nema ili nema pojma kako bi to napravio. Onda slijedi razgovor, objasnjava se zasto je tko odabrao te brojeve, objasnjavaju se praznine, neznanja, adresiraju problemi... to traje dok devovi ne spuste brojeve koji su jako bliski jedan drugima - odnosno, svakome je jasno o cemu se tu tocno radi i koliko je to otprilike posla. Bitno je napomenuti da broj ne odredjuje tocno koliko dana traje task, samo tezinu. S obzirom da je niz ogranicen, od 1-24, nekako treba u glavi rasporediti sto smatras jednostavnim taskom a sto epic taskom.

.

U iteracijskim sastancima, svaka dva tjedna, manageri odaberu storye (featureove) koje bi najradije vidjeli u igri, a devovi ih onda razbijaju u taskove i zajednicki dogovaraju tocan posao koji treba odraditi i njegovo trajanje. Nitko ne dobija odredjeni task, vec su svi na taskboardu i svatko uzme sto misli da moze odraditi. Ako je neki task 'mutan' i ne mozemo naci tocno rijesenje, zakaze se design meeting, gdje se igramo CRC karticama, piskaramo klase, procese, komponente, dok ne shvatimo koliko je tu tocno posla, pa onda ponovimo planiranje samo za taj task. Iako se to ne preporuca, obicno sredimo to planiranje odmah sutradan i ostavimo task u iteraciji jer rijetko neki task naraste da bude van dva tjedna posla, koliko god mutan bio. Ako ipak naraste, onda uzmemo storye koji su primarni ili temeljni, oni idu na plocu a ostali taskovi za slijedecu iteraciju.

.

Neki put ti treba vise vremena, neki put krace, neki put ubijes dvije muhe jednim udarcem pa se u nekoj statistici lagovi u taskovima izjednace. Bitno je da kroz nekoliko iteracija mozes odrediti koliko user storya tim moze odraditi u 2 tjedna, zbrojis one bodove tezine s pocetka price - to je brzina tima. Ako podijelis zbroj svih preostalih storya sa velocityem tima, dobit ces ugrubo launch window, ako si normalan uzet ces nekih 30ak% pogreske u plus i minus, ali i to je vec dovoljno precizno.

.

Onda, ako ti to ne odgovara, razmisljas sto ces dalje. Osnovno pravilo je 'cutting is shipping', pa neke storye ostavljas za kasnije, ali ako nisi na kraju projekta mozes pridruziti vise ljudi projektu.

.

Izmjene koje smo mi nekako prirodno pridodali sistemu je da na sastancima obicno odredjujemo best-case scenario za taskove, jer smo vec dovoljno duboko u projektu da neka design pogreska iz proslosti moze napraviti pravi mayhem, a refactoring moze biti i dugotrajan i bolan. Takodjer nekako prirodno je ispalo da cijeli story pripadne jednoj osobi - iako sam ja protiv toga, ispalo je kratkorocno da jedna osoba brze odradi sve taskove za story sama nego da dijeli taskove s ljudima. Normalno taskovi se dijele ako je netko usred iteracije ostao bez posla a druga osoba je na prvom tasku jos. Pokazalo se na kraju da sam u pravu oko ovoga, jer obavljanje cijelog storya neumitno zadrzava znanje cijelog featurea u jednoj osobi - evo jos uvijek se pilim sa client-side pathfindingom jer je dynamic loading sustav smece kakvo nisam vidio od svojih pocetaka u C++ i WinAPIu - napisano od strane jednog jedinog covjeka koji nije imao sanitycheck da ga zaustavi. Takodjer nam je velocity od pocetka pao drasticno jer smo izgubili jednog clana tima, taskovi su postali premutavi, a manageri nisu razumjeli zasto rijesavanje nekih taskova prije drugih trazi manje posla. Takodjer, dugo nismo imali refactoring iteraciju i neki spageti u kodu se vise ne mogu raspetljati ni za mjesec dana, kamoli za dva tjedna.

Sta ces, niti jedan sistem nije savrsen, ali ja trenutno krivim porazavajuci omjer (studenti, neznalice, lijencine) : (ljudi koji znaju sta rade, ljudi koji rade)

Makar ne crunchamo jer je netko polizao prst, digao ga u vjetar i rekao "We can do that in two years", pa onda imao projekt koji kasni dvije godine.

.

A da, zaboravio sam ti odgovorit na najsladje pitanje sa pocetka :-)

Imali smo i mi diskusija gdje tupis manageru "NEMAM POJMA KOLIKO TO MOZE TRAJATI JER NEMAM POJMA O TOME!" a on ti odgovori "Ma, kako nemas nista, moras imati makar neki feeling koliko to moze trajati". Ima situacija kad nitko nema pojma sto bi trebalo napraviti, ali tu je dobrodosla ta nasa izmjena da se odmah slijedeci dan dva u iteraciji napravi istrazivanje - normalno doda se research task sa svojim vremenom. Ako uspijes u dan dva researcha skuziti sta treba napraviti, onda ide opet brzinsko planiranje za te taskove. Ako ne, ili ako taskovi eksplodiraju odjednom u neke epice, onda to ide za slijedecu iteraciju.

I zaboravio si još navesti refactoring :)

A za kvalitetan refactoring ti trebaju i kvalitetniji ljudi. Što ponekad zna predstavljati veliki problem...