DevOps-siffror som används fel

Som mjukvaruutvecklare utför vi mycket av vårt konkreta arbete framför datorer. Men många beslut fattas utifrån de berättelser vi har accepterat eller de diagram vi ritar på våra whiteboards. Jag ska visa tre diagram som ofta används på fel sätt.

De genvägar som diagrammen representerar är värdefulla eftersom de hindrar oss från att uppfinna hjulet på nytt gång på gång. De här föreställningarna kan finnas i huvudet på en enskild utvecklare, i ett team, ett företag eller i branschen som helhet. De är kraftfulla, men kan användas för både bra och dåliga resultat.

Vi hamnar särskilt illa till när våra genvägar döljer information eller helt enkelt är felaktiga.

Göm era burndown-diagram!

Ett diagram som jag ser att alla självutnämnda Agile-team använder är burndown-diagrammet.

Syftet med diagrammet är att visa om teamet är på väg att leverera det som det har åtagit sig. Det ska ge teamet en tidig varning, så att de kan informera intressenter eller omprioritera vid behov.

När vi sätter ett mål i diagrammet antyder det dock vissa underliggande antaganden om hur mjukvaruutveckling fungerar. Det förutsätter att arbetet kan utföras på ett förutsägbart och jämnt sätt, vilket inte stämmer. Men det behöver inte vara ett problem. Det kan fungera som en tidig varning till teamet om att något inte går som förväntat och ge teamet möjlighet att vidta lämpliga åtgärder.

Oftare används burndown-diagrammet som ett styrmedel från ledningen. En projektledare eller en illasinnad Scrum Master kan dyka upp mitt i sprinten och sätta press på teamet eftersom burndown-diagrammet ser dåligt ut i deras ögon. Men det är inte meningsfullt att diskutera om ett burndown-diagram är bra eller dåligt. Diagrammet speglar helt enkelt den aktuella verkligheten.

Vi måste komma ihåg att burndown-diagrammet finns till för teamet. I sig självt säger det inget värdefullt eller konkret. Om vårt burndown-diagram förvånar eller skrämmer oss bör vi ta reda på exakt vad som förvånar oss och hur vi kan hantera det som team.

När burndown-diagrammet används fel skapar det inte bara inget värde, utan frustrerar också aktivt utvecklare som försöker lösa komplexa problem de aldrig har stött på tidigare.

Hantera försenade projekt

Att projekt ibland blir försenade går inte helt att undvika. Alla team tar på sig för mycket någon gång. De kan pressas till det, eller så missar de helt enkelt sitt mål.

Förhoppningsvis upptäcker vi tidigt i processen att vår ambition sannolikt inte kommer att uppfyllas, så att vi hinner agera. Men standardåtgärden när en deadline riskerar att missas är fel. När vi blir medvetna om att en deadline förskjuts förstärker vår intuitiva reaktion tyvärr bara problemet.

Standardåtgärden är följande: Företag brukar sätta in fler resurser och fler utvecklare för att lösa problemet. Förväntningen eller förhoppningen är att vi kommer fram snabbare när fler händer och hjärnor arbetar med problemet.

I verkligheten leder dock introduktionen av nya personer i ett projekt till en omedelbar produktivitetsminskning. Tiden som krävs för att sprida domänkunskap, granska arbete och hantera utmaningarna med att skala upp ett team börjar bromsa det redan försenade teamet.

Tills tillräckligt med tid har gått och de nya teammedlemmarna har kommit in i arbetet kommer de extra resurserna bara att ha minskat sannolikheten att vi når deadline. Som The mythical Man -Month rekommenderar är det enda sättet att hantera en deadline som verkar missas att minska omfattningen eller skjuta upp deadline.

Det finns också en dold kostnad i att lägga till fler resurser. När resurser behövs för att rädda ett projekt som ligger efter tidsplanen är det sannolikt att räddarna hittas internt. Det påverkar inte bara de projekt som personerna ursprungligen tilldelades, utan skapar också en instabil teamstruktur som gör kontinuerliga förbättringar svåra, om inte omöjliga.

