Hvad er Kanban-modellen i softwareudvikling?

Hvad er Kanban?

Kanban er en meget populær ramme for udvikling i den agile softwareudviklingsmetodologi. Det giver en gennemsigtig måde at visualisere et teams opgaver og arbejdskapacitet. Det bruger primært fysiske og digitale tavler til at give teammedlemmerne mulighed for at visualisere den aktuelle tilstand af det projekt, de arbejder på.

Kanban opstod i Toyota i 1940'erne. Kanbans betydning på japansk er "billboards". Kanban-brættet har kolonner og historiekort. Kolonnerne er ingenting, men arbejdsprocestilstande og -kort er intet andet end en demonstration af den faktiske opgave, et teammedlem udfører.

Disse kort havde et just-in-time-signal: en station anmodede kun om dele, når den rent faktisk havde brug for dem, så intet blev bygget på forhånd. Kanban bevarer den idé. Det er en metode, der lægges oven på din eksisterende proces snarere end en erstatning for den, så den passer til enhver livscyklus til softwareudvikling model du allerede kører.

Hvornår skal man bruge Kanban?

Kanban er egnet til teams, hvis arbejde ankommer uforudsigeligt, og som har brug for at frigive, så snart et element er klar. Her er de vigtigste grunde til at bruge Kanban-metoden:

• Kanban kan bruges i ethvert domæne, og det kan bruges meget effektivt i softwareudvikling. Kanban projektledelse hjælper med at forbedre effektiviteten af ​​teamet.
• Det er et pull-baseret system. Opgaver bliver trukket, så snart en person er fri.
• Kanban bør bruges, når du vil frigive dit arbejde til enhver tid. Det kræver git branching, men det kan lade sig gøre.
• Kanban skal bruges, når du vil ændre prioriteterne i farten. Til det skal du blot placere denne historie øverst i to-do-køen.
• Den skal bruges, når du vil visualisere dit arbejde, og du vil se fremdriften i dine opgaver visuelt.

Pasform er den ene halvdel af beslutningen; udbyttet nedenfor er den anden.

Fordele ved Kanban-metoden

Det stærkeste argument for Kanban er, at det forbedrer leveringen uden at tvinge en reorganisering frem. Ingen ændrer titel, og der pålægges ingen sprintkalender, men alligevel gør tavlen køer, blokeringer og overbelastede personer synlige på dag ét. En flaskehals, som alle kan se, har en tendens til at blive løst.

Teams, der kører Kanban, rapporterer konsekvent følgende fordele:

• Kortere leveringstider: WIP-grænser reducerer den tid, et kort bruger på at vente, hvilket er der, hvor den største del af forsinkelsen gemmer sig.
• Højere fleksibilitet: Et presserende punkt kan når som helst placeres øverst i opgavekolonnen uden at skulle vente på en iteration.
• Bedre samarbejde: Når en kolonne når sin grænse, hjælper gratismedlemmer med at rydde den i stedet for at starte noget nyt.
• Empowerment af medarbejdere: Enkeltpersoner vælger deres næste kort og ejer dets status, hvilket fjerner flaskehalse ved godkendelse.
• Forudsigelig prognose: Historisk cyklustid giver et evidensbaseret leveringsestimat i stedet for et gæt.
• Less spild: Intet startes, før systemet har kapacitet til at afslutte det.

Disse resultater følger af fire principper, der styrer enhver Kanban-implementering.

De fire principper for Kanban

Nedenfor er de fire vigtigste kerneprincipper i Kanban:

1. Start med det, du har nu: Kanban-systemet foreslår at arbejde trinvist og starte med det, du har i øjeblikket. Da en af ​​dens praksis er at forbedre løbende, skal du forbedre systemet gradvist.
2. Accepter at forfølge inkrementelle, evolutionære forandringer: Kanban anbefaler en trinvis ændring i processen, og du må ikke lave en stor ændring i processen på én gang.
3. Respekter den nuværende proces, roller og ansvar: Begynd igen med det, du har nu, og skift processen, rollen og ansvarsområder gradvist.
4. Tilskynd til lederskab på alle niveauer: Hvert individ kan fungere som leder og give ideer til at forbedre effektiviteten af ​​det overordnede Kanban-system. Du skal ikke tro, at dette er en aktivitet på ledelsesniveau, og selv det yngste medlem af teamet kan fungere som leder.

Principper beskriver tankegangen. De seks praksisser nedenfor beskriver den daglige adfærd, der omsætter dem til virkelighed.

