Smidigere

This post is a Norwegian language summary of a talk I did April 14th, 2008

Jobber du smidig? Jeg jobber ikke smidig. Men jeg jobber smidigere enn jeg gjorde for tre måneder siden og enda mer smidig enn jeg jobbet for et år siden. Og om et år kommer jeg til å jobbe enda smidigere.

Men Smidige metoder handler ikke om et mål, de handler om konstant forbedring gjennom bedre og hyppigere feedback.

Samlingen med metoder som kalles Agile er forent om et manifest. Vi har oversatt det smidige manifest til norsk, men jeg foretrekker en mer uformell versjon: “Vi er ikke helt dumme heller, så vi skjønner at vi er plassert her på jorden for å skape verdi, ikke bruke papir, at en idiot med et verktøy (eller en prosess) er fortsatt en idiot, at kontrakter kan fordele skyld når ting går galt, men aldri forhindre at ting går galt, og at ingen plan overlever kontakt med fienden”. Men å jobbe smidigere handler ikke om å følge et buzzword, om å sammenligne vår Scrum-implementasjon med Jeff Sutherlands Scrum-implementasjon. Faktisk liker jeg ikke å snakke om Smidig så godt i det hele tatt. I stedet vil jeg snakke om hyppigere og bedre feedback.

Hvorfor feedback?

Hva er ikke hyppig og god feedback? Å utvikle et prosjekt over to år og så sette det hele i drift gir god feedback (men ofte negativ), men ikke hyppig. Å lese gjennom en kravspesifikasjon med rød penn gir rask feedback, men den er svært begrenset i hvor godt den sikrer prosjektet. For å reduserer risikoen er både god og hyppig feedback nødvendig. Vi trenger feedback for være sikre på å oppdage en rekke risikoer: Har vi misforstått kravene? Har vi tilstrekkelig framdrift til å nå målet? Hvor mye uforutsett arbeid lurer bak hjørnet? Og hyppig tilbakemelding er essensielt for menneskelig lykke, også. Studier innen positiv psykologi viser (veldig overforenklet) at det som gjør oss lykkelige er Lystbetont fremdrift mot et meningsfullt mål. Dersom målet er for stort og vi ikke får interessante resultater under veis, undergraver det vår lykke og derved vår motivasjon. Vi vet også at det er enorm overproduksjon i IT-prosjekter. Prosjekter leverer masse funksjonalitet som aldri brukes. Standish group anslår andelen med funksjonalitet som benyttes ofte til bare 20 %. Ved å levere inkrementelt kan vi angripe denne overproduksjonen. Og det er nettopp leveranser i hver iterasjon til et produksjonsaktig miljø og demonstrasjon av funksjonaliteten til forretningssiden som har snudd vårt prosjekt i riktig retning.

Hva kommer i veien for feedback

Vi har måttet kjempe mot mange hinder for å forbedre vår feedback. Her er noen av de viktigste:

  • Teknologi: Typiske applikasjonsservere og EAI verktøy gjør produksjonssetting til en veldig tidkrevende og kompleks prosess. De undergraver forståelsen av løsningen, og vi har gjentatte ganger sett at det eneste vi angrer på når vi kaster dem ut er at vi ikke gjorde det før.
  • Arkitektur: Jo flere distribuerte deler løsningen er splittet opp i, desto vanskeligere er installasjon og test. Spesielt problematisk er det at mange SOA-forkjempere ser ut til å like slike distribuerte løsninger. Vi hadde lite distribusjon, og har fått enda mindre med tiden.
  • Profesjonsfokus i organisasjonen: Mange organisasjoner har konflikter mellom test-avdelinger, drifts-avdelinger, forvaltnings-avdelinger eller andre. Vi har gått mer og mer mot en tjenesteorientert organisering i stedet for en profesjonsorganisert organisering. Dette reduserer koordineringsbehovet og øker leveransedyktigheten.
  • “Smidig i midten”: Mange ser ut til å tro at poenget med smidige metoder er å plassere dem i mellom en stor kravfase og en stor testfase. Dette fjerner feedback de stedene der den er mest nyttig!
  • Kravhåndtering: Jeg skal ikke si så mye om dette, men i stedet referere til min artikkel om kravhåndtering

