Kanban-modell i programvareteknikk

Hva er Kanban?

Kanban er et veldig populært rammeverk for utvikling i den smidige programvareutviklingsmetodikken. Det gir en transparent måte å visualisere oppgavene og arbeidskapasiteten til et team. Den bruker hovedsakelig fysiske og digitale tavler for å la teammedlemmene visualisere den nåværende tilstanden til prosjektet de jobber med.

Kanban oppsto i Toyota på 1940-tallet. Kanbans betydning på japansk er «billboards». Kanban-tavlen har kolonner og historiekort. Kolonnene er ingenting, men arbeidsflyttilstander og kort er ikke annet enn en demonstrasjon av den faktiske oppgaven et teammedlem utfører.

Når skal jeg bruke Kanban?

Her er grunnene til å bruke Kanban-utviklingsmetoden:

• Kanban kan brukes i alle domene, og det kan brukes veldig effektivt i programvareutvikling. Kanban-prosjektledelse hjelper til med å forbedre effektiviteten til teamet.
• Det er et pull-basert system. Oppgaver blir trukket så snart en person er ledig.
• Kanban bør brukes når du vil gi ut arbeidet ditt når som helst. Det krever git-grening, men det er gjennomførbart.
• Kanban bør brukes når du ønsker å endre prioriteringene i farten. For det er alt du trenger å gjøre å sette denne historien på toppen av gjøremålskøen.
• Den bør brukes når du vil visualisere arbeidet ditt, og du vil se fremdriften til oppgavene dine visuelt.

Kanban-kort

Kanban-systemet anbefaler visualisering av arbeid. Det foreslår bruk av den fysiske og den digitale tavlen.

Kanban-kortene er viktige brikker på Kanban-tavlen ettersom det representerer arbeidet som teamet jobber med. Disse kortene vil ha

1. Prioritet
2. Eieren
3. typen
4. Tidsfrist

En kolonne i Kanban-tavlen representerer arbeidsstadiet, og du kan plassere en WIP-grense (Work in Progress) på kolonnen. WIP-grensen betyr det maksimale antallet kort som kan forbli i den kolonnen.

Siden Kanban-prosjektledelsen bruker et pull-basert system, når og når en utvikler er ledig, kan han/hun trekke et kort fra to-do-kolonnen til dev-kolonnen.

Kanban Board

Kanban Board er et smidig prosjektstyringsverktøy som hjelper med å implementere Kanban for å administrere prosjekter for personlige og forretningsformål. Det er et fysisk eller digitalt (JIRA) brett designet for å hjelpe team med å visualisere arbeidet sitt på forskjellige stadier og prosesser. Det hjelper også med å representere stadiene i arbeidet med kolonner ved hjelp av kort.

Den har kolonner som representerer statusen til arbeidet som

1. Å gjøre,
2. dev
3. Testing
4. Ferdig.

Hver av disse kolonnene kan ha kort <=WIP-grensen. Kortene representerer det faktiske arbeidet.

Du kan bruke positive tall for å begrense pågående arbeid, og dette grensetallet kan plasseres på toppen av kolonnene i både fysiske og digitale Kanban-tavler. Enhver person i teamet kan administrere statusen til kortet sitt, og hele teamet kan visualisere arbeidsflyten. Neste i denne Kanban-opplæringen vil vi lære om Kanban Workflow.

Kanban arbeidsflyt

Kanban arbeidsflyt er et sett med trinn som hjelper team med å definere eksplisitte retningslinjer og prinsipper i Kanban. Den representerer reglene og prosedyrene mens arbeidet pågår på tvers av ulike stadier av utviklings- og leveringssykluser. Kanban arbeidsflyt består av trinnvise prosesser mellom oppstart og levering av en bestemt oppgave.

Den grunnleggende rektor Kanban følger er, "slutt å starte, begynn å fullføre". Ved hjelp av WIP-grenser får den gjort mer arbeid. Det er tilpassbare Kanban-arbeidsflyter og tilstander tilgjengelig i alle moderne verktøy som JIRA.

Nedenfor er de grunnleggende tilstandene som mange programvareteam følger for sin arbeidsflytadministrasjon.

