Close

kanban

Hoe de kanban-methodologie van toepassing is op softwareontwikkeling

Onderwerpen zoeken
Jira-bord

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.

Sjabloon gebruiken

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

[VERVOLG]

Softwareontwikkeling optimaliseren met Kanban Flow

Kanban Flow is de basis van agile- en DevOps-methodologieën en verhoogt de efficiëntie door probleemloze taakvoortgang te integreren met gevisualiseerde workflows. Kanban Flow is een afspiegeling van het vereenvoudigde voorraadbeheer van supermarkten. Het zorgt ervoor dat taken precies in het ontwikkelingsproces worden verwerkt wanneer dat nodig is.

Taken worden op Kanban-borden weergegeven in de vorm van kaarten. Dit maakt het mogelijk om de voortgang op een transparante manier bij te houden en knelpunten snel te identificeren. Door het werk in uitvoering (WIP) te beperken, optimaliseren teams de toewijzing van resources en zorgen ze voor een stabiele workflow. De focus van Kanban op continue verbetering wordt mogelijk gemaakt door statistieken zoals controlediagrammen en cumulatieve stroomdiagrammen. Hierdoor kunnen teams hun workflows iteratief verfijnen.

Op het gebied van softwareontwikkeling bevordert Kanban Flow dynamisch taakbeheer, versnelt het de leveringscycli en verhoogt het de klanttevredenheid door teamleden geconcentreerd, ononderbroken te laten werken. In wezen belichaamt Kanban Flow efficiëntie, een harmonieuze mix van transparantie, aanpassingsvermogen en continue verbetering. Hierbij wordt het potentieel van agile-methodologieën volledig benut.

Structureer je Kanban-flow

Het ontwikkelen van een gestructureerde Kanban-flow binnen je softwareontwikkelingsteam is essentieel voor een effectieve implementatie van Kanban. Dit zorgt voor een soepele voortgang van taken en een geoptimaliseerd workflowbeheer. Zo kun je je Kanban-flow structureren:

Visualiseer de workflow: Begin met het visualiseren van de workflow van je team op een Kanban-bord. Het bord, fysiek of virtueel, moet elke fase van het ontwikkelingsproces weergeven, van het begin tot de voltooiing van de taak.

Standaardiseer de workflow: Definieer en standaardiseer de fasen van de workflow op basis van de processen en vereisten van je team. Veelgebruikte stappen zijn onder meer 'Te doen', 'In uitvoering' en 'Gereed', maar pas ze zo nodig aan om jouw unieke workflow weer te geven.

Identificeer blockers en afhankelijkheden: Zorg ervoor dat je Kanban-bord directe identificatie van blockers en afhankelijkheden mogelijk maakt. Deze transparantie zorgt voor snelle oplossingen en voorkomt onderbrekingen van de workflow.

Stel WIP-limieten in (werk in uitvoering): Implementeer WIP-limieten voor elke fase van de workflow om overbelasting te voorkomen en om een stabiele workflow te handhaven. WIP-limieten helpen de toewijzing van resources te optimaliseren en multitasking te verminderen, wat een hogere productiviteit bevordert.

Stimuleer samenwerking: Stimuleer een samenwerkingscultuur binnen je team, waarbij leden gezamenlijk knelpunten aanpakken en samenwerken om te zorgen voor een soepele voortgang van de workflow. Deze gezamenlijke aanpak bevordert de efficiëntie en versnelt de voltooiing van taken.

Gebruik kanban-kaarten: Geef elke taak weer als een kanban-kaart op het bord, met essentiële informatie zoals de beschrijving van de taak, de uitvoerder en de geschatte voltooiingstijd. Kanban-kaarten maken het mogelijk om de voortgang van taken visueel bij te houden en de transparantie binnen het team te bevorderen.

Door je kanban-flow op deze manier te structureren, kun je je softwareontwikkelingsprocessen vereenvoudigen, de samenwerking tussen teams verbeteren en de efficiëntie van taakbeheer maximaliseren.

De oorsprong van Kanban ontdekken