Kravhåndteringen kan være et undergravende element for mange prosjekter. En fixed-scope (fastsatt omfang?) ramme for prosjektet oppfordrer kunden til å plassere så mange krav som mulig inn i prosjektet. Dette kan umulig hjelpe på problemet med overproduksjon! Niklas Bjørnerstedt snakker om “Minimal Deployable Entity”. Den skal være dårligere enn det du har i dag, så lenge du kan leve med den. All erfaring viser at det er smerter i organisasjoner som setter i drift ny programvare uansett hva man gjør. Å la kunden være litt sulten på mer er et prinsipp som Japanerne gjerne kaller Hara Hachi Bu: Spis bare til du er 80 % mett. Og så stopper du.

Hvordan få ekte feedback

Nøkkelen for å angripe problemene rundt feedback er å fokusere på bare én ting: Hver iterasjon skal driftsette kode i et så produksjonsnært miljø som mulig, og hver iterasjon skal demonstrere funksjonalitet for kunden. Vi gjør dette i iterasjoner på 2 uker. Dersom du trenger fire uker for å ha noe å vise fram, for å få med deg kunden og driftsette: Bruk fire uker. Dersom du trenger seks, bruk seks. Dersom du trenger åtte… så ville jeg vurdere å kansellere prosjektet. Vi har lagt inn mye innsats på å ha smidigere iterasjoner: Ved å strømlinjeforme installasjonsprosessen, kan vi installere hyppigere. Ved å automatisere og forbedre testaktivitetene kan vi bli tryggere på at det vi leverer er av bra kvalitet. Ved å bryte ned organisasjonsmessige akvarier mellom enheter som er involvert i en produksjonssetting kan vi få hyppigere produksjonssetting. Grunntanken er å observere de tingene som gjør iterasjonene tyngre ved å gjøre det vanskeligere å driftsette og demonstrere systemet. Disse tingene må du endre!

En ny måte å tenke på?

Når jeg skulle angripe installasjonsprosessen vår startet jeg med å dokumentere alt som skulle til for å installere systemet fra bunnen. Det ble cirka seks sider. Så gikk jeg gjennom og streket under alt som var unødvendig med en rød penn. Så fikset jeg scripts, kode og verktøy. Nå er beskrivelsen på én side, og vi kan med én enkel kommando installere databaseskjema og programvare for et system fra bunnen. Vi kan til og med angi til kommandoen at det skal kjøre forhåndslagret testdata over det ferdige installerte systemet. Dette gjøres automatisk hver time. Hvordan angriper vi så dokumentasjon? I stedet for å dokumentere det gi gjør, bør vi bli flinkere til å redusere kompleksiteten. I stedet for å bli bedre teknologer, bør vi velge enklere teknologi. I stedet for å bli flinkere til å koordinere, bør vi samle de menneskene som må jobbe sammen i ett team. Og min kjepphest: I stedet for å bli flinkere til å gjøre ting riktig første gang, bør vi bli flinkere til å lære av våre feil på en trygg måte.

The road to wisdom? – Well, it’s plain and simple to express: Err and err and err again but less and less and less. – Piet Hein

Comments:

Steingrim - Apr 14, 2008

Jeg er veldig enig i mye av det du skriver, selv om jeg ikke nødvendigvis får muligheten til å gjennomføre det i det daglige :)

“I stedet for å dokumentere det vi gjør, bør vi bli flinkere til å redusere kompleksiteten”

Dette burde nesten være en programmerers mantra. Kompleksitet reduseres ved å følge konvensjoner, følge konvensjoner, benytte kraftige rammeverk som lar oss uttrykke mer med mindre kode og ved å ikke ta lure snarveier. “Clever code” er ikke like gøy tre år etterpå. Nevnte jeg følge konvensjoner?

petter - Sep 18, 2008

Mmmm.. Siden jeg ikke har kommet meg på JavaZone får jeg kose meg med slike blogposter.

Vakkert :)