Fără doar și poate, metodologiile Agile utilizate în acest moment de către tot mai multe echipe ce dezvoltă proiecte software, nu reprezintă un capăt de drum. Dezbaterile despre eficiența acestor metodologii duc la concluzia că ne aflăm într-un proces de evoluție și maturizare care va mai continua o perioadă .
#NoAgile reprezintă, după părerea mea, doar o etapă intermediară a acestui proces și este rezultatul unor dezamăgiri și frustrări acumulate de-a lungul unor experiențe nefericite de implementare a agilității dar și a unei dorințe de progres, de transformare și îmbunătățire continuă.
#NoAgile nu este un fenomen de sine stătător, bine conturat, însă este cel mai concis mod de a caracteriza perioada post-Agile. O căutare rapidă pe Twitter după #NoAgile relevă atât comentarii acide ce consideră că agilitatea reprezintă cel mai nociv lucru ce a "lovit" comunitatea IT în ultima perioadă cât și comentarii ce se doresc vizionare și care țintesc către un Agile 2.0. De cele mai multe ori, acestea din urmă au accente deseori extreme și, mai în glumă sau mai în serios, am început să le consider în ultima vreme o bază a constituirii unui XXP (extreme-extreme-programming).
Interesant este faptul că în tot acest amalgam îi mai regăsim pe cei care acum descoperă Agile, cu valorile și principiile sale, și sunt în plin proces de tranziție de la rutina de multe ori rigidă a managementului predictiv/tradițional către o filozofie de lucru flexibilă și dinamică. Nu e greu de imaginat stupoarea cu care aceștia privesc fenomenul #NoAgile, temându-se că au nimerit din lac în puț.
În cele ce urmează mă voi referi la acele practici extreme care își găsesc tot mai mulți susținători în comunitatea IT. Nu este, cred, o întâmplare că denumirea fiecăreia dintre acestea este prefixată obsedant cu #No, fapt ce le conferă din start o anumită aură de agresivitate revoluționară (să nu uitam de agitația creată la vremea sa de către NoSQL!). Lista următoare nu are pretenția că este una exhaustivă, însă cu siguranță include cele mai relevante și dezbătute practici în comunitate: #NoEstimates, #NoProject, #NoBacklog, #NoSprint și #NoReleases.
#NoEstimates este un subiect ce a căpătat tot mai mult contur în ultimii doi ani, în special după apariția cărții lui Vasco Duarte: "NoEstimates: How To Measure Project Progress Without Estimating" (Duarte, 2016). Cu toate acestea, ideea este mult mai veche, Woody Zuill sau Allen Holub discutând despre această abordare acum mai bine de 15 ani. Esența #NoEstimates constă în utilizarea de metode alternative pentru planificarea, monitorizarea și controlul proiectelor software, metode care să nu implice estimarea. Această inițiativă se bazează pe constatarea că acuratețea estimărilor în software este redusă și că, deși experiența ar putea ajuta la îmbunătățirea acesteia, apariția oricărei variabile noi poate cu ușurință să reseteze toate premisele pe care s-a clădit această acuratețe. Prin urmare, din această perspectivă, estimarea este privită în mod extrem ca o activitate complet inutilă.
Cu toate acestea continuăm să măsurăm, planificăm și monitorizăm proiectele software pe baza estimărilor deoarece, în esență, politica multor corporații astăzi este următoarea:
" Este în regulă să greșești, dar nu e în regulă să fii nesigur. " (Demarco, 2003)
Prin urmare vom livra pe bandă rulantă estimări inexacte ca alternativă la "ridicatul din umeri", în ciuda faptului că aceste estimări au de multe ori o acuratețe foarte redusă.
Un exemplu extrem de relevant este cel postat pe Twitter de Cory Foy în 2014 (Figura 1). El prezintă situația acurateței estimărilor folosind puncte (0, 1, 2, 3, 5, 8, 13 sau 20 bazate pe șirul Fibonacci) realizate de una dintre echipele coordonate de el și arată că pentru oricare dintre estimări există diferențe relevante în ceea ce privește durata de execuție a user story-urilor. Pe de altă parte, calculând media timpului necesar de implementare a user story-urilor ce aveau asignate același număr de puncte a constatat că acesta nu variază foarte mult în raport cu complexitatea estimată. Concluzia sa a fost că, dacă s-ar fi considerat această medie pentru măsurarea velocității și planificarea proiectului, rezultatul ar fi fost mult mai aproape de realitate decât utilizarea punctelor rezultate în urma estimării.
Rezultate similare a obținut și Vasco Duarte atunci când a luat în considerare 23 de proiecte IT a căror estimări și timpi de execuție au fost anonimizați și făcuți publici.
Alternativa la estimare ar putea fi pur și simplu numărarea funcționalităților/user-story-urilor ce trebuie implementate. Această alternativă poate fi utilizată în predicții și alte instrumente de control și monitorizare a proiectelor software cu rezultate mai bune decât estimările "clasice", dar fără a consuma timpul necesar estimării.
Pe cât de simplă și evidentă pare o astfel de concluzie, e tot pe atât de greu de implementat. În primul rând din cauza mentalității și a obișnuinței. Pare că suntem mai atașați de o estimare făcută de noi, chiar dacă aceasta se dovedește a fi greșită (chiar venim cu o serie de argumente în a explica de ce a fost dată o astfel de estimare la momentul respectiv). Pe de altă parte, o predicție și planificare a proiectului formulată automat poate afecta "stresul pozitiv" dat de angajamentul public pe care fiecare dintre noi ni-l luăm în momentul în care dăm o estimare. Ne vine mai ușor să demonstrăm că predicția nu e corectă decât că estimarea noastră a fost greșită.
Nu în ultimul rând trebuie să luăm în considerare că #NoEstimates funcționează cu atât mai bine cu cât complexitatea funcționalităților aplicației este similară, iar acest lucru presupune și un anumit nivel de maturitate a echipei ce definește acele funcționalități.
Alan Kelly este inițiatorul și suporterul înfocat al ideii de #NoProjects (Kelly, 2017), susținând că în ceea ce privește dezvoltarea de software nu avem de a face cu proiecte în accepțiunea clasică a termenului. Conform (PMI, 2017) "un proiect este un efort temporar asumat pentru a realiza un produs, un serviciu sau un rezultat unic". Aspectul temporar al unui proiect presupune că acesta are o dată de început și o dată de finalizare, iar în acest interval de timp avem definite un scop al proiectului și resursele ce pot fi utilizate (fie ele umane, materiale sau financiare).
Problema însă este aceea că proiectele software nu sunt niciodată finalizate, ele fiind întreținute, modificate și îmbunătățite atât timp cât sunt utilizate. În momentul în care nu se mai lucrează pentru o aplicație software, foarte probabil că aceasta nu mai este utilizată în mod curent de utilizatori. Prin urmare durata unui proiect software este aproape egală cu durata de viață a produsului software respectiv, iar ciclul de viață al unui astfel de proiect nu poate fi prins într-un plan inițial, mai mult sau mai puțin rigid, ci mai degrabă reprezintă un flux continuu de cicluri de dezvoltare sau pur și simplu un flux continuu de funcționalități dezvoltate și instalate în produsul final (de exemplu, în 2011 Amazon instala o nouă versiune a softului lor în producție la fiecare 11.6 secunde (Humble, 2014), iar astăzi avem o versiune nouă de produs la fiecare secundă (McKendrick, 2015)).
Astfel, o serie de practici ce țin de abordarea predictivă a gestionarii proiectelor nu se mai aplică în cazul softului. Sunt afectate clauzele contractuale, gestionarea riscurilor, monitorizarea și controlul dar și practici ce țin de metodologii Agile unde temporalitatea continuă să fie considerată ca o caracteristică a proiectelor software.
#NoBacklog duce mai departe ideea de a dezvolta mereu ceea ce este mai valoros pentru client, din perspectiva obiectivelor de business ce trebuie atinse. Orice activitate ce se concentrează pe altceva decât pe dezvoltarea celui mai valoros/important user story nu reprezintă altceva decât risipă - waste, așa cum este descris în Lean Software Development (Mary Poppendieck, 2003) - cu alte cuvinte o pierdere pentru proiect.
Ca o paranteză, aș dori să subliniez aici faptul că adoptarea practicii #NoEstimates ajută la identificarea user story-ului ce va fi implementat deoarece clientul (sau Product Owner-ul în terminologia Scrum) nu mai este tentat să pună în balanță valoarea de business cu costul acelui user story. De asemenea, adoptarea #NoBacklog implică #NoEstimates deoarece nu mai este necesar să parcurgem, cu o anumită frecvență, elementele din backlogul unui produs pentru a le estima și, uneori, chiar a le re-estima pentru reactualizarea planurilor proiectului.
Astfel, deoarece putem identifica întotdeauna care este cel mai valoros user-story pentru client la un moment dat nu este nevoie să știm care este următorul user-story din listă. Abia în momentul în care user-story-ul curent este finalizat ne vom pune din nou întrebarea care este următorul user-story important. Prin urmare backlogul de produs va avea mereu un singur element: primul!
Un argument solid pentru aplicarea acestei practici vine dinspre unul dintre promotorii Kanban în software, David J. Anderson, care în (Anderson, 2010) arăta că limitarea numărului de taskuri dezvoltate în paralel (Work In Progress - WIP) poate afecta calitatea produsului dezvoltat.
În Figura 2 este prezentată o diagramă de flux cumulativ care conține două metrici importante:
Lead time - durata medie pe care o parcurge un user story de când este preluat din backlog și până este instalat în mediul de producție
(Work) in progress - numărul de user story-uri ce se află în dezvoltare la un moment dat. (Cu alte cuvinte acele user story-uri a căror dezvoltare s-a început, dar care nu au fost finalizate.)
David J. Anderson demonstrează într-un mod empiric, pe baza mai multor studii de caz, că Lead time-ul este invers proporțional cu robustețea funcționalităților implementate și, în același timp, că valoarea Lead time-ului este direct influențată de WIP. De aceea, una dintre cele mai importante acțiuni implementate în Kanban este limitarea WIP, pentru a vedea unde apar gâtuiri în fluxul de dezvoltare.
Întorcând-ne la subiectul secțiunii, #NoBacklog este de fapt o consecință directă a ducerii la extrem a ideii dezvoltate de Anderson prin impunerea limitei WIP = 1. Astfel, întreaga echipă de proiect va lucra doar la un singur user-story la un moment dat și nu va trece la următorul până când acesta nu este implementat în producție. Această idee este îmbrățișată cu succes de o serie de echipe ce practică mob-programming (Karin Obermüller, 2016).
Am grupat aceste idei laolaltă deoarece ele sunt înrudite. În accepțiunea Scrum un plan al unei versiuni funcționale intermediare a unei aplicații ce urmează a fi instalată pe serverul de producție (release) este format din suma planurilor mai multor sprinturi în care se va dezvolta acea versiune. Dacă nu există sprinturi, atunci dispare și ideea de release așa cum este ea descrisă mai sus. (Varianta #NoSprints pentru cei care nu utilizează Scrum, dar sunt familiarizați cu alte metodologii Agile iterative și incrementale - de exemplu, Extreme Programming - este #NoIterations.)
Dezvoltarea incrementală și iterativă în perioade fixe, predefinite de timp este înlocuită astfel de dezvoltarea într-un flux continuu. Această abordare este încurajată și de metodologia Kanban sau, într-un context mai general, de Lean Software Development, fiind redus (aproape) la zero timpul de obținere a feedbackului pentru un user-story finalizat. Astfel, un user-story deja implementat nu va trebui să aștepte zile sau chiar săptămâni până la finalul iterației când va fi revizuit de către client sau alți stakeholderi, acesta primind feedback imediat și fiind ulterior, după aplicarea eventualelor corecții, instalat în mediul de producție. De notat că #NoProjects reprezintă de fapt o generalizare a #NoSprints / #NoIterations / #NoReleases, iar acestea se încadrează perfect într-o echipă ce implementează atât #NoEstimates cât și #NoBacklog.
#NoAgile reprezintă cu siguranță una dintre direcțiile viabile spre care se vor îndrepta tot mai multe echipe ce acum urmează diverse metodologii ca Scrum, Extreme Programming, Kanban sau combinații ale acestora. Pe de altă parte, însă trebuie să fim conștienți că există o serie de situații în care #NoAgile nu doar că nu este benefic, dar ar putea chiar să dăuneze. Tranziția către #NoAgile necesită un nivel superior de maturitate și, în același timp, un context și un mindset potrivite.
Industria IT astăzi este invadată de tineri. După cum constata și "Uncle Bob" în (Martin, 2014) numărul programatorilor se dublează la fiecare cinci ani de zile, iar această creștere exponențială va mai continua o bună perioadă de timp. În consecință, într-o companie în medie jumătate dintre angajați au mai puțin de cinci ani experiență în dezvoltarea de aplicații software. Astfel, numărul celor care au practicat și au auzit de metodologii predictive de gestionare a softului scade dramatic, procentual vorbind. Prin urmare există tendința în IT, în special în companiile tinere, de a considera că nu s-a întâmplat mare lucru în lumea gestionării proiectelor înainte de Agile, lucru care nu poate decât să dăuneze însăși agilității.
Din punctul meu de vedere, nici una din practicile amintite în acest articol nu trebuie testate la începutul carierei. Consider că e necesară o trecere graduală de la, de exemplu, estimare în unități de timp la estimarea în puncte și apoi abia apoi făcută tranziția la #NoEstimates. Sau o tranziție de la codificare individuală la cea în pereche și abia după, o maturizare suficientă să se experimenteze mob-programming. Și așa mai departe.
Trecerea directă la #NoEstimates sau mob-programming ascunde adevăratele principii ce stau la bazate utilizării acestor practici, iar rezultatul este că ele vor fi urmate fără a ști de ce. Acest lucru ne face neputincioși, în timp, în a pune la îndoială practica, de a o îmbunătăți și de a o adapta la specificul unui anumit context de lucru.
Anderson, D. J. (2010). Kanban: Successful Evolutionary Change for Your Technology Business . Blue Hole Press .
Demarco, T. (2003). Waltzing with Bears - Managing Risk on Software Projects. Dorset House.
Duarte, V. (2016). NoEstimates: How To Measure Project Progress Without Estimating. OikosofySeries.
Humble, J. (2014). The Case for Continuous Delivery. ThoughtWorks.
Karin Obermüller, J. C. (2016). Mob Programming - the Good, the Bad and the Great. "under the hood" blog.
Kelly, A. (2017). Continuous Digital - An agile alternative to projects for digital business. -.
Mary Poppendieck, T. (2003). Lean Software Development: An Agile Toolkit . Addison-Wesley Professional.
McKendrick, J. (2015). How Amazon handles a new software deployment every second. zdnet.