🎲 — mikrobloggeriet olorm — olorm-37 · olorm-38 · olorm-39
I utvikling følger vi ofte en Kanban-inspirert prosess med tavle inndelt i kolonner med oppgave-lapper:
| innkommende | pågående | verifisering | ferdig |
|---|---|---|---|
| ny sak | |||
| fiks | |||
| oppgave |
Kanban sier: Begrens antall oppgaver under arbeid!
Vi vet jo alle at for mange samtidige oppgaver skaper krevende kontekstbytter, generell fare for kaos, og økt total tidsbruk per oppgave — så dette er et fornuftig råd.
En vakker innsikt er å alltid lese tavlen fra høyre til venste (systemet er pull-basert, ikke push-basert). Hvilken oppgave er nærmest å være ferdig? En ferdig oppgave leverer verdi og innsikt, og frigjør plass til neste oppgave.
Jeg finner kvalitet i at team-medlemmer følger denne prioriteringen med “sist først”. Det betyr at jeg synes det er verdifult at en pull-request tas relativt raskt, på bekostning av å fortsette med sin egen koding e.l.
Tenk gjerne: “Hva kan jeg gjøre denne morgenen for å unblocke en oppgave?”
Når en ny oppgave skal påbegynnes (vi har en del individuell frihet ved valg av uløst oppgave) finner jeg kvalitet i at man velger “kjipe” bugfiks-oppgaver fremfor kul ny feature. Selv om disse er likestilt “horisontalt” på tavla, tenker jeg at bugfiksen er mer “høyrestilt” (= høyere stilt?) enn en ny feature.
Men så må man selvfølgelig passe på at man også bruker nok tid på de mer langsiktige oppgavene.
Relatert mikroblogg av undertegnede: Fart i utvikling?
Hva tenker du, har du noen andre tommelfingerregler du liker? Er du uenig i mine tanker? Det er lov, jeg er det ofte selv!
—Richard Tingstad