Hoewel Kanban prominent aanwezig is onder de agile- en DevOps-softwareteams van vandaag, is de Kanban-methodologie zelf al meer dan 50 jaar oud. 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 flow tussen supermarkt en consument optimaliseert. Omdat voorraadniveaus overeenkomen met consumptiepatronen, neemt de efficiëntie van het voorraadbeheer van supermarkten aanzienlijk toe doordat de hoeveelheid overtollige voorraad die altijd beschikbaar moet zijn, kan worden verminderd. Ondertussen kan de supermarkt er nog steeds voor zorgen dat essentiële producten altijd op voorraad zijn.

Toen Toyota hetzelfde systeem in hun fabrieken ging toepassen, was het doel om hun enorme voorraadniveaus beter af te stemmen op het werkelijke verbruik van materialen. Om capaciteitsniveaus in realtime in de fabriek (en naar leveranciers) te communiceren, zouden werknemers een kaart of 'kanban' kunnen 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-kaart doorgegeven aan het magazijn waarin werd beschreven welk materiaal er nodig was, de exacte hoeveelheid van dit materiaal, enzovoort. Het magazijn had al een nieuwe bak met dit materiaal klaarstaan, die vervolgens naar de fabriek werd getransporteerd. Vervolgens stuurde het magazijn zelf een kanban naar de leverancier voor een nieuwe levering. Hoewel dit proces zich sinds de jaren veertig verder heeft ontwikkeld, vormt ditzelfde 'just-in-time'-productieproces (JIT) nog steeds de kern van de kanban-methodologie.

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 flexibelere planningsopties, snellere output, duidelijkere focus, en transparantie gedurende de hele ontwikkelingscyclus.

Kanban-bord | Atlassian agile coach

Hoewel de kernprincipes van de Kanban-structuur tijdloos en van toepassing zijn op bijna elke branche, zijn het met name softwareontwikkelingsteams die bijzonder succesvol zijn geweest met de agile-aanpak. In tegenstelling tot het implementeren van Kanban in een fabriek, 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 taakkaarten, en zelfs die kunnen virtueel zijn.

Kanbanborden

Het werk van alle Kanban-teams draait om een Kanban-bord, een tool die wordt gebruikt om werk te visualiseren en de workflow binnen het team te optimaliseren. Hoewel fysieke borden populair zijn bij sommige teams, zijn virtuele borden een cruciale tool voor agile softwareontwikkeling vanwege hun traceerbaarheid, eenvoudigere samenwerking en toegankelijkheid vanaf meerdere locaties.

Een digitaal of fysiek Kanban-bord zorgt ervoor dat het team hun werk visualiseert, hun workflow standaardiseert en direct alle blockers en afhankelijkheden identificeert en oplost. 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 kunnen ze de workflow in kaart brengen om aan hun unieke processen te voldoen.

De Kanban-methodologie is gebaseerd op volledige transparantie van het werk en communicatie van de capaciteit in realtime. 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.' Kanban-teams vertegenwoordigen elk werkitem als een aparte kaart op het bord. Het belangrijkste doel van het weergaven van werk als een kaart op het Kanban-bord is om teamleden de voortgang van het werk te laten bijhouden door de workflow op een zeer visuele manier weer te geven.

Kanban-kaarten bevatten cruciale informatie over projecttaken, waardoor teams inzicht krijgen in wie verantwoordelijk is voor welke taken. Ook bevatten de kaarten een korte beschrijving van de taken en hoe lang ze naar schatting duren. Kaarten op virtuele Kanban-borden bevatten vaak ook screenshots en andere technische details die waardevol zijn voor de uitvoerder.

Teamleden in staat stellen om op elk moment de status van elke taak en relevante informatie te bekijken, bevordert een verhoogde focus, uitgebreide traceerbaarheid en snelle identificatie van blockers en afhankelijkheden.

Voordelen van de Kanban-structuur

Kanban is een van de populairste methodologieën voor softwareontwikkeling die tegenwoordig door agile-teams worden gebruikt. Kanban biedt extra voordelen voor taakplanning en capaciteit voor teams van elke omvang.

Flexibiliteit bij planning

Een Kanban-team is alleen gericht op het werk dat in uitvoering is. Zodra de teamleden een taak hebben voltooid, selecteren ze de volgende taak uit de backlog. De producteigenaar kan werk in de backlog een andere prioriteit geven zonder het team te verstoren, omdat veranderingen 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.

Tip van pro's:

