Håndtering af teknisk gæld med DX og AI

Hver virksomhed, stor som lille, bekymrer sig om teknisk gæld. Gartner estimerer, at omkring 40% af infrastruktursystemer har dette problem. I en undersøgelse af CIO’er af McKinsey, følte næsten en tredjedel, at over 20% af deres nye produktbudget gik til at løse problemer relateret til teknisk gæld. Men modsat, hvad mange tror, er dette ikke kun et kodningsproblem; det er også et udvikleroplevelsesproblem (DX). For når udviklere skal arbejde med utilstrækkelig arkitektur, forældet værktøj og underlødige udviklingsworkflows, lider produktivitet, præstation og moral.

Prioritering af teknisk gæld med udvikleren i mente, fokuserer på, hvordan de tilgår arbejdet, hvilke værktøjer de bruger og hvilke karrierefremskridt de kan opnå, hjælper hold med at fokusere og leverer hurtigere. Dette er, hvorfor måden, virksomheder håndterer teknisk gæld, ændrer sig, drevet af DX og en øget fokus på AI-drevet værktøj.

Udvikleroplevelse

Måden, udviklere ofte bliver onboarding, efterlader meget at ønske. Det kan tage et par uger alene for nogen at begynde at bidrage til et projekt. Når de endelig har kunnet tilføje små funktioner eller patches, er det ikke usædvanligt at se, at den kontinuerlige integration (CI) tjeneste fejler på grund af noget helt uafhængigt af de ændringer, de har arbejdet på. Dette er grundlæggende testssuiten, der fejler på grund af dårlige kvalitetsproblemer, og udvikleren har ikke indsendt ændringer for at gøre testssuiten fejl. Det er en ustabil, dårligt skrevet test, der kun virker 90% af tiden. Den eksisterende team er sandsynligvis okay med det – det blot langsommere processer – men værktøjet kan være forældet og demoraliserende for nogen uden for organisationen.

Dette er kun et eksempel på mange, der forhindrer den rette DX. En måde at forhindre dette på er at have en udpeget champion på dit softwareingeniør- og udviklingsteam. Mange små organisationer har ikke en DX-leder, men store, succesfulde organisationer har det. Disse eksperter holder øje med ting som, hvor lang tid det tager for en ny udvikler at konfigurere en miljø. Og hvis to uger er for lang tid, finder de ud af, hvordan de kan reducere denne tid med halvdelen.

Der er værktøjer derude til at hjælpe, som CircleCI, med native funktioner, der kan spore ustabiliteten af en testssuite. Hvad der er nødvendigt, er, at nogen tager ledelsen og stopper efter hver sprint for at adresse nogle af de ændringer, der vil gøre koden lettere at vedligeholde og arbejde med i fremtiden. Det kommer ned til at have en leder, der er interesseret i at gøre DX bedre. For at gøre det sker, skal du lede efter en senior-ingeniør, ledsaget af en relativt ny medarbejder, der kan give feedback på mulige huller.

Også, IDC forventer, at AI-drevet softwaretestautomatiseringsmarkedet vil fortsætte at vokse med en CAGR på 31,2% indtil 2027, så sikr dig, at du udnytter denne teknologi til fulde.

Mål og advarselssignaler

Der er mange mål, du kan spore, når du vurderer, hvordan teknisk gæld påvirker dit team. Nogle grundlæggende er “tid til at løse” eller “tid til funktion.” Lad os sige, du bemærker en fejl og ved, hvordan du kan løse den. Nogle værktøjer kan spore tiden brugt fra kodelæsning til produktion. For eksempel ville du være i stand til at se, at en meget lille patch tog to forretningsdage at løse og afsende, når dit team skal kunne gøre det på få timer. Du kan også spore forhold, som antallet af fejlrettelser i forhold til antallet af færdige funktioner.

Der er også måder at identificere, når moralproblemer påvirker dit teams præstation. DX-ledere kan køre undersøgelser kvartalsvis for at bestemme, hvor glad en udvikler er for at arbejde på et projekt eller en del af det. De kan bore ned og spørge om specifikke områder som CI-processen. Og du kan altid spore omskiftning eller omsætning i dit team. Hvis du bemærker, at folk holder op med at arbejde, kan de føle, at deres bekymringer ikke bliver hørt.

Arbejde med AI

