De Mikado-methode is een framework om veranderingen aan te brengen in een complexe code door software ontwikkelaars. Een goede eerste indicatie van waar Mikado voor staat is dat de bedenkers het een Naïeve Aanpak noemen.
De bedenkers zijn Ola Ellnestam en Daniel Brolund. Zij beschrijven de Mikado-methode als een framework hoe om te gaan met complexe veranderingen wanneer code (t.b.v. een it-systeem) herschreven dient te worden. Maar wat als de ontwikkelaars het risico van aanpassen te groot vinden of het gewoonweg niet aandurven vanwege de mogelijke consequenties?
Zoals je vermoedelijk wel weet is Mikado ook een spel waarbij je stokjes weghaalt zonder dat je de andere stokjes laat bewegen. Net als het spel is het veranderen (het weghalen van een stokje) bij kleine veranderingen vaak nog goed te overzien.
Naarmate je verder komt in het spel zijn er steeds meer onderlinge afhankelijkheden. Dit wordt in deze methode als volgt beschreven: op een willekeurig gegeven moment zullen grote of kleine veranderingen in eerder geschreven code plaats dienen te vinden.
Mikado richt zich met name op grote veranderingen, waarbij het handig is om een framework of methodiek te hanteren. Het hoofddoel van de Mikado-methode is overzicht te houden tijdens de verandering, waardoor de kans op fouten in de code afneemt.
Het Mikado-model is beschreven in het boek The Mikado Method. Het boek is in Nederland bij de bekende verkooppunten verkrijgbaar, maar is nu (deels) vrijgegeven op manning.com en daar in te zien.
Dit artikel zal met name software ontwikkelaars aanspreken, toch is het ook interessant voor Scrum Masters en Agile Coaches. De Mikado-methode hanteert namelijk een andere benadering dan veelal gebruikelijk en bouwt voort op agile processen zoals refactoring, TDD en snelle feedback.
De 4 basisbegrippen van de Mikado-methode
De Mikado-methode wordt ook wel het Mikado framework genoemd. De methode hanteert 4 basisbegrippen. Deze 4 basisbegrippen zijn eenvoudig te begrijpen:
- Stel een doel
- Experimenteer
- Visualiseer en
- Maak ongedaan.
Kortom, geen ‘rocket science’, maar waarom is het dan anders? Het ‘anders zijn’ ligt in het specifieker kijken naar wat het onderliggende probleem is.
Wat is het onderliggende probleem?
De auteurs beschrijven dat alle softwareontwikkelaars ooit een grasmat zullen moeten betreden waar ze liever niet op willen spelen. Dit wordt beschreven als volgt: de code was ooit vers groen gras, maar inmiddels is het een bruin veld (brown fields) waar men liever niet meer komt. Simpelweg omdat het veranderen van de code teveel organisatie of persoonlijke risico’s met zich meebrengt.
Door velen medewerkers in de organisatie is het niet mogelijk of gewenst om de wedstrijd op of met het bruine gras aan te gaan vanwege de voornoemde risico’s, maar het voortbestaan van een organisatie is veelal mede afhankelijk van verse code. Een organisatie heeft vers groen gras nodig om het concurrentiespel goed te kunnen spelen. Aan de ontwikkelaars de taak om een omgeving te creëren waarmee de organisatie de concurrentiestrijd aan kan gaan.
En als je als ontwikkelaar dat bruine veld dan toch moet betreden is het Mikado-model met 9 processtappen volgens de auteurs een zeer geschikt middel: ‘het werkt heel goed samen met Extreme Programming, Scrum en Kanban.’
De 9 processtappen van de Mikado-methode.
De 9 processtappen van de Mikado-methode worden kort toegelicht. De afbeelding toont het framework.
Stap 1: Teken het originele Mikado doel.
Schrijf een User Story voor het Mikado doel. Schrijf het Mikado doel op een stuk papier, trek er een dubbele cirkel eromheen.
De dubbele cirkel is er om gedurende alle processtappen het oorspronkelijke doel aan te geven. Het doel waar men zich aan gecommitteerd heeft wat dus behaald dient te worden. Je creëert focus en alles wat je doet moet gericht zijn op het behalen van het doel.
Het doel draagt zorg voor 2 belangrijke voorwaarden:
- Is het gekozen doel het startpunt voor verandering?
- Zonder doel weet je niet of je succesvol bent.
Het belangrijkste van het doel is echter dat het je doet bewegen tot het doen van een experiment. Zie stap 2.
Stap 2: Voer het doel naïef uit
Ga direct experimenteren, analyseer vooraf de mogelijke gevolgen niet, implementeer en leer. Dit heet de Naïeve Aanpak, want je creëert een experiment om te leren. De gedachte erachter is dat er regelmatig veel tijd besteed wordt aan analyseren en te interpreteren, terwijl de wijziging direct doorvoeren direct de juiste inzichten verstrekt.
Zodra je gaat experimenteren gaan er dingen ook fout, hiervan leer je en kan je diverse variabelen valideren en/of voorbereidingen treffen.
In sommige organisaties ontstaan dan de eerste spanningen, want leren door fouten te maken past goed binnen agile denken. Maar niet alle organisaties zijn gecharmeerd van deze gedachtegang, daar mogen fouten niet of beperkt worden gemaakt. Dat is tevens een van de redenen waarom de verouderde systemen niet graag door de ontwikkelaars worden aangepakt.
Stap 3: Zoek eventuele fouten
Ontdek je fouten, belemmeringen en/of problemen dan ga je door naar stap vier. Dat is echter geen procesfout of verloren tijd, je hebt inzicht gekregen in de afhankelijkheden die het bereiken van jouw doel belemmeren.
Zijn er geen fouten dan ga je door naar stap 8 of 7. Zie afbeelding.
Stap 4: Kom met directe oplossingen voor de fouten
Fouten dienen opgelost te worden, over-analyseer deze fouten echter niet. Kom met directe oplossingen, het maakt volgens de methodiek niet uit waar deze gevonden worden. Kom dus snel met een oplossing in de volgende iteratie.
Vaak is er sprake van diverse afhankelijkheden en deze dienen opgelost te worden voor implementatie. Dit doe je door voortdurende iteraties, waarbij het geleerde wordt meegenomen naar de toekomstige iteratie.
Stap 5: Teken de directe oplossingen als nieuwe voorwaarden
Het visueel maken is een heel bekende agile werkwijze. De oplossing wordt opgeschreven en verwijst met een pijl naar het doel. De oplossing noemt men daaropvolgend een voorwaarde voor het oorspronkelijke doel.
Dit is een leerproces op zichzelf, de ene keer is de oplossing geschikt voor meerdere fouten en kan je deze met 1 pijl aangeven de andere keer wordt je geconfronteerd met veel meer oplossingen voor veel verschillende problemen.
Soms heb je geen oplossing, hanteer dan een ‘placeholder’ waar ‘de fout’ op staat. Deze komt later in de rebound.
Stap 6: Zet de code terug in de oorspronkelijke staat als er fouten zijn gemaakt.
De zesde stap van de Mikado-methode is in menig organisatie een issue. Want eindelijk is er iets opgeleverd, maar dan blijken er alsnog fouten in de code naar voren te komen. Een veelvoorkomende reactie is dan om datgene dat werkt te behouden en alleen de fout(en) te herstellen.
In de Mikado-methode is dit het lastigste onderwerp, de werkwijze die men dan hanteert is het volledig ongedaan maken van de oplevering of te wel de gedane wijziging terugbrengen in de oorspronkelijke staat! Volgens velen is dit het vernietigen van gedaan werk!
Dit is volgens de bedenkers de grootste en belangrijkste drempel bij het toepassen van deze methode.
De Naïeve Aanpak
Volgens de auteurs is er echter slechts één juiste methode. Blijf de Naïeve Aanpak hanteren! Stap 1 tot en met 5 geven het al aan, in deze zesde stap is het credo:
Ga altijd terug naar de laatst werkende situatie, voordat je verdere wijzigingen doorvoert.
Het vermijden van fout op fout stapeling is essentieel voor herhaalbaarheid en voorspelbaarheid.
Het achterliggende idee is heel eenvoudig, je zult fouten moeten maken om te kunnen leren. Het leren gaat met horten en stoten en wordt in een aantal organisaties helaas gezien als verspilling. Dat is het volgens de auteurs echter niet, het is in hun visie de belangrijkste manier om te leren.
Ze stellen zelfs dat het niet terug kunnen gaan na een eerder werkende versie berust op een misvatting. Het gaat immers niet alleen om het opleveren van werkende code. Een systeemontwikkeling dient zich volgens hen te richten op het leren over het systeem, het domein, de taal en de gebruikte technologie.
Het maken van de veranderingen is slechts een fragment van de totale ontwikkeltijd en de grote waarde van de Naïeve Aanpak is wat je leert over het systeem. Het stelt je in staat om te zien wat je eigenlijk in de weg staat.
Het overwinnen van de angst om terug te keren is een belangrijke stap voorwaarts in de Mikado-methode
Stap 7: Herhaal het proces voor elk van de directe oplossingen
Herhaal voor elk van de voorwaarden, één voor één, de voorgaande stappen, beginnend met stap 2. Dit betekent dat voor elk van de voorwaarden, begin met een schoon werkend systeem en probeer de voorwaarde naïef te implementeren. Zoek de fouten (indien aanwezig), bedenk oplossingen voor de fouten, noteer ze als voorwaarde, draai de wijzigingen terug en ga dan verder met de volgende voorwaarde.
Stap 8: Controleer of er geen fouten zijn
Als er verder geen fouten zijn dan is de verandering geslaagd, dit geef je aan met een vinkje bij de oplossing. Je kan dan overgaan tot het overdragen van de code. Veelal hanteert met hiertoe een aantal voorwaarden:
- De code wordt gecompileerd.
- De testen worden uitgevoerd.
- Het product is goed.
- De veranderingen zijn zinvol om in te checken.
Wellicht zullen er nog wat veranderingen moeten worden doorgevoerd en ga je door met de volgende iteratie en een nieuwe voorwaarde. Je start weer bij stap 2.
Als de wijzigingen niet helemaal zinvol zijn, kijk dan naar de afbeelding en kijk of ze vergezeld moeten gaan van een paar extra wijzigingen om een verstandige oplevering te maken. Je kunt eventueel het controleren van de voorwaarden uitstellen, totdat je de code incheckt.
Ga verder met het selecteren van een nieuwe voorwaarde om mee te werken als volgende iteratie, en herhaal het proces vanaf stap 2.
Stap 9: Als het Mikado doel is bereikt, ben je klaar!
Het doel is bereikt, alle voorwaarden zijn vervuld de code is ingecheckt. Tijd voor een feestje en weer door!
Samenvatting
De Mikado-methode is een andere kijk op software ontwikkeling. Dit artikel geeft inzicht in hoofdlijnen van het proces. Wellicht is de Mikado Methode niet geheel nieuw voor je, maar het is interessant om je nog eens verder te verdiepen in deze methode.
Hiervoor verwijs ik je naar het boek of manning.com waar veel dieper op dit framework wordt ingegaan.