Administrarea datoriilor tehnice cu DX și AI

Fiecare companie, mare sau mică, se îngrijorează despre datoriile tehnice. Gartner estimează că aproximativ 40% din sistemele de infrastructură au această problemă. Într-un sondaj al CIO-urilor de către McKinsey, aproape o treime au simțit că peste 20% din bugetul lor pentru produse noi a fost alocat pentru a rezolva probleme legate de datoriile tehnice. Dar, contrar a ceea ce mulți cred, aceasta nu este doar o problemă de codificare; este și o problemă de experiență a dezvoltatorului (DX). Deoarece atunci când dezvoltatorii trebuie să lucreze cu o arhitectură inadecvată, instrumente învechite și fluxuri de lucru subpar, productivitatea, performanța și moralul suferă.

Prioritizarea datoriilor tehnice cu dezvoltatorul în minte, concentrându-se pe modul în care abordează munca, pe instrumentele pe care le utilizează și pe avansările de carieră pe care le pot obține, ajută echipele să se concentreze și să livreze mai repede. Acesta este motivul pentru care modul în care companiile gestionează datoriile tehnice se schimbă, condus de DX și o atenție sporită asupra instrumentelor bazate pe inteligență artificială.

Apărarea DX

Modul în care dezvoltatorii sunt adesea integrați în echipă lasă mult de dorit. Poate dura câteva săptămâni pentru ca cineva să înceapă să contribuie la un proiect. Odată ce au reușit să adauge funcții mici sau corecturi, nu este neobișnuit să vezi serviciul de integrare continuă (CI) eșuând din cauza unui lucru complet nelegat de modificările pe care le-au făcut. Acesta este, în esență, testul suite care eșuează din cauza problemelor de calitate slabă, iar dezvoltatorul nu a trimis modificări pentru a face testul suite să eșueze. Este un test slab, prost scris, care funcționează doar 90% din timp. Echipa existentă este probabil mulțumită de asta – doar încetinește procesele – dar instrumentele pot fi învechite și demoralizante pentru oricine din afara organizației.

Acesta este doar un exemplu din multe care împiedică o experiență DX corectă. Un mod de a preveni acest lucru este de a avea un campion desemnat în echipa dvs. de inginerie software și dezvoltare. Multe organizații mici nu au un lider DX, dar cele mari și de succes da. Acești profesioniști țin evidența lucrurilor, cum ar fi cât timp îi ia unui dezvoltator nou să configureze un mediu. Și dacă două săptămâni sunt prea mult, ei găsesc modalități de a reduce timpul la jumătate.

Există instrumente care pot ajuta, cum ar fi CircleCI, cu funcții native care vor urmări instabilitatea unui test suite. Ceea ce este necesar este ca cineva să ia inițiativa și să se oprească după fiecare sprint pentru a aborda unele dintre modificările care vor face codul mai ușor de întreținut și de lucru în viitor. Acesta este un lider interesat de îmbunătățirea DX. Pentru a face acest lucru, căutați un inginer de nivel senior, însoțit de un membru relativ nou al personalului care poate oferi feedback despre posibile lacune.

De asemenea, IDC estimează că piața de automatizare a testării software bazate pe inteligență artificială va continua să crească cu o rată anuală compusă de 31,2% până în 2027, așa că asigurați-vă că utilizați această tehnologie la maximum.

Metrici și semne de avertizare

Există multe metrice pe care le puteți urmări atunci când evaluați modul în care datoriile tehnice afectează echipa dvs. Unele dintre acestea sunt “timp de corectare” sau “timp de funcție”. Să zicem că observați o eroare și știți cum să o corectați. Unele instrumente pot urmări timpul petrecut de la scrierea codului până la producție. De exemplu, ați putea vedea că o corectură mică a durat două zile lucrătoare pentru a fi corectată și expediată, atunci când echipa dvs. are nevoie să poată face acest lucru în câteva ore. Puteți urmări, de asemenea, raporturi, cum ar fi numărul de corecturi de erori versus numărul de funcții finalizate.

Există, de asemenea, modalități de a identifica atunci când problemele de moral afectează performanța echipei dvs. Liderii DX pot efectua sondaje trimestriale pentru a determina cât de fericit este un dezvoltator care lucrează la un proiect sau la o parte a acestuia. Ei pot detalia și întreba despre domenii specifice, cum ar fi procesul de integrare continuă. Și puteți urmări întotdeauna rata de rotație a personalului în echipa dvs. Dacă observați că oamenii pleacă în mod constant, ei ar putea simți că îngrijorările lor nu sunt auzite.

Instrumente cu inteligență artificială