De seks Kanban-kernepraksis

Følgende er de seks vigtigste kernepraksisser i Kanban:

1. Visualiser arbejdsgangenDette princip foreslår at have en Kanban-tavle (fysisk eller digital) til at visualisere arbejdsgangen. Hver enkelt person i et team skal se sit eget kort og kortene fra andre teammedlemmer. Du kan flytte dine kort i forskellige kolonner i henhold til tavlens layout. Det skaber stor gennemsigtighed i teamet og gør det også nemmere at løse blokeringer.
2. Begræns igangværende arbejde: Kanban er et pull-baseret system, og det forbedrer effektiviteten af ​​et team til at begrænse igangværende arbejde og have opgaver, der kan udføres inden for den givne tidsramme af teamet. Denne WIP-grænse gælder fra begyndelsen til slutningen af ​​workflowet. Du kan anvende grænsen oven på kolonnen ved hjælp af et positivt heltal.
3. Fokus på flow: Dette princip fokuserer på flow og på eventuelle afbrydelser. Hvis der er afbrydelser eller blokeringer, skal de rettes permanent.
4. Eksplicitte politikker: Politikker kan etableres i et team for at reducere omarbejdet og fokusere på de områder, der kræver opmærksomhed, eller hvor det er mere effektivt.
5. Feedbacksløjfe: Feedback-loops er meget vigtige i Kanban. Det er ikke kun inden for holdet, men mellem flere hold, trænere osv. Dette hjælper med at forbedre den generelle sundhed i Kanban-systemet.
6. Kontinuerlig forbedring: Dette er kerneprincippet i Kanban-systemet. Der står, at man altid kan forbedre processen, og det vil resultere i en bedre effektivitet.

Praksisser kræver ejere, hvilket Kanban håndterer anderledes end andre agile metoder.

Kanban-roller og -ansvar

Kanban foreskriver ingen nye jobtitler, og det er bevidst – det tredje princip beder dig om at respektere de roller, du allerede har. En udvikler forbliver en udvikler. I praksis opstår der dog to ansvarsområder, efterhånden som et bestyrelsesmedlem modnes, og modne implementeringer navngiver dem eksplicit.

Serviceleveringschef Ejer arbejdsflowet på brættet. Denne person holder øje med kort, der er holdt op med at bevæge sig, eskalerer blokeringer, holder kolonner inden for deres WIP-grænser og kører gennemgangen, hvor teamet inspicerer sine egne cyklustidsdata. Serviceanmodningschef ejer det, der kommer på tavlen, repræsenterer de kunder, der fremsætter anmodninger, sorterer to-do-kolonnen, så det mest værdifulde element kommer øverst, og gør udvælgelsespolitikken eksplicit.

Begge dele er ansvarsområder snarere end ekstra personale; én person bærer ofte begge dele. Det, der betyder noget, er, at nogen er ansvarlig for flowet og nogen for indtaget. De artefakter, de håndterer, kommer derefter.

Kanban kort

Kanban-metoden anbefaler visualisering af arbejde. Den foreslår brugen af ​​både den fysiske og den digitale tavle, og tavlen nedenfor viser disse kolonner med kort fordelt på tværs.

Kanban-kortene er vigtige brikker på Kanban-brættet, da det repræsenterer det arbejde, som teamet arbejder på. Disse kort vil have

1. Prioritet
2. Ejer
3. Type
4. Afleveringsdato

En kolonne i Kanban-tavlen repræsenterer arbejdsstadiet, og du kan placere en WIP-grænse (Work in Progress) på kolonnen. WIP-grænsen betyder det maksimale antal kort, der kan forblive i den kolonne.

Da Kanban-metoden bruger et pull-baseret system, kan en udvikler, når han/hun er ledig, trække et kort fra to-do-kolonnen til dev-kolonnen. Det bræt, disse kort findes på, fortjener et nærmere kig.

Kanban Board

Kanban Board er et agilt projektstyringsværktøj, der hjælper med at implementere Kanban til at styre projekter til personlige og forretningsmæssige formål. Det er en fysisk eller digital (JIRA) tavle designet til at hjælpe teams med at visualisere deres arbejde på forskellige stadier og processer. Det hjælper også med at repræsentere stadierne af arbejdet med kolonner ved hjælp af kort.

Det har kolonner, der repræsenterer status for arbejdet som

1. At gøre,
2. dev
3. Test
4. Udført.

