Ako je vec toliko izbistreno, trebalo bi da si napredovao malo vise od utisaka. Agile methodologies (i XP kao njihov predstavnik) imaju itekako bolji pristup i programiranju i razvoju softvera uopste. Nije to samo pair programming, nego novi nacin planiranja i implementacije celog projekata.
Zamisli da MORAS da zavrsis projekat za 3 meseca i da ne mozes da pomeris rokove (u ovoj prici si project manager). Ako radis na tradicionalni nacin kao sto te uce u skoli, moze lako da ti se desi da 15 dana pre planiranog kraja shvatis da ce ti trebati jos par dodatnih meseci. A kome to da kazes?
Agile methodologies imaju drugaciji pristup. Umesto da mesec dana analiziras, mesec dana dizajniras i mesec dana programiras, napravi se ciklus od nedelju dana. Kada prikupis nesto malo zahteva, od njih napravis user stories, features ili use cases (kako ko voli da zove TO). Zatim svakoj od njih uz pomoc onoga ko ti trazi projekat dodelis prioritete i ocenis tezinu. I pocnes. Malo dizajna, malo programiranja. Posle nedelju dana imas neki osecaj koliko mozes da uradis (moze da bude prilicno varljiv osecaj, ali je bolji nego da liznes palac i okrenes ka vetru, kao sto se inace radi). Pomnozis to sa 13 (broj nedelja u 3 meseca) i pocnes od toga. Za sledecu nedelju planiras da uradis samo onoliko koliko si uradio prosle nedelje. Posle dve nedelje znas nesto bolje (i opet korigujes matematiku). I tako dalje. Na taj nacin mozes sefovima na vreme da kazes kako stoje stvari, a ne 10 dana pre kraja projekta. Recimo da shvatis da ne mozes da zavrsis projekat na vreme. Tradicionalna resenja bi bila:
1. da zaposlis jos programera
2. da teras postojece programere da rade vise (i subotu ako treba)
3. da smanjis kvalitet koda na racun brzine (tj. vise bagova, spageti kod itd)
Ni jedno od toga ne valja. Recimo da zaposle 3 nova programera (malo verovatno, ali eto). Oni ce da isisaju krv starijim programerima, jer niko od novih ne zna skoro nista o okruzenju, specificnostima biznis modela i aplikacije, standardu za kodiranje itd. itd. Neko mora da ih nauci. Tako se produktivnost za odredjeno vreme cak i smanji, umesto da se poveca. I dok se ta ista produktivnost efektivno poveca (zato su novi i dosli), odose svi vozovi.
Za broj 2. no comment. Programeri su cudne zverke koje se ne teraju bicem. Doci ce oni, ali to nece ni na sta da lici. Kada jednog od njih ostavi devojka (ko zna gde se on smuca subotom, ma sta projekat, druga je po sredi), sve ce da pukne.
Za 3 isto nema potrebe za objasnjenjem zasto ne valja (ponekad moja omiljena tehnika, priznajem).
Dakle, resenje je broj 4 koje tradicionalne metodologije ne predvidjaju - scope of the project. U dogovoru sa sefovima izbacis funkcionalnosti koje su manje vazne, a to dodas posle (ili nikad). Bitno je da za 3 meseca zavrsis projekat tako da zaista radi ono sto je najvaznije i ono sto ce korisnici prvo da gledaju i rade. Lakse ces da prezivis ako neko primeti da nedostaje neka manje vazna stvar, nego da ima bagova u kljucnoj funkcionalnosti. Jako je vazno da prioritete mozes lako da dodeljujes/menjas u toku samog projekta, sto u tradicionalnim metodologijama ne mozes bas jednostavno da radis. Cak i kada izadju novi zahtevi, napravis novi use case dodelis tezinu i prioritet i teras dalje. Analiza/dizajn/kodiranje u malim iteracijama te spasavaju nevolje. Isto tako izbegavas use case paralysis, sto je situacija kad se ceo tim mesec dana svadja (bez napretka), jer ne mogu da se dogovore koji UML dijagram je najbolji i da li da koriste 'include' ili 'extend' za use case.
Inace UML dijagrami su...heh...gubljenje vremena u situacijama kao ova gore.
A computer once beat me at chess, but it was no match for me at kick boxing.