Kanban i vedlikeholdsprosjekter

I systemutvikling er Kanban en metode som passer spesielt godt til vedlikeholdsprosjekter. Når man snakker om smidig utvikling tar man ofte for gitt at man vil jobbe Scrum. Erfaringsmessig fungerer ikke Scrum like bra i alle typer situasjoner. Når det gjelder vedlikeholdsprosjekter møter man mange utfordringer med Scrum. Mange av utfordringene kan løses ved å bruke Kanban-metodikken.

Hovedutfordringen med Scrum i et vedlikeholdsprosjekt er uforutsigbarheten som ligger i et slikt prosjekts natur. Kanban er laget for å håndtere uforutsigbarhet og passer derfor godt.

Kanban baserer seg, som Scrum, i stor grad på empiri og prosessforbedringsteori. Hovedtankene er tatt fra Lean og involverer prinsipper som ”Eliminate Waste”, ”Pull Scheduling”, ”Stop the Line” og ”Just in Time”. Reglene for Kanban er enklere og krever litt mer av team og kunde, men fungerer erfaringsmessig meget bra for vedlikehold av programvare.

Kanban-regler

Det er tre regler man må følge i Kanban:

  • Visualiser arbeidsflyten: Som i Scrum er det viktig å visualisere flyt. Dette gjøres enkelt ved å benytte en tavle og Kanban-kort som representerer oppgavene.
  • Reduser samtidig arbeidsmengde: Det er et mål å ha så korte køer som mulig. Det vil si at man skal redusere antall samtidige oppgaver. Dette sørger for at flere oppgaver blir løst på kortere tid og at man får en bedre flyt i arbeidet.
  • Mål gjennomstrømningstid: For å kunne forbedre prosessen må man kunne måle resultatet av endringer. Ved å måle tiden fra et problem dukker opp til det er løst og satt i produksjon, kan man lett måle om endringer gjør denne tiden lengre eller kortere.

Kanban-kort

Et Kanban-kort representerer en oppgave. Man kan sette regler for at ingen kan jobbe på mer enn én oppgave av gangen, men man åpner for at flere kan jobbe på samme oppgave. Dette er aktuelt for eksempel i forbindelse med parprogrammering. Et Kanban-kort inneholder informasjon om hvilken oppgave det gjelder, gjerne en ID til et issue tracker-system, hvem som utvikler, hvem som tar QA, og revisjonsnummer fra versjonskontrollsystemet.

Kanban-tavle

En Kanban-tavle er veldig lik en Scrum-tavle. Det viktigste er at den visualiserer den faktiske arbeidsprosessen. På denne måten kan man lett se hvor køene oppstår Bildet under viser tydelig at man har altfor mange åpne QA-oppgaver.

Kanbantavle uten begrensninger

Dette løses opp i ved å sette grenser for antall samtidige arbeidsoppgaver for å sikre flyt. Dette er gjort på bildet under.

Kanbantavle med begrensninger

Begrense antall samtidige oppgaver.

Det viktigste prinsippet for å sikre god flyt er å redusere antall køer og lengden på de køene man må ha. Dette må man eksperimentere med samtidig som man måler gjennomstrømningshastigheten for å finne de reglene og begrensningene som gir best flyt. I noen tilfeller kan det faktisk være at man må ha færre åpne oppgaver enn man er teammedlemmer. Kanskje kan et team på 10 personer bare ha 5 åpne oppgaver totalt. Dette vil måtte løses ved bruk av parprogrammering, noe som vil kunne øke hastigheten totalt sett.

Daglig møte

Daglig møte er ikke noe krav i Kanban, men en god skikk å ta med seg fra Scrum. En viktig forskjell er at man skifter fra å stille de tre klassiske spørsmålene fra Scrum og heller fokuserer på arbeidsoppgavene på tavla. Man går igjennom oppgavene og spør hver enkelt oppgave: “Hva kan vi gjøre for deg, kjære arbeidsoppgave, så du blir løst raskest mulig?”. Dette øker fokuset på oppgavene betraktelig og er med på å holde flyten oppe.

Hva skiller Kanban fra Scrum?

I korte trekk er det fravær av sprinter som er den største overgangen. Dette vil gi betraktelig bedre respons fra teamet og man vil kunne gjøre de viktigste tingene ferdig og produksjonsklare først uten å måtte vente på at alle andre oppgaver i sprinten skal bli ferdig.

Det åpner igjen for hyppigere utrulling av produksjonsklar kode, noe som minsker tiden før tilbakemeldinger kommer tilbake til utvikler, som igjen gjør eventuell feilretting enda raskere. En god sirkel, men andre ord.

Ulempen med Kanban er man ikke har sprintene som forutsigbare leveranser. Når man driver et vedlikeholdsprosjekt må man vurdere om man vil bytte ut denne forutsigbarheten med muligheten for raskere og mer effektivt vedlikehold.

Kanban sier heller ingenting om roller. Erfaringsmessig er rollene i Scrum godt definerte og fungerer fint sammen, så det er god praksis å fortsette med Produkteier og Scrum Master. I tillegg tar man med seg retrospektivet fra Scrum, som et hjelpemiddel for å forbedre prosessen.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s