Delen via

Wat is Kanban?

Kanban is een Japanse term die signboard of reclamebord betekent. Een industriële ingenieur genaamd Taiichi Ohno ontwikkelde Kanban bij Toyota Motor Corporation om de productie-efficiëntie te verbeteren.

Hoewel Kanban is gemaakt voor productie, deelt softwareontwikkeling veel van dezelfde doelstellingen, zoals toenemende stroom en doorvoer. Softwareontwikkelingsteams kunnen hun efficiëntie verbeteren en sneller waarde leveren aan gebruikers met behulp van Kanban-richtlijnen en -methoden.

Afbeelding van personen die Kanban-borden gebruiken.

Kanbanprincipes

Het aannemen van Kanban vereist naleving van enkele fundamentele procedures die kunnen verschillen van de vorige methoden van teams.

Werk visualiseren

Het kan lastig zijn om inzicht te krijgen in de status van het ontwikkelteam en de voortgang van het werk. Werkvoortgang en huidige status zijn gemakkelijker te begrijpen wanneer ze visueel worden weergegeven in plaats van als een lijst met werkitems of een document.

Visualisatie van werk is een belangrijk principe dat Kanban voornamelijk via Kanban-borden aanpakt. Deze borden gebruiken kaarten die zijn ingedeeld op voortgang om de algehele status te communiceren. Het visualiseren van werk als kaarten in verschillende statussen op een bord helpt gemakkelijk het grote beeld te zien van waar een project zich momenteel bevindt, en potentiële knelpunten te identificeren die van invloed kunnen zijn op de productiviteit.

Diagram met een Kanbanbord.

Een pull-model gebruiken

In het verleden hebben belanghebbenden functionaliteit aangevraagd door werk naar ontwikkelteams te pushen, vaak met strakke deadlines. Kwaliteit leed wanneer teams shortcuts moesten nemen om de functionaliteit binnen het tijdsbestek te leveren.

Kanban richt zich op het handhaven van een overeengekomen kwaliteitsniveau waaraan moet worden voldaan voordat het werk wordt overwogen. Om dit model te ondersteunen, pushen belanghebbenden geen werk naar teams die al op capaciteit werken. In plaats daarvan voegen belanghebbenden verzoeken toe aan een backlog die een team in hun workflow opneemt zodra er capaciteit beschikbaar is.

Een WIP-limiet opleggen

Teams die te veel tegelijk aan te veel dingen proberen te werken, kunnen te maken krijgen met een verminderde productiviteit als gevolg van frequente en dure contextwisselingen. Het team is druk, maar het werk wordt niet gedaan, wat leidt tot onaanvaardbare hoge doorlooptijden. Door het aantal achterstandsitems te beperken waar een team tegelijkertijd aan kan werken, kunt u de focus vergroten terwijl contextwisseling wordt verminderd. De items waar het team momenteel aan werkt, worden werk in uitvoering (WIP) genoemd.

Teams bepalen een WIP-limiet of het maximum aantal items waaraan ze tegelijk kunnen werken. Een goed gedisciplineerd team zorgt ervoor dat de WIP-limiet niet wordt overschreden. Als teams hun WIP-limieten overschrijden, onderzoeken ze de reden en werken ze om de hoofdoorzaak aan te pakken.

Continue verbetering meten

Om continue verbetering te oefenen, hebben ontwikkelteams een manier nodig om de effectiviteit en doorvoer te meten. Kanbanborden bieden een dynamische weergave van de statussen van werk in een werkstroom, zodat teams kunnen experimenteren met processen en de impact op werkstromen gemakkelijker kunnen evalueren. Teams die Kanban omarmen voor continue verbetering, gebruiken metingen zoals doorlooptijd en cyclustijd.

Kanbanborden

Het Kanban-bord is een van de hulpprogramma's die teams gebruiken om Kanban-procedures te implementeren. Een Kanbanbord kan een fysiek bord of een softwaretoepassing zijn waarin kaarten worden weergegeven die in kolommen zijn gerangschikt. Typische kolomnamen zijn Te doen, Bezig en Gereed, maar teams kunnen de namen aanpassen aan hun werkstroomstatus. Een team kan bijvoorbeeld liever Nieuwe, Ontwikkeling, Testen, UAT en Gereed gebruiken.

