HVA KOSTER DET Å GJØRE ALT SAMTIDIG?

Parallellitet og kontekstbytte

Tallene verktøyet bruker, hvor de kommer fra, og hva de ikke kan si.

JUSTERBAR ANTAKELSEVerktøyet ganger ikke i stillhet med ett tall. Faktoren er en antakelse du kan endre.

Kort fortalt

Når et scenario har en WIP-grense over 1, kjører flere tiltak samtidig. Da starter arbeidet tidligere, men hvert enkelt tiltak tar lenger tid fordi oppmerksomheten deles. Verktøyet modellerer dette som en gjennomstrømningsfaktor: effektiv varighet = varighet ÷ (1 − tap).

Det er én ting du bør vite før du stoler på tallet: forskningen er ikke enig med seg selv. Den mest siterte kilden er en erfaringsregel forfatteren selv ikke kaller en måling, og den best målte programvaredataen peker i en annen retning enn folk flest tror. Derfor er tapstabellen noe du kan justere, ikke en fasit vi har bakt inn.

Tallene verktøyet bruker

Default er Weinbergs tabell. Kolonnen til høyre er konsekvensen, ikke en egen kilde.

Samtidige tiltak	Tap av produktiv tid	Effektiv varighet per tiltak	Gjennomstrømning mot én av gangen
1	0 %	× 1,00	1,00×
2	20 %	× 1,25	1,60×
3	40 %	× 1,67	1,80× — høyest
4	60 %	× 2,50	1,60×
5	75 %	× 4,00	1,25×

Legg merke til formen: gjennomstrømningen stiger, topper seg rundt tre samtidige, og faller igjen. Fire parallelle tiltak gir omtrent samme gjennomstrømning som to, og fem er verre enn begge. Det er ikke noe vi har lagt inn med vilje — det følger av Weinbergs egne tall når man regner dem om til gjennomstrømning.

Over fem samtidige brukes tapet for fem videre. Weinbergs tabell stopper der, og vi gjetter ikke.

Kildene

Merket med samme evidensvokabular som resten av verktøyet.

Hypotese / erfaringsregel

Weinberg (1991)

Quality Software Management, Vol. 1: Systems Thinking, Dorset House, s. 284–285.

Sier: Med to samtidige prosjekter går 20 % av tiden til kontekstbytte, med tre 40 %, med fire 60 %.

Sier ikke: At dette er målt. Weinberg presenterer det som en erfaringsregel, ikke som et laboratorieresultat. Tallene er likevel de mest siterte på feltet, i praksis fordi ingenting mer stringent har erstattet dem.

Brukes som default i verktøyet, nettopp fordi den er den vanligste referansen — ikke fordi den er den best dokumenterte.

Randomisert eksperiment

Mark, Gudith & Klocke (2008)

The Cost of Interrupted Work: More Speed and Stress. Proceedings of CHI 2008, s. 107–110. PDF ↗

Sier: Deltakere som ble avbrutt fullførte oppgavene raskere enn de som ikke ble avbrutt, uten målbar kvalitetsforskjell — men med vesentlig mer stress, frustrasjon, tidspress og opplevd anstrengelse.

Sier ikke: At avbrudd er gratis. Kostnaden dukket opp som belastning på mennesker, ikke som tapt tid i dette oppsettet. Studien måler dessuten avbrudd i en oppgave, ikke det å ha flere prosjekter gående over uker.

Grunnen til at verktøyet ikke påstår at tapet nødvendigvis viser seg som forsinkelse. Det kan like gjerne vise seg som slitasje, og det fanger ingen kurve opp.

Observasjon

Vasilescu et al. (2016)

The Sky Is Not the Limit: Multitasking Across GitHub Projects. Proceedings of ICSE 2016. PDF ↗

Sier: På store mengder faktiske GitHub-data henger moderat multitasking sammen med høyere produktivitet, ikke lavere. Men det finnes et punkt med avtakende utbytte, der gevinsten blir spist opp av kognitiv overbelastning.

Sier ikke: At sammenhengen er årsak. Dette er observasjonsdata — produktive utviklere kan tenkes å påta seg flere prosjekter, snarere enn at flere prosjekter gjør dem produktive.

Den viktigste korreksjonen til «multitasking er alltid tap». Formen på kurven — opp, topp, ned — er grunnen til at vi viser gjennomstrømning og ikke bare tap.

Observasjon

Tregubov et al. (2017)

Impact of Task Switching and Work Interruptions on Software Development Processes. Proceedings of ICSSP 2017.

Sier: Utviklere som jobber i flere prosjekter bruker en betydelig del av arbeidstiden på kontekstbytte, og det påvirker treffsikkerheten i kostnads- og tidsestimater.

Sier ikke: En bestemt prosentsats som kan overføres til et hvilket som helst team.

Støtter at effekten er reell og verdt å modellere, uten å gi et tall vi kan bruke direkte.

Hva kildene er uenige om

Weinberg beskriver et bratt, lineært tap. ICSE-dataene beskriver en omvendt U der litt parallellitet er bedre enn ingen. CHI-eksperimentet finner ikke tapt tid i det hele tatt, men finner menneskelig belastning.

De tre er ikke nødvendigvis i konflikt — de måler ulike ting på ulike tidsskalaer: minutter med avbrudd, uker med prosjektbytte, og en erfaren praktikers inntrykk av team over år. Men de kan ikke slås sammen til ett tall uten å miste nettopp det som skiller dem.

Derfor: verktøyet bruker Weinberg som utgangspunkt fordi det er den kjente referansen, viser deg gjennomstrømningen så du ser den omvendte U-en, og lar deg endre tapstabellen når du har bedre tall for ditt eget team. Om dere måler noe annet hos dere, er det tallet bedre enn alle fire kildene her.

Forbehold i modellen

Tapet bruker scenarioets WIP-innstilling som en konstant. Verktøyet modellerer ikke faktisk samtidighet time for time.
Tapet treffer kalendertid, ikke kostnad. Et tiltak blir ikke dyrere av å gå saktere i denne modellen — det lander senere, og rekker dermed færre effektmåneder innen horisonten.
Kostnaden ved kontekstbytte rammer sannsynligvis ikke alt arbeid likt. Utforskende arbeid med lang oppvarming taper trolig mer enn rutinepreget arbeid. Modellen skiller ikke.
Menneskelig belastning er ikke modellert i det hele tatt. CHI-studien antyder at det er der kostnaden faktisk kan havne.
Tallene i eksempeldataene er illustrative, som ellers i verktøyet.

ⓘ Denne siden er referanseinnhold og henter ingen data fra arbeidsflaten din.