Edument

Du utövar <infoga metodik här>, men är du agil?

Nästan alla påstår sig vara agila. Vissa "på sitt sätt", andra mer formellt som en del av ett ramverk. Från små nystartade företag till stora bilförsäljare, från utvecklingsgrupper till HR, att inte vara agil är motsvarigheten till att erkänna att du hatar hundvalpar eller något lika normbrytande.

Även om ett agilt arbetssätt fungerar som ett universalmedel för alla problem, handlar den här artikeln inte om att räkna upp de olika sätten det har slaktats på. Istället kommer jag fokusera på varför det är svårt att uppnå vad agil utveckling lovar: Ett värde som levereras till kunder iterativt för att upprätthålla korta feedbackcykler. Detta underlättar snabb respons i samband med förändringar i omgivningen och bidrar med maximerad anpassning till de senaste affärsbehoven.


Varför misslyckas dina agila projekt? Är det för att du inte följer SCRUM, SAFe, LeSS eller <infoga metodik här> religiöst nog? Är det så att toppledningen bara följer en vattenfallsmodell med agila inslag istället för att adoptera tankesätten?


Möjligen, men du är också belastad med vikten av teknisk skuld.


Teknisk skuld är en metafor som myntats av Ward Cunningham 1992 och beskriver aktiviteter du inte utför i nuläget, men som sannolikt kommer att skapa problem längs. För att sätta detta i perspektiv; hur kan du vara agil och leverera värde snabbt när alltför stora ändringar krävs för varje ny funktion på grund av suboptimal arkitektur? Eller när upprepade buggar förstör din användarupplevelse och mekanismen för att säkerställa leveranser av hög kvalitet är alldeles för besvärlig? Du kan helt enkelt inte vara agil när du plågas av teknisk skuld.


Alves, Nicolli SR, et al. (2014) har i sitt arbete med titeln "Towards an ontology of terms on technical debt" identifierat 13 typer av teknisk skuld i mjukvaruprojekt. Några av de vanligare inkluderar:

  • Arkitektur- & designskuld
    • Hög koppling, ingen åtskillnad av oro, brist på modularitet, användning av antimönster
  • Kodskuld
    • Kod luktar, oläslig och mycket komplex kod
  • Test & automatiseringsskuld
    • Låg kodtäckning, manuell testning och distribution
  • Folkskuld
    • Knapp och koncentrerad expertis, brist på delad kunskap


Oavsett vilket agila ramverk du väljer så är teknisk skuld oundvikligt. Det agila ramverket illustrerar hur du organiserar ditt projekt, fördelar rollerna och definierar release-processen, men kommer inte göra de avgörande valen för dig när du hamnar i skuld.


Hur kan du då skydda ditt projekt från att bli lamslagen av teknisk skuld?


Teknisk skuld ackumuleras av val som, medvetet eller inte, gynnar kortfristiga intäkter framför negativa konsekvenser i framtiden. Därför bör du:

  1. Erkänna teknisk skuld som en av de främsta faktorerna som hindrar din effektivitet, tid till marknad och innovation
  2. Återbetala teknisk skuld genom att förse dina utvecklare med nödvändiga resurser
  3. Lär projektmedlemmarna att urskilja beslut som ökar teknisk skuld


De två förstnämnda handlar om strategi, kultur och i slutändan insikten att ju längre du undviker handling, desto närmare kommer du förödelse. 

Med det senare kan Edument hjälpa till med våra begåvade konsulter och våra kurser om olika programmeringsspråk, mjukvaruarkitekturtestdriven utveckling, och Git.


Källa: dilbert.com



Av: Dimitrios Platis


JavaScript seem to be disabled in your browser.

You must have JavaScript enabled in your browser to utilize the functionality of this website.