Hm, dosad smo izbistrili dosta o tome koliko mi se čini, ali ne mogu da se otmem utisku da je to samo personnel management a ne kvalitativno bolji pristup programiranju (bar extreme). Ali da zvuči, zvuči. :)

f

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.

Kao što rekoh, u pitanju je personnel management, što je svakako jedna vrsta umetnosti i sa neospornom vrednošću u industriji softvera, ali rekao bih ne i deo onoga što podrazumevam pod „art of computer programming“. Da sam upravnik projekta sve te stvari bi me jako obradovale i verovatno sprečile čir-dva ili više, ali pošto sam više zainteresovan za metodologije rešavanja (matematičkih) problema programiranjem, cela ta stvar me ne pokreće preterano. Trudim se da postavim ovu razliku uz dužno poštovanje prema svim ljudima koji tu metodu praktikuju i kojima pomaže da prehrane porodicu programerskim hlebom.

f

Da, ovde se postavlja pitanje da li teme vezane za upravljanje projektima spadaju u Art of Programming. Možda i ne, ali gde onda?

Smatram da nije veliki greh da usvojimo poruke o upravljanju projektima, s obzirom da odgovarajući forum ne postoji a da tema nije sasvim bez zainteresovanih. Bar dok se ne namnože dovoljno da ima smisla da ih kolektivno udomimo na neko prikladnije mesto.

Dajte ljudi ova tema je savim na mjestu.

Ako ko treba matematicke probleme da rjesava na elegantan nacin sa bitvise operatorima neka izvoli... mislim da ova tema je na mjestu.

Hvala za linkove evo sam se lijepo zabavio na ovim sajtovima a ponesto i naucio.

Pre nego sto ista napisem o tome, moram da kazem da nisam praktikovao potpuni XP, ali sam dosta o njemu citao u poslednje vreme i neke elemente primenjivao.

Extreme programming nije samo management metodologija, vec metodologija programiranja i managementa razvoja. Misa Kostic je pisao vise o toj strani organizovanja poslova nego o samom programiranju. Ali XP metodologija govori i o programerskim tehnikama kao sto su unit i acceptance testing, refactoring, programiranje udvoje i sl. Ipak, elementi metodologije su veoma povezani medjusobno i smisljeni kao celina koja funkcionise zajedno, tako da se ne mogu zanemariti druge njene vrednosti koje se ne ticu samog programiranja.

Evo da se ja nadovezem nekim svojim iskustvom na ovu diskusiju: programiranje spram planiranja. Potakao me je jedan napis gore, u stilu:"...planiranje me bas i ne dotice, ja zivim za algoritme itd. itd.".
Trenutno sam u firmi u kojoj radim team leader (tako li se pise :) ), i mogu vam reci da nisam nimalo srecan zbog toga. Borim se rukama i nogama da ne idem navise, jer sam DUSOM I SRCEM programer/koder, i ne dam nikom da mi izbije tastaturu iz ruke. Zelim da odgovaram samo za svoj rad, a ne za tudji (ne)rad i nista me drugo ne dotice.

Medjutim...to su zelje, a zivot je nesto drugo. Pre ili kasnije me ceka samostalni projekat, sa sve planovima, ljudima (resursima), rokovima, odgovornoscu itd. itd. Jednostavno, tako se radi, ne samo u mojoj firmi, vec i na Zapadu (kojem svi mi tezimo, je li tako). Ustaljeno je misljenje da svi programeri imaju neki svoj razvojni put, koji se zavrsava negde na mestu Program Manager-a (ili slicno).

Zakljucak: treba odvojiti vreme za blagovremeno ucenje svih tih tehnika planiranja. To zato sto za uspeh firme (na zalost) nije najpresudniji kvalitet koda koji cini njen proizvod, vec i management i marketing i ko zna sta jos sto sve cini trziste. Biti programer vise nije tako jednostavno; treba biti i trgovac, i reklamni agent i od svega drugog pomalo.
Pozdrav i oprostite na digresiji

Rajko

Da bi se ulazilo u ozbiljniju diskusiju oko metodologija razvoja software-a treba znati vise od jedne. Zaista ne znam da li je iko ikada propagirao razvoj kao sto ga ti navodis gde se najpre uradi kompletna analiza pa kompletan dizajn i onda samo kodira i kodira. RUP (Rational Unified Proccess), kao druga "velika" metodologija razvoja software pored XP-a, je tu veoma slican sa XPom.

