Teknikvärlden förändras snabbt, snabbare än någonsin. För några år sedan trodde vi att endast världens Amazons och Facebooks skulle kunna göra kontinuerliga leveranser. Nu börjar fenomenet få fäste, börjar bli allmänt accepterat och innan vi vet ordet av kommer det att bli en handelsvara. Alla kommer att göra det.
Varför? Eftersom förmågan att släppa ofta ger organisationer en stor konkurrensfördel jämfört med konkurrenter med långsammare genomströmningstider. För att kunna tillämpa kontinuerlig leverans måste teamet bygga in kvalitet i allt de gör. Detta innebär att produkten inte bara når kunderna snabbare - den är också bättre. Att lära sig att bygga in kvalitet med Kanban hjälpte mitt utvecklingsteam att minska slöseriet, leverera snabbare och kommunicera bättre med organisationen runt omkring oss.
Keep reading to learn how my development team changed our infrastructure, development practices, and culture to enable continuous delivery.
Hur kvalitet och kontinuerlig leverans hänger ihop
Jag har haft turen att ingå i ett team som arbetar med att förbättra vår organisations förmåga att leverera snabbt, så jag har upplevt den turbulens som uppstår när man går från en version per månad till flera versioner per dag.
Om man tillämpar traditionella testmetoder kan utmaningen verka omöjlig, och utan att helt förändra sättet vi bygger och testar programvara kan vi faktiskt inte förvänta oss att nå en hållbar kontinuerlig leverans.
Vårt antagande av Kanban och Kanban-metoden var grundläggande för den riktning som vi var på väg mot. Genom att använda metoden kunde vi identifiera våra flaskhalsar, synliggöra väntetiden och maximera fördelarna med små partier och kontinuerligt flöde.
Vi insåg snart att om vi ville ha någon chans att kunna släppa kontinuerligt måste vi minska omarbetningen. I den gamla världen tog testare och affärsanvändare två veckor av iterationen för sina kvalitetskontroller. En stor del av tiden gick inte åt till att testa, utan till att identifiera och logga ett stort antal fel och hantera instabila miljöer.
Vi angrep problemet på tre fronter: Infrastruktur, utvecklingsmetoder och kultur.
Infrastruktur: Minska mänskliga fel
För att minska antalet omarbetningar i vår infrastruktur utvecklade vi en helt ny leveransledning som transporterade både kod och sammanhang. Vi skapade också testmiljöer på begäran för att minska den tid som gick åt till att konfigurera dem manuellt och ändra felaktiga konfigurationer.
Detta innebar en drastisk minskning av manuella steg i byggandet och distributionen. Även om detta till en början bara implementerades i våra testmiljöer gav det oss omedelbara fördelar. Möjligheten att testa i tillförlitliga miljöer, som skapats med en upprepningsbar process, minskade vår testtid avsevärt.
Utvecklingspraxis: Bättre kommunikation, mindre användarhistorier
Beteendestyrd utveckling (BDD)
Vi införde beteendestyrd utveckling (Behavior Driven Development, BDD) för att minska missförstånden mellan intressenterna och utvecklingsteamet och som en följd av detta minska omarbetningen på grund av missförstånd.
BDD gav utmärkta resultat mycket tidigt. Vi insåg snart hur mycket vi hade överlåtit till individuella tolkningar - och i vilken utsträckning detta hade orsakat de flesta av de brister som vi fann i kvalitetskontrollverksamheten. Tack vare BDD minskade antalet fel dramatiskt. Ju mer vi förbättrade samarbetet i grupperna, desto mer ökade kunskapen om verksamheten hos medlemmarna. Detta gjorde det lättare att fatta beslut; beslut som tidigare hade krävt långa, frustrerande möten blev nu snabba samtal.
Mindre användarhistorier
Ett annat tillvägagångssätt som vi fann mycket fördelaktigt för att minska omarbetningen var att vertikalt dela upp våra användarberättelser och därmed minska deras komplexitet. Detta innebar ofta att logiken i den nya koden skulle omfatta en enda kodväg. Lägre komplexitet innebar färre defekter och mindre omarbete.
Balanserad strategi för automatisering av tester
Samtidigt definierade vi en strategi som innebar hög användning av automatiserade tester på enhetsnivå, ett konsekvent lager av automatiserade tester på API-nivå och ett mycket tunt lager av UI-drivna tester i linje med Mike Cohns pyramid för automatiserade tester. Detta gjorde att vår regressionssvit kunde förbli snabb och stabil, något som är helt grundläggande om du vill kunna leverera kundvärde varje gång ditt utvecklingsteam lägger fram ny kod.
Användningen av BDD och implementeringen av testautomatisering innebar inte att vi slutade utföra utforskande testning, utan att aktiviteten blev mindre och mindre tidskrävande på grund av att antalet defekter minskade och att berättelserna blev mindre och mindre omfattande.
Att bygga kvalitet i
Jag arbetade under ett par månader med en produkt som innebar omvandling av en dataström till en annan datastruktur som skulle konsumeras av en klient, och jag minns att jag aldrig testade något mer än 10 minuter, och det kändes aldrig som om jag lämnade något efter mig. Det var befriande för mig att känna att jag kunde producera kvalitetsarbete i snabb takt utan att offra något.
Våra kunder hade inte heller några problem. Vi inspekterade programmet i en storleksordning mindre än tidigare, men kvaliteten på våra resultat var högre. Vi byggde in kvalitet.
Kultur: Uppmuntra samarbete
Denna typ av omvandling är inte särskilt svår ur teknisk synvinkel. Det är mycket mer komplicerat ur kulturell synvinkel. När jag började på det företag jag hänvisar till fann jag extremt skickliga utvecklare som inte var vana vid testning. De hade blivit bortskämda av testarna som sprang efter deras skräpiga kod och aldrig fått något intresse för denna disciplin.
Det är svårt att förändra kulturen. Vår strategi var att uppmuntra hälsosamma beteenden snarare än att straffa dåliga beteenden. Vi uppmuntrade och berömde till exempel utvecklare som var villiga att testa, och vi berömde även personer som arbetade i par. Vi uppmuntrade och erkände alla typer av samarbete. Vi visste att teamet måste bli en enhet av människor som litade på varandra och inte bara en grupp människor med alla de färdigheter som krävs för att leverera en komplex lösning.
Kunskapsdelning och skapandet av en teststam
Vi behövde uppnå en sammanhållning i arbetet som gav möjlighet till samarbete och tog bort flaskhalsar samtidigt som arbetet flöt på. En av nycklarna till framgång var att vi fokuserade på att bygga upp t-formade färdigheter genom att lära av varandra och erbjuda hjälp i alla lägen.
Ett framgångsrikt initiativ var skapandet av Test Tribe. Tribe var en frivillig och helt självständig grupp människor som brydde sig om mjukvarukvalitet. Efter ett tag blev den här gruppen, som träffades varje vecka för att ha Lean Coffee-liknande samtal, stor och majoriteten av medlemmarna var utvecklare. Jag har inte tillräckligt med utrymme för att nämna ett antal experiment och förbättringar som började på denna nivå.
En anmärkningsvärd framgång var utformningen av ett verktyg som avsevärt förbättrade testbarheten av vår huvudapp, vilket minskade tiden för utforskning från timmar till minuter. Stammen bidrog också till att förändra vår process, ta bort onödiga steg och i ett specifikt fall identifiera en förändring som minskade ledtiden med 30 % med liten ansträngning.
Stammen blomstrade och dess framgångar spreds snabbt till de olika grupperna där medlemmarna fanns. Grupperna började experimentera mer och mer och förbättra sina system, vilket var fantastiskt att observera.
Byggkvalitet i: Slutliga tankar
Alla organisationer kan tillämpa kontinuerlig leverans - och det bör de göra om de vill konkurrera på den moderna marknaden. Kontinuerlig leverans hjälper organisationer att inte bara leverera snabbare än konkurrenterna, utan också med högre kvalitet.
Jag har sett detta fungera i mitt eget utvecklingsteam, genom en rad stegvisa förändringar som resulterade i ett stort skifte i hur vi arbetade - och som hjälpte oss att gå från en version per månad till flera versioner per dag:
Infrastruktur: Vi ändrade vår infrastruktur för att minska antalet manuella steg i byggandet och distributionen. Detta gjorde det möjligt för oss att få mer tillförlitliga testmiljöer med betydligt kortare testtider, vilket innebar att vi kunde leverera snabbare med färre fel.
Utvecklingspraxis: Vi ändrade våra utvecklingsrutiner för att förbättra kommunikationen uppåt och över hela organisationen. Detta hjälpte oss att minska antalet omarbetningar på grund av missförstånd. Vi gjorde också användarberättelser mindre och enklare, vilket minskade komplexiteten och därmed gjorde det lättare att leverera ofta. Vi implementerade en balanserad strategi för testautomatisering, vilket gjorde att vår regressionssvit kunde förbli snabb och stabil.
Kultur: Slutligen förändrade vi vår kultur på samma sätt som vi förändrade allt annat - snabbt, men stegvis, så att förändringarna blev hållbara. Vi uppmuntrade sunda beteenden som främjade testning och samarbete mellan grupper. Vi skapade en Test Tribe, en grupp testentusiaster, vars inflytande spreds över hela organisationen och bidrog till att befästa vår nya kultur: en kultur som byggde på samarbete, kommunikation och kvalitet.
Alla dessa ansträngningar resulterade i ett system som var utformat för att leverera snabbt, med kvalitet inbyggd i varje steg i processen.
![En global plan för hantering av samarbetsarbete [Video]](https://blog.planview.com/wp-content/uploads/2019/07/A-Global-Collaborative-Work-management-blueprint.png)
