Close

kanban

Hoe de kanban-methodologie van toepassing is op softwareontwikkeling

Onderwerpen zoeken

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.

Jira-bord

Ga gratis aan de slag met de Jira kanban-sjabloon

Sjabloon gebruiken

Kanban-artikelen

[VERVOLG]

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

Kanban-bord | Atlassian agile coach

While the core principles of the framework are timeless and applicable to almost any industry, software development teams have found particular success with the agile practice. In part, this is because software teams can begin practicing with little to no overhead once they understand the basic principles. Unlike implementing kanban on a factory floor, which would involve changes to physical processes and the addition of substantial materials, the only physical things software teams need are a board and cards, and even those can be virtual.

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.

Agile kanban-bord | Atlassian agile coach

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.

Tip van pro's:

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.

Overlapping skill sets lead to smaller cycle times. When only one person holds a skill set, that person becomes a bottleneck in the workflow. So teams employ basic best practices like code review and mentoring help to spread knowledge. Shared skills mean that team members can take on heterogeneous work, which further optimizes cycle time. It also means that if there is a bottleneck of work, the entire team can swarm on it to get the process flowing smoothly again. For instance, testing isn't only done by QA engineers. Developers pitch in, too.

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.

Tip van pro's:

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.

Agile controlediagram | Atlassian agile coach

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.

Cumulatief stroomschema

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.

Jira-bord

Ga gratis aan de slag met de Jira kanban-sjabloon

Sjabloon gebruiken
Dan Radigan
Dan Radigan

Agile heeft een enorme impact op mij gehad, zowel op professioneel als persoonlijk vlak. Ik heb geleerd dat de beste ervaringen agile zijn, zowel in code als in het leven. Ik ben vaak te vinden bij alles wat te maken heeft met technologie, fotografie en motorrijden. 

Hierna
Borden