kanban
Hoe de kanban-methodologie van toepassing is op softwareontwikkeling
Ga gratis aan de slag met de kanban-sjabloon van Jira
Maximaliseer de efficiëntie door het belangrijkste werk te zien en in beweging te houden.
Wat is kanban?
Kanban is een populair framework dat wordt gebruikt om agile en DevOps-softwareontwikkeling te implementeren. Hier is communicatie in realtime voor nodig over capaciteit evenals volledige transparantie van het werk. Werkitems worden op een visuele manier vertegenwoordigd op een kanban-bord, waardoor teamleden op elk moment de status van elk onderdeel van het werk kunnen zien.
Kanban-artikelen
Ontdek kanban met Jira Software
Stapsgewijze instructies voor het aansturen van een kanban-project, het prioriteren van je werk, het visualiseren van de workflow en het minimaliseren van werk in uitvoering met Jira Software.
Probeer deze tutorialVan 'Te doen' naar 'Gereed' met Jira-kanban-borden
Het kanban-bord van Jira Software is ontworpen om teams te helpen de cyclustijd continu te verbeteren en de efficiëntie te verhogen.
Probeer het gratisKanban is enorm prominent aanwezig onder de agile- en DevOps-softwareteams van vandaag, maar de kanban-methodologie van het werk dateert van meer dan 50 jaar geleden. Eind jaren veertig begon Toyota zijn engineeringprocessen te optimaliseren op basis van hetzelfde model dat supermarkten gebruikten om hun winkelvoorraad aan te vullen. Supermarkten hebben net genoeg producten op voorraad om aan de vraag van de consument te voldoen, een praktijk die de stroom tussen de supermarkt en de consument optimaliseert. Omdat voorraadniveaus overeenkomen met consumptiepatronen, neemt de efficiëntie van supermarkten aanzienlijk toe bij het voorraadbeheer doordat de hoeveelheid overtollige voorraad die op elk moment beschikbaar moet zijn, kan worden verminderd. Ondertussen kan de supermarkt er nog steeds voor zorgen dat het gegeven product dat een consument nodig heeft altijd op voorraad is.
Toen Toyota hetzelfde systeem in de fabrieken ging toepassen, was het doel om hun enorme voorraadniveaus beter af te stemmen op het werkelijke verbruik van materialen. Om capaciteitsniveaus in realtime op de fabrieksvloer (en aan leveranciers) te communiceren, zouden werknemers een kaart of 'kanban' doorgeven tussen teams. Op het moment dat het laatste onderdeel werd gepakt uit een bak met materialen die in de productielijn werden gebruikt, werd er een kanban doorgegeven aan het magazijn waarin werd beschreven welk materiaal nodig was, de exacte hoeveelheid van dit materiaal, enzovoort. Het magazijn had al een nieuwe bak met dit materiaal klaarstaan, die vervolgens naar de fabrieksvloer werd getransporteerd. Daarna stuurde ze zelf een kanban naar de leverancier voor een nieuwe levering. De leverancier had ook een bak van dit specifieke materiaal klaarstaan, die dan naar het magazijn van Toyota werd verzonden. Hoewel de signaleringstechnologie van dit proces sinds de jaren veertig is geëvolueerd, wordt de kern ervan nog steeds gevormd door ditzelfde JIT-productieproces (Just In Time).
Kanban voor softwareteams
Agile softwareontwikkelingsteams kunnen tegenwoordig dezelfde JIT-principes gebruiken door de hoeveelheid werk in uitvoering (WIP) af te stemmen op de capaciteit van het team. Dit geeft teams meer flexibele planningsopties, snellere output, duidelijkere focus, en transparantie gedurende de hele ontwikkelingscyclus.

Hoewel de kernprincipes van het framework tijdloos en van toepassing zijn op bijna elke branche, zijn het met name softwareontwikkelingsteams die bijzonder succesvol zijn geweest met de agile aanpak. Voor een deel komt dit omdat softwareteams aan de slag kunnen met weinig tot geen overhead zodra ze de basisprincipes begrijpen. In tegenstelling tot het implementeren van kanban op een fabrieksvloer, wat veranderingen in fysieke processen en de toevoeging van substantiële materialen met zich meebrengt, zijn de enige fysieke dingen die een softwareteam nodig heeft een bord en kaarten, en zelfs die kunnen virtueel zijn.
Kanbanborden
Het werk van alle kanban-teams draait om een kanban-bord, een hulpmiddel dat wordt gebruikt om werk te visualiseren en de stroom van het werk binnen het team te optimaliseren. Hoewel fysieke borden populair zijn bij sommige teams, zijn virtuele boards een cruciale hulpmiddel in elke tool voor agile softwareontwikkeling vanwege hun traceerbaarheid, eenvoudigere samenwerking en toegankelijkheid vanaf meerdere locaties.
Ongeacht of het bord van een team fysiek of digitaal is, hebben ze als functie om ervoor te zorgen dat het werk van het team wordt gevisualiseerd, hun workflow wordt gestandaardiseerd en alle blockers en afhankelijkheden onmiddellijk worden geïdentificeerd en afgesloten. Een eenvoudig kanban-bord is een workflow die uit drie stappen bestaat: Te doen, In uitvoering en Gereed. Afhankelijk van de grootte, structuur en doelstellingen van een team, kan de workflow echter in kaart worden gebracht om te voldoen aan het unieke proces van een bepaald team.
De kanban-methodologie is gebaseerd op volledige transparantie van het werk en realtime communicatie van capaciteit. Daarom moet een kanban-bord worden gezien als de 'Single Source Of Truth' ofwel de enige bron van waarheid voor het werk van het team.

