Thinking inside a bigger box - Latest Comments in Forskning på smidige prosjekter

Re: Forskning på smidige prosjekter

Johannes Brodwall — Mon, 26 May 2008 16:17:07 -0000

Hei, Magne

Ettersom "vi smidige" ofte er veldig dypt nede i enkeltprosjekter er det definitivt en kjempefare for å overgeneralisere.

Det praktiske motstykket til det du sier er at vi observerer "dette ser ut til å fungere for oss, jeg vet ikke om det vil fungere for dere". Jeg bestreber meg veldig på å presisere på at jeg har veldig få datapunkter, men det er lett å la seg rive med.

Takk for en spennende diskusjon.

Re: Forskning på smidige prosjekter

Magne Jørgensen — Mon, 26 May 2008 16:07:42 -0000

De to kanskje viktigste argumentene for å bygge valg av metode på bedre evidens er:
1) At man i mindre grad tar utgangspunkt over-genereliserer fra sin egen erfaring og problemkontekst.
2) At man i mindre grad utsettes for teoriladet observasjon (at alt passer inn i ens egen modell av hvordan verden er skrudd sammen)

De fleste er enige i det, men vi går vel alle uunngåelig den fellen likevel. Noe jeg tror også "de smidige" gjør.

Så er det problemet om å finne ut når en metode er bedre - som i stor grad er uløst. Noe er iboende (f eks av vi ikke klarere å studiere vitenskapelig noe vi ikke klarere å definere tilstrekkelig presist), men noe tror jeg skyldes at mye av forskningen går fram på feil måte og at vi må innse at noe kunnskap er svært lokal - dvs at vi kan finne ut noe innen en avgjrenset kontekst (et firma), men i mye større grad bør avstå fra å generalisere. Så håpløst er det ikke - men vanskelig. Jeg tror f eks at det kan finnes lokale, meningsfulle, nyttige målinger av kvalitets og produktivitets-relaterte egenskaper ved programvare.

mvh Magne (litt stresset på tid, men dersom du ønsker å legge noe av diskusjonen vår/mine kommentarer inn på bloggen - gjerne en forkortet versjon, må du bare gjøre det)

Re: Forskning på smidige prosjekter

Johannes Brodwall — Mon, 26 May 2008 16:05:02 -0000

Hei, Magne

Jeg har merket selv at det er veldig lett å falle i felle med å forsøke å avvise kritikk ("deflect") i stedet for å svare på den. Jeg forsøker selv å ta meg i nakkeskinnet mer her.

Forstår jeg deg riktig når du sier at et studie for å finne ut av effekten av smidige metoder (eller feedback) burde hatt en dimensjon til? Slik at spørsmålet blir "innen hvilke problemtype er hvilken iterasjonslengde korrelert med vellykkede prosjekter?"

Jeg skjønner poenget ditt med begge spørsmålene som du spurte på Geilo til å være at noen problemer går det ikke an å ha meningsfull fremdrift innenfor en tidsperiode som er for kort. Er det riktig? For å bruke en utslitt metafor: Det er ikke meningsfullt å ha iterasjonslengde på under 9 måneder på leveranse av spedbarn.

Min erfaring er at de fleste oppgavene innen utvikling kan og bør stykkes opp i oppgaver på under et dagsverk. Når jeg ikke gjør det selv, produserer jeg dårligere resultater (og jeg finner alltid i etterkant at det var en måte jeg kunne stykket det opp bedre). Og det er en ganske stor gruppe med selv-erklærte "dyktige" utviklere som ikke klarer å stabilisere koden sin i løpet av en dag.

Kanskje et annet område som kunne være verdt å få bedre empiri på.

Som du påpeker er det motsetning mellom feedbackfrekvens og størrelse på chunks. Jeg tror den viktigste faktoren her ikke er problemtype, men prosjektstørrelse. Men smidige prosjekter oppfordrer typisk til mindre prosjekter. Jeg tror dette både er for å underbygge hyppig feedback, men også fordi det er en vanlig oppfatning at store prosjekter er mindre vellykket. Som igjen går tilbake til det du sier om planer som er vanskelige å sammenstille.

Et spørsmål til sist: Jeg forstår deg til å si at det er bedre å forske på "NÅR fungerer X bedre enn Y", heller enn "FUNGERER X bedre enn Y". Det kan jeg si meg enig i. Men dette endrer ikke problemet du påpeker med at vi ikke klarer å definere "BEDRE", ikke sant?

Re: Forskning på smidige prosjekter

Magne Jørgensen — Mon, 26 May 2008 15:59:00 -0000

Forkortet og repostet av Johannes etter tillatelse fra Magne Jørgensen

Du er inne på mye jeg også synes er helt vesentlige i dine tanker rundt hvordan vet vi at ... Og hyggelig å få respons på kritikk. Synes generelt sett vi kritiserer hverandre for lite - tar gjerne imot kritikk på mine synspunkter/studier/resultater etc ;-)

Ved å redusere til "iterasjoner" og "suksess" i ROI-termer er du/vi kanskje noe nærmere å kunne evaluere "agile" - men bare noe. Jeg har selv (etter en del studier på lignende tema - som om verktøy xxx er bedre enn verktøy yyy i firma zzz) mistet troen på at slike studier er særlig nyttige. Selv ikke med den helt avgjørende overgangen fra "er x bedre enn y" til "når er x bedre enn y" synes slike studier å være særlig verdifulle. Noe av problemene skyldes definisjonsproblemer - a la de du er inne på, men det viktigste er at man sjelden har sammenligninger av interesse der noe er ALLTID bedre enn noe annet, og det hjelper en organisasjon lite at det f eks i GJENNOMSNITT har vært best i den studerte konteksten.

[...] Ditt fokus på hyppige iterasjoner bør - etter min mening - også sees i et problemløsningsperspektiv, dvs hva er den optimale feedback-sekvens for en viss type feedback gitt et eget kompetansenivå og type problem. At man lenge har hatt for lite feedback innen systemutvikling innen mange metoder, vil kanskje si at hyppigere SOM OFTEST vil forbedre nytten/effektiviteten/... er selvsagt langt mindre
verdifull kunnskap enn å vite mer om hvilken type feedback, når og hvor ofte et visst nivå med feedback er gunstig.