Du er kjent med Scrum, ikke sant? Jeg vil gjette ja med tanke på at The Scrum Alliance har over 400 000 medlemmer, og av dem bruker de fleste med hell i organisasjonene sine.
Men det er ikke den eneste måten å bygge programvare på en smidig måte - seriøst! Har du hørt om Kanban?
For litt bakgrunnsinformasjon ble den opprinnelig brukt på lean-produksjon som en måte å visualisere inndata og utdata av arbeid mens det strømmet gjennom en fabrikk. Denne visualiseringen ble presentert på et brett kjent som - vent på det - Kanban. Mer nylig og mer relevant for deg, er det blitt brukt som en metode for å administrere programvareutvikling.
Først skissert av nevrolog David J. Anderson, er det en måte å organisere programvareutvikling og planlegging som lar deg avdekke prosessproblemer og konsekvent levere verdifulle forbedringer i produktet ditt - som jeg vet, det høres ideelt ut. Enkelt sagt, når som helst, kan du se hvor arbeid (representert ved kort) er i ferd med å utvikle seg.
Hvordan det fungerer
Det grunnleggende Kanban-brettet bruker seks kolonner som viser hvor hvert verk er i produktutviklingssyklusen. En grov prøve av hvordan det ser ut er nedenfor.
Se dette Kanban-tavleeksemplet på Trello.
Kolonne 1: Etterslep
Backlog-kolonnen skal inneholde en prioritert liste over ideer, feil eller forretningsbehov. Kortet trenger ikke å ha massevis av detaljer ennå, men det skal ha nok informasjon til at teammedlemmene dine forstår hvorfor det er viktig.
Kolonne 2: Planlegging
I denne kolonnen vil en produktsjef fylle ut en spesifikasjon for funksjonen ved å møte forretningsmessige interessenter, ingeniører og designere. Når den er klar, vil han eller hun flytte den til kolonnen “Klar for teknikk”.
Kolonne 3: Klar for prosjektering
På dette stadiet skal alle kortene ha detaljerte spesifikasjoner. Selv om du fremdeles kan ha spørsmål om tekniske detaljer, bør virksomhetens krav være klare.
Kolonne 4: Pågår
Du kan når som helst flytte et kort til “Pågår”. Dette selvdrevne "pull" -systemet bygger en kultur for personlig ansvarlighet og nysgjerrighet.
Kolonne 5: Testing
Når du har fullført arbeidet med kortet, flytter du det til "Testing" der en annen ingeniør (eller noen i QA-teamet) vil hente det.
Kolonne 6: Distribuert
En annen avgjørende funksjon er at arbeid kontinuerlig skal leveres til et iscenesettelses- eller produksjonsmiljø. Denne kolonnen gjør det mulig for alle på teamet å se hva arbeidet har blitt utgitt nylig.
Fordelene og avveiningene
Når du bestemmer deg mellom Kanban og en mer vanlig metodikk som Scrum eller Waterfall, må du huske disse fordelene og utfordringene:
Fordel: Forbedrer samarbeidet
I noen utviklingsteam jeg har jobbet med, var ingeniører spesialister. Hvert team skulle ha et par frontendingeniører og backendingeniører. Dette betydde at arbeidet ofte ble blokkert fordi en ingeniør var opptatt med noe annet.
Kanban derimot begrenser arbeidet som pågår og fraråder blokkeringer. Hvert teammedlem kan bare jobbe med ett element av gangen, og alle som ikke er opptatt, kan trekke arbeid fra toppen av kolonnen “Klar for teknikk”. Dette oppmuntrer ingeniørgeneralister og samarbeid mellom teammedlemmer.
Øk fordelen: Ikke la ting gå før de er klare
Kanban fungerer bare når du venter på å flytte kort til neste kolonne til de er helt ferdige. (Bonus: Dette minimerer feilene sterkt.)
Utfordring: fraråder tid til å reflektere
Som standard er det ingen tidsboksede spurter med klare mål, datomål og utgivelsessykluser. Tenk i stedet på hvert kort som et selvstendig verk som kan fullføres og utgis når som helst.
Med denne kontinuerlige strømmen av arbeid, er det ingen "vente til neste sprint" -alternativ. Du må kontinuerlig sjekke brettet, trekke neste element og flytte ferdige elementer nedstrøms. Med mindre du bygger inn tid for tilbakeblikk og standup, kan det være vanskelig for teammedlemmer å følge med på hvordan de gjør det.
Kom deg rundt det: Lån hva som fungerer fra Scrum
Jeg har brukt daglige standups og retrospektiver med Kanban og funnet ut at de gir verdi. Hvis det er jevnlige møter eller mønstre som fungerer for teamet ditt, må du ikke endre dem til å følge dogmen. Budsjetter tid for å snakke om prioriteringene og hvordan de har endret seg slik at alle vet hva som skjer i produktutviklingssyklusen.
Fordel: Øker åpenhet
Hver utvikler må ta initiativ til å flytte et kort til kolonnen “Pågår”. Hvilket betyr at laglederen til enhver tid kan se på hvem som er opptatt, hvem som ikke er opptatt, og hvor lenge noe arbeid har pågått.
Når produksjonen avtar eller stopper, lar Kanban deg se nøyaktig hvorfor. Enten det er fordi forretningsteamet ikke har prioritert elementer i etterslepet, produktgruppen ikke er ferdig med spesifikasjonen, dev-teamet beveger seg saktere enn forventet, eller QA-teamet har ikke klart å teste noe; flaskehalsene er åpenbare.
Øk fordelen: Tillat fremgang å være offentlig
En av fordelene er at Kanban er veldig visuell. Selv ikke-tekniske teammedlemmer kan se på et Kanban-styre og fortelle hvor arbeidsstykker er i gang. Bruk dette til din fordel og la teamets prestasjoner skinne ved å plassere styret ditt på et offentlig sted.
Utfordring: Tillater ikke langtidsplanlegging
Å bekymre deg for tidsfrister og anslag er ikke den mest produktive bruken av tiden din, så du kan sette pris på at Kanban handler mer om den daglige produksjonen. Når det er sagt, gir den alene ikke et system for å bygge en langsiktig plan. Dette kan føre til at du jobber med prosjekter sporadisk fremfor å fokusere på en ting i lang tid. Det er tøft å tilbringe en dag på prosjekt A, deretter en dag på prosjekt B og deretter bytte tilbake til prosjekt A.
Kom deg rundt det: Bruk det når prioriteringene dine sannsynligvis vil endres
Hver kolonne i styret ditt er uavhengig av de andre, så teammedlemmer kan flytte rundt på ting når som helst. Dette kan irritere utviklere i en Scrum-setting (hvor estimater for sprinten er gjort på forhånd), men Kanban trives i denne typen raskt skiftende omgivelser.
Alle vil være mer produktive, men det kan være vanskelig å prøve noe nytt hvis du ikke en gang er sikker på hvor du skal begynne. Jeg har funnet Kanban som nyttig, og håper du også vil finne den nyttig for din personlige arbeidsflyt (eller til og med for hele teamet!).
Tweet meg hvis du bestemmer deg for å ta det!