Hver af disse kolonner kan have kort <=WIP-grænsen. Kortene repræsenterer det faktiske arbejde.

Du kan bruge positive tal til at begrænse igangværende arbejde, og dette grænsetal kan placeres øverst i kolonnerne i både fysiske og digitale Kanban-tavler. Enhver person i teamet kan administrere status for sit kort, og hele teamet kan visualisere arbejdsgangen. Digitalbrædder såsom jira Tilføj de samme grænser med automatisk cyklustid trackonge. Dernæst vil vi lære om den Kanban-arbejdsgang, som disse kolonner repræsenterer.

Kanban arbejdsgang

Kanban arbejdsgang er et sæt trin, der hjælper teams med at definere eksplicitte politikker og principper i Kanban. Det repræsenterer reglerne og procedurerne, mens arbejdet foregår på tværs af forskellige stadier af udviklings- og leveringscyklusser. Kanban workflow består af trin-for-trin processer mellem start og levering af en bestemt opgave.

Det grundlæggende princip, Kanban følger, er, "stop med at starte, start med at afslutte". Ved hjælp af WIP-grænser får den gjort mere arbejde. Der er tilpassede Kanban-arbejdsgange og tilstande tilgængelige i ethvert moderne værktøj som JIRA.

Nedenfor er de grundlæggende tilstande, som mange softwareteams følger for deres workflowstyring.

Bemærk at "klar til"-tilstandene er køer, ikke arbejde. Et kort kan sidde i en på ubestemt tid, så reglen, der flytter kort, betyder mere end tilstandene.

Pull Baseret System

Kanban er en pull-baseret metode, hvor opgaver bliver trukket frem for at blive skubbet. Så snart du har udfyldt dit nuværende kort, kan du trække et nyt kort fra den forrige kolonne på Kanban-brættet.

Med WIP-grænsen hjælper Kanban med at forbedre Lead Time og Cycle Time. Der bør være det mindst mulige mellemrum mellem disse to tidspunkter. For eksempel har vi 5 udviklere og kun 1 tester; hvad vil der ske i dette tilfælde? Der vil altid være mange kort, der kræver test, og de vil sidde stille og vente.

For at overvinde de ovenfor nævnte problemer og forbedre effektiviteten, følger Kanban den pull-baserede tilgang med WIP-grænser, hvor der ville være et begrænset antal kort, der skal trækkes.

Så en tester vil trække en opgave fra "klar til test"-stadiet, når han er færdig med sin nuværende opgave. Med WIP-grænsen i Kanban-kolonner (udviklingsstadier) vil du ikke have mange uovervågede kort i Kanban-arbejdsgangen.

Det pull-baserede system hjælper også med at finde den korrekte hastighed for holdet. Med den rigtige hastighed på plads vil holdet præstere bedre. Alt her afhænger af ét tal: WIP-grænsen.

Begrænsning af WIP (igangværende arbejde)

I Kanban-metoden begrænser WIP antallet af opgaver/kort, som et teammedlem eller et helt team kan arbejde på ad gangen.

WIP-grænserne sikrer, at teamet stabiliserer deres arbejde og øger den prædiktive karakter, hvilket er essentielt i det pull-baserede system. Normalt træffes WIP-grænsebeslutningen af ​​teamet selv.

Grund til at indstille WIP-grænserne

Her er grunde til at indstille WIP-grænserne:

• Det flytter fokus på at få tingene gjort, da en person fokuserer på en enkelt opgave ad gangen.
• Det hjælper teams til at forstå deres kapacitet.
• Det forbedrer produktiviteten og cyklustiden.
• Det hjælper med at undgå ophobning af opgaver (i ventetilstand).
• Det forbedrer flowet i arbejdsgangen, så opgaverne fortsætter med at bevæge sig.
• Det hjælper også med at løse blokeringer, da en person ikke skifter mellem forskellige opgaver.

⚠️ Advarsel: En grænse, der er sat for højt, er det samme som ingen grænse – kortkøen og cyklustiden forlænges. En grænse, der er sat for lavt, efterlader folk inaktive. Skift grænsen for én kolonne ad gangen, og hold øje med cyklustiden i to uger.

Det er den sidste del af teorien; afsnittet nedenfor omsætter den til handling.

Sådan implementerer du Kanban trin for trin

Kanban er nemt at starte: trin et beskriver, hvad du allerede gør. Arbejd igennem denne sekvens med hele teamet til stede.