Op softwareontwikkeling gebaseerde Kanbanborden geven kaarten weer die overeenkomen met productachterstanditems. De kaarten bevatten links naar andere items, zoals taken en testcases. Teams kunnen de kaarten aanpassen om informatie op te nemen die relevant is voor hun proces.

Schermopname van een Kanban-bord voor softwareontwikkeling.

Op een Kanbanbord is de WIP-limiet van toepassing op alle kolommen in uitvoering. WIP-limieten zijn niet van toepassing op de eerste en laatste kolommen, omdat deze kolommen werk vertegenwoordigen dat niet is gestart of voltooid. Kanbanborden helpen teams binnen WIP-limieten te blijven door de aandacht te vestigen op kolommen die de limieten overschrijden. Teams kan vervolgens een actie uitvoeren om het knelpunt te verwijderen.

Cumulatieve stroomdiagrammen

Een veelvoorkomende aanvulling op kanbanborden op basis van softwareontwikkeling is een grafiek die een cumulatief stroomdiagram (CFD) wordt genoemd. De CFD illustreert het aantal items in elke staat in de loop van de tijd, meestal over enkele weken. Op de horizontale as wordt de tijdlijn weergegeven, terwijl op de verticale as het aantal productachterstanditems wordt weergegeven. Gekleurde gebieden geven de statussen of kolommen aan waarin de kaarten zich momenteel bevinden.

De CFD is vooral nuttig voor het identificeren van trends in de loop van de tijd, waaronder knelpunten en andere onderbrekingen in de voortgangssnelheid. Een goede CFD toont een consistente opwaartse trend terwijl een team aan een project werkt. De gekleurde gebieden in de grafiek moeten grofweg parallel zijn als het team binnen de WIP-limieten werkt.

Afbeelding van een cumulatief stroomdiagram.

Een bult in een of meer gekleurde gebieden duidt meestal op een knelpunt of belemmering in de stroom van het team. In de volgende CFD is het voltooide werk in groen vlak, terwijl de teststatus in blauw groeit, waarschijnlijk vanwege een knelpunt.

Afbeelding van een knelpunt in een cumulatief stroomdiagram.

Kanban en Scrum in Agile-ontwikkeling

Hoewel scrum en Kanban breed passen onder de paraplu van Agile-ontwikkeling, zijn Scrum en Kanban heel anders.

  • Scrum richt zich op sprints met vaste lengte, terwijl Kanban een doorlopend stroommodel is.
  • Scrum heeft rollen gedefinieerd, terwijl Kanban geen teamrollen definieert.
  • Scrum maakt gebruik van snelheid als een belangrijke metrische waarde, terwijl Kanban de cyclustijd gebruikt.

Teams nemen vaak aspecten van zowel Scrum als Kanban in gebruik om ze zo effectief mogelijk te laten werken. Ongeacht welke kenmerken ze kiezen, kunnen teams altijd beoordelen en aanpassen totdat ze de beste pasvorm vinden. Teams moeten eenvoudig beginnen en het belang van het regelmatig leveren van waarde aan gebruikers niet verliezen.

Kanban met GitHub

GitHub biedt een Kanban-ervaring via projectborden (klassiek).< Deze borden helpen u bij het organiseren en prioriteren van werk voor specifieke functieontwikkeling, uitgebreide roadmaps of releasecontrolelijsten. U kunt projectborden (klassiek) automatiseren om de kaartstatus te synchroniseren met gekoppelde problemen en pull-aanvragen.

Kanban met Azure Boards

Azure Boards biedt een uitgebreide Kanban-oplossing voor DevOps-planning. Azure Boards heeft een diepgaande integratie in Azure DevOps en kan ook deel uitmaken van de integratie van Azure Boards-GitHub.

  • Last updated on