De softwareteams van vandaag zijn, althans in hun processen, wendbaarder! Ze zijn bereid om buiten vastgestelde parameters te denken om te volgen wat voor hen werkt. Ze willen graag leren en nieuwe technieken voor projectmanagement en projectprocessen toepassen.
Een projectmanagementmethode genaamd Kanban maakt al een aantal jaren de ronde in de software-industrie en heeft de afgelopen vijf jaar geld gewonnen. Samen met Agile-methoden heeft de toepassing van de Kanban-methode bedrijven veel te vieren gegeven.
Maar er is ook de kritiek dat Kanban niets anders is dan een verheerlijkte takenlijst. Dus waar gaat dat allemaal over? Laten we het uitzoeken.
Wat is Kanban?
Als uw bedrijf klaar is om verder te gaan dan de traditionele benadering van softwareprojectbeheer, is er vandaag geen gebrek aan technieken voor projectbeheer.
Ten eerste is er het Agile Project Management-systeem, dat zich richt op niet-lineaire, iteratieve methoden voor softwareontwikkeling. Het gebruik van Agile-methoden is duidelijk in Scrum, dat zich richt op een meer flexibele benadering van projectmanagement.
Agile heeft ook koppelingen naar andere projectmanagementkaders, zoals Kanban en Extreme Programming. Van deze heeft Kanban veel populariteit bereikt. Immers, wie wil er nu geen door de Japanners ontwikkeld proces?
Kanban is een concept dat in de Toyota Manufacturing Plant is geëvolueerd om just-in-time (JIT) -productie te realiseren die kosten bespaart en minder gebruik van middelen mogelijk maakt. In de kern volgt het het "pull" -principe van het werk, wat betekent dat taken of producten moeten worden "getrokken" door eisen en eisen, en niet van bovenaf moeten worden "gepusht". Het werd ontwikkeld om te zorgen voor een betere opslag van auto-onderdelen in Toyota-fabrieken, op basis van de vraag. Dit betekende dat naarmate de vraag steeg, verzoeken zouden worden ingevuld.
Het concept werd aangepast aan de software-industrie met een paar wijzigingen door David Anderson, in zijn boek uit 2010, Kanban . Sindsdien is het met veel succes gebruikt voor verschillende projecten. Het kan een enorme hulp zijn bij complexe projecten die aan een kant van de ontwikkelingscyclus kunnen leiden tot overbelasting.
Kortom, het Kanban-systeem behandelt het softwareprojectproces als een pijplijn. Laten we zeggen dat een softwareproces drie soorten taken heeft: analyse, ontwikkeling, testen en ten slotte implementatie. Laten we zeggen dat er twintig taken moeten worden voltooid.
In het geval van een traditioneel projectbeheersysteem, bijvoorbeeld
- Er zijn in totaal 25 verhalen
- Analisten kunnen vijf verhalen per week verwerken
- Ontwikkelaars kunnen vijf verhalen per week verwerken
- Testers zijn beperkt tot drie verhalen per week
In deze situatie stapelt het werk zich eenvoudig op aan het einde van de testers. Aan het einde van week 1 is de situatie als volgt:
- Slechts drie verhalen zijn overgegaan tot implementatie.
- Ontwikkelaars en analisten werken aan drie verhalen, omdat testers niet in staat zijn om de output van de ontwikkelaars te nemen en hetzelfde te testen.
- Werk wordt opgestapeld, waardoor ontwikkelaars en analisten en de projectmanager, in een fix terechtkomen.
De analisten en ontwikkelaars zijn nu misschien gewoon aan het duimen! Of hun manager kan zich realiseren dat ze inactief zijn en hen opnieuw toewijzen aan een ander project, waar een vergelijkbare situatie kan ontstaan. Er zijn dus twee projecten die vastzitten in de testfase!
De problemen in een dergelijke situatie zijn niet moeilijk te zien. Wat heeft het voor zin om tien verhalen (of stukjes software) te ontwikkelen als ze niet snel worden getest?
Nu verder met de Kanban-methode.
De Kanban-methode is een uiterst eenvoudig concept. Het volgt een eenvoudige logica van het gebruik van een "pull-methode" om eerst de knelpunten te verwijderen en de Works in Progress (WIP's) te beperken voor betere werkprocessen.
In zijn eenvoudigste vorm helpt Kanban letterlijk 'visual board' door items uit een takenlijst te 'trekken' in plaats van te werken met tijdlijnen. De Kanban-methode helpt bij het identificeren van de knelpunten, zodat de processtroom beter wordt beheerd.
Een standaard Kanban-bord heeft een lijst met uit te voeren taken, lopende taken en voltooide taken.
In softwarebeheer kunnen de taken echter een beetje complexer zijn. De meeste Agile-projecten hebben ook een vergelijkbaar bestuur. In een Kanban-bord zijn de stadia van de inzet duidelijk gemarkeerd, samen met een nummer voor elke kolom. Dit aantal staat voor het maximale aantal taken of verhalen dat een bepaalde stap aankan.
Ons voorbeeld op een Kanban-bord ziet er ongeveer zo uit aan het begin van de tweede week. Dit betekent dat ontwikkelaars en analisten die week niet zullen werken aan het optimale aantal verhalen. Het zou duidelijk zijn dat het werk zich ophoopt aan het einde van de tester. En organisaties kunnen ervoor zorgen dat teams samenwerken om de tests gedaan te krijgen. Als alternatief kunnen ze kijken naar andere modellen van processtroom zodat dit niet gebeurt.
Wanneer projecten via het Kanban-systeem worden afgehandeld, is er minder ruimte voor opgestapeld werk. Verhalen worden opgenomen volgens de maximale beschikbare bandbreedte.
In een typische Kanban-opstelling wordt het werk op basis van de beschikbare bandbreedte opgepakt en wordt het werk door teams binnengehaald, zodat ze altijd op maximale capaciteit staan. Het systeem zorgt ook voor een snelle track, voor taken die urgent zijn, zodat ze met minimale inspanning door het bord gaan.
Bekijk dit Kanban-bord.
Het is duidelijk dat alle stappen op maximale efficiëntie werken. En de taak die op de "Fast Track" staat, is ook verantwoord.
Kanban is zeker niet de enige methode die wordt gebruikt om de efficiëntie te verhogen door WIP te beperken. Er zijn andere systemen die hetzelfde resultaat bereiken, bijvoorbeeld CONWIP (Constant Works in Progress) en DBR (Drum-Buffer-Rope) -systemen, die voornamelijk bedoeld zijn voor de industrie.
Kanban is echter het systeem dat het best is aangepast aan de software-industrie.
Waarin verschilt Kanban van Agile-methoden?
In de kern is Kanban een methode die sommige elementen van Agile Project Management gebruikt. Veel projecten in het Agile-framework hebben wortels in Lean-benaderingen. Het verschil tussen Kanban Methodology en Agile Project Management is niet zo zwart en wit als de voorstanders van de twee methoden ons doen geloven. Ze hebben meer gemeen dan verschillen.
Het Agile-framework is geen absoluut. De vraag is niet of teams Agile zijn of niet. Teams hebben vaak behendigheid in verschillende mate. Een van de methoden om meer flexibiliteit te hebben in uw softwareontwikkelingsproces is het gebruik van Kanban.
Er zijn enkele verschillen tussen Kanban- en Agile-methoden. Enkele van de kenmerken van Kanban-ontwikkeling, die enigszins verschillen van Agile, zijn:
- Tijdlijnen zijn geen significante factor . Dit is een moeilijk concept om onze hoofden omheen te slaan, omdat het erg niet-intuïtief lijkt. "Hoe werk je zonder deadlines?", Vragen mensen vaak. Maar als elk lid van het team met zijn / haar maximale efficiëntie bezig is, dan is de tijd geen factor meer.
- Verhalen (taken) zijn groter dan in typische Agile-systemen. Meestal zijn de lengte en complexiteit van verhalen langer dan bij een typisch Scrum-project. Omdat de nadruk niet ligt op het schatten van tijd, maar eenvoudigweg op het krijgen van het proces, kan Kanban het zich veroorloven om aan grotere verhalen te werken.
- Er is geen significante verandering in bestaande processen. De principes van Kanban voor softwareontwikkeling, zoals geformuleerd door de oprichter, David Anderson, in zijn blog, omvatten de volgende basisprincipes:
-
- Begin met wat je nu doet
- Spreek af om incrementele, evolutionaire verandering na te streven
- Respecteer het huidige proces, rollen, verantwoordelijkheden en titels
- Elk verhaal wordt gemeten in cyclustijd . Het project wordt niet geëvalueerd door de traditionele Agile berekening van snelheid (het aantal voltooide verhalen gedurende een bepaalde tijd), maar door cyclustijd. Dit betekent dat Kanban de nadruk legt op hoe lang het duurde om een taak te voltooien. Je ziet vaak een ticker op veel Kanban-borden die vermelden hoeveel dagen het team nodig heeft om een verhaal af te ronden. Deze schatting wordt doorgevoerd in de volgende cyclus.
Kanban: Een bord, maar wat anders?
Kanban is dus een bord dat ons laat zien hoe de verhalen zijn gerangschikt - is dat zelfs zo'n groot probleem, velen vragen. Er is in feite veel discussie over wat Kanban is en kan doen.
Is Kanban slechts een methode om de workflow te beheren? Of is het iets dat je samen met Agile-methoden kunt gebruiken voor maximale efficiëntie? Of kan het een geheel nieuwe manier van workflowbeheer zijn?
Elk team gebruikt Kanban naar eigen goeddunken, voor hun specifieke situatie. Hoe dan ook, Kanban heeft de potentie om te werken als een manier van leven voor softwareontwikkeling, indien optimaal gebruikt.
Of het nu wordt gebruikt om de workflow te beheren of als een nieuw paradigma bij softwareontwikkeling, het valt niet te ontkennen dat het helpt bij het beheren van OHW's.
Om Kanban het beste te laten werken, is het belangrijk om het niet alleen te beschouwen als het beheren van OHW's, maar als een kader voor projectbeheer. Bepaalde basisrichtlijnen zullen het proces helpen.
- Optimaliseer teams zodat geen team iets start dat ze niet kunnen afmaken. Dit helpt het proces mee.
- Weersta geen wijzigingen van het originele Kanban-systeem. Als uw project het goed zal doen met deadlines en tijdlijnen, neem dan hetzelfde op als u zou doen. Dit zorgt voor een gezondere en robuustere ontwikkelomgeving.
- Vermijd teamwerk niet. Kanban lijkt misschien, maar is het niet, een model dat is gebaseerd op individuen die geïsoleerd werken. Teamwerk moet een integraal onderdeel zijn van Kanban-softwareontwikkeling.
- Denk buiten de doos. Denk na over veranderingen in de workflow. Veel teams kiezen nu voor testgestuurde ontwikkeling, met acceptatietestgestuurde ontwikkeling, waarbij de acceptatietests eerst worden uitgevoerd met gebruiksscenario's, die vervolgens de vereiste functies en de aard van de ontwikkeling aandrijven.
hybriden
Naarmate meer en meer bedrijven de projectmanagementtools gebruiken die het meest geschikt zijn voor hun specifieke situatie, is het niet verwonderlijk dat twee van de beste projectmanagementmethodieken: Scrum en Kanban, met veel succes zijn geïntegreerd.
De hybride, Scrumban genaamd, dringt door in veel projecten.
Als een organisatie Scrum al gebruikt, maar het moeilijk vindt om het project bij elkaar te houden, ofwel omdat de sprints niet goed werken, omdat testen niet luchtdicht is, is het misschien tijd om Scrumban te overwegen.
Om het simpel uit te leggen, ging Scrumban met een vergrootglas naar de sprints. Het gaat niet alleen om de sprints als onderdeel van het project, het gaat om wat er binnen de sprints gebeurt. Scrumban helpt te onderzoeken hoe een verhaal wordt verwerkt in een sprint, en dat kan het verschil maken.
Scrumban, of een van zijn varianten, is een minimale verandering ten opzichte van bestaande praktijken. Het mooie van het gebruik van Kanban is dat het kan worden gebruikt met vrijwel elk soort projectmanagementmodel: waterval, Agile of alles daartussenin.
Aan de slag met Kanban
Het is gemakkelijk om te beginnen met het Kanban-systeem. Het is ook mogelijk om Kanban op een minimale manier te implementeren als een proef voor een bepaald deel van een project.
- Breng het softwareontwikkelingsproces in kaart. Maak een duidelijke kaart van het hele proces. Hoe werkt het project - van het eerste ontwerp, tot ontwikkeling, tot testen, tot veranderingen in functies - in de realiteit?
- Maak een lijst van de stappen waar Kanban zal worden gebruikt. Gebruik de stappen die volledig onder uw controle zijn. Dit omvat doorgaans de analyse-, ontwikkelings-, evaluatie- en testfasen.
- Werk aan belangrijke punten zoals:
- Beperkingen voor de werken in uitvoering voor elke stap.
- Processen voor versneld / geblokkeerd werk
- Schattingen achter de envelop met betrekking tot de cyclustijd
- Frequentie van het Kanban-bestuur / proces / schattingsonderzoek
- Koop een whiteboard en een stapel Post-It-notities.
- Begin
- Herzie indien nodig.
- Herhaling
Dus ga je gang en ga aan de slag op Kanban!
Wees niet bang als het niet uitpakt zoals je in eerste instantie had bedoeld. Het hele idee achter Agile-methoden is om tegemoet te komen aan veranderingen in mensen en processen! Laat ons weten wat uw ervaringen zijn met de Kanban-methode.
Aanbevolen artikelen
- 6 Best Nuttig Een Project Management Office (PMO)
- 8 nuttige stappen om geavanceerde verhaalkaarten te maken voor uw project
- De 5 belangrijke waarden van extreem programmeren (krachtig)