Pre ulaska u dalju raspravu zelim da naglasim da XP ne poznajem tako dobro kao RUP. Drugo, trudicu se da koristim termine razumljive svima (necete videti reci poput Inception, Elaboration....:) ).

RUP se takodje bazira na razvojnim ciklusima, od kojih se svaki sastoji i od dorade use-casove, i od analize, dizajna.... RUP takodje mada ne tako explicitno kao XP savetuje da se sto pre dobije kod koji "nesto radi" pa da se kroz iteracije poboljsava.
Tako da iterativni razvoj definitivno nije prednost XPa vec je to defakto neminovnost kakvu god razvojnu metodologiju izabrao.






Procena rokove je problem koji na koji ni jedna meni poznata metodologija nije dala niti moze dati odgovor. Nije sef taj koji je bitan, nego klijent. Klijentu ti moras na samom pocetku razvoja da kazes precizan rok kada ce software biti zavrsen i tacno koje ce funkcionalnosti software imati. U tom trenutku ti naravno da ne mozes da imas uvid u sve segmente softwarea, klijentskih zahteva, u potencijalne probleme... Tu pomoci nema, jednostavno moras na osnovu iskustva da procenis vreme. Iterativni razvoj ti omogucava da na vreme uocih potencijalne probleme i da na vreme reagujes ne bili sprecio kasnjenje projekta, ali rokovi moraju da se postuju :).

Procena rokova je mozda i najkriticnija faza razvoja jer iz nje sve proizilazi. Klijent defitivno mora da se ispostuje u rok koji si ugovorio sa njim mora da se postuje. Varijanta da mu kazes "e prijatelju software tvoj nece imati to i to sto smo se dogovorili jer projekat kasni" takodje pada u vodu. Sa druge strane kratki rokovi dovode, ukratko, do nekvalitetnog softwarea zbog cega ce opet na kraju klient biti nezadovoljan. Najveci problem u vezi sa rokovima je sto se ono definisu kada znas najmanje o softwareu koji treba da razvijas.



Ne treba biti iskljuciv. Mozda bi bas pisanje UML diagrama dovelo do toga da greske i ne nastanu.

Ne zelim da kazem da je RUP pristup bolji, uopste nisam kvalifikovan da tako nesto izjavim jer nisam ni ucestvovao ni u jednom XP projektu. XP definitivno ima krajnje zanimljivih resenja koja bih licno voleo da isprobam u praksi.
Sa druge strane nije ni toliko razlicit od RUP. Ima nekoliko stvari u kojima se dosta razlikuju, ali i dosta stvari u kojima su slicni.

Ovo je opet malo jednostran prikaz situacije, po mom mišljenju.



Nije neminovnost. Ako praviš proizvod za "široko tržište" onda se manje-više radi po vodopad modelu. Iterativnost postoji u smislu da se u sledeću verziju proizvoda uključuje "feedback" od marketinga, ali u toku jednog razvojnog ciklusa sve ide uglavnom linearno.




Opet sve zavisi. Ti izgleda uglavnom radiš projekte za poznate mušterije koji nisu deo tvoje firme. Međutim, postoje i druga dva scenarija:

1. Nepoznate mušterije (maloprodaja)
2. "Mušterije" su drugi delovi iste kompanije.

U oba slučaja ovo što si napisao ne pije vodu. I rokovi i funkcionalnost su relativno fleksibilni i sve je stvar procene unutar firme koja funkcionalnost ide u sledeću verziju.

Termin "waterfall" se pojavio jos 70-ih i odatle je sve pocelo, sa raznim varijacijama. Uz manje izmene taj pristup je danas vise zastupljen nego sto se misli.



RUP (o kome nije bilo reci) je pre "prva" nego "druga" metodologija, jer se vise koristi od XP-a. Nigde ne stoji da je XP najbolji uvek i svuda (uzgred, niti je to RUP), tako da s moje strane nema potrebe za raspravama cija je igracka bolja. Evo par clanaka koji govore o razlikama i slicnostima:

http://www.therationaledge.com/content/mar_01/f_xp_gp.html
http://www.therationaledge.com/content/apr_01/f_xp2_gp.html

I generalno poredjenje pristupa:

http://www.stsc.hill.af.mil/crosstalk/1995/01/Comparis.asp

U agilnim metodolgijama ljudi i komunikacija sa njima se stavljaju iznad svega. Ja licno mislim da to nedostaje RUP-u. Drugo, za male projekte ili projekte srednje velicine gde se zahtevi cesto menjaju, RUP je znatno komplikovaniji, a alati su blago receno grozni (opet moje licno misljenje).