Slimme producteigenaren overleggen altijd met het ontwikkelingsteam wanneer ze veranderingen in de backlog overwegen. Als userstory's 1-6 bijvoorbeeld in de backlog staan, kan de schatting van userstory 6 gebaseerd zijn op de voltooiing van userstory's 1-5. Het is altijd een goede gewoonte om veranderingen te bevestigen bij 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 kortere cyclustijden. Wanneer slechts één persoon een set vaardigheden bezit, wordt die persoon een knelpunt in de workflow. Teams gebruiken daarom eenvoudige beste praktijken zoals codereview en mentoring om de aanwezige kennis te verspreiden. Gedeelde vaardigheden betekenen dat teamleden heterogeen werk kunnen aannemen, wat de cyclustijd verder optimaliseert.

Bovendien stelt deze aanpak het hele team in staat om knelpunten op het werk gezamenlijk aan te pakken, waardoor een snelle oplossing wordt vergemakkelijkt en een soepele workflow wordt gegarandeerd. De verantwoordelijkheden op het gebied van testen gaan bijvoorbeeld verder dan QA-ingenieurs en omvatten ook ontwikkelaars, wat een gezamenlijke inspanning bevordert om de efficiëntie te handhaven. In een Kanban-systeem zorgt het hele team ervoor dat het werk soepel verloopt tijdens het proces.

Minder knelpunten

Multitasking is funest voor de efficiëntie. Een verhoogde werklast leidt er tegelijkertijd toe dat er vaker van context wordt gewisseld, waardoor de voortgang van taken naar voltooiing wordt belemmerd. Daarom is een belangrijk principe van het Kanban-proces het beperken van het werk in uitvoering (WIP). Limieten voor werk in uitvoering benadrukken knelpunten in het proces van het team als gevolg van gebrek aan focus, mensen of vaardigheden.

Een doorsnee softwareteam kan bijvoorbeeld vier workflowfasen 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 dan dat ze tijd besteden aan het beoordelen van andermans werk. Een lage limiet moedigt het team aan om speciale aandacht te besteden aan issues in de beoordelingsstatus en het werk van anderen te bekijken voordat ze hun codebeoordelingen verhogen. Hierdoor wordt uiteindelijk de totale cyclustijd verkort.

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 elk 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 daling in cyclustijd 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 blockers ontdekken aan de hand van het aantal issues dat in een bepaalde fase is toegenomen. Issues in tussenliggende fasen zoals 'In uitvoering' of 'Wordt beoordeeld' worden nog niet aan klanten geleverd. Een blocker in deze fasen kan de kans op ernstige integratieconflicten vergroten wanneer het werk upstream wordt samengevoegd.

Cumulatief stroomschema

Continue levering

Continue levering (CD) is het proces waarbij regelmatig werk wordt vrijgegeven aan klanten. Continue integratie (CI) is het proces waarbij code automatisch wordt gebouwd en incrementeel wordt getest gedurende de dag. Samen vormen ze een CI/CD-pipeline die essentieel is 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 zijn gericht op de just-in-time (en één voor één) levering van waarde. Hoe sneller een team innovatie op de markt kan brengen, des te competitiever hun product gaat zijn. Kanban-teams richten zich precies daarop: het optimaliseren van de workflow 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

Releasemethodologie

Scrum

Regelmatige sprints met vaste lengte (d.w.z. twee weken)

kanban

Continue flow

Rollen

Scrum

Producteigenaar, scrummaster, ontwikkelingsteam

kanban

Continue levering of naar eigen oordeel van het team

Belangrijkste statistieken

Scrum

Snelheid

kanban

Cyclustijd

Veranderingsfilosofie

Scrum

Teams moeten proberen om de sprintvoorspelling niet te veranderen tijdens de sprint. Als dat wel gebeurt, worden de inzichten over schattingen aangetast.

kanban

Verandering kan op elk moment plaatsvinden

Sommige teams combineren de idealen van Kanban en scrum tot 'scrumban.' Ze combineren bijvoorbeeld de sprints met vaste lengte en functies van Scrum met de focus op WIP-limieten (werk in uitvoering) en de cyclustijd van Kanban.

Voor teams die net beginnen met agile, raden we echter ten zeerste aan om één methodologie te kiezen en er een tijdje mee te experimenteren. Als je team klaar is om aan de slag te gaan met de Kanban-methodologie, gebruik dan vandaag nog het gratis Kanban-bord-sjabloon!

Jira-bord

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.

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