luxshan ratnaravi bloghoved

Hypoteser - et middel til at udvikle det rigtige

Ved at tage en hypotesebaseret tilgang til softwareudvikling tvinges man til at måle, om nye features skaber værdi, og dermed til først at acceptere en feature som værende "done", når den faktisk bliver benyttet af brugerne.

Når et udviklingsteam arbejder med user stories for at (videre)udvikle et it-produkt, er det rimeligt klart, hvilken værdi den pågældende user story vil skabe for brugerrollen. Værdiskabelsen er nemlig en iboende del af user story'ens anatomi i form af 'so that'-delen, som gør, at den pågældende feature kan sættes i kontekst i applikationen, så bl.a. udvikleren kan sætte sig i brugerens sted. Dog er det langt fra sikkert, at der rent faktisk bliver skabt værdi, blot fordi user story'en er implementeret og lever op til Scrum-teamets aftalte 'Definition of Done' (DoD), og user story'ens acceptkriterier.

Kvalitet eller behov?

Traditionelt kan en DoD bestå af punkter som fx "UAT bestået", "peer-review foretaget" og "dokumentation udarbejdet". Disse sikrer bl.a., at featuren opnår en hvis kvalitet, inden den gøres tilgængelig for brugeren (lad os her ikke tænke i 'releases', men i stedet i Continuous Design/Deployment/Integration/Delivery) . Dog siger kvaliteten af en given feature ikke noget om behovet for den og dermed dens relevans og eksistensberettigelse i produktet.

Hvis en ny feature, der fx viser en tidslinje over brugerens vigtigste, historiske handlinger et år tilbage, lever op til teamets DoD og de af Product Owner'en (PO'en) definerede acceptkriterier, betyder det givetvis, at featuren er gennemtestet, veldokumenteret, effektivt kodet og opfører sig, som brugerne forventer. Men det siger intet om, om featuren rent faktisk er noget, brugeren har brug for.

Når man nu ikke kan forudsige fremtiden...

Den intelligente læser vil nu indskyde, at det jo er PO'ens ansvar at sikre, at alt, hvad udviklingsteamet laver, er værdiskabende for brugeren - og dermed det 'rigtige'. Og det er også korrekt - i hvert fald for brugernes udtrykte behov og pain points. Men når det kommer til brugernes tavse behov, samt forudsigelse af fremtidige pains, er PO'en desværre ikke klogere end de informationer, han har fået ud af kravstillerne, konkurrentanalyserne og brainstormsessionerne.

Medmindre PO'en kan læse tarotkort eller har en krystalkugle, bliver man nødt til at prøve sig frem med kvalificerede bud på, hvad brugernes fremtidige behov vil være. Dette kræver først og fremmest en kulturændring, hvor ledelsen, udviklerne og ikke mindst brugerne forstår vigtigheden af og fordelene ved at tage en hypotesebaseret tilgang til software-/produktudvikling.

Hypoteser

Som Barry O'Reilly skriver om emnet, er der, specielt i komplekse, uforudsigelige og foranderlige produktmarkeder, store gevinster at hente ved at lade hypoteser sætte retningen af kommende features. Lader man videnskabens hypotesebaserede tilgang til forståelse af virkeligheden gennem eksperimenter være måden, hvorpå man udvikler software, udnytter man muligheden for at være kreativ i problemløsningen - og efterfølgende måle, om brugerne bruger den foreslåede feature.

En oversættelse mellem skridtene i et traditionelt eksperiment og de tilsvarende i softwareudviklingen kunne være:

En oversættelse mellem videnskabens skridt og de tilsvarende i softwareudviklingen.

Succeskriterierne ind i DoD og acceptkriterierne

En måde at få denne hypotesedrevne tilgang til softwareudvikling manifesteret hos udviklingsteamet er simpelthen at udvide DoD'en med det krav, at features skal benyttes af brugerne, før de kan betegnes som værende endeligt 'done'. I acceptkriterierne for den specifikke user story kan man så udspecificere succeskriteriet, og dermed præcist hvor meget featuren skal benyttes over en given tidsperiode. Acceptkriteriet for førnævnte historiske overblik kunne fx lyde: "i løbet af en måned skal mindst 50 % af vores brugere have benyttet featuren gentagne gange".

Dette tvinger teamet til hele tiden at være obs på, om den nyligt implementerede feature rent faktisk gør nogen gavn - og hvis den ikke gør, skal den laves om, og hypotesen revurderes og gentestes. Dermed får man skabt et indirekte feedback-loop, så teamet hurtigt kan lave nye og eksisterende features om, hvis de ikke bliver brugt (nok).

Hvad kræver det?

For virkeligt at få gavn af en hypotesedrevet tilgang til softwareudvikling kræver det som nævnt en kultur, hvor det er okay at fejle - ikke kun internt, men også hos produktets brugere, der skal forstå idéen med at iterere sig til succes. Desuden bør brugen af features'ne ikke være det eneste feedback-loop, da direkte møder med brugerne, brainstorm-workshops, regelmæssig kommunikation om kommende features og tilfredshedsundersøgelser al sammen bør være faktorer, som sikrer, at produktet bliver en succes.

Ledelsen skal også forstå, at denne tilgang indledningsvist i værste fald kan være en dyr affære, da man potentielt kan starte med at ramme meget forbi med sine hypoteser. Dog kræver det 'at lave det rigtige' nogle indledende skridt, og det er mere en proces end en destination, men får man først tilgangen ind under huden på alle de rigtige interessenter, er det en oplagt måde at komme og holde sig foran konkurrenterne.

Hvad er dine erfaringer med hypotesedrevet udvikling?

Relateret indhold

Luxshan Ratnaravis billede

Kommentarer (2)

Kommentarer (2)
Rasmus Kristensen

Lige en lille prefix, jeg har mest arbejdet med at lave computerspil så mit syn er helt klart farvet af det :)

Jeg har været med til at forsøge denne tilgang på et spil projekt, men det vidste jeg at være rigtigt svært at måle korrekt og sætte kriterierne op så de faktisk lave et bedre produkt. Med dit eksempel af at være sikker på at en feature bliver benytte af mindst X brugere om måneden, er der mange dårlige måder at opnå det mål på, f.eks. ved at give folk 1$ for hver gang de bruger den, det er ikke sikkert det hjælper dine brugere eller din forretning men folk vil stadig gå ind og bruge den. Og selvom at man gør sit bedste for at ikke "snyde" folk ind, så er det også rigtigt svært at finde svar på hvorfor at folk gør noget bestemt, hvis man ikke har adgang til en stor forsøgs grupper man kan spørge direkte og tests det på.

Et sted hvor jeg har fundet denne tilgang lidt mere naturlig, er vil mange backend projekter, hvor der kan være nemmere metrics at gå efter, f.eks. ved skalering af et system, kan man sige X brugere samtidigt med denne bruger profil, og så bruge det til at lede udviklingen, men med det eksempel skal man også være sikker på at det er den rigtige bruger profil man måler på.

Jeg syntes dog det kan være hjælpsomt at sætte nogle mål op, man skal bare være meget forsigtigt at de faktisk flytter en i den retning man vil, da der altid er mange måder at tolke dataene på, folk har en tildens til at se det de gerne vil se.

Log ind eller opret en konto for at skrive kommentarer