ABONAMENTE VIDEO REDACȚIA
RO
EN
NOU
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 21
Abonament PDF

Lupta noastră împotriva Datoriei Tehnice

Septimiu Mitu
Development Lead
@Endava



PROGRAMARE

Când implementezi o nouă funcționalitate ai două opțiuni: (neagră sau albă) - repede și neglijent sau curat și inteligent. În primul caz se tot adaugă o datorie tehnică pe care vei fi nevoit să o plătești la un moment dat. Dacă alegi opțiunea a doua - investești initial mai mult timp și energie - dar devine mai ușor să dezvolți aplicația în viitor.

Fig 1. grafice adaptate după cursul PSPO de la Scrum.org

Conștientizarea

Proiectul la care am lucrat a pornit de la zero. Au fost momente când am fost presați de timp și sprint după sprint am început să acumulăm puțin câte puțin datorie tehnica. De obicei, la sfârșitul sprintului ne dădeam seama că ne-am supraestimat abilitațile de a livra noi funcționalitătți. La acel moment eram mult mai interesați în a livra cât mai mult și cât mai repede, în defavoarea calității tehnice. Feedback-ul din partea clientului pe partea de arhitectură a venit foarte tarziu, iar când a venit am realizat că parte din codul nostru nu respectă îndeaproape recomandările lui. Câteodată am livrat o funcționalitate care mergea corect din punct de vedere al businessului, dar codul din spate era slab structurat.

Ne place ideea de arhitectură emergentă în care structura aplicației se dezvoltă pe măsura ce proiectul evoluează. Pe măsură ce sunt implementate cerințele clientului arhitectura aplicației se dezvoltă și se cristalizează. E o modalitate bună de a lupta împotriva incertitudinii -  atuncind nu știm de la început în detaliu toate cerințele sistemului, îl construim pe măsură ce aflăm răspunsul la întrebări.

Adăugând o componentă aici, alta dincolo, aplicația noastră a început să semene tot mai mult cu Frankenstein. Din punct de vedere al utilizatorului - aplicația făcea tot ce trebuia - dar codul a devenit pe zi ce trece tot mai greu de întreținut.

Un alt punct slab al echipei noastre era faptul că aveam o singură persoană specializată pe o anumită tehnologie - ca de exemplu Alex pe BPM. Când el era plecat în concediu,ceilalți membri ai echipei care au scris cod BPM, neștiind ce era acolo, au scris cod doar ca să meargă fără să înțeleagă în amănunt implementarea BPM. Acest lucru se numește efectul autobuz: de câți oameni e nevoie să fie călcați de autobuz pentru ca echipa să nu-și mai poată continua activitatea în mod normal. În cazul nostru efectul autobuz era egal cu unu. Pentru a înlătura această deficiență, am încercat să avem cel puțin două persoane care să știe codul care ține de o anumită tehnologie (în cazul BPM a fost vorba despre Cosmin și Ștefan).

Nevoia de schimbare

Pe măsura ce încheiam un Sprint și încă unul, codul sursă al aplicației devenea tot mai dificil de întreținut. Tot ce am pus sub preș începea să iasă la suprafață. Dezvoltatorii nu mai erau capabili să scrie cod pentru o nouă componentă până nu puneau la punct codul existent. Soluțiile rapide aplicate în trecut au transformat codul în nisipuri mișcătoare.

Auzeam tot mai des la întâlnirile zilnice SCRUM: task-ul meu a durat de două ori mai mult decât a fost estimat pentru că a trebuit să sap și să refactorizez sistemul. Oamenii deveneau pe zi ce trece tot mai frustrați. Dezvoltatorii deveneau tot mai nemulțumiți pentru că petreceau mai mult timp să curețe codul existent decât să scrie funcționalități noi. Managementul s-a alarmat pentru că a scăzut velocitatea echipei. În același timp dezvoltatorii au început să stea tot mai mult peste program în încercarea disperată de a livra funcționalitătile promise la timp.

Pentru a gestiona User Story-urile și task-urile  folosim atât tabla de SCRUM cât și Jira. Tabla de SCRUM e inima echipei noastre unde ne întâlnim și discutăm toate problemele. Folosim Jira pentru a oferi  Product Owner-ului posibilitatea de a vedea evoluția proiectului (Product Ownerul se afla în altă locație decât locația echipei de dezvoltare). Pe măsura ce timpul trecea - Jira a devenit tot mai greu de gestionat datorită task-urilor neînchise, task-urilor neplanificate, modificărilor la User Story apărute între timp. Din Jira a devenit imposibil să-ți dai seama de starea proiectului. La un moment dat lucrurile au devenit atât de grave încât nu am mai putut continua să lucrăm așa.

Vizibilitatea

Pentru că nu se mai putea continua așa - am scos totul la lumină: am pus datoria tehnică pe tabla agile și în Confluence. Partea cea mai grea a fost discuția cu clientul, să admitem că avem o problema și să-i cerem susținerea.

Am început prin a revizui întreaga arhitectură și întreg codul. Am extins utilizarea Sonar, intrumentul folosit de noi pentru controlul calitătii și Jenkins - care ne ajută la livrarea continuă.

Colegul nostru de la Endava Cluj - Mădălin - a mers un pas mai departe. A creat un panou care oferă o imagine de ansamblu asupra celor mai importanți indicatori de calitate.  Și aceasta pentru toate echipele care lucrează la un același proiect într-un mod comparativ. După cum puteți vedea în imaginea de mai jos se pot urmări: numărul și tipul bug-urilor și trendul evoluției lor, acoperirea cu teste unitare a sistemului și rezultatul rulării testelor automate.

Plata datoriei

Sunt trei pași pentru a scapa de datorie (conform cursului de PSPO de la Scrum.org):

  1. Încetează să te mai împrumuți.
  2. Plătește câte puțin din datorie.
  3. Repetă pasul 2.

După ce am facut vizibilă datoria tehnică pe tabla de agile și în Confluence, am început să rezolvăm din ea puțin câte puțin în fiecare sprint. La un moment dat ne-am dat seama că în ritmul acesta se termina proiectul și noi nu terminam datoria tehnică. Așa că ne-am luat un sprint ca să o rezolvam. În același timp am încetat să ne mai împrumutăm.



LANSAREA NUMĂRULUI 141

Analiza de business (BA)

miercuri, 27 martie, ora 18:00

sediul Accesa

Facebook Meetup StreamEvent YouTube

NUMĂRUL 140 - Generative AI

Sponsori

  • Accenture
  • BT Code Crafters
  • Accesa
  • Bosch
  • Betfair
  • MHP
  • BoatyardX
  • .msg systems
  • Yardi
  • Colors in projects

INTERVIURI VIDEO