ABONAMENTE VIDEO REDACȚIA
RO
EN
NOU
Numărul 150
Numărul 149 Numărul 148 Numărul 147 Numărul 146 Numărul 145 Numărul 144 Numărul 143 Numărul 142 Numărul 141 Numărul 140 Numărul 139 Numărul 138 Numărul 137 Numărul 136 Numărul 135 Numărul 134 Numărul 133 Numărul 132 Numărul 131 Numărul 130 Numărul 129 Numărul 128 Numărul 127 Numărul 126 Numărul 125 Numărul 124 Numărul 123 Numărul 122 Numărul 121 Numărul 120 Numărul 119 Numărul 118 Numărul 117 Numărul 116 Numărul 115 Numărul 114 Numărul 113 Numărul 112 Numărul 111 Numărul 110 Numărul 109 Numărul 108 Numărul 107 Numărul 106 Numărul 105 Numărul 104 Numărul 103 Numărul 102 Numărul 101 Numărul 100 Numărul 99 Numărul 98 Numărul 97 Numărul 96 Numărul 95 Numărul 94 Numărul 93 Numărul 92 Numărul 91 Numărul 90 Numărul 89 Numărul 88 Numărul 87 Numărul 86 Numărul 85 Numărul 84 Numărul 83 Numărul 82 Numărul 81 Numărul 80 Numărul 79 Numărul 78 Numărul 77 Numărul 76 Numărul 75 Numărul 74 Numărul 73 Numărul 72 Numărul 71 Numărul 70 Numărul 69 Numărul 68 Numărul 67 Numărul 66 Numărul 65 Numărul 64 Numărul 63 Numărul 62 Numărul 61 Numărul 60 Numărul 59 Numărul 58 Numărul 57 Numărul 56 Numărul 55 Numărul 54 Numărul 53 Numărul 52 Numărul 51 Numărul 50 Numărul 49 Numărul 48 Numărul 47 Numărul 46 Numărul 45 Numărul 44 Numărul 43 Numărul 42 Numărul 41 Numărul 40 Numărul 39 Numărul 38 Numărul 37 Numărul 36 Numărul 35 Numărul 34 Numărul 33 Numărul 32 Numărul 31 Numărul 30 Numărul 29 Numărul 28 Numărul 27 Numărul 26 Numărul 25 Numărul 24 Numărul 23 Numărul 22 Numărul 21 Numărul 20 Numărul 19 Numărul 18 Numărul 17 Numărul 16 Numărul 15 Numărul 14 Numărul 13 Numărul 12 Numărul 11 Numărul 10 Numărul 9 Numărul 8 Numărul 7 Numărul 6 Numărul 5 Numărul 4 Numărul 3 Numărul 2 Numărul 1
×
▼ LISTĂ EDIȚII ▼
Numărul 69
Abonament PDF

#NoAgile

Dan Suciu
Lector, PhD @ Facultatea de matematică și informatică, UBB



MANAGEMENT


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

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

Figura 1. Exemplu de proiect unde media timpului necesar
dezvoltării unei funcționalități este aceeași indiferent de complexitatea estimată.

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.

#NoProjects

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

#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.)

Figura 2. Diagrama de flux cumulativ

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

#NoSprints/#NoReleases

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.

Concluzii

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

Referințe

  1. Anderson, D. J. (2010). Kanban: Successful Evolutionary Change for Your Technology Business . Blue Hole Press .

  2. Demarco, T. (2003). Waltzing with Bears - Managing Risk on Software Projects. Dorset House.

  3. Duarte, V. (2016). NoEstimates: How To Measure Project Progress Without Estimating. OikosofySeries.

  4. Humble, J. (2014). The Case for Continuous Delivery. ThoughtWorks.

  5. Karin Obermüller, J. C. (2016). Mob Programming - the Good, the Bad and the Great. "under the hood" blog.

  6. Kelly, A. (2017). Continuous Digital - An agile alternative to projects for digital business. -.

  7. Mary Poppendieck, T. (2003). Lean Software Development: An Agile Toolkit . Addison-Wesley Professional.

  8. McKendrick, J. (2015). How Amazon handles a new software deployment every second. zdnet.

  9. PMI. (2017). PMBOK® Guide - Sixth Edition. Project Management Institute.

NUMĂRUL 149 - Development with AI

Sponsori

  • Accenture
  • BT Code Crafters
  • Accesa
  • Bosch
  • Betfair
  • MHP
  • BoatyardX
  • .msg systems
  • P3 group
  • Ing Hubs
  • Cognizant Softvision
  • Colors in projects