Agile Development, good or bad?

25 Jun 2007

Intai de toate, va recomand citirea unui [manifest excelent][1] scris de [Alex Deva][2]. Post-ul asta reprezinta parerea mea despre subiect.

[1]: http://antiagile.indigenious.ro/ “” [2]: http://alexandru.deva.googlepages.com/home “”

Tur rapid prin notiuni

Classic Development (CD) = Stilul abordat de majoritatea companiilor mari, enterprise. Caracteristica principala a acestui stil e stabilirea tuturor specificatiilor tehnice si functionale inainte de-a scrie macar o linie de cod. Totul e planificat in avans si se stabileste un calendar de dezvoltare, dupa care se incepe munca de productie.

Agile Development (AD) = Daca CD este un costum, AD e o pereche de jeans. Caracteristica principala a stilului este viteza de dezvoltare obtinuta prin eliminarea cat mai multor proceduri birocratice. Motto: [Release][3] [early][4], [release][5] [often][6].

[3]: http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/ar01s04.html “” [4]: http://involve.jisc.ac.uk/wpmu/oss-watch/2007/04/20/release-early-release-often/ “” [5]: http://blogs.edgehill.ac.uk/webservices/2007/04/26/release-early-release-often/ “” [6]: http://radio.weblogs.com/0103807/stories/2002/12/01/understandingTheImportanceOfReleaseEarlyReleaseOften.html “”

Alb, negru sau gri?

Daca se poate, gri! Cu alte cuvinte, consider ca o varianta hibrid CD-AD poate aduce rezultate bune.

Specificatiile nu trebuie ignorate

A insista prea mult pe ele, totusi, e o mare inutilitate, pentru ca, sa fim seriosi, cum poti sti din start absolut toate detaliile legate de functionarea aplicatiei pe care-o creezi? Pana nu testezi fiecare functie in parte, pana nu primesti feedback de la utilizatori, n-ai cum sa stii. A nu se ignora specificatiile, dar a nu se exagera cu ele. Odata ce ai stabilit liniile generale in specificatii, beneficiezi de cateva avantaje:

• poti sa estimezi mult mai obiectiv costul proiectului, in timp si bani;
• in cazul in care clientul se razgandeste si vrea sa schimbe ceva in proiect, ai un document pe baza caruia esti indreptatit sa taxezi extra;
• ai specificatii, le “rupi in bucatele” masurabile si nu te gandesti “mai am 30 de zile sa termin proiectul asta, hai sa vad de unde-l apuc”, ci “mai am 30 de zile sa termin proiectul asta, azi fac bucatica asta”, pentru ca doar asa poti sa [get things done][7]!

[7]: http://en.wikipedia.org/wiki/Getting_Things_Done “”

Contractul e obligatoriu

Am lucrat si fara contract si cu. Pe firma si ca freelancer. Cu factura fiscala si fara. Indiferent de cum lucrezi, ai nevoie de un contract in care sa fie trecute cateva aspecte ale colaborarii (e OK fara contract la proiectele foarte mici, care nu presupun multa planificare si nici nu dureaza mult):

• specificatiile proiectului trebuie trecute in contract;
• modalitatea si parametrii de plata trebuie trecuti in contract;
• ce se intampla daca ulterior apar cereri de modificari neprevazute in specificatiilor initiale;
• unde incepe si unde se termina proiectul/contractul (aspect vital!).

Release early, release often

Acesta este unul din cele mai meseriase principii in web development, dar si cel mai greu de urmat! Lanseaza un prototip functional, cat de repede posibil. Urmareste feedback-ul utilizatorilor. Imbunatateste produsul. Lanseaza versiunea imbunatatita. Asculta-ti utilizatorii. Implementeaza ce trebuie implementat si lanseaza versiunea imbunatatita. Si tot asa…
Majoritatea utilizatorilor finali vor vedea produsul nostru diferit de cum il vedem noi, ca developeri si il vor folosi in cele mai neimaginabile moduri :) . Nu sunt un expert in [user-testing][9], dar toti expertii spun cat de imprevizibili sunt utilizatorii. Daca succesul produsului tau depinde de utilizatori, nu iti doresti sa lansezi o versiune finala netestata intensiv, pentru ca va trebui sa schimbi mult.

[9]: http://en.wikipedia.org/wiki/Usability_testing “”

Relatia client-developer

