“Cunoașterea adevărată constă în a-ți ști gradul de ignoranță.”, Confucius
De-a lungul carierei mele de 15 ani ca dezvoltator, technical lead, manager de proiect, freelancer, trainer, agile/lean/technical coach și din nou dezvoltator am văzut multe eșecuri în dezvoltarea de software. Dar am văzut și succese neașteptate.
Dintre toate industriile, dezvoltarea de software pare destul de imprevizibilă. În calitate de client, poți cere să adaugi o funcționalitate destul de simplă ce pare să dureze o zi sau două până e gata, (ex. Adaugă euro la un sistem de contabilitate creat pentru francii francezi) și în realitate îți va lua două luni. Sau poți cere o funcționalitate care pare teribil de complexă dar durează doar o zi pentru a fi dezvoltată. La ce să te aștepți? La un buget de zece ori mai mare pentru funcționalitatea de care ai nevoie sau la un software livrat mai rapid decât l-ai cerut?
Reacția umană inițială la imprevizibilitate este de a adăuga mai multe puncte de control, mai mult proces, mai mult management. La urma urmei, fabricile pot produce mai repede atunci când acestea sunt mai bine gestionate, optimizate și automatizate. De ce nu ar funcționa și în software? Lucram pentru o companie de outsourcing ca technical lead când managementul a decis să obțină certificarea CMMI. În caz că nu sunteți familiari cu el, CMMI este un "maturity model" pentru dezvoltarea de software. Nivelul 3, cel la care era evaluată compania se axa pe a avea un proces standardizat și măsurat. Nivelul 4 consta în îmbunătățiri continue bazate pe metrici. Fiind implicat în proces, am învățat foarte mult despre CMMI. CMMI-ul nu este un sistem rău, dar cerințele lui pot fi prost interpretate. Este foarte ușor pentru o companie să dea faliment dacă cerințele sunt interpretate ad litteram. Cea mai simplă cale de ieșire dintr-o evaluare CMMI este de a lua fiecare cerință și a adăuga un document pentru ea. Acest lucru ar crea atât de mult de lucru încât ori ar trebui suspendată producția, ori compania ar trebui să mai angajeze oameni care să scrie documentele. Din fericire, liderul proiectului de tranziție, Managerul Calității, a ales o altă cale. A citit cerințele CMMI-ului și a găsit cel mai bun mod de a răspunde la ele. Pentru o mai bună înțelegere a contextului, CMMI cere să dovedești că urmărești anumite practici, dar nu precizează exact ce fel de dovadă este necesară. Dovada poate fi un document, dar deseori este suficient să ai raportul dintr-un tool, o poză sau un checklist.
Experiența CMMI m-a învățat două lucruri:
1. A avea un mod de lucru structurat este benefic pentru dezvoltarea de software.
2. Punctele de control încetinesc producția.
Eram la acel moment un dezvoltator de software interesat de cum să execuți în mod repetitiv proiecte de succes. CMMI avea potențial, dar în același timp putea să se transforme cu ușurință într-un proces greu de întreținut care nu asigura succesul.
La momentul respectiv din cariera mea, am început să caut orice tip de cunoaștere care ar putea ajuta. Cum fac alte companii dezvoltare de software? Există principii fundamentale de urmat pentru a crea software de înaltă calitate în timp ce menții clienții fericiți? Care sunt ingredientele succesului?
Am început prin a citi cărți și articole pe tema asta.
Lucrările lui Fred Brooks “The Mythical Man Month” și “No silver bullet” mi-au deschis ochii către ceva ce nu conștientizasem înainte: dezvoltarea de software este diferită de celelalte industrii. Până la urmă, să adaugi oameni la un proiect de construcție ce este în întârziere va ajuta proiectul să se termine mai repede. Nu și în cazul dezvoltării de software: să adaugi oameni unui proiect deja întârziat în mod normal îl va întârzia și mai mult (lucru știut sub forma de „legea lui Brooks”). Mai interesant, legea lui Brooks poate uneori fi evitată. Motivul pentru care proiectul este livrat mai târziu este că oamenii care se alătură proiectului trebuie întâi să învețe. Dar, dacă sunt aleși astfel încât să aibă deja cunoștințele necesare, vor ajuta în loc să încetinească livrarea.
Cartea lui Steve McConnel, “Software Estimation: Demystifying the Black Art” a fost o altă lectură interesantă. Modul prin care făceam estimări la vremea respectivă era ghicitul. CMMI mă expusese deja la metode de estimare, dar cartea mi-a oferit o mai bună înțelegere. Ca inginer, am găsit tentante și cu mult sens ideile de a profita de statistici și de a face peer review pentru a îmbunătăți estimările.
Pe de altă parte dezvoltarea de software părea că nu se înțelege bine cu statistica. Un lucru pe care l-am învățat din lecturile mele (mă tem că nu-mi amintesc sursa exactă) a fost că bug-urile nu erau distribuite uniform în cod. În mod ciudat, nu sunt: ele tind să se grupeze. O primă consecință este că zonele în care un bug este găsit ar trebui verificate cu mai multă grijă pentru alte bug-uri. Totuși, dacă distribuția normală nu se aplică la localizarea bug-urilor în cod merită să ne întrebăm: s-ar aplica distribuția normală la estimări?
Cărțile și articolele au fost foarte interesante, dar tot nu am ajuns la concluziile căutate despre cum să faci dezvoltare de software de succes. Ce ar ajuta: mai mult proces, estimări mai precise, mai multe practici, programatori mai buni...?
Nimeni nu părea să știe.
Atunci m-am decis să mă mut într-o companie mică de dezvoltare de produs, să mă implic într-o comunitate agile în șapte orașe românești și în mod treptat să mă îndrept către training și coaching agile, lean și tehnic.
... este din păcate un termen foarte ambiguu, plin de emoție și de marketing. În ciuda acestor provocări, am înțeles că este un set de principii, un set de practici și o listă de beneficii potențiale.
Beneficiile sunt la diferite niveluri:
Agilitatea Businessului – capacitatea unei companii de a se adapta rapid la nevoile pieței și ale clienților.
Agilitatea Dezvoltării – capacitatea de a produce o funcționalitate pe care clientul o dorește, mai rapid decât are nevoie acesta de ea.
Principiile sunt enunțate în Manifestul Agile; în loc să le citez, le voi enumera pe scurt (și incomplet) , dar filtrate de interpretarea mea:
Gestionează echipa, nu fiecare individ.
Dă autonomie echipei și arată-i scopul clar, lăsându-i să-și facă treaba.
Tratează echipa de dezvoltare ca pe niște adulți inteligenți și motivați, nu ca pe niște copii ce au nevoie de îndrumare.
Îmbunătățirea continuă a modului în care echipa și compania lucrează. Căutarea continua a impedimentelor și îndepărtarea lor cu zel.
Feedback-ul este instrumentul cel mai important de control al procesului. Asigurați-vă că feedback-ul este în timp util, de înaltă calitate și se aplică la toate nivelurile de dezvoltare software (de la cod, design, cerințe și funcționalități utilizate). Practicile cele mai agile/lean/tehnice sunt despre feedback.
Multă lume crede că practicile sunt cele care definesc agile: întâlnirile zilnice, retrospectivele, integrarea continuă, Test Driven Development, ca să dau doar câteva exemple. În cei cinci ani de training și coaching am învățat despre agile, lean și practicile tehnice.
Ori de câte ori o companie vrea să facă o transformare agile, prima întrebare pe care eu și colegii mei de la Mozaic Works o avem este: "Ce sperați să obțineți cu asta?"
Răspunsurile variate pe care le primim "Am auzit că agile este cool", "concurenții noștri o fac", "clienții noștri ne-au cerut să facem agile" necesită mai multe discuții. Cel mai bun răspuns la care ne așteptăm este "avem nevoie pentru a îmbunătăți X", unde X este de obicei: reducerea ciclului de release, calitate, productivitate (pe baza unor criterii clare) sau inovație.
Prin definirea unui scop de business clar, ne putem pune de acord asupra principiilor și putem introduce practicile care sunt cele mai potrivite pentru companie. Uneori, companiile au nevoie de implementări complete de Scrum, alteori de Kanban, în timp ce unii au nevoie doar să înceapă cu Visual Management și îmbunătățire continuă.
Nu este important să fii neapărat agile, dar agilitatea în afaceri reprezintă un avantaj competitiv.
Dar de ce ar funcționa agile? Cum ajută? Întrebarea aceasta m-a condus la o altă concluzie interesantă.
Am învățat acest lucru de la o discuție cu Mike Beedle, unul dintre semnatarii Manifestului Agile și co-autor al uneia dintre primele cărți despre Scrum. Am simțit că am cochetat cu ideea înainte, fără a pune însă degetul pe ea.
Ca să fim mai exacți:
“Software-ul este cunoaștere codată și foarte precisă.“
Codată, din moment ce este scrisă în cod. Precisă, deoarece computerele nu pot lucra cu ambiguitate.
Această declarație simplă are impact în fiecare aspect al dezvoltării de software. Iată câteva aspecte pe care le-am extras:
Dezvoltarea de software constă în traducerea cerințelor ambigue în cod precis.
Ceea ce este echivalent cu a construi cunoștințe.
Când construiești cunoștințe, sunt de ajutor oricâte creierul poți folosi. De aceea, planificarea în echipa și programare în pereche pot fi foarte eficiente.
Calitatea rezultatului și eficiența procesului este influențată de câte pierderi are transferul de cunoștințe. Cel mai bun transfer de cunoștințe se face prin comunicare față-în-față, din cauza feedback-ului instant și de înaltă calitate (poziția corpului, gesturile feței și mâinilor, mișcarea ochilor, inflexiunile vocale etc.). Documentele nu oferă niciun feedback-ul cititorilor; va trebui să discutați cu autorul pentru a le înțelege mai bine. (A nu se înțelege că documentația nu este de ajutor pe termen lung.)
Oamenii au tendința de a subestima precizia necesară. Feedback-ul continuu este singura modalitate de a se muta asimptotic către ea.
Un număr foarte mare de decizii este necesar pentru a obține o cunoaștere exactă. Aceste decizii sunt împărțite între client și echipa de dezvoltare. Echipa are nevoie de întregul context, astfel încât deciziile lor să se potrivească cu nevoile clientului.
Structurarea cunoașterii construite este un impediment cu care încă ne luptăm în industria software.
Programatorii au nevoie de o minte specială, pregătită să transforme cerințele ambigue în cod precis.
Pentru a încheia: de ce agile? Pentru că:
Agilitatea în afaceri, dezvoltarea agilității și productivitatea îmbunătățită pot fi obținute prin utilizarea principiilor, valorilor și practicilor agile.
Dezvoltarea de software înseamnă construire de cunoștințe și necesită o abordare fundamental diferită față de construirea de piulițe și șuruburi.
Dezvoltatorii au performanțe mai bune când au autonomie, expertiză și scop (cheia către motivația intrinsecă după cum spune Dan Pink) și lucrează într-un mediu care favorizează fluxul (vezi lucrările lui Mihaly Csikszentmihalyi despre fericire și productivitate)
Când nu este agile util? Există situații chiar și în dezvoltarea de software, când construirea de cunoștințe nu joacă un rol atât de important: de ex. , customizări pentru aplicații sau platforme existente. Există modele de afaceri care funcționează și care nu au nevoie de agilitate. De exemplu, software de contabilitate. Există dezvoltatori care sunt mai fericiți atunci când primesc task-uri pe care le rezolvă fără a lua o mulțime de decizii; un mediu agil îi va face nefericiți.
Așadar, este agile răspunsul? Nu cred. Mai avem încă un drum lung de parcurs pentru a obține predictibilitate în dezvoltarea de software. Cred totuși că unul din două lucruri se pot întâmpla. Industria fie va:
Găsi moduri să minimizeze nevoia de construire de cunoștințe prin specializare.
Nu pot spune încă pe ce drum vom merge, dar pentru mine a doua direcție sună foarte interesantă și merită de a fi explorată.
de Ovidiu Mățan
de Mircea Vădan