Opkomsten af AI-værktøj er beregnet til at gøre udviklere og ingeniører mere produktive og produkter skal afsendes hurtigere, men teknisk gæld langsommere dette ned. Lad os sige, du bruger et værktøj som GitHub eller Copilot til at hjælpe med kodeændringer, derefter indsender du pull-anmodningen, og CI tager et par timer at komme tilbage til dig. I mellemtiden, arbejder en udvikler på noget andet? Tjekker emails? Det er en kontekstskift og en produktivitetsdræber.

Udviklere vil arbejde på produkter, hvor de kan fokusere på kode. Værktøjet er der for at hjælpe dem med at komme i produktion, ikke for at være en konstant vejspærring. AI kan spare tid, men det er op til ingeniørteamene at definere deres egne standarder for acceptabel kompleksitet. For at gøre dette, skal du først sikre, at al kode, der tilføjes til din hovedgren, har et acceptabelt niveau af teknisk gæld. Før det, skal du have en åben diskussion og få accept fra ingeniørteamet om det accepterede niveau af teknisk gæld og kodekvalitet. Sikr dig, at alle ved, at at gå over dette mærke kræver øjeblikkelig remediering. Når du har defineret disse standarder, kommer AI i spil.

Der er et tilfælde for AI-agenter med ingeniører, der fungerer som orkestratorer. En Capgemini-undersøgelse af 1.100 chefer i store virksomheder har afsløret, at 82% planlægger at integrere AI-agenter i de næste tre år, og de har allerede indvirkning på fremtidens arbejde. Du kan se på en fejlrapport og se, at det er små nok til, at en AI-agent kan håndtere det fra begyndelsen til kodegennemgang, hvilket sparer dit team tid og frigør dem til at håndtere mere komplekst arbejde. Men nogle gange, når vi blindt følger disse værktøjer, er der kompromiser, som AI kæmper for at overveje.

Det er, hvor en menneskelig mening bliver den afgørende faktor.

Justering af teknisk gæld med mål

Hvordan justerer du reduktion af teknisk gæld med mål, du forsøger at opnå eller målbare resultater? Det går tilbage til acceptabel teknisk gæld, og nogle gange i forretning, skal du afsende hurtigt. Du kan gøre det, mens du ved, at et produkt ikke skalerer, og der kan være problemer med præstation over tid. Ofte vil en udvikler lave en note til at vende tilbage til det senere, når der er tid til at løse disse problemer, men det sker sjældent. Og når denne dårlige kultur overtager, hvor du konstant skal afsende i morgen, bliver effekten af gælden overvældende tydelig.

Dette er forståeligt for en startup, men ikke for en forretning, der har været i gang i et årti. Du skal begynde at skifte din kultur tidligt og aktivt for at håndtere teknisk gæld; ellers vil du bruge en masse penge på at løse produktionsfejl eller bekymre dig om sikkerhed og overholdelse.

Til sidst er der mål, der kan hjælpe med at kommunikere værdien af at refaktorere eller betale ned teknisk gæld til interessenter. Tid kunne være et, fra begyndelse til produktion, eller fra åbning af en pull-anmodning til sammenlægning og afsendelse til produktion. Et andet er gennemsnitlig tid til reparation (MTTR). I dette tilfælde kan du have fundet en fejl eller en brudt bygning, og du måler, hvor lang tid det tager for dit team at løse det. Du kunne spore antallet af fejl, du har i produktion. Hvis du ser, at dette tal stiger, kan der være et problem relateret til teknisk gæld.

Teknisk gæld med rente

Hver organisation kan dedikere et par timer hver uge til at forbedre sin DX for at reducere teknisk gæld. Hvis ikke, kan du betale for det senere, sandsynligvis ved langsommere præstation, en betydelig langsommelse i udviklingshastighed eller sikkerhedsproblemer. For eksempel kunne dit team af ingeniører og udviklere have udskudt opgraderinger til Ruby on Rails i et årti. Pludselig er projektomkostningerne øget med en halv million dollars, fordi versionen af Ruby er fire generationer tilbage, hvilket efterlader dig med en masse kode og forældede afhængigheder.

Hvis du havde opgraderet gradvist, ville du ikke være i denne situation. Så støt dit softwareudviklingsteam og betal, mens du går. Ellers vil den tekniske gæld komme tilbage for at hjemsøge dig, med rente.