Att skriva kod för mjukvarulösningar innebär att lösa många små problem, och de små lösningarna aggregeras sedan för att skapa en lösning på större problem. När väl alla kodrader fungerar tillsammans kan en utvecklare ibland sakta backa och hoppas att ingenting ska rubba balansen som för närvarande gör att mjukvarulösningen fungerar. Problemen uppstår dock direkt när kraven på mjukvaran förändras, och vi måste dyka ner i tusentals rader kod och förstå vad som behöver ändras och hur förändringen inte ska ha sönder något som vi redan har byggt. Detta är observationen som ledde till att Extreme Programming-rörelsen redan på 1990-talet betonade vikten av att hålla kostnaden för en ytterligare förändring av systemet konstant, istället för att öka med antalet funktioner i systemet.

Det har visat sig att vissa beteenden håller nere kostnaden för att vidareutveckla system och de är relativt allmänt tillämpbara som ingenjörsprinciper inom produktutveckling. Det handlar om att använda sig av ett vetenskapligt tänkande genom att börja med att ställa upp sina förväntningar på vad till exempel en liten bit kod ska göra. Vi konstruerar ett test som kan utvärdera om koden är korrekt, redan innan vi ens har skrivit koden. Sedan kan vi experimentera med lösningar och direkt ta reda på om lösningen faktiskt uppfyller våra förväntningar som vi ställde upp i testet.

Det kallas ibland för att ”skifta vänster” eftersom potentiella problem och felaktiga antaganden upptäcks tidigare på tidslinjen, längre till vänster på tidslinjen.

Detta är ett sätt att tänka som sträcker sig utanför att utveckla mjukvara. Till exempel konstruerade biltillverkaren Tesla en robot som kunde utvärdera om en stol är bra, redan innan de ens börjat designa stolen. När de väl hade ett snabbt och effektivt sätt att veta om sätet uppfyllde alla krav såsom mjukhet, hantering av lukter, fläckar etc., kunde de iterera på en bra sätesdesign mycket snabbare. Idag anses de ha en av världens bekvämaste stolar att sitta i länge.

Eftersom utmaningen ligger i frågan, hur vet jag att min lösning fortfarande uppfyller alla krav jag har på den när jag gör en förändring av lösningen? Då behövs ett billigt sätt att ta reda på att allt fortfarande fungerar. Detta innebär nästan alltid ett automatiserat flöde för att testa både lågnivåantaganden, att varje liten komponent gör vad den ska och att produktens delar och helhet fungerar som de ska. Att bygga den förmågan kostar initialt, och sedan lite över tiden, men är det enda sättet att undvika att kostnaden för förändringar ökar exponentiellt och därmed gör produkten nästan omöjlig att förändra.

Inom mjukvara bygger vi så kallade continuous delivery pipelines som i praktiken är datorer som kör script för att försöka bygga mjukvara och köra tester på den nya versionen för att se att den fortfarande fungerar. Det kräver naturligtvis att alla utvecklare skriver tester innan de skriver kod, precis som vi pratade om ovan. Annars har pipelinen inget att testa. Det kräver därför att vi kommer överens om hur vi gör saker i våra arbetslag, att vi ställer varandra till svars genom att till exempel titta på varandras förslag till förändringar till koden innan det tillåts gå vidare i processen. Se till att det följer den standard vi sätter tillsammans, att det finns tester etc. Att skapa system av hög kvalitet, vare sig de består av mjukvara, hårdvara eller en kombination, kräver disciplin och vi måste hjälpa varandra att upprätthålla den disciplinen. Det kan inte läggas till utifrån eller efteråt, kvalitet behöver byggas in av de som bygger, när de bygger. Tänk att du skulle vilja ta upp en ny dörr i en vägg hemma och anlitar en hantverkare. Det är föga tröst för dig om en besiktningsman i efterhand konstaterar att väggen skurits på fel ställe eftersom hantverkaren inte använt linjal innan arbetet påbörjades.

Vad betyder detta för olika domäner? I SAFe finns nu en uppdaterad Built-In Quality artikel som beskriver hur vi kan använda dessa kvalitetshöjande tekniker inom olika områden. Samma grund gäller fortfarande, varje domän har sina mer tillämpade pusselbitar som ger en input till det fortsatta arbetet.

Detta tankesätt är djupt och kan kräva att vi ifrågasätter långvariga antaganden om ”hur vi gör saker här.” En viktig kontrollfråga kan vara: ”om vi kunde göra en värdefull förändring i vår produktion inom några timmar, vilka krav skulle det ställa på våra arbetssätt samtidigt som vi bibehåller god kvalitet för våra kunder?”

Fredrik Viljesjö