Ersätt krav med hypotestestning

Krav beskriver en egenskap eller funktion som en användare behöver för att åstadkomma något specifikt och är ett vanligt sätt att beskriva företagets och projektets mål. Det är ett angreppssätt som kan verka logiskt eftersom man på förhand försöker beskriva vad som ska uppnås. För vem kan arbeta mot något som är okänt? I den här artikeln ska jag redogöra för ett konkurrerande (bättre) angreppssätt där man faktiskt erkänner att de flesta mål, dvs krav, är okända. Metoden kallas för hypotestestning och har sin grund i forskningsvärlden.

En hypotes är är något vi tror (och hoppas) ska stämma, men som vi ännu inte har bevisat är sant.

"Vi tror att att kunder kommer att registrera sig på vår nya spelsajt om vi erbjuder nya spelare 100 kr att spela för"

En hypotes måste också vara testbar:

“Vi vet att vårt antagande är korrekt när tusen nya spelare har registrerat sig inom en vecka”

Hypotestestning handlar i huvudsak om två saker; att ställa de frågor som man är intresserad av att få bekräftade och att hitta på sätt att bekräfta dem. En fördel med att använda hypotestestning i stället för krav är att man “tvingar” hela teamet till samarbete och kollaboration. När man ger ett team ett problem att lösa, till skillnad från en redan uttänkt lösning i vilken man har låst fast sig i, så engageras teamets kreativa sida.

Att specificera krav är egentligen att formulera hypoteser men där man på förhand betraktar dem som sanna utan bevisföring. I de projekt där man är helt säker på vad man håller på med, vilket problem som ska lösas och hur det ska lösas, fungerar krav bra. Men i hur många projekt som du har jobbat i har man varit helt säker på vad man håller på med?

De flesta mjuvaruprojekt lever under extrem ovisshet, dvs man är inte bara osäker på lösningen utan man är lika osäker på vilket problem som ska lösas. I den typen av projekt är hypoteser bättre än krav. 

Hypoteser är svar formulerade som frågor och är per definition testbara. Genom att söka svar på frågor lär man sig sådant man annars inte skulle ha vetskap om. Låt oss definiera en enkel process för hypotestestning:

  1. Identifiera dina antaganden
  2. Formulera antagandena som hypoteser
  3. Prioritera de antaganden som bär störst risk utifrån en affärssynvinkel
  4. Bryt ner hypoteserna i testbara delar
  5. Bygg den minsta möjliga mjukvara som kan testa och bekräfta hypotesen
  6. Är den bekräftad, gå vidare med nästa hypotes. Om inte, justera antagandet, hypotesen och upprepa eller inse att det var en dålig idé från början.

 Framsteg ska inte mätas utifrån om mjukvaran fungerar eller ej, utan vad man har lärt sig om vad dess användare vill ha. Till syvende och sist kommer marknaden att återkoppla och avgöra dess öde. Den enda frågan är hur lång tid det kommer att ta innan återkopplingen sker och hur mycket pengar som har spenderats innan det sker.

En förutsättning för hypotestestning är att man jobbar med frekvent och kontinuerlig produktionssättning, vad vi vanligen kallar för Continuous Delivery. Med en releasestrategi som hela tiden pumpar ut nya förändrade och förbättrade versioner kan man på ett strukturerat sätt "zooma in" på problem och lösning på samma gång.

Mats Wessberg
mats.wessberg@metrical.se