Kanban Model i Software Engineering

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.

Hvornår skal man bruge Kanban?

Her er grundene til at bruge Kanban-udviklingsmetoden:

• 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.

Kanban kort

Kanban-systemet anbefaler visualisering af arbejde. Det foreslår brugen af ​​den fysiske og den digitale tavle.

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 projektledelse bruger et pull-baseret system, når og når en udvikler er ledig, kan han/hun trække et kort fra to-do-kolonnen til dev-kolonnen.

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 sit korts tilstand, og hele teamet kan visualisere arbejdsgangen. Næste i denne Kanban-tutorial lærer vi om Kanban Workflow.

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.

Stater	Forståelse af opgaver
At gøre	Opgaver ankommer her for første gang i denne tilstand.
Klar til analyse	Analyser opgaven og tilføj krav fuldstændigt.
Klar til udvikling	Analyse afsluttet og udvikling kan starte.
I udviklingen	Opgaver er under udvikling.
Klar til test	Udvikling afsluttet, og nu kan test starte.
I testen	Opgaverne afprøves.
Klar til udgivelse	Test afsluttet; frigivelse kan ske.
Frigivet/Udført	Udgivet.

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 rigtige hastighed for holdet. Med den rigtige hastighed på plads vil holdet præstere bedre.

Ledetid og cyklustid

I Kanban-metoden er ledetid og cyklustid meget brugt, der er forskel på de to, og det er vigtigt at forstå det for at undgå forvirringen.

Leveringstid	Cyklustid
Ledetid måles som tiden mellem opgavens ankomst i din arbejdsgang og dens afgang fra arbejdsgangen, hvilket betyder, at den er blevet frigivet.	Cyklustiden måles som tiden mellem opgavens ankomst i tilstanden "i gang" og ankomsten af ​​opgaven i "klar til frigivelse".

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

I det ideelle scenarie bør kløften mellem ledetid og cyklustid være minimal, og Kanban bruger et kumulativt flowdiagram (CFD) til at måle historiske data for lead og cyklustid.

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-diagram vil give dig indikatorer eller problemområder, du skal rette. Det vil give dig et klart billede og baseret på dette diagram. Du kan rette dit teams gennemløbstid og cyklustid.

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.

Gennemløb = WIP/cyklustid

Begrænsning af WIP (igangværende arbejde)

I Kanban udviklingsmetodologi begrænser WIP antallet af opgaver/kort, som kan arbejdes med af et teammedlem eller hele på én gang.

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 hjælper med at bevæge arbejdsgangen, og opgaver bliver ved med at bevæge sig.
• Det hjælper også med at løse blokeringer, da en person ikke skifter mellem forskellige opgaver.

Scrum vs. Kanban

Her er de vigtige forskelle mellem Scrum vs. Kanban