Kanban-kaarten
De letterlijke vertaling van 'kanban' uit het Japans is 'visueel signaal'. Voor kanban-teams wordt elk werkitem weergegeven als een aparte kaart op het bord.
Het belangrijkste doel van het voorstellen van werk als een kaart op het kanban-bord is om teamleden in staat te stellen de voortgang van het werk door de workflow op een zeer visuele manier te volgen. Kanban-kaarten bevatten kritische informatie over dat specifieke werkitem, waardoor het hele team volledig inzicht krijgt in wie verantwoordelijk is voor dat werk, een korte beschrijving van de taak die wordt uitgevoerd, hoe lang dat stuk werk naar schatting duurt, enzovoort. Kaarten op virtuele kanban-borden bevatten vaak ook screenshots en andere technische details die waardevol zijn voor de uitvoerder. Teamleden de mogelijkheid bieden om op ieder moment de status van werkitems te zien, evenals alle bijbehorende details, zorgt voor meer focus, volledige traceerbaarheid en snelle identificatie van blockers en afhankelijkheden.
De voordelen van kanban
Kanban is een van de populairste methodologieën voor softwareontwikkeling die tegenwoordig door agile teams worden gebruikt. Kanban biedt verschillende extra voordelen voor taakplanning en doorvoer voor teams van elke omvang.
Flexibiliteit bij planning
Een kanban-team is alleen gericht op het werk dat in uitvoering is. Zodra het team een werkitem heeft voltooid, pakken ze het volgende werkitem dat bovenaan de backlog staat. De producteigenaar kan werk in de backlog een andere prioriteit geven zonder het team te verstoren, omdat wijzigingen buiten de huidige werkitems geen invloed hebben op het team. Zolang de producteigenaar de belangrijkste werkitems bovenaan de backlog houdt, weet het ontwikkelingsteam dat ze maximale waarde terugleveren aan het bedrijf. Er is dus geen behoefte aan iteraties met een vaste lengte zoals in scrum.
Slimme producteigenaren overleggen altijd met het ontwikkelingsteam wanneer ze wijzigingen in de backlog overwegen. Als userstories 1-6 bijvoorbeeld in de backlog staan, kan de schatting van userstory 6 gebaseerd zijn op de voltooiing van gebruikersverhalen 1-5. Het is altijd een goede gewoonte om wijzigingen kort te sluiten met het engineeringteam om vervelende verrassingen te voorkomen.
Kortere tijdcycli
Cyclustijd is een belangrijke statistiek voor kanban-teams. Cyclustijd is de hoeveelheid tijd die een eenheid werk nodig heeft om door de workflow van het team te reizen - vanaf het moment dat het werk begint tot het moment dat het wordt geleverd. Door de cyclustijd te optimaliseren, kan het team vol vertrouwen de levering van toekomstig werk voorspellen.
Overlappende skillsets leiden tot minder lange cyclustijden. Wanneer slechts één persoon een set vaardigheden bezit, wordt die persoon een knelpunt in de workflow. Teams gebruiken daarom eenvoudige best practices zoals codereview en mentoring om de aanwezige kennis te verspreiden. Gedeelde vaardigheden betekenen dat teamleden heterogeen werk kunnen aannemen, wat de cyclustijd verder optimaliseert. Het betekent ook dat als er een knelpunt is, het hele team kan meewerken om het proces weer soepel te laten verlopen. Testen wordt bijvoorbeeld niet alleen gedaan door QA-engineers. Ontwikkelaars helpen hier ook een handje.
In een kanban-framework is het de verantwoordelijkheid van het hele team om ervoor te zorgen dat het werk soepel verloopt tijdens het hele proces.
Minder knelpunten
Multitasking is funest voor de efficiëntie. Hoe meer werkitems er op een bepaald moment actief zijn, hoe meer contextomschakeling er nodig is, wat het pad naar voltooiing belemmert. Daarom is een belangrijk principe van kanban het beperken van de hoeveelheid werk in uitvoering (WIP). Limieten voor werk in uitvoering benadrukken knelpunten en achterstanden in het proces van het team als gevolg van gebrek aan focus, mensen of vaardigheden.
Een doorsnee softwareteam kan bijvoorbeeld vier workflowtoestanden hanteren: Te doen, In uitvoering, Codebeoordeling en Gereed. Ze kunnen ervoor kiezen om een WIP-limiet van 2 in te stellen voor werkitems met de status Codebeoordeling. Dat lijkt misschien een lage limiet, maar daar is een goede reden voor: ontwikkelaars schrijven vaak liever nieuwe code, in plaats van tijd te besteden aan het beoordelen van het werk van iemand anders. Een lage limiet moedigt het team aan om speciale aandacht te besteden aan problemen in de beoordelingsstatus en om het werk van anderen te herzien voordat ze hun eigen codebeoordelingen verhogen. Dit verkort uiteindelijk de totale cyclustijd.
Visuele statistieken
Een van de kernwaarden is een sterke focus op het continu verbeteren van de efficiëntie en effectiviteit van het team bij elke iteratie van het werk. Diagrammen bieden een visueel mechanisme voor teams om ervoor te zorgen dat ze blijven verbeteren. Wanneer het team gegevens kan zien, is het gemakkelijker om knelpunten in het proces te herkennen (en weg te nemen). Twee rapporten die veel worden gebruikt door kanban-teams, zijn controlediagrammen en cumulatieve stroomdiagrammen.
Een controlediagram toont de cyclustijd voor elke issue en een voortschrijdend gemiddelde voor het team.
Het doel van het team is om de hoeveelheid tijd te verminderen die een issue nodig heeft om het hele proces te doorlopen. Het zien van de gemiddelde cyclustijddaling in het controlediagram is een indicator van succes.
Een cumulatief stroomdiagram toont het aantal issues in elke toestand. Het team kan gemakkelijk blokkades zien aan de hand van het aantal issues dat in een bepaalde toestand is toegenomen. Problemen met tussenliggende toestanden zoals 'In uitvoering' of 'Wordt beoordeeld' worden nog niet aan klanten geleverd en een blokkering in deze toestanden kan de kans op ernstgige integratieconflicten vergroten wanneer het werk stroomopwaarts wordt samengevoegd.
Continue levering
Continue levering (CD) is de praktijk van het regelmatig vrijgeven van werk aan klanten. Continue integratie (CI) is de praktijk van het automatisch bouwen en incrementeel testen van code gedurende de dag. Samen vormen ze een CI/CD-pipeline die essentieel is voor ontwikkelingsteams (vooral voor DevOps-teams) om software sneller te leveren en tegelijkertijd een hoge kwaliteit te garanderen.
Kanban en CD vullen elkaar prachtig aan omdat beide technieken zich richten op de just-in-time (en een voor een) levering van waarde. Hoe sneller een team innovatie op de markt kan brengen, hoe competitiever hun product op de markt zal zijn. En kanban-teams richten zich precies daarop: het optimaliseren van de werkstroom naar klanten
Scrum vs. Kanban
Kanban en scrum delen enkele van dezelfde concepten, maar hebben heel verschillende benaderingen. Ze moeten dan ook niet met elkaar worden verward.
Scrum | kanban | |
Cadans | Regelmatige sprints met vaste lengte (2 weken) | Continue flow |
Releasemethodologie | Aan het einde van elke sprint, indien goedgekeurd door de producteigenaar | Continue levering of naar eigen oordeel van het team |
Rollen | Producteigenaar, scrummaster, ontwikkelingsteam | Geen bestaande rollen. Sommige teams roepen de hulp in van een agile coach. |
Belangrijkste statistieken | Snelheid | Cyclustijd |
Veranderingsfilosofie | Teams moeten ernaar streven om tijdens de sprint geen wijzigingen aan te brengen in de sprintvoorspelling. Als dat wel gebeurt, worden de inzichten over schattingen in gevaar gebracht. | Verandering kan op elk moment plaatsvinden |
Sommige teams conbineren de idealen van kanban en scrum in 'scrumban'. Ze gebruiken bijvoorbeeld sprints met vaste lengte en rollen uit scrum en de focus op WIP-limieten (werk in uitvoering) en de cyclustijd uit kanban. Voor teams die net beginnen met agile, raden we echter ten zeerste aan om de ene of de andere methodologie te kiezen en er een tijdje mee te experimenteren. Je kunt altijd later nog je voorkeur uitspreken.
Ga gratis aan de slag met de Jira kanban-sjabloon
Maximaliseer de efficiëntie door het belangrijkste werk te zien en in beweging te houden.
Klaar om aan de slag te gaan?
Stapsgewijze instructies voor het aansturen van een kanban-project, het prioriteren van je werk, het visualiseren van de workflow en het minimaliseren van werk in uitvoering met Jira Software.
Lees deze tutorialAgile ontwerp: proces en richtlijnen voor collaboratief ontwerp
Bij collaboratief ontwerp wordt iteratie toegepast op een productontwerp door aan het begin van een project de perspectieven van de klanten en ontwikkelaars te zoeken. Lees meer informatie.
Lees dit artikel