God forvaltning af teknisk gæld gør forskellen mellem et vellykket og mislykket softwareprojekt. At ignorere eller undlade at anerkende teknisk gæld kan føre til højere udviklingsomkostninger og lave økonomiske afkast. Så i betragtning af indsatsen, forståelse og håndtering af teknisk gæld bør være en prioritet til softwareingeniører og beslutningstagere på højt niveau.
Teknisk gæld eller kodegæld er ikke nødvendigvis negativ - nogle gange kan det være strategisk løftestang til dit projekt i det lange løb. Så hvis du vælger at have teknisk gæld, er der normalt en strategi, hensigt og begrundelse bag det. Og selvom det er risikabelt, kan det være meget gavnligt. Næsten hver virksomhed har en vis grad af teknisk gæld - tricket er at vide, hvordan man identificerer og styrer det. Dette blogindlæg hjælper dig med at gøre netop det, så lad os se på, hvad teknisk gæld er, hvilken slags teknisk gæld der er, hvordan de påvirker din udviklingsproces, og hvordan du kan styre det.
Teknisk gæld, teknisk gæld, eller kode gæld er begrebet forsinkelse eller udeladelse af arbejde for at gennemføre et projekt eller nå et mål hurtigere, men som også medfører mere omarbejdning senere i projektets livsfase. Vi kan sammenligne det med at bygge et hus uden et komplet sæt tegninger - byggeriet afsluttes muligvis hurtigere, men huset vil have betydelige strukturelle problemer, som vil tage mere tid og flere penge at løse senere.
I softwareudviklingsområdet er det almindeligt at levere en funktion med det samme for at forstå, hvordan den vil skaleres. Når den er skaleret markant, kan vi tilpasse den til den dimension, den har nået. Men hold dig opdateret, da vi vil dække alle former for teknisk gæld senere.
Alt i alt kan teknisk gæld henvise til enhver del af web- eller appudvikling, men det er normalt rettet mod programmering, især kode refactoring. Og ligesom finansiel gæld, kode eller teknisk gæld påløber renter - Jo længere gælden eller efterslæbet af ignorerede problemer opbygges, jo dyrere bliver det at rette op på.
I en McKinsey-undersøgelse gennemført i 2020, CIO'er rapporterede, at 10 til 20% af teknologien budgettere allokeret til ny software omdirigeres til at løse problemer relateret til Teknisk gæld. Endnu mere bekymrende anslog CIO'er, at teknologigæld beløber sig til 20 til 40% af værdien af hele deres teknologiejendom før afskrivning. Dette betyder hundreder af millioner af dollars ubetalt gæld til større virksomheder.
Teknisk gæld er et naturligt resultat af softwareudvikling, og når det kommer til at identificere det, er de fleste eksperter enige om to bredere kategorier:
Bevidst teknisk gæld eller aktiv gæld opstår, når hold bevidst ønsker en hurtig, men ufuldkommen implementering til 1) etablere en tilstedeværelse på et hurtigt udviklende marked eller 2) at indsamle kundefeedback. Bevidst teknisk gæld anvendes ofte, når der udvikles minimum levedygtige produkter (MVP), som løbende vil blive videreudviklet og fastlagt i henhold til feedback fra kunder og kunder.
Men teams har sjældent tid til at gå tilbage og redesigne, hvordan de oprindeligt planlagde, så det er altid bedst at samarbejde med et team, der har projektet ordentligt kortlagt for hver livsfase. For eksempel, hos Imaginary Cloud, går udviklere tilbage til at optimere og forbedre koden til appen eller softwaren, når den er live.
Et godt og simpelt eksempel på bevidst teknisk gæld er, hvordan Airbnb ikke gider at rette deres websteds yndlingsknap. Der var et øjeblik, hvor knappen til yndlingshuse eller værelser ikke fungerede. Da Airbnb's fokus var hurtig vækst på det tidspunkt, havde de ikke noget imod at springe dette problem over. Holdet løste først problemet, da virksomheden begyndte at nyde mere popularitet og nåede en mere moden fase i sin livscyklus.
Utilsigtet teknisk gæld sker ved et uheld og opstår normalt, når udviklere Forstår ikke markedets krav eller hvordan man designer en arkitektur for at imødekomme markedets krav.
For eksempel, når et team designer et softwaresystem, forsøger et team at balancere ved at tænke fremad og fremtidssikre deres plan med enkelhed og levering. Efterhånden som systemet udvikler sig, og kravene ændres, kan de indse, at deres strategi er mangelfuld, eller at den nye funktionalitet er blevet vanskelig og langsom at implementere.
Teknisk gæld har også specifikke typer, der hver især inkluderer det specifikke problem inden for titlen:
Selvom disse typer er meget specifikke, er den mest populære Martin Fowlers tekniske gældskvadrant som beskriver de former for gæld (bevidst og utilsigtet) og valget af at påtage sig gæld (hensynsløs eller forsigtig).
Vi kan identificere hver kvadrant ved at tildele den en farve, der svarer til dens ønskværdighed: rød og orange (øverst og nederst til venstre) angiver advarsel; grøn og blå (øverst og nederst til højre) angiver ønskværdighed.
Lad os tage hver kvadrant efter tur og overveje rollen som et udviklingsteam i styringen af risikoen.
Denne form for gæld opstår, når Teamet har den rette viden til at gennemføre opgaven endnu beslutter bevidst at gå med en hurtig og dårlig kvalitetsløsning, normalt til fordel for hurtig implementering. Dette er nogle af de spørgsmål, du skal stille, før du vælger denne metode:
At ikke styre aspekter som det ovennævnte er det, der tipper bevidst teknisk gæld ind i det hensynsløse område.
Det betyder at starte noget nyt i et langsomt tempo, for at sikre, at du og alle andre, der arbejder med dig, ved præcis, hvad du skal gøre, og hvilke procedurer du skal følge.
Bevidst og forsigtig tech-gæld handler om træffe informerede beslutninger og dermed overveje, om udbetalingen for en tidligere udgivelse er større end omkostningerne ved at betale den af. Den teamet anerkender problemet og dets konsekvenser men skal leverer i øjeblikket funktionaliteten til tiden. I dette tilfælde planlægger teamet også, hvordan man håndterer virkningerne under hensyntagen til ethvert værst tilfælde.
Uforvarende og hensynsløs er Den mindst ønskelige form for gæld du vil have - det kaldes normalt software entropi som vi forklarer i næste kapitel. Holdene forventes at forstå det grundlæggende af de teknologier, de bruger, og ignorering af dem vil resultere i en buggy applikation med uventet applikationsadfærd eller dårlig vedligeholdelse. Et veluddannet team med opdateret branchekendskab og bedste praksis bør være i stand til at undgå denne type teknisk gæld.
Dette er uforsætlig slags gæld - det kan ske på trods af en omhyggelig tilgang til projektets arkitektur og kode. Ofte er det først efter at en funktionalitet er implementeret eller projektet er afsluttet, at teamet indser, at hvis de havde designet de enkelte komponenter i applikationen anderledes, ville de sandsynligvis ende med en bedre løsning. Så målet er at maksimere læringsmuligheden, så du kan gå fra „utilsigtet“ til „forsigtig“ for mere af din tekniske gæld.
Bitrot eller softwareentropi er den slags teknisk gæld, du vil undgå, som vi har nævnt ovenfor. Det sker over tid, når en komponent eller et system langsomt udvikler sig til unødvendig kompleksitet gennem mange trinvise ændringer, ofte når der arbejdes på af flere udviklere, der måske ikke fuldt ud forstår den originale arkitektur. Denne mangel på dygtighed er en utilsigtet og hensynsløs form for gæld tilskrives dårlig logik og kodningspraksis.
Du vil undgå softwareentropi, fordi:
Vi anbefaler, at du kigger efter hold, der har en dedikeret projektleder, der kan holde deres udviklere ansvarlige ved at sikre, at udviklingsprocessen ikke giver plads til bitrot.
Læs også:
Ifølge en Undersøgelse udført af Stepsize, 61% af ingeniørteams hævder, at det meste af den tekniske gæld kommer fra backendSpecifikt i webserverslutpunkter. Virksomhedsapps og websteder og generel infrastruktur er også dele af kodebasen, der akkumulerer en stor mængde teknisk gæld. Resultaterne tyder på, at Virksomheder kan øge deres produktivitet dramatisk ved at betale ned teknisk gæld i disse områder af deres kodebase.
Andre hovedfaktorer, der bidrager til teknisk gæld, omfatter:
Disse spørgsmål kan akkumuleres over tid, hvis det ikke overvågesDette resulterer i tekniske problemer, der skal løses i fremtiden. Det vil være bedst at samarbejde med et kompetent team eller partner med de rigtige processer, planer og tidsplaner. Dette team skal gøre objekterne synlige ved at registrere poster i softwarens backlog, hvor problemerne vil blive vurderet og prioriteret til løsning.
Tag eksemplet med Twitters berømte Fail Whale-sag. Platformen plejede at gå ned flere gange og gå i „nødvedligeholdelsestilstand“, hvilket skadede virksomheden. Udseendet af den fredfyldte, optimistiske beluga blev en stigende bekymring, da Twitter udvidede sig til et bredere publikum. Derfor besluttede Twitter at integrere et udviklingsteam, der instrumenterede hele systemet og begyndte at genopbygge hver del, der var ved at bryde, ved at flytte deres backend-processer til en række programmeringssprog, der var mere kompatible med Java Virtual Machine-rammen.
Når disse ændringer var implementeret, var Twitters team i stand til at bruge mindre tid på fejlfinding af afbrydelser og mere tid på at udvikle nye funktioner, reducere teknisk gæld, slippe af med teknisk ineffektivitet og endelig give en bedre brugeroplevelse.
„Slibning er ikke særlig tilfredsstillende. Det er svært at stå op foran alle og sige, „vi vil ordne tingene her lidt efter lidt med en masse hårdt arbejde.“ Store prangende bevægelser er lettere at sælge det meste af tiden. Men de fungerer ikke næsten lige så godt og er tilbøjelige til fuldstændig og forfærdelig fiasko.
Det er vigtigt at nævne det Teknisk gæld kommer ikke altid fra udviklingshold. Ansættelsesfirmaer eller kunder vil ofte pålægge begrænsninger førende udviklere uden andet valg end at pådrage sig dem. Disse er normalt:
Læs også:
Når det er bevidst:
Udviklingsteams kan håndtere forsætlig teknisk gæld ved Sporing af efterslæbet når man bevidst udsætter arbejde, der skal afsluttes. Hvis et team ikke kan holde trit med deres løfte om at gå tilbage for at gennemgå koden, eller det ikke har midlerne til at gøre det, er det usandsynligt, at det bliver tilbagebetalt og vil blive til utilsigtet designgæld over tid.
Denne gæld opstår normalt fra forretningsbeslutninger; derfor interessenter og produktejere bør holdes ansvarlige for periodiseringen.
Når det er tilfældigt:
At refaktorere et system med succes er en enorm opgave, men dette bør gøres nu og da, når systemet er i en stabil tilstand. Ellers kan teamet overkonstruere systemet og pådrage sig unødvendige afmatninger.
I dette tilfælde tech-leads og produktejere bør være ansvarlige for at sikre, at der afsættes tid til at løse denne form for teknisk gæld som følge af designbeslutninger og hyppigt skiftende krav.
Læs også:
Teknisk gæld er ikke altid en byrde - den kan mange gange være en strategisk løftestang for succes, hvis den styres godt. Hos Imaginary Cloud kan vi samarbejde med dig i det nødvendige udviklingsstadium for at kvitte dig for unødvendig gæld, både teknisk og designmæssig. Uanset om det er at bringe din idé til live gennem udvikling af web- og app-software eller at udjævne dit teams færdigheder gennem teamudvidelse, sørger vi for, at din tech-gæld håndteres godt hvert trin på vejen.
Alsidig og datadrevet vækstmarkedsfører med dybdegående forretningskendskab, opdateret med den seneste udvikling i det digitale marketinglandskab.
People who read this post, also found these interesting:
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
%20(1).webp)
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