1. Kortlæg den aktuelle arbejdsgang. Gå et færdigt element baglæns gennem hver aflevering, det har passeret. Hver aflevering bliver til en kolonne, inklusive de ventetilstande, som ingen officielt ejer.
2. Tegn brættet. Én kolonne pr. stat, fra venstre mod højre, og slutter med Udført. En whiteboard med post-it-sedler er tilstrækkelig den første måned.
3. Skriv kortene. Giv hver genstand ombord et kort med prioritet, ejer, type og forfaldsdato, og placer den derefter i den kolonne, der matcher dens faktiske tilstand.
4. Definer "udført" for hver kolonne. Skriv exitkriterierne på tavlen. Denne praksis med eksplicitte politikker er det, der forhindrer kort i at hoppe baglæns.
5. Angiv indledende WIP-grænser. Vælg et startnummer for hver kolonne undtagen To-do og Færdig ved hjælp af en metode nedenfor, og skriv det derefter over overskriften.
6. Enig i pull-reglen. Ingen starter et nyt kort, mens deres kolonne er nået sin grænse; de ​​hjælper i stedet med at rydde kolonnen til højre for dem.
7. Gå på brættet dagligt. Gå fra højre mod venstre, med det ældste kort først, og spørg, hvad der blokerer dette kort, og hvem der kan fjerne blokeringen i dag.
8. Mål, og stram derefter. Efter to uger viser cyklustidsdata, hvilken kolonne der indeholder kort længst. Sænk denne grænse, eller tilføj kapacitet, og gentag derefter.

Det er i trin fem, at de fleste teams går i stå, så her er de tre størrelsesmetoder, som praktikere bruger:

Behandl det første tal som en hypotese. Par tavlen med formelt agile test forhindrer testkolonnen i at blive flaskehalsen, og de to tidspunkter nedenfor viser, om det virker.

Ledetid og cyklustid

I Kanban-metoden anvendes ledetid og cyklustid i vid udstrækning, men der er forskel på de to, og det er vigtigt at forstå det for at undgå forvirring.

Her er det også vigtigt at forstå ikke at medtage den tid, der går mellem klar til udgivelse og faktisk udgivelse.

Cycle Time = Work in Progress/Throughput

💡 Tip: Leveringstiden er, hvad kunden oplever; cyklustiden er, hvad teamet kontrollerer. Et stort hul betyder, at arbejdet venter i kø, før nogen starter det, så ret optagelsen, før du sætter fart på teamet.

I det ideelle scenarie bør forskellen mellem gennemløbstid og cyklustid være minimal, og Kanban bruger et kumulativt flowdiagram (CFD) til at måle historiske data for gennemløbs- og cyklustid. Dette diagram er emnet for næste afsnit.

Kumulativt flowdiagram (CFD)

CFD er et diagram, som er tilgængeligt i alle førende værktøjer til styring af arbejdsgange ligesom JIRA. Dette diagram måler det samlede antal arbejdskort/opgaver, der kom ind i arbejdsgangen og samlede fuldførte kort/opgaver over tid.

Det hjælper dig med at få et estimat af gennemsnitlig leveringstid og cyklustid for forudbestemt tid.

CFD-diagrammet giver dig indikatorer eller problemområder, du skal løse. Det giver dig et klart billede, og baseret på dette diagram kan du korrigere dit teams gennemløbstid og cyklustid. Det kumulative flowdiagram nedenfor viser hver tilstand som et farvet bånd; et bånd, der bliver ved med at udvide sig, er flaskehalsen.

Diagrammet læses gennem fire størrelser:

1. Leveringstid: Det er varigheden mellem et nyt korts ankomst til din arbejdsgang og dets endelige afgang fra arbejdsgangen.
2. Cyklustid: Det er en varighed mellem kortets ankomst i funktionstilstand og når kortet er klar til frigivelse.
3. WIP: Igangværende arbejde (WIP) begrænser den maksimale mængde af arbejdsemner i de forskellige stadier af arbejdsgangen.
4. gennemløb: Det er den faktiske ydeevne, og den fortæller det faktiske antal kort leveret i en given tidsramme.

Throughput = WIP/Cycle Time

Det dækker artefakter, mekanikker og metrikker. Det resterende spørgsmål er, hvordan Kanban klarer sig i forhold til Scrum.

Scrum vs. Kanban

Her er de vigtige forskelle mellem Scrum vs. KanbanFor et bredere billede, se Agile vs. Scrum.

Ofte Stillede Spørgsmål