Något som många pratar om idag är Continuous Delivery (CD) och jag fick möjlighet att lyssna på Jez Humble från Thoughtworks Studios som är en av dom främsta inom området.

Hela sessionen handlade i huvudsak om vad CD är och vad det är man uppnår och inte någon djupdykning i arkitektur och verktyg.

Så, vad är CD?
– Ett sätt att få mätbarhet i snabb förändringen
– Continuous integration
– Att fokusera på organisation och arkitektur
– Att skapa en kultur för continus improvement

Något som vi också går mer mot i utvecklingen är hypotesdriven leverans, dvs. vi vill prova något för att se om det ger oss den effekten vi eftersöker. Det kräver ett annat tänk och arbetssätt. Ofta skapar man ett experiment, en low fidelity feature som går att testa mot ex. 50% användare som använder funktionen och det vill man få ut med “en enkel knapptryckning”. Hela syftet med CD är att minska kostnad, tid och risk vid leverans av små inkrementella ändringar till användaren.

Så hur vet man när man uppnår effekten av CD? Enligt Jez handlar det om att mäta produktivitet och ett sätt är att titta på hur fort vi kan lära oss nya saker. Titta på feedbackloopen och utgå från den ledtiden och sätt ett mål.

Något som också är av stor vikt är att titta på:
– Bygger vi rätt saker
– Minskar vi risken i release
– Mjukvara ska alltid vara möjlig att släppa i produktion
– Prioritera det som ska gå att släppas
– Alla ska få automatiserad feedback
– Det måste finnas en plan för CD, arkitektur, kompetens och ansvar

Det här fick mig att fundera hur vi lär oss nya saker och att börja titta mer på hur vi kan uppnå en hypotesdriven leverans och hitta “pain points”. Eller som Jez uttrycker det “Don’t fight stupid, make more awesome”.