Människovänliga specifikationer är nyckeln till bättre mjukvara

Kära företagsledare,

Är du trött på att höra ursäkter från IT- eller FoU-avdelningen, som ”något kom emellan” och ”det här var oväntat”, den dag du förväntade dig att få se ett IT-system eller en tjänst för slutanvändare?

Vad hände? Ropar leveransorganisationen åt dig att dina krav inte var tillräckliga, trots att du involverade slutkunden i planeringsfasen?

Tänk om du kunde hitta grundorsaken till alla dessa problem?

Vi vill alla skapa värdefull mjukvara för människor i en värld präglad av felbenägna processer, expertbias och organisatoriska utmaningar. Min kollega Tatu har skrivit en mycket bra introduktion till ATDD och TDD som beskriver vad det är och hur det hjälper en organisation att ”shift left”.

Låt oss gå djupare in på problemen med att planera för sent och att inte koppla dina affärskrav (specifikationer) till Definition of Done.

Definition of Done är drivkraften i Agile

Även med Agile-metoder kan det vara mycket svårt att fokusera på verkligt kundvärde.

När mjukvaruorganisationer (verksamhet och IT/FoU) påbörjar sin agila transformation och börjar arbeta verkligt agilt uppstår ofta ett problem: begreppet Definition of Done (DoD) är otydligt när det gäller slutanvändarens krav. Med andra ord: Hur säkerställer du att du gör rätt saker ur ett kravperspektiv?

En DoD av låg kvalitet kan vara ett symptom på många problem. Oftast innebär det att du saknar ett bra sätt att precisera dina acceptanskriterier för slutanvändaren.

Jag skulle säga att om dina UX-designers, utvecklare, driftteam och testare börjar diskutera om funktionerna är korrekta under demomötet, har du mycket onödig kod och teknisk skuld i din mjukvaruutvecklingsprocess. Denna skuld kallas ofta för ”slöseri” i mjukvaruprojekt.

Ett demomöte bör användas som ett granskningssteg för att kontrollera DoD för era arbetsuppgifter. Det ger dig också möjlighet att visa leveransen för slutanvändare och få återkoppling inför kommande sprintar.

Planering är död, men ändå inte

Som utvecklare och testautomatiseringsingenjör har jag upplevt agila transformationer den hårda vägen. När de agila evangelisterna har ”lämnat byggnaden” och sagt att det inte finns någon ”teknisk och specifikationsorienterad förplanering” (vi har alla hört det förut ...) lämnas du ganska hjälplös. Hur fokuserar du dina dagliga aktiviteter och kommunicerar tydligt vad som behöver göras ur ett verksamhetsperspektiv för att få funktioner och epics redo för demo?

Och kom ihåg: En User Story är inte en specifikation!

Problemen blir ännu tydligare när du försöker få ut själva releasen. Kommunikationen börjar kretsa kring end-to-end-användningsfall när du borde slutföra releasen, och vid den tidpunkten är sådana överväganden oftast för sena.

Kommunikationen är förstås enklare när färre än tjugo personer arbetar med din tjänst eller produkt för slutanvändare, inklusive alla intressenter. Men om ni är fler kan jag säga att fler inte betyder bättre.

Utan en tydlig vision (DoD för slutanvändaren) för din agila metod (Scrum eller kanban) saknar du det fokus som behövs i utvecklingen. Dessutom saknar dina team en tydlig riktning.

Röran som uppstår när det saknas ett tydligt mål för hela systemet

Om det här känns igen finns det sannolikt utrymme att förbättra hur du planerar. Otillräckliga specifikationer och avsaknaden av rätt verktyg för att verifiera dem på ett agilt sätt – alltså ingen testautomatisering på verksamhets- eller slutanvändarnivå – hindrar dig, trots att de inte längre borde göra det.

Låt mig understryka poängen. Om din planering är rörig låter du människor göra antaganden, och det är minst sagt riskabelt. Tekniska problem är vanligtvis inte problemet – det är affärskraven och testningen av dem.

Ett tydligt tecken på att du arbetar med ”mini-waterfall” eller ”Scrum, But” är att implementation och testning sker i olika sprintar, utan tydliga funktionella specifikationer utöver punktlistor i ett Word-dokument.

Ingen vill ha det slöseri och den tekniska skuld som detta orsakar. Du kan driva projektet på det här sättet under en viss tid, men ytterligare förändringar ovanpå det kommer till slut att skapa ett system som varken går att använda eller arbeta med.

Eftersom DevOps gärna eliminerar slöseri

Ett tema som återkommer gång på gång i litteraturen om DevOps är att eliminera slöseri. Att göra helt fel sak är den största källan till slöseri och ligger inte i någons intresse!

Vid bristfällig planering behöver du alltså metoder och verktyg för att validera värdet för slutanvändaren och göra testerna av detta värde så snabba som möjligt.

Specification by example med Gherkin och Robot Framework

Om mjukvaruingenjörer inte lägger tillräckligt med arbete på specifikationer blir slutresultatet enorma mängder bortslösad tid och pengar.

Du behöver specifikationer, även i den agila världen! Men här kommer det viktiga: du måste skapa dem så att en människa kan förstå dem. Att översätta tekniska specifikationer för slutanvändare och samarbeta med dem är kärnan i Agile-metoder. Särskilt i stora och komplexa organisationer, där inte alla är mjukvaruingenjörer.

Med Specification by Example (SBE) kan du få en tydlig förståelse för problemet och en lösning på det.

1. Kombinera SBE och Design Thinking för att utforska och välja en bra lösning på det verifierade affärsproblemet.

2. Resultatet blir dokumenterat beteende för slutanvändare (börja med ett par ”solskensfall”) i Gherkin-syntaxformatet (Given, When, Then).

3. Efter workshops kring dessa användningsfall i Gherkin-format har du ett tydligt användarflöde att implementera och testa.

Sedan kommer styrkan och elegansen hos ett nyckelordsdrivet testramverk, som Robot Framework. Du kan faktiskt implementera automatiseringen bakom dessa steg, vilket ger dig ett E2E-testfall för hela systemet som, lyckligtvis, också är din specifikation för affärskrav!

Nu använder du Acceptance Test Driven Development (bild 2)! Det gynnar inte bara test- och QA-personal – hela projektet har nu ett tydligt mål att arbeta mot.

Gemensam förståelse skapar effektivitet och fokus i utvecklingsflödet.

En tydlig Definition of Done skapar fokus

Enligt min erfarenhet kan sprintplaneringen och genomförandet knappast flyta smidigare när du hanterar dina funktionella och tekniska specifikationer på det här sättet!

Särskilt under sprinten blir det äntligen möjligt att uppnå det lugn och fokus som krävs för att nå en DoD före demon/reviewen. För att göra det här arbetsflödet möjligt för ditt team krävs stor disciplin från alla intressenter (ja, särskilt från Business Owner och Product Owners). Alla berörda behöver utbildning. Särskilt i början bör intressenterna hålla de första workshopparna ansikte mot ansikte.

Som alltid finns vi här för att hjälpa till. Hör av dig om du behöver hjälp att minska slöseri.