Ei bine, ce-am descoperit eu e ca aceasta relatie joaca un rol decisiv in succesul sau insuccesul unui proiect. Exista mai multe feluri de clienti, iar Alex ii prezinta foarte fain. As vrea sa fac si eu o clasificare (probabil incompleta, dar din proprie experienta) a clientilor:

1. Clientul “pietzar”, de-obicei, e genul de client care vrea un site dinamic si ieftin. Cu el nu-ti doresti sa te-ncurci, doar daca esti muritor de foame. El e administratorul unei firme mici/medii in industrie/servicii/agricultura, vorbeste lejer de zecile de mii de euro, e zgarcit si se targuieste ca-n piata. Il refuzi politicos, recomandandu-i alt developer, sau ii faci o oferta de pret care sa compenseze pentru atitudinea lui.
2. Clientul pe steroizi e cel care, iertat sa-mi fie, se baga. Si vrea sa stie. Si sa comunice 2-3 ore pe zi. Si sa vada progres de la o ora la alta. Si nu e niciodata multumit, desi faci EXACT asa cum ti-a spus anterior. Si se tot razgandeste. Pe de-asupra, mai e si zgarcit si nu e dispus sa plateasca pentru toate iteratiile facute din cauza lui. Oh, da, ii cunoastem! Acest tip de client este o versiune “imbunatatita” a clientului “pietzar”.
3. Clientul invizibil semneaza contractul, iti da cat ceri si cum ceri, iti spune in mare cam ce ar vrea si asteapta sa-i livrezi produsul final, perfect. E mai putin stresant decat clientul pe steriozi, dar vai si-amar la livrare! Cu acest gen de oameni e vital sa ai un contract bun, daca nu vrei sa iesi in pierdere.
4. Clientul dispus intelege domeniul (se pare ca am dus discutia mult in domeniul dezvoltarii de site-uri web, dar principiile sunt valabile si in alte domenii), cunoaste costurile, eventual cere mai multe oferte, eventual incearca sa negocieze costurile si, in general, e genul de client care se implica atat cat ii ceri. Proiectul se desfasoara in parametri normali, livrarea se face la termen, toti sunt fericiti. Nu ies multi bani, dar nu e nici mult stres. E o chestie… constanta.
5. Clientul partener e rar. Am avut privilegiul de-a avea un astfel de client pentru aproximativ 2 ani. Acesta e clientul care are idei, care e dispus sa investeasca, cu el poti comunica la acelasi nivel si te face sa simti ca participi la ceva maret… El are pasiune pentru ceea ce face, stie unde vrea s-ajunga si cum il poti ajuta si reuseste sa-ti transmita din pasiunea sa. Acest gen de client ne provoaca sa devenim mai buni in ceea ce facem.

Alege sa refuzi

Freelancerii si companiile mici (sub 5 oameni) sunt cei mai afectati de supra-incarcare cu proiecte. Ai 1-2 proiecte mari, dar mai iei vreo 2-3 mici, pe langa, ca “deh, nu iau mult timp”. Stii ce-ti iau, insa? Energie si productivitate. Te vei grabi sa le termini pe cele mici, “c-apoi m-apuc de asta mare” si nu vei mai avea timp si energie destula incat sa duci proiectul mare la bun sfarsit. Mi s-a intamplat… e groaznic!

Domeniul asta e atat de vast, piata e atat de mare (si in continua crestere!), incat trebuie sa selectam—nu le putem face pe toate! In Romania, mai ales, trebuie sa participam cu totii la educarea clientilor. Cei mai multi nu considera web development-ul ca industrie serioasa, asa ca nu inteleg valoarea muncii noastre si, implicit, nu sunt dispusi sa plateasca pentru ea.
Adevarul este ca sunt atatia ueb dizainari care habar n-au ce zic si fac, dar fac reclama proasta industriei! “Imi face nepotu’ meu cu 200, iar tu-mi ceri 1,500!?” Suna cunoscut?

Stiti ce mi se mai pare interesant? Faptul ca exista tot mai multe firme meseriase, in Romania, care nu-si gasesc oameni capabili. Nu mai pleaca asa multi ca in anii trecuti. De ce sa nu ramai in Romania si sa fii platit bine? Dar esti destul de bun incat sa fii platit bine? Ce se-ntampla, ne-a lovit lenea?

Cam atat… ma duc sa-mi fac un [site dinamic][11] ca mi-s ueb dizainar, manca-tzi-ash!

[11]: http://www.myspace.com/ “”