Creșterea instrumentelor bazate pe inteligență artificială ar trebui să facă dezvoltatorii și inginerii mai productivi și să expedieze produsele mai repede, dar datoriile tehnice încetinesc acest proces. Să zicem că utilizați un instrument, cum ar fi GitHub sau Copilot, pentru a ajuta la modificările codului, apoi trimiteți o solicitare de extragere, iar integrarea continuă durează câteva ore pentru a vă răspunde. Între timp, lucrează un dezvoltator la altceva? Verifică e-mailurile? Acesta este un schimb de context și un ucigaș de productivitate.

Dezvoltatorii vor să lucreze la produse unde pot pur și simplu să se concentreze pe cod. Instrumentele sunt acolo pentru a-i ajuta să ajungă la producție, nu pentru a fi o barieră constantă. Inteligența artificială poate economisi timp, dar depinde de echipele de ingineri să-și definească propriile standarde pentru complexitatea acceptabilă. Pentru a face acest lucru, asigurați-vă mai întâi că orice cod adăugat la ramura dvs. principală are un nivel acceptabil de datorii tehnice. Înainte de aceasta, aveți o discuție deschisă și obțineți acordul echipei de ingineri cu privire la pragul acceptabil de datorii tehnice și calitate a codului. Asigurați-vă că toată lumea știe că depășirea acestui prag necesită remediere imediată. Odată ce ați definit aceste standarde, inteligența artificială intră în joc.

Există un caz pentru agenți inteligenți artificiali cu ingineri care acționează ca orchestratori. Un sondaj Capgemini al 1.100 de executivi de la întreprinderi mari a arătat că 82% intenționează să integreze agenți inteligenți artificiali în următorii trei ani, iar aceștia au impact deja asupra viitorului muncii. Ați putea examina un raport de eroare și observați că este suficient de mic pentru a fi gestionat de un agent inteligent artificial, de la început până la revizuirea codului, economisind timpul echipei dvs. și eliberându-i să se ocupe de lucrări mai complexe. Cu toate acestea, uneori, atunci când urmăm orb aceste instrumente, există compromisuri pe care inteligența artificială nu le poate lua în considerare.

Acesta este momentul în care o părere umană devine factorul decisiv.

Alinierea datoriilor tehnice cu obiectivele

Cum aliniați reducerea datoriilor tehnice cu obiectivele pe care le urmăriți sau cu rezultate măsurabile? Acesta se referă la datoriile tehnice acceptabile, iar uneori, în afaceri, trebuie să expediați rapid. Puteți face acest lucru știind că un produs nu se escaladează, iar pot exista probleme de performanță pe măsură ce trece timpul. Adesea, un dezvoltator va face o notă pentru a reveni la acest lucru mai târziu, atunci când există timp pentru a aborda aceste probleme, dar rareori se întâmplă acest lucru. Și atunci când o astfel de cultură slabă preia, în care trebuie să expediați mereu, impactul datoriilor devine evident.

Acest lucru este înțelept pentru o companie de start-up, dar nu și pentru o afacere care a funcționat timp de un deceniu. Trebuie să începeți să schimbați cultura dvs. devreme și activ pentru a gestiona datoriile tehnice; altfel, veți cheltui o sumă enormă de bani pentru a remedia erorile de producție sau pentru a vă îngrijora cu privire la securitate și conformitate.

În cele din urmă, există metrice care pot ajuta la comunicarea valorii refacerii sau rambursării datoriilor tehnice către părțile interesate. Timpul poate fi unul dintre acestea, de la început până la producție, sau de la deschiderea unei solicitări de extragere până la fuziunea și expedierea acesteia către producție. Un altul este timpul mediu de reparare (MTTR). În acest caz, ați putea descoperi o eroare sau o construcție defectă și măsurați cât timp îi ia echipei dvs. pentru a o repara. Puteți urmări, de asemenea, numărul de erori pe care le aveți în producție. Dacă observați că acest număr crește, ar putea exista o problemă legată de datoriile tehnice.

Datoriile tehnice cu dobândă

Fiecare organizație poate dedica câteva ore pe săptămână pentru a-și îmbunătăți DX și pentru a reduce datoriile tehnice. Dacă nu, este posibil să plătiți mai târziu, probabil prin performanță lentă, o încetinire considerabilă a vitezei de dezvoltare sau probleme de securitate. De exemplu, echipa dvs. de ingineri și dezvoltatori ar fi putut amâna actualizările pentru Ruby on Rails timp de un deceniu. Brusc, costul unui proiect a crescut cu jumătate de milion de dolari, deoarece versiunea de Ruby este cu patru generații în urmă, lăsându-vă cu o masă de cod și dependențe învechite.

Dacă ați fi actualizat treptat, nu ați fi în această situație. Prin urmare, sprijiniți echipa dvs. de dezvoltare software și plătiți pe măsură ce mergeți. Altfel, aceste datorii tehnice vă vor hărțui mai târziu, cu dobândă.