Scrum	Kanban
Scrum lægger vægt på planlægning. Det starter med sprintplanlægning og ender med sprint retrospektiv. Der afholdes mange møder, som er med til at sikre, at holdet er på linje med de næste trin, prioriteter og erfaringer fra tidligere sprints.	Kanban er åben for at foretage ændringer på farten. Det betyder, at der er mindre stivhed og ting kan ændre sig ofte.
Det anbefaler indsamling af tidsmålinger lavet under spurter	Kanban anbefaler grafer for at få et overblik over teamets fremskridt over tid.
Scrum ikke længere beder om et tilsagn fra teams. I stedet handler det om sprintmålene og prognoserne.	Kanban er afhængig af tidsboksning og prognoser.
Det lægger vægt på planlægning og så estimering spiller en meget vigtig rolle i Scrum	Kanban har ingen obligatoriske krav til estimering.
Hver individet har sin rolle og ansvar.	Ingen sæt roller så fleksibilitet med hensyn til individuelt ansvar.
Gentagelserne/Sprints er faste i varighed. Denne varighed varierer fra 2 uger til 1 måned.	Kanban er ikke baseret på varighed. Denne ting måles med hensyn til cyklustider.
Holdene er forpligtet til at forpligte sig en bestemt mængde arbejde.	Engagement er ikke nødvendigt det er valgfrit for hold.
I denne metode tværgående teams er vigtige, da de kan håndtere enhver forstyrrelse, der kan forårsage en flaskehals i softwareudviklingen.	Under specialiseret team er vigtigt.
Det er ikke muligt at tilføje varer til løbende iterationer.	Ny elementer kan nemt tilføjes hvis den ekstra kapacitet er tilgængelig.
Et sprintefterslæb ejes kun af en enkelt hold.	Flere holds kan dele Kanban bord.
Leverancer er bestemt af spurter, som et sæt arbejde skal være afsluttet og klar til gennemgang.	Produkter og processer er leveret løbende på et nødvendigt grundlag. Så test- og gennemgangsprocessen fortsætter samtidigt.
Scrum software udviklingsmetode fokuserer på efterslæbet.	Kanban metode helt fokuserer på proces dashboard.
Hver teammedlem har en bestemt rolle i Scrum master bestemmer tidslinjer, produktejer sætter mål og mål, og teammedlemmer udfører udviklingsarbejdet.	Der er ingen foruddefinerede roller for et team. Der kan dog stadig være en projektleder; teamet opfordres til at samarbejde og arbejder sammen.
Bedste til projekter med skiftende prioriteter.	Ideel til hold med stabile prioriteter som næppe ændrer sig over tid.
Måler produktionen ved hjælp af hastighed gennem spurter.	Måler produktionen vha cyklustid eller den nøjagtige tid, det tager at fuldføre et helt stykke af et projekt.
Scrum kræver en fuldstændig skift fra den traditionelle model til Agile Scrum-modellen, der ville blive implementeret i projektet.	Kanban tillader ikke drastiske ændringer i projektet.
Det er en ideel metode til projekter med vidt forskellige prioriteter.	Bedste velegnet til hold med stabile prioriteter.
I Scrum er hele team fokuserer på at samarbejde og fuldføre opgaven at levere kvalitetsudviklingsarbejde.	Teams arbejder for at nå mål og reducere tiden til at fuldføre hele processen. Reduktion i tidscyklussen er således den største indikator for succes her.
Scrum vægt på sine tidsplaner; nye elementer kan ikke tilføjes til igangværende iterationer.	Kanban er mere iterativ af natur som den har ikke specifikke tidsrammer. Så nye varer kan løbende tilføjes, når der er yderligere kapacitet til rådighed.
Det samlede arbejde udføres i partier/Sprints.	Hele projektet udføres på bevægelse af enkelttrådet arbejdsemne strømme.
Scrum master fungerer som en problemløser.	Kanban opfordrer hvert teammedlem er en leder og dele ansvaret mellem dem alle.
Scrum foreskriver time-boxede iterationer.	Kanban fokuserer på planlægger en anden varighed til individuel iteration.
Scrum hjælper virksomheder med at spare tid og penge.	Kanban metode fokus på løbende forbedringer, produktivitet og effektivitet.
opnå stabil og konsekvent kommunikation præstation på alle niveauer.	Teammedlemmer er mere tilbøjelige til at nå deres mål meget lettere på grund af den visuelle karakter af Kanban-tavler.
Projekt er kodet og testet under spurten gennemgå	Teammedlemmer er mere tilbøjelige til at nå deres mål meget lettere på grund af den visuelle karakter af Kanban-tavler.
Det er nemmere at tilpasse sig de konstante ændringer på grund af de korte spurter og regelmæssig feedback.	Det er designet til et regelmæssigt, stabilt output, kan store ændringer i kundernes efterspørgsel få Kanban til at mislykkes.
De samlede omkostninger ved projektet er minimale, hvilket kan føre til hurtigere og billigere resultat.	Hvis en opgave ikke er korrekt estimeret, skal den samlede projektomkostninger vil aldrig være nøjagtige. I sådanne tilfælde kan opgaven fordeles over flere spurter.
Denne metode kræver erfarne teammedlemmer kun. Så hvis teamet består af folk, der ikke er eksperter, kan projektet ikke afsluttes i tide.	Ingen specifikke tidsrammer er allokeret med hver fase, så teammedlemmer aldrig får en idé om, hvor meget tid de kan tage i hver fase.
I denne Agile Scrum-metode er det nemmere at levere et kvalitetsprodukt på et aftalt tidspunkt.	Den er designet til en regelmæssigt, stabilt output, store ændringer i kundernes efterspørgsel kan få Kanban til at falde.
projektplan vil aldrig forstyrre også selvom et teammedlem forlader holdet.	Hvis nogen af ​​teammedlemmerne forlader under udviklingen, kan det skade projektudviklingen.
Daglige møder nogle gange frustrere teammedlemmer.	Forældet Kanban-tavle kan føre til problemer i udviklingsprocessen.
Store projekter kan nemt opdeles ind i let overskuelige spurter.

Resumé

• Kanban definition: Kanban er defineret som en agil udviklingsmetodologi til at udvikle software, biler, varer, medicin, sko eller ethvert andet produktionsarbejde.
• Kanban bruger Kanban-tavlen til at visualisere arbejdet. Den bruger kolonner som stadier (to-do, dev, test osv.) og kort som et arbejdsemne.
• Kanban-metoden understøtter den fysiske og digitale tavle til visualisering.
• Kanban er et pull-baseret system, og kort trækkes fra den forrige fase til de nuværende stadier af teammedlemmer.
• Kanban-metoden bruger CFD-diagrammet til at forstå teamets gennemløbstid og cyklustid. Dette diagram hjælper holdene med at rette kløften mellem disse to tidspunkter og forbedre effektiviteten.
• Kanban udviklingsmetodologi, WIP begrænser antallet af opgaver/kort, som kan arbejdes med af et teammedlem eller hele på én gang.
• WIP begrænser skifter fokus på at få tingene gjort, da en person fokuserer på en enkelt opgave ad gangen.