Det vore inte ett problem om det hände sällan, men för många företag är det tyvärr normen: att flytta medarbetare från projekt till projekt i en förvirrande dans av skiftande prioriteringar.

Men allt är inte hopplöst, även om jag har målat upp en dyster bild av missade deadlines. Det finns saker vi kan göra.

Dra av plåstret och minska omfattningen

Det viktigaste steget är att tidigt fundera på om ett projekt kommer att bli försenat. Ofta är den bästa lösningen att minska omfattningen och vara medveten om hur du kan göra det till en meningsfull del-leverans.

Att minska omfattningen kan vara demotiverande, eller till och med oacceptabelt i vissa fall, men då behöver vi investera i att göra det enklare att lägga till resurser i våra projekt om behovet uppstår.

När deadline närmar sig och du märker att du kommer att missa ditt mål är det svårt att rätta till situationen. Det finns dock några åtgärder du kan vidta för att göra det enklare att lägga till resurser i ett projekt vid behov.

Bästa tipsen för att förenkla introduktionen

Jag rekommenderar att du behandlar alla mjukvaruprojekt som open source. Det innebär att fokus måste ligga på att göra det enkelt att bidra.

Det måste finnas dokumentation för användning, testning och utveckling av projektet. Testning måste vara automatiserad, och kvalitetsgrinden kan inte utgöras av en senior ingenjör – den bör i stället vara en petig robot. Verktygen som lagrar vår källkod har utvecklats för att stödja open source-arbetsflöden eller är starkt inspirerade av dem, så utnyttja plattformarnas inbyggda funktioner.

Se åtminstone till att följande finns på plats:

• En README med tydlig och tillgänglig dokumentation om hur du bygger, använder och testar produkten

• Länkar till pipelines, kodstandarder och extern dokumentation finns med

• Ett arbetsflöde som är tydligt beskrivet

• Alla nyckelpersoner nämns, inklusive hur de kan kontaktas

Det svåra med de här åtgärderna är att de fungerar som en försäkring. Det kan vara svårt att komma ihåg hur viktiga de är när du inte känner att du behöver dem. Men den dag du behöver dem har du inte råd att inte ha vidtagit de här åtgärderna.

Den överraskande sanningen om automatisering

Som DevOps-person har jag en inte helt sund förkärlek för automatisering. Vi vet att automatisering är en förutsättning för att kunna skala mer än linjärt med teamets storlek. Den ger också många fördelar när det gäller kvalitet, granskning, leveranshastighet och tillförsikt.

Vår intuition säger att mängden manuellt arbete minskar när vi investerar i automatisering. Men Accelerate DevOps Research motsäger faktiskt detta. De har funnit att automatiserad driftsättning i själva verket skapar mer manuellt arbete. Det beror på att det nu finns en mängd förändringar att testa och granska.

Vi bör dock vara medvetna om att vi bara har tagit bort en typ av manuellt arbete. Tricket är att se till att du mäter rätt sak, annars kan automatiseringsinsatsen bedömas som ett misslyckande trots att du har automatiserat en del av ditt arbetsflöde.

Den här ökningen av manuellt arbete är anledningen till att många automatiseringsinitiativ pausas eller bedöms som misslyckade. Vi måste inte bara göra mer manuellt arbete, utan också underhålla vår automatisering.

I organisationer som befinner sig i ett tidigt skede av att automatisera sina processer, eller har begränsad erfarenhet av automatisering, finns en tendens att misstro automatisering. Det leder till dubblerat arbete som utförs av både robotar och människor.

För att dra nytta av automatisering behöver vi också ändra vårt tankesätt. Genom att vara medveten om den här tillfälliga ökningen av manuellt arbete innan du påbörjar en automatiseringsprocess kan du förhoppningsvis undvika en obehaglig överraskning. I det här blogginlägget har jag visat några allmänt vedertagna siffror. Du kan läsa om en missuppfattning på företagsnivå i agile alignment trap.

Jag hade nöjet att delta i DevOpsDays Zurich 2019 och dela mina tankar från scenen i presentationen: Misused Figures of DevOps.