If you always write perfect code, know how to predict the future and don’t care how your money is spent, you don’t need to read this. The rest of you need to know this stuff.
A feedback loop is the path your assumptions travel before they are validated or invalidated. Naturally you will have different feedback loops for different assumptions. In this post we will discuss three levels of feedback loops that should be easily recognizable. They are:
Continue reading
Du er inne i et prosjekt som har gått et par tre måneder. Det finnes ikke noe i produksjon, men backloggen er lang som et vondt år og består av noen hundre user stories som ble estimert en gang i begynnelsen. Første release nærmer seg med friske stormskritt, ingen vet egentlig hvor mye som er ferdig og hvor mye som gjenstår.
Flickr creative commons: jwright4701
Høres dette kjent ut? Da kan det hende at ditt prosjekt snart skal utnevne svarteper. Denne personen skal vade gjennom krav og user stories og rydde opp i backloggen. Prosjekter bygger nemlig ikke bare opp teknisk gjeld. Funksjonell gjeld eller rot i funksjonelle krav, kan være minst like hemmende.
Så hvem er svarteper? Det er stakkaren som blir utnevnt til funksjonellt ansvarlig, og som kommer til å kjempe de neste ukene eller månedene bare for å få hodet over vannet.
Åpent spørsmål til slutt, hvorfor tar det ofte så lang tid, gjerne helt til prosjektet er i krise, at man innser at noen må ha overordnet funksjonell oversikt? Og at dette er en veldig viktig oppgave som noen må jobbe med på fulltid helt fra starten av.
De fleste IT-satsinger som feiler, gjør dette på grunn av sviktende forutsetninger. Det være seg alt fra intrikate tekniske problemer til manglende resonnans i markedet og dermed utilstrekkelige inntekter, som ikke rettferdiggjør investeringen.
De som investerer i IT-utvikling baserer sin beslutning på en rekke årsaker, som enten er riktige eller gale. Selvfølgelig prøver de innen rimelighetens grenser å være sikre på at årsakene holder vann. Business caser, markedsundersøkelser og andre analyser er ofte brukt til dette formålet.
For sent
Det sier seg selv at en feilsatsing aldri ville sett dagens lys dersom de sviktende forutsetninger var kjent på forhånd. Dessverre oppdager vi som jobber med utvikling alt for ofte de sviktende forutsetninger alt for sent. Dette skjer alltid i store prosjekter med få store leveranser. Noen sier at dette er en del av hverdagen. Du vinner noen, og taper noen andre. That’s life.
Jeg synes en slik holdning er passiv. Riktignok er vi nødt til å gjøre antagelser for å være produktive, men vi må jobbe systematisk for å validere dem – så fort som mulig.
Det er alltid en sunn øvelse for alle som jobber med utvikling å se på arbeidet som blir gjort med en investor sine øyne. Ville vi jobbet slik vi gjør idag, dersom vi hadde investert vår egen årslønn? Hva ville vi gjort i et slikt scenario?
Vi ville validert våre antagelser tidligst mulig.
Et verktøy for å eliminere spekulasjon
Validering av antagelser starter med å skille fakta fra spekulasjon. I den påfølgende prioriteringen spør vi hvilke antagelser som er viktigst. Sagt med andre ord: Hvilken antagelse ville få størst negative konsekvenser for utviklingen dersom den var ugyldig?
Vi bruker iterasjoner til å utvikle små inkrementer av programvaren, i den hensikt å konvertere antagelser til fakta. Deretter setter vi fragmentene i produksjon slik at de blir tatt i bruk av reelle brukere. Ingen kan argumentere mot hvor mange nye bruker som registrerte seg forrige uke, eller hvor ofte en ny funksjon blir brukt etter lansering.
Iterativ utvikling gjør at vi fortløpende tilpasser oss de fakta vi skaper. Dermed blir både vi og investeringen en del av virkeligheten.
Hvordan ville du investert?
The Iterate Blog 