Dagens softwareteam er i det mindste i deres processer mere smidige! De er villige til at tænke uden for sætte parametre for at følge, hvad der fungerer for dem. De er ivrige efter at lære og indføre nye teknikker til projektstyring og projektprocesser.
En projektstyringsmetode kaldet Kanban har foretaget runder i softwarebranchen i ganske mange år og har fået valuta i de sidste fem år. Sammen med Agile-metodologier har brugen af Kanban-metoden givet virksomhederne meget at fejre.
Men der er også kritik af, at Kanban ikke er andet end en glorificeret opgaveliste. Så hvad handler det om? Lad os finde ud af det.
Hvad er Kanban?
Hvis din virksomhed er klar til at gå videre end den traditionelle softwareprojektledelsesmetode, er der i dag ingen mangel på projektstyringsteknikker.
For det første er der Agile Project Management-systemet, der fokuserer på ikke-lineære, iterative metoder til softwareudvikling. Brug af agile metoder er tydeligt i Scrum, der fokuserer på en mere fleksibel tilgang til projektledelse.
Agile har også links til andre projektstyringsrammer som Kanban og Ekstrem Programmering. Af disse har Kanban opnået en masse popularitet. Hvem vil trods alt ikke have en proces udviklet af japanerne?
Kanban er et koncept, der udviklede sig i Toyota Manufacturing Plant for at opnå just-in-time-produktion (JIT), hvilket reducerer omkostningerne og muliggør mindre ressourceudnyttelse. I hjertet følger det “pull” -princippet om arbejde, hvilket betyder, at opgaver eller produkter skal "trækkes" af krav og efterspørgsel og ikke "skubbes" ovenfra og ned. Det blev udviklet for at sikre bedre lagerbeholdning af bilkomponenter i Toyota-fabrikker, baseret på efterspørgsel. Dette betød, at når efterspørgslen steg, ville anmodninger blive udfyldt.
Konceptet blev tilpasset softwarebranchen med et par ændringer af David Anderson i hans bog fra 2010, Kanban . Siden da er det blevet brugt til forskellige projekter med stor succes. Det kan være til stor hjælp i komplekse projekter, der har potentialet til at lide af overbelastning på den ene side af udviklingscyklussen.
Grundlæggende behandler Kanban-systemet softwareprojektprocessen som en pipeline. Lad os sige, at en softwareproces har tre typer opgaver: analyse, udvikling, test og til sidst implementering. Lad os sige, at der er tyve opgaver, der skal udføres.
I tilfælde af et traditionelt projektstyringssystem, hvis f.eks.
- Der er i alt 25 historier
- Analytikere er i stand til at håndtere fem historier om ugen
- Udviklere er i stand til at håndtere fem historier om ugen
- Testere er begrænset til tre historier om ugen
I denne situation hænger arbejdet simpelthen op ved testernes ende. I slutningen af uge 1 vil situationen være som følger:
- Kun tre historier er gået videre til implementering.
- Udviklere og analytikere arbejder på tre historier, da testere ikke er i stand til at tage udviklerens output og teste det samme.
- Arbejdet bliver stablet, hvilket efterlader udviklere og analytikere og projektlederen i en rettelse.
Analytikerne og udviklerne kan nu simpelthen vride tommelfingrene! Eller deres manager kan måske indse, at de er inaktive og omfordele dem til et andet projekt, hvor en lignende situation kan opstå. Så der er to projekter, der nu sidder fast i testfasen!
Problemerne i en sådan situation er ikke svære at se. Hvad er poenget med at udvikle ti historier (eller bits software), når de ikke snart skal testes?
Nu videre til Kanban-metoden.
Kanban-metoden er et ekstremt enkelt koncept. Det følger en simpel logik ved at bruge en "pull-metode" til først at fjerne flaskehalse og begrænse WIPs (Works in Progress) til bedre arbejdsprocesser.
I sin enkleste form hjælper Kanban bogstaveligt talt “visuelt bord” ved at “trække” genstande fra en opgaveliste i stedet for at arbejde med tidslinjer. Kanban-metoden hjælper med at identificere flaskehalse, så processflowet styres bedre.
Et grundlæggende Kanban-bord har en liste over opgaver, der skal udføres, igangværende opgaver og udførte opgaver.
I softwarestyring kan opgaverne imidlertid være lidt mere komplekse. De fleste Agile-projekter har også et lignende bord. I et Kanban-bord er trinnene i indsættelsen tydeligt markeret sammen med et nummer for hver søjle. Dette nummer repræsenterer det maksimale antal opgaver eller historier, som et bestemt trin kan håndtere.
Vores eksempel på et Kanban-bord ser sådan ud i begyndelsen af den anden uge. Dette betyder, at udviklere og analytikere ikke vil arbejde på det optimale antal historier den uge. Det ville være indlysende, at arbejdet er ved at blive stablet ved testers afslutning. Og organisationer kan sikre, at hold samarbejder for at få testen udført. Alternativt kan de se på andre modeller af processflow, så dette ikke sker.
Når projekter håndteres gennem Kanban-systemet, er der mindre plads til at blive stablet op. Historier optages i henhold til den maksimale tilgængelige båndbredde.
I en typisk Kanban-opsætning vil arbejde blive udført i overensstemmelse med den tilgængelige båndbredde, og arbejde trækkes ind af hold, så de altid har maksimal kapacitet. Systemet giver også mulighed for et hurtigt spor, til opgaver, der haster, så de bevæger sig gennem tavlen med mindst mulig indsats.
Se på dette Kanban-bord.
Det er tydeligt, at alle trin fungerer med maksimal effektivitet. Og den opgave, der er på ”Fast Track”, er også taget højde for.
Kanban er på ingen måde den eneste metode, der bruges til at øge effektiviteten ved at begrænse WIP. Der er andre systemer, der opnår det samme resultat - for eksempel CONWIP (Constant Works in Progress) og DBR (Drum-Buffer-Rope) -systemer, der primært er beregnet til fremstillingsindustrier.
Kanban er imidlertid det system, der er bedst modificeret til at passe til softwarebranchen.
Hvordan adskiller Kanban sig fra agile metodologier?
I hjertet er Kanban en metode, der bruger nogle elementer i Agile Project Management. Mange projekter i Agile-rammen har rødder i Lean-tilgange. Forskellen mellem Kanban-metodologi og Agile Project Management er ikke så sort / hvid, som fortalerne for de to metoder ville få os til at tro. De har mere til fælles end forskelle.
Den agile ramme er ikke en absolut. Spørgsmålet er ikke, om holdene er agile eller ej. Hold har ofte agility i forskellige grader. En af metoderne til at have mere smidighed i din softwareudviklingsproces er at bruge Kanban.
Der findes et par forskelle mellem Kanban- og Agile-metodologier. Nogle af funktionerne ved Kanban-udvikling, der adskiller sig lidt fra Agile, er:
- Tidslinjer er ikke en betydelig faktor . Dette er et hårdt koncept til at vikle vores hoveder rundt, da det forekommer meget ikke-intuitivt. ”Hvordan arbejder du uden tidsfrister?” Spørger folk ofte. Men hvis hvert medlem af teamet er engageret i hans / hendes maksimale effektivitet, ophører tiden med at være en faktor.
- Historier (opgaver) er større end i typiske agile systemer. Historiernes længde og kompleksitet er typisk længere end med et typisk Scrum-projekt. Da fokus ikke er på estimering af tid, men blot på at få processen til at gå videre, kan Kanban have råd til at arbejde på større historier.
- Der er ingen væsentlig ændring i eksisterende processer. Principperne for Kanban for softwareudvikling, som formuleret af dens grundlægger, David Anderson, i sin blog inkluderer følgende grundlæggende principper:
-
- Start med det, du gør nu
- Enig om at forfølge trinvise, evolutionære ændringer
- Respekter den aktuelle proces, roller, ansvar og titler
- Hver historie måles i cyklustid . Projektet evalueres ikke ved den traditionelle Agile beregning af hastighed (antallet af historier afsluttet i løbet af en given tid), men med cyklustid. Dette betyder, at Kanban lægger vægt på, hvor lang tid det tog at gennemføre en opgave. Du kan ofte se et ticker på mange Kanban-tavler, der nævner, hvor mange dage teamet tager for at afslutte en historie. Dette estimat feeds ind i den næste cyklus.
Kanban: Et bestyrelse, men hvad andet?
Så Kanban er et bestyrelse, der viser os, hvordan historierne er arrangeret - er det selv en så stor ting, spørger mange. Der er faktisk en hel del diskussioner om, hvad Kanban er og kan gøre.
Er Kanban bare en metode til at styre arbejdsgangen? Eller er det noget, man kan bruge sammen med Agile-metodologier for maksimal effektivitet? Eller kan det være en helt ny måde at styre workflow på?
Hvert hold bruger Kanban, som de finder passende, til deres særlige situation. Uanset hvad har Kanban potentialet til at fungere som en livsstil for softwareudvikling, hvis den bruges til sit optimale niveau.
Uanset om det bruges til at styre workflow eller som et nyt paradigme i softwareudvikling, benægter det ikke, at det hjælper med at styre WIP'er.
For at få Kanban til at fungere bedst, er det vigtigt at tænke på det, ikke bare som at styre WIP'er, men som en projektstyringsramme. Visse grundlæggende retningslinjer vil hjælpe processen med.
- Optimer holdene, så intet hold starter noget, de ikke kan afslutte. Dette hjælper processen sammen.
- Modstå ikke ændringer fra det originale Kanban-system. Hvis dit projekt klarer sig godt med frister og tidsplaner, skal du integrere det samme, som du ville. Dette skaber et sundere og mere robust udviklingsmiljø.
- Hold ikke sammen med teamarbejdet. Kanban kan virke som, men er ikke, en model baseret på personer, der arbejder isoleret. Teamarbejde skal være en integreret del af Kanban softwareudvikling.
- Tænke ud af boksen. Tænk på ændringer i arbejdsgangen. Mange teams vælger nu Test-Driven Development med Acceptance Test-Driven Development, hvor accepttestene udføres først med brugssager, som derefter driver de krævede funktioner og arten af udviklingen.
Hybrider
Da flere og flere virksomheder bruger projektstyringsværktøjer, der er bedst egnet til deres særlige situation, er det ikke overraskende, at to af de bedste projektstyringsmetoder: Scrum og Kanban, er blevet integreret til stor succes.
Hybriden, kaldet Scrumban, gør indblanding i mange projekter.
Hvis en organisation allerede bruger Scrum, men finder det vanskeligt at holde projektet sammen, enten med sprints, der ikke fungerer godt, til at teste ikke at være lufttætte, kan det være tid til at overveje Scrumban.
For at forklare det enkelt involverede Scrumban at tage et forstørrelsesglas til sprinterne. Det handler ikke kun om sprints som en del af projektet, det handler om hvad der sker inden for sprints. Scrumban hjælper med at undersøge, hvordan en historie bliver behandlet inden for en sprint, og det kan muligvis gøre hele forskellen.
Scrumban eller en hvilken som helst af dens varianter er en minimal ændring fra eksisterende praksis. Det smukke ved at bruge Kanban er, at det kan bruges med praktisk talt enhver form for projektstyringsmodel: vandfald, agile eller noget derimellem.
Kom godt i gang med Kanban
Det er let at komme i gang med Kanban-systemet. Det er også muligt at implementere Kanban på en minimal måde som en prøve for en bestemt del af et projekt.
- Kortlægge softwareudviklingsprocessen. Lav et klart kort over hele processen. Hvordan fungerer projektet - fra det oprindelige design, til udvikling, til test, til ændringer i funktioner, fungerer i virkeligheden?
- Liste ned trinene, hvor Kanban vil blive brugt. Brug de trin, der er helt under din kontrol. Dette omfatter typisk analyse, udvikling, gennemgang og testfaser.
- Arbejd med vigtige punkter såsom:
- Begrænsninger til de igangværende værker for hvert trin.
- Processer til fremskyndet / blokeret arbejde
- Back-of-the-kuvert-estimater med hensyn til cyklustid
- Hyppighed af Kanban-bestyrelsens / proces- / estimatgennemgang
- Køb et tavle og en stak med Post-It-noter.
- Kom igang
- Gennemgå efter behov.
- Gentage
Så gå videre og kom i gang med Kanban!
Vær ikke bange, hvis det ikke viser sig, som du oprindeligt havde til hensigt. Hele ideen bag Agile-metodologier er at imødekomme ændringer i mennesker og processer! Fortæl os om dine oplevelser med Kanban-metoden.
Anbefalede artikler
- 6 bedste hjælpsomme projektstyringskontor (PMO)
- 8 nyttige trin til at opbygge sofistikerede historiekort til dit projekt
- De 5 vigtige værdier ved ekstrem programmering (kraftfuld)