Stater	Forståelse av oppgaver
Å gjøre	Oppgaver kommer hit for første gang i denne tilstanden.
Klar for analyse	Analyser oppgaven og legg til krav fullstendig.
Klar for utvikling	Analyse fullført og utvikling kan starte.
I utviklingen	Oppgaver er under utvikling.
Klar for testing	Utvikling fullført, og nå kan testingen starte.
I testingen	Oppgaver testes ut.
Klar for utgivelse	Testing fullført; utgivelse kan skje.
Utgitt/ferdig	Løslatt.

Pull-basert system

Kanban er en pull-basert metode der oppgaver blir trukket i stedet for å bli presset. Så snart du har fullført ditt nåværende kort, kan du trekke et nytt kort fra forrige kolonne på Kanban-brettet.

Med WIP-grensen hjelper Kanban med å forbedre ledetid og syklustid. Det bør være minst mulig gap mellom disse to tidspunktene. For eksempel har vi 5 utviklere og bare 1 tester; hva vil skje i dette tilfellet? Det vil alltid være mange kort som krever testing, og de vil sitte stille og vente.

For å overvinne problemene nevnt ovenfor og forbedre effektiviteten, følger Kanban den pull-baserte tilnærmingen med WIP-grenser, der det vil være et begrenset antall kort som skal trekkes.

Så en tester vil trekke en oppgave fra "klar for testing"-stadiet når han har fullført sin nåværende oppgave. Med WIP-grensen i Kanban-kolonner (utviklingsstadier), vil du ikke ha mange uovervåkede kort i Kanban-arbeidsflyten.

Det pull-baserte systemet hjelper også med å finne riktig hastighet for laget. Med riktig hastighet på plass vil laget prestere bedre.

Ledetid og syklustid

I Kanban-metoden er ledetid og syklustid mye brukt, det er en forskjell mellom de to, og det er viktig å forstå det for å unngå forvirring.

Leveringstid	Syklus tid
Ledetid måles som tiden mellom oppgavens ankomst i arbeidsflyten din og dens avgang fra arbeidsflyten, noe som betyr at den er frigitt.	Syklustid måles som tiden mellom oppgavens ankomst i tilstanden «pågår» og ankomsten av oppgaven i «klar for utgivelse».

Her er det også viktig å forstå å ikke inkludere tiden det tar mellom klar for utgivelse og faktisk utgivelse.

Cycle Time = Work in Progress/Throughput

I det ideelle scenariet bør gapet mellom ledetid og syklustid være minimalt, og Kanban bruker et kumulativt flytdiagram (CFD) for å måle historiske data for lead og syklustid.

Kumulativt flytdiagram (CFD)

CFD er et diagram som er tilgjengelig i alle ledende verktøy for arbeidsflytstyring som JIRA. Dette diagrammet måler den totale mengden arbeidskort/oppgaver som kom inn i arbeidsflyten og samlet fullførte kort/oppgaver over tid.

Det hjelper deg å ha et estimat for gjennomsnittlig ledetid og syklustid for forhåndsdefinert tid.

CFD-diagram vil gi deg indikatorer eller problemområder du kan fikse. Det vil gi deg et klart bilde, og basert på dette diagrammet. Du kan korrigere lagets ledetid og syklustid.

1. Leveringstid: Det er varigheten mellom et nytt korts ankomst i arbeidsflyten din og dets endelige avgang fra arbeidsflyten.
2. Syklus tid: Det er en varighet mellom kortets ankomst i arbeidstilstand og når kortet er klart for utgivelse.
3. WIP: Pågående arbeid (WIP) begrenser maksimalt antall arbeidselementer i de forskjellige stadiene av arbeidsflyten.
4. gjennomstrømming: Det er den faktiske ytelsen, og den forteller det faktiske antallet kort som er levert i en gitt tidsramme.

Gjennomstrømning = WIP/syklustid

Begrenser WIP (pågår arbeid)

I Kanban utviklingsmetodikk begrenser WIP antall oppgaver/kort som kan arbeides med av et teammedlem eller hele på en gang.

WIP-grensene sikrer at teamet stabiliserer arbeidet sitt og øker den prediktive naturen, noe som er essensielt i det pull-baserte systemet. Vanligvis tas WIP-grensebeslutningen av teamet selv.

Grunn til å angi WIP-grensene

Her er grunner til å angi WIP-grensene:

• Det skifter fokus på å få ting gjort når et individ fokuserer på en enkelt oppgave om gangen.
• Det hjelper teamene til å forstå deres kapasitet.
• Det forbedrer produktivitetsføring og syklustid.
• Det hjelper med å unngå opphopningsoppgaver (i ventemodus).
• Det hjelper i bevegelsen av arbeidsflyten og oppgavene fortsetter å bevege seg.
• Det hjelper også å løse blokkere ettersom en person ikke bytter mellom ulike oppgaver.

Scrum vs. Kanban

Her er de viktige forskjellene mellom Scrum vs. Kanban

Scrum	Kanban
Scrum legger vekt på planlegging. Det starter med sprintplanlegging og ender opp med sprint retrospektiv. Det holdes mange møter som bidrar til å sikre at teamet er på linje med de neste trinnene, prioriteringene og læringen fra tidligere sprints.	Kanban er åpen for å gjøre endringer mens du er på farten. Det betyr at det er mindre stivhet og ting kan endres ofte.
Det anbefaler innsamling av tidsmålinger laget under sprint	Kanban anbefaler grafer for å få oversikt over lagets fremgang over tid.
Scrum ikke lenger ber om et engasjement fra team. I stedet handler det om sprintmålene og prognosene.	Kanban er avhengig av tidsboksing og prognoser.
Det legger vekt på planlegging, og så estimering spiller en svært viktig rolle i Scrum	Kanban har ingen obligatoriske krav for estimering.
Hver individet har sin rolle og ansvar.	Nei sette roller så fleksibilitet når det gjelder individuelle ansvarsområder.
Iterasjonene/Sprints er faste i varighet. Denne varigheten varierer fra 2 uker til 1 måned.	Kanban er ikke basert på varighet. Denne tingen måles i forhold til syklustider.
Lag er pålagt å forplikte seg en bestemt mengde arbeid.	Engasjement ikke nødvendig det er valgfritt for lag.
I denne metoden, Tverrfunksjonelle lag er viktige siden de kan håndtere eventuelle forstyrrelser som kan forårsake en flaskehals i programvareutviklingen.	Å ha spesialisert team er viktig.
Det er ikke mulig å legge til elementer til pågående iterasjoner.	Ny elementer kan enkelt legges til hvis tilleggskapasiteten er tilgjengelig.
Et sprint-etterslep eies av kun av en enkelt lag.	Flere lags kan dele Kanban-brett.
Leveranser er bestemmes av spurter, som et sett med arbeid må være fullført og klar for gjennomgang.	Produkter og prosesser er leveres fortløpende på nødvendig grunnlag. Så test- og vurderingsprosessen fortsetter samtidig.
Scrum programvareutviklingsmetode fokuserer på etterslepet.	Kanban-metoden helt fokuserer på prosessdashbord.
Hver teammedlem har en bestemt rolle i Scrum master bestemmer tidslinjer, produkteier setter mål og mål, og teammedlemmer utfører utviklingsarbeidet.	Det er ingen forhåndsdefinerte roller for et team. Det kan imidlertid fortsatt være en prosjektleder; teamet oppfordres til å samarbeide og samarbeide.
Best for prosjekter med endre prioriteringer.	Ideell for lag med stabile prioriteringer som neppe endres over tid.
Måler produksjon ved hjelp av hastighet gjennom spurter.	Måler produksjonen vha syklus tid eller den nøyaktige tiden det tar å fullføre en hel del av et prosjekt.
Scrum krever en fullstendig skifte fra den tradisjonelle modellen til Agile Scrum-modellen som skulle implementeres prosjektet.	Kanban tillater ikke drastiske endringer i prosjektet.
Det er en ideell metode for prosjekter med vidt varierende prioriteringer.	Passer best for lag med stabile prioriteringer.
I Scrum er hele team fokuserer på å samarbeide og fullføre oppgaven å gi kvalitetsutviklingsarbeid.	Team jobber for å nå mål og redusere tiden for å fullføre hele prosessen. Dermed er reduksjon i tidssyklusen de største indikatorene på suksess her.
Scrum vekt på timeplanene; nye elementer kan ikke legges til pågående iterasjoner.	Kanban er mer iterativ av natur som den har ikke spesifikke tidsrammer. Slik at nye varer kontinuerlig kan legges til når ekstra kapasitet er tilgjengelig.
Det totale arbeidet er utført i partier/Sprints.	Hele prosjektet utføres på bevegelse av entrådet arbeidselement flyter.
Scrum master fungerer som en problemløser.	Kanban oppfordrer hvert teammedlem er en leder og dele ansvaret mellom dem alle.
Scrum foreskriver iterasjoner i tidsboks.	Kanban fokuserer på planlegger en annen varighet for individuell iterasjon.
Scrum hjelper bedrifter å spare tid og penger.	Kanban-metoden fokus på kontinuerlig forbedring, produktivitet og effektivitet.
Oppnå stabil og konsekvent kommunikasjon ytelse på alle nivåer.	Det er mer sannsynlig at teammedlemmer gjør det oppnå sine mål mye lettere på grunn av den visuelle naturen til Kanban-brett.
Prosjekt er kodet og testet under sprinten anmeldelse	Det er mer sannsynlig at teammedlemmer gjør det oppnå sine mål mye lettere på grunn av den visuelle naturen til Kanban-brett.
Det er lettere å tilpasse seg de konstante endringene på grunn av de korte spurtene og jevnlige tilbakemeldinger.	Det er designet for en vanlig, jevn utgang, kan store endringer i kundenes etterspørsel få Kanban til å mislykkes.
Den totale kostnaden for prosjektet er minimal som kan føre til raskere og billigere resultat.	Hvis en oppgave ikke er riktig estimert, totale prosjektkostnader vil aldri være nøyaktige. I slike tilfeller kan oppgaven fordeles over flere spurter.
Denne metodikken krever erfarne teammedlemmer bare. Så hvis teamet består av personer som ikke er eksperter, kan ikke prosjektet fullføres i tide.	Nei spesifikke tidsrammer tildeles med hver fase, så teammedlemmene får aldri ideen om hvor mye tid de kan ta i hver fase.
I denne Agile Scrum-metoden er det det lettere å levere et kvalitetsprodukt til avtalt tid.	Den er designet for en regelmessig, jevn utgang, store endringer i kundenes etterspørsel kan få Kanban til å falle.
Ocuco prosjektplanen vil aldri forstyrre selv om et teammedlem forlater laget.	Hvis noen av teammedlemmene går ut under utviklingen, kan de gjøre det skade prosjektutviklingen.
Daglige møter noen ganger frustrere lag medlemmer.	Utdatert Kanban-tavle kan føre til problemer i utviklingsprosessen.
Store prosjekter kan enkelt deles inn i lett håndterbare spurter.

Sammendrag

• Kanban-definisjon: Kanban er definert som en smidig utviklingsmetodikk for å utvikle programvare, biler, varer, medisiner, sko eller annet produksjonsarbeid.
• Kanban bruker Kanban-tavlen for å visualisere arbeidet. Den bruker kolonner som stadier (to-do, dev, testing, etc.) og kort som et arbeidselement.
• Kanban-metodikk støtter den fysiske og digitale tavlen for visualisering.
• Kanban er et pull-basert system, og kort trekkes fra forrige fase til nåværende stadier av teammedlemmer.
• Kanban-metoden bruker CFD-diagrammet for å forstå teamets ledetid og syklustid. Dette diagrammet hjelper teamene med å fikse gapet mellom disse to tidspunktene og forbedre effektiviteten.
• Kanban utviklingsmetodikk, WIP begrenser antall oppgaver/kort som kan arbeides med av et teammedlem eller hele på en gang.
• WIP begrenser skifter fokus på å få ting gjort når en person fokuserer på en enkelt oppgave om gangen.