Den Smidige myte?
This is a Norwegian language copy of an article I published with Niklas Bjørnerstedt in the Norwegian computing magazine ComputerWorld
Studier som utgir seg for å være vitenskapelig utført viser seg stadig å ikke tåle nærmere granskning. Kommersielle tenkesmier tar mange snarveier i kampen om å få frem oppsiktsvekkende resultater. Forskeren Magne Jørgensen har gjennom årene bidratt til å “avsløre†flere tvilsomme studier og dermed bidratt til å heve den vitenskapelige standarden innenfor systemutvikling. Vi synes dette er en hederverdig innsats som vi har lært mye av. Vi synes dog at Magne har blitt overivrig i det siste. I både artikler og foredrag virker han å fremfekte et syn som stiller spørsmålstegn ved all erfaring som ikke er vitenskapelig bevist. Det siste eksemplet på dette synet sto å lese i CW den 24. mars. Når artikkelen bruker denne skepsisen til å koble smidig utvikling med ord som “mote†og “tro†så føler vi at forskeren er i ferd med å kaste ut barnet med badevannet.
Kan det noen gang bevises at smidig utvikling er effektivere enn “tradisjonell utviklingâ€? Problemstillingen er sannsynligvis for åpen. Det finnes mange måter man kan definere “effektiv†på, en uendelig antall måter å være smidig på og enda flere måter å utvikle på som ikke er smidige. Vitenskapelige studier må redusere en problemstilling til noe som lar seg måle. For eksempel: Gir parprogrammering færre defekter enn individuell programmering? Faren med å redusere problemstillinger på denne måten er at det som gjenstår kan bli et meningsløst spørsmål uten kontekst. Et studie har for eksempel nylig vist at en naken mann (eller kvinne) ikke mister mer varme gjennom hodet enn resten av kroppen. Men dette er ikke relevant til hvor vidt vi bør ta på oss lue om vinteren: I det virkelige livet er det få som velger å gå ut nakne på vinteren, men mange som går barhodet. I sitt foredrag på Software 2009 hevdet Magne tilsvarende at Fred Brooks berømte påstand “Adding manpower to a late software project makes it later†ikke er verdt mye da det er en overforenkling (Brooks skal selv ha innrømmet at det er en “outrageous oversimplificationâ€). De fleste prosjektledere vil derimot si at dette er et godt eksempel på en erfaringsbasert regel. Selvfølgelig er den ikke sann i alle tilfeller, men man bør ha gode grunner for å bryte den.
Som et komplement til vitenskapelige studier er det jo vanlig å bruke erfaringsbaserte slutninger. Disse erfaringene kan være falske, vi mennesker er mestere på å lure oss selv, men det må likevel være bedre å basere seg på en erfaring enn å bare gjette. Hvis det så kommer vitenskapelige studier som tilsier at erfaringen er falsk så er det et grunnlag for å endre adferd. Det er viktig å samle erfaring på en måte som er tilnærmet vitenskapelig for å unngå noen av de fallgruvene Magne gir eksempler på i sine innlegg.
Systematisk bruk av erfaringer er også fundamentet for smidige metoder. Etter en kort iterasjon revurderer teamet resultatet og sin arbeidsform. Målet er nettopp å basere seg på erfaring og empiri framfor blind tro. Slik vil et smidig team bruke iterasjonene på å hente inn mer informasjon om teknikkene de bruker, måten de jobber på og hvor vidt arbeidet deres tilfredsstiller kundens behov.
Smidige metoder er heller ikke en moteting, slik Magne ser ut til å hevde. Smidig utvikling har en lang tradisjon. Det oppsto ikke med det smidige manifestet i 2001. Tankeretningen vokste ut fra det samme miljøet som ble kalt objektorientert på 90-tallet. Dette er et miljø med sterke bånd til akademia tilbake fra Smalltalk og Simula67 før dette. I tillegg har man lånt fra Toyota Production System sin erfaring innen prosessindustrien. En tradisjon som bygger på det W. Edwards Deming kalte Plan-Do-Check-Act - en tilpasning av den vitenskapelige metode til industrien.
Smidig utvikling er et rammeverk for å lære fra erfaring. På samme måte som man kan bruke vitenskapens verktøy bra eller dårlig, kan man bruke smidig utvikling bra eller dårlig. Det vil aldri finnes metoder som garanterer at vi lykkes. I stedet ønsker vi metoder som hjelper oss å oppdage når vi ikke gjør det.
Niklas Bjørnerstedt, Leanway Johannes Brodwall, Steria
Publisert i Computerworld 22. mai 2009 (kun i papirutgaven)
Comments:
[Magne Jørgensen] - May 27, 2009
Hei!
Det interessante for min del er at artikkelen min handler om at vår tolkning påvirkes av hva vi tror på, IKKE om simidige metoder. Smidige metoder er kun valgt av eksperimenthensyn. Tror ikke jeg sier noe som helst negativt eller positivt om smidige metoder i hele artikkelen (men har ikke sjekket). Hadde jeg brukt det meste annet enn smidige metoder i eksperimentmaterialet, hadde vel ingen reagert ;-).
Når det gjelder problemer rundt studiemetodikk og bruk av erfaringsbasert kunnskap, så underviser jeg i det i flere sammenhenger - og er en stor tilhenger av det. Tror ikke vi er uenige her.
Tror forøvrig ikke at jeg formulerte at Brook’s lov ikke er verdt mye, kun at den msibrukes/misforstås en del og er en grov overforenkling/ikke en lov (men her er det vel vanskelig å bevise/motbevise noe), ref. “I sitt foredrag på Software 2009 hevdet Magne tilsvarende at Fred Brooks berømte påstand “Adding manpower to a late software project makes it later†ikke er verdt mye da det er en overforenkling (Brooks skal selv ha innrømmet at det er en “outrageous oversimplificationâ€).”
mvh Magne
jhannes - May 28, 2009
Hei, Magne
Synd at vi misforsto poenget ditt. Vi har jo tidligere diskutert hvor vidt det kan besvares om “gyldigheten av” smidige metoder er eller kan holde vann vitenskaplig, så dette farget hvordan jeg leste artikkelen din.
Jeg husker ikke nøyaktig detaljene fra foredraget ditt på Software 2009, men jeg oppfattet at du der rettet kritikken mer direkte mot påstander om smidige metoder. Finnes slidene dine fra dette foredraget tilgjengelig noe sted?
Johannes Brodwall - May 28, 2009
Hei, Magne
Synd at vi misforsto poenget ditt. Vi har jo tidligere diskutert hvor vidt det kan besvares om “gyldigheten av” smidige metoder er eller kan holde vann vitenskaplig, så dette farget hvordan jeg leste artikkelen din.
Jeg husker ikke nøyaktig detaljene fra foredraget ditt på Software 2009, men jeg oppfattet at du der rettet kritikken mer direkte mot påstander om smidige metoder. Finnes slidene dine fra dette foredraget tilgjengelig noe sted?