25
Jun 07

Agile Development, good or bad?

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

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 early, release often.

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!

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, 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.

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 ca mi-s ueb dizainar, manca-tzi-ash!

  • Povesteam mai devreme cu "Bogdan (a.k.a. kelye)":http://blog.anarhism.ro/ si imi zicea ca un exemplu foarte bun de agile dev este "Ghelir":http://www.ghelir.ro/. Indeed!
    Ghelir este un magazin virtual care vinde un sigur produs timp de o zi. Sunt sigur ca "Dragos":http://dragosh.bloghost.ro/ si echipa lui l-au planificat mult, inainte, dar au lansat site-ul de-ndata ce a fost functional. Din primele zile si-au dat seama ca socoteala de-acasa nu se potriveste-ntotdeauna cu cea din targ, dar au fost flexibili si s-au miscat *agil*, reusind sa depaseasca momentele de criza. Buna treaba!
  • @kelye, nu as subestima valoarea unui site web, oricat de "4 pagini HTML" ar fi. Gandeste-te la organizarea informatiei, design, uzabilitate... Se scrie bine despre aspectele astea pe "blog-ul Simplissimo":http://blog.simplissimo.ro/!

    "Alege sa te respecti" -- indeed! Despre asta e vorba, la urma urmei. Sa fim seriosi, activam intr-un domeniu in care e greu sa fii muritor de foame! Trebuie sa ne respectam!
  • kelye
    Ar mai fi un aspect de luat in calcul cand se discuta de web development.
    Exista "site web" si "aplicatie web".
    Primul il rezolvi oricand cu orice tip de client fara prea multi nervi si in cel mai Agile mod posibil.
    O aplicatie totusi nu e asa usor de abordat. Trebuie gandita mult la inceput.
    Si asta ar fi rolul project manager-ului. Sa ia legatura cu clientul... sa vada ce vrea, sa "vada" aplicatia finala si, pe baza experientei, sa faca sugestii de functionalitati pe care sa le discute cu clientul iar in final sa se inceapa scrierea codului.

    "Problema esenţială cu Agile e că programatorul trebuie să muncească, alert şi ingenios, toate cele 7-8 ore cât stă la servici."
    ...si dupa 2 luni de munca Agile ai un burn-out de toata frumusetea ... iar daca nu, sigur te trezesti in 6 luni ca ai pierdut contactul cu tot ce inseamna "noutate" in industrie si ajungi sa te crezi un zeu in cei x metri patrati ai biroului. ( asta nu inseamna ca sunt de acord cu frecatul mentei la munca in general)

    "Alege sa refuzi" as inlocui cu "Alege sa te respecti"
    Din pacate multi ajung la concluzia asta dupa ce trec prin gastrita/ulcer. Eu acum cer pe un magazin virtual peste 1500E, nu pun osCommerce, platesc designer sa faca bine ceea ce face (chiar daca as fi putut sa trag eu de un template in photoshop) si incerc sa fac o aplicatie "manusa" pentru client.

    “Imi face nepotu’ meu cu 200, iar tu-mi ceri 1,500!?”
    Din pacate sunt si firme care cer cat nepotul si arunca repede un template furat peste un script free si gata... au solutia.
    Din fericire multi s-au fript cu ei si incep sa se gandeasca de doua ori daca "ieftin=bine".
  • @seraphim, priveste lucrurile din perspectiva urmatoare: orice relatie de business pe care o ai cu cineva (client, de ex.) se bazeaza pe incredere. Discuti cu el despre detaliile proiectului, platii, etc. Practic, "semnezi" un contract verbal.
    Dar "verba volent, scripta manent", asa ca de ce nu ai extinde intelegerea verbala intr-un document scris, semnat (electronic e suficient) de ambele parti? Nu ai nevoie de firma ca sa inchei un contract. Sigur, nu il vei putea folosi dpdv legal, dar in foarte multe cazuri nici nu vei avea nevoie. Contractul include conditiile unei relatii, ale unei colaborari.
    Apoi, tu ii faci un serviciu clientului si nu el tie. Tu stabilesti conditiile :).

    @Andrei, good point! Nu iti poti permite sa freci menta! ;)

    @Aurelian, am aruncat o privire pe acel model de contract si pare sa contina sectiunile importante.
  • Ai scris bine domnule! Cel putin asta e parerea unui newbie ... Insa recunosc ca am multe semne de intrebare la unele chestii. Oricum, considerand experienta ta mult superioara, nu cred ca pot avea vreun repros.

    Referitor la contracte: e cam greu sa te gandesti la astea (ca sa nu mai zic si sa le folosesti) cand nu stii despre ce e vorba. Zicea mai demult Badboy parca, pe wdb, ca ideal e ca un freelancer sa fi trecut in trealabil printr-o agentie serioasa. Nici nu sti cata dreptate ii dau. Sunt multe castiguri ... cel putin in cazul meu asa ar fi, singura chestie care nu ar fi la fel de faina ar fi poate venitul, insa depinde si de companie si de ce stii sa faci.

    E super aiurea ca freelancer fara un nume puternic sa faci prea multe figuri in fata clientului. De asta zic ca e grav cand nu ai contract (btw: astea se pot face daca nu e legat?! adica daca nu ai acte - pfa- si sa fie doar un fel de intelegere intre tine si client?). E nasol sa lucrez la un proiect, si dupa un timp sa fii nevoit sa te conformezi la ce ti se impune, pentru ca altfel de alegi doar cu nervi...si e si nasol cand nu iti primesti banii.

    Ar mai fi si alte categorii de clienti in afara de cei pe care ia-i scris tu ;))
  • Buna ideea cu siteuri gratis, ma batea si pe mine gandul acum vreun an, insa as fi ales o alta abordare.
    Legat de contracte, un bun exemplu mi se pare modelul "asta":http://rails-business.googlegr... (fisier .odt, 23K), daca as avea ocazia acela ar fi templateul pe care as vrea sa il folosesc.
  • Se spune că adevărul e undeva la mijloc, dar mă cam îndoiesc că se aplică şi aici.

    În primul rând, dezvoltarea agilă este foarte neînţeleasă în România. În primul rând, nu înseamnă lipsă de documentaţie, ci, printre altele, are un alt mod de realizare a hârţogăriei. Nu ai o hartă Gantt (şi acum când încep să coordonez un proiect, îmi dau seama cât de inutil e Gantt-ul meu), ci ai un backlog, cum se numeşte în Scrum. Nu faci big design up front (BDUF), ci scrii nişte specificaţii sumare, despre care vorbeşte şi Joel Spolski. Atât cât să poţi să începi să proiectezi şi să scrii cod. Şi ce-mi place mult de tot e că tehnicile agile sunt în special axate pe scrisul codului, nu întocmitul de hârtii şi doc-uri.

    Problema esenţială cu Agile e că programatorul trebuie să muncească, alert şi ingenios, toate cele 7-8 ore cât stă la servici. Nu prea merge „azi frec menta că recuperez oricum mâine” şi nici bâjbâiala în tehnologie.

    Partea bună e că Agile te forţează să aplici nişte tehnici excelente. Când ai făcut unit-testing ultima oară? Care este procentul de code coverage? Cum faci testare funcţională a proiectului? Cum gestionezi resursele externe? Cum se evaluează codul? Cum faci deployment?
blog comments powered by Disqus