God hantering av teknisk skuld gör skillnaden mellan ett framgångsrikt och misslyckat mjukvaruprojekt. Att ignorera eller underlåta att redovisa teknisk skuld kan leda till högre utvecklingskostnader och låg ekonomisk avkastning. Så med tanke på insatserna, förståelse och hantering av teknisk skuld bör prioriteras för mjukvaruingenjörer och beslutsfattare på hög nivå.
Teknisk skuld eller kodskuld är inte nödvändigtvis negativ - ibland kan det vara strategisk hävstång för ditt projekt på lång sikt. Så om du väljer att ha teknisk skuld finns det vanligtvis en strategi, avsikt och motivering bakom det. Och även om det är riskabelt kan det vara mycket fördelaktigt. Nästan varje företag har en viss grad av teknisk skuld - tricket är att veta hur man identifierar och hanterar det. Det här blogginlägget hjälper dig att göra just det, så låt oss titta på vad teknisk skuld är, vilken typ av tekniska skulder det finns, hur de påverkar din utvecklingsprocess, och hur du kan hantera det.
Teknisk skuld, teknisk skuld, eller kod skuld är begreppet att försena eller utelämna arbete för att slutföra ett projekt eller nå ett mål snabbare, men som också orsakar mer omarbetning senare i projektets livsfas. Vi kan jämföra det med att bygga ett hus utan en komplett uppsättning ritningar - byggandet kan slutföras tidigare, men huset kommer att ha betydande strukturella problem som tar mer tid och mer pengar att fixa senare.
Inom mjukvaruutvecklingsområdet är det vanligt att leverera en funktion direkt för att förstå hur den kommer att skalas. När den har skalat avsevärt kan vi anpassa den till den dimension den har nått. Men håll dig uppdaterad, eftersom vi kommer att täcka alla typer av tekniska skulder senare.
Sammantaget kan teknisk skuld hänvisa till någon del av webb- eller apputveckling, men det riktas vanligtvis till programmering, särskilt kodrefactoring. Och precis som finansiell skuld, kod eller teknisk skuld tillför ränta - Ju längre skulden eller eftersläpningen av ignorerade frågor byggs upp, desto dyrare blir det att rätta till.
I en McKinsey-undersökning genomfördes 2020, CIOs rapporterade att 10 till 20% av tekniken budget allokerad till ny programvara omdirigeras till att åtgärda problem relaterade till Teknisk skuld. Mer oroande är att CIO:er uppskattade att teknikskulden uppgår till 20 till 40% av värdet av hela deras teknikegendom före avskrivningar. Detta innebär hundratals miljoner dollar obetalda skulder för större företag.
Teknisk skuld är ett naturligt resultat av mjukvaruutveckling, och när det gäller att identifiera det, är de flesta experter överens om två bredare kategorier:
Avsiktlig teknisk skuld eller aktiv skuld inträffar när team medvetet vill ha en snabb men ofullkomlig implementering till 1) etablera sig på en marknad som utvecklas snabbt eller 2) för att samla in feedback från kunder. Avsiktlig teknisk skuld tillämpas ofta vid utveckling av minimilivskraftiga produkter (MVP), som kontinuerligt kommer att vidareutvecklas och fixas enligt kund- och kundfeedback.
Men team har sällan tid att gå tillbaka och omforma hur de ursprungligen planerade, så det är alltid bäst att samarbeta med ett team som har projektet ordentligt kartlagt för varje livsfas. Till exempel, på Imaginary Cloud, går utvecklare tillbaka till att optimera och förbättra koden för appen eller programvaran när den är live.
Ett bra och enkelt exempel på avsiktlig teknisk skuld är hur Airbnb inte brydde sig om att fixa sin webbplats favoritknapp. Det fanns ett ögonblick då knappen till favorithus eller rum inte fungerade. Eftersom Airbnbs fokus var snabb tillväxt vid den tiden, hade de inget emot att hoppa över det här problemet. Teamet fixade problemet först när företaget började njuta av mer popularitet och nådde en mer mogen fas i sin livscykel.
Oavsiktlig teknisk skuld sker av misstag Detta sker oftast när utvecklare Förstår inte marknadens krav eller Hur man utformar en arkitektur för att möta marknadens krav.
Till exempel, när man utformar ett mjukvarusystem, försöker ett team balansera genom att tänka framåt och framtidssäkra sin plan med enkelhet och leverans. När systemet utvecklas och kraven förändras kan de inse att deras strategi är bristfällig eller att den nya funktionaliteten har blivit svår och långsam att implementera.
Teknisk skuld har också specifika typer, var och en inklusive det specifika problemet i titeln:
Även om dessa typer är mycket specifika, är den mest populära Martin Fowlers tekniska skuldkvadrant som beskriver typerna av skuld (avsiktlig och oavsiktlig) och valet att ta på sig skuld (hänsynslös eller försiktig).
Vi kan identifiera varje kvadrant genom att tilldela den en färg som motsvarar dess önskvärdhet: röd och orange (uppe och nere till vänster) indikerar varning; grönt och blått (uppe och nere till höger) indikerar önskvärdhet.
Låt oss ta varje kvadrant i tur och ordning och överväga rollen för ett utvecklingsteam för att hantera risken.
Denna typ av skuld uppstår när Teamet har rätt kunskap för att genomföra uppgiften ännu beslutar medvetet att gå med en snabb och dålig kvalitetslösning, vanligtvis till förmån för snabb implementering. Det här är några av de frågor du bör ställa innan du väljer den här metoden:
Att inte hantera aspekter som ovan nämnda är vad som tipsar avsiktlig teknisk skuld till det hänsynslösa territoriet.
Det betyder att starta något nytt i långsam takt, att se till att du och alla andra som arbetar med dig vet exakt vad du ska göra och vilka procedurer du ska följa.
Avsiktlig och försiktig teknisk skuld handlar om fatta välgrundade beslut och därmed överväga om utbetalningen för en tidigare release är större än kostnaderna för att betala av den. Den teamet känner igen problemet och dess konsekvenser men måste Tillhandahåller för närvarande funktionaliteten i tid. I det här fallet planerar teamet också hur man hanterar effekterna, med tanke på alla värsta fall.
Oavsiktlig och hänsynslös är Minst önskvärd typ av skuld du vill ha - det kallas vanligtvis mjukvaruentropi som vi förklarar i nästa kapitel. Lag förväntas förstå grunderna av de tekniker de använder, och ignorering av dem kommer att resultera i en buggy applikation med oväntat applikationsbeteende eller dåligt underhåll. Ett välutbildat team med aktuell branschkunskap och bästa praxis bör kunna undvika denna typ av teknisk skuld.
Detta är oavsiktlig typ av skuld - det kan hända trots en noggrann inställning till projektets arkitektur och kod. Ofta är det först efter att en funktionalitet har implementerats eller projektet är avslutat att teamet inser att om de hade designat de enskilda komponenterna i applikationen annorlunda skulle de förmodligen hamna med en bättre lösning. Så målet är att maximera inlärningsmöjligheten så att du kan gå från ”oavsiktlig” till ”försiktig” för mer av din tekniska skuld.
Bitrot eller mjukvaruentropi är den typ av teknisk skuld du vill undvika, som vi har nämnt ovan. Det händer över tid när en komponent eller ett system långsamt förvandlas till onödig komplexitet genom många stegvisa förändringar, ofta när de arbetas på av flera utvecklare som kanske inte helt förstår den ursprungliga arkitekturen. Denna brist på skicklighet är en oavsiktlig och hänsynslös form av skuld tillskrivs dålig logik och kodningspraxis.
Du vill undvika programvaruentropi eftersom:
Vi rekommenderar att du letar efter trupper som har en dedikerad projektledare som kan hålla sina utvecklare ansvariga genom att se till att utvecklingsprocessen inte lämnar utrymme för bitrot att uppstå.
Läs också:
Enligt en studie utförd av Stepsize, 61% av ingenjörsteamen hävdar att det mesta av den tekniska skulden kommer från backend, särskilt i webbserverns slutpunkter. Företagsappar och webbplatser och allmän infrastruktur är också delar av kodbasen som ackumulerar en stor mängd teknisk skuld. Resultaten tyder på att företag kan dramatiskt öka sin produktivitet genom att betala ner teknisk skuld i dessa områden av deras kodbas.
Andra huvudfaktorer som bidrar till teknisk skuld inkluderar:
Dessa frågor kan ackumuleras över tid om den inte övervakasDetta leder till tekniska brister som måste åtgärdas i framtiden. Det är bäst att samarbeta med ett kompetent team eller partner med rätt processer, planer och tidsscheman. Detta team bör göra objekten synliga genom att registrera poster i programvarubackloggen, där problemen kommer att bedömas och prioriteras för lösning.
Ta exemplet med Twitters berömda Fail Whale-fall. Plattformen brukade krascha flera gånger och gå på ”nödunderhållsläge”, vilket skadade verksamheten. Utseendet på den fridfulla, optimistiska beluga blev ett ökande problem när Twitter expanderade till en bredare publik. Därför beslutade Twitter att integrera ett utvecklingsteam som instrumenterade hela systemet och började bygga om varje del som var på väg att bryta genom att flytta sina backend-processer till en serie programmeringsspråk som var mer kompatibla med Java Virtual Machine-ramverket.
När dessa förändringar genomfördes kunde Twitters team spendera mindre tid på att felsöka avbrott och mer tid på att utveckla nya funktioner, minska teknisk skuld, bli av med teknisk ineffektivitet och slutligen ge en bättre användarupplevelse.
”Slipning är inte särskilt tillfredsställande. Det är svårt att stå upp framför alla och säga, ”vi kommer att fixa saker här lite för bit med mycket hårt arbete.” Stora prickiga drag är en enklare försäljning för det mesta. Men de fungerar inte nästan lika bra och är benägna att helt och hållet misslyckas.”
Det är viktigt att nämna det Teknisk skuld kommer inte alltid från utvecklingsteam. Anställningsföretag eller kunder kommer ofta att kräva begränsningar ledande utvecklare utan något annat val än att ådra sig dem. Dessa är vanligtvis:
Läs också:
När det är avsiktligt:
Utvecklingsteam kan hantera avsiktliga tekniska skulder genom att spåra eftersläpningen när man medvetet skjuter upp arbete som måste slutföras. Om ett team inte kan hålla jämna steg med sitt löfte om att gå tillbaka för att granska koden eller om det inte har möjlighet att göra det, är det osannolikt att det kommer att återbetalas och kommer att förvandlas till oavsiktlig designskuld över tid.
Denna skuld uppstår vanligtvis från affärsbeslut; därför intressenter och produktägare bör hållas ansvariga för periodiseringen.
När det är oavsiktligt:
Att framgångsrikt omstrukturera ett system är en enorm uppgift, men detta bör göras då och då när systemet är i en steady-stade. Annars kan teamet överkonstruera systemet och drabbas av onödiga avmattningar.
I det här fallet tekniska ledare och produktägare bör vara ansvariga för att se till att tid avsätts för att lösa denna typ av teknisk skuld som uppstår på grund av designbeslut och ofta föränderliga krav.
Läs också:
Teknisk skuld är inte alltid en börda - den kan många gånger vara en strategisk hävstång för framgång om den hanteras väl. På Imaginary Cloud kan vi samarbeta med dig i vilket utvecklingsstadium som helst för att rensa dig från onödiga skulder, både tekniska och designmässiga. Oavsett om det handlar om att förverkliga din idé genom webb- och appmjukvaruutveckling eller höja teamets färdigheter genom teamförlängning, ser vi till att din tekniska skuld hanteras väl varje steg på vägen.
Mångsidig och datadriven tillväxtmarknadsförare med fördjupad affärskunskap, uppdaterad med den senaste utvecklingen inom det digitala marknadsföringslandskapet.
Människor som läste det här inlägget tyckte också att dessa var intressanta:
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
%20(1).webp)
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
