woensdag 24 mei 2023
Agile werken lijkt te betekenen “hacken”, ofwel kort door de bocht gaan in het maken van software. Bij complexe softwaresystemen zien we dat het regelmatig problemen oplevert: software die te laat wordt opgeleverd, zonder de gewenste kwaliteit. Interne en externe opdrachtgevers snappen niet meer wat ze nu krijgen. Herkenbaar? In dit artikel gaan we op deze problematiek in en leggen we uit wat goed kan helpen bij Agile werken met complexe systemen.
Waarom Agile werken
Veel bedrijven hebben het Agile werken tegenwoordig omarmd. We zien bij grotere organisaties dat het gebruik van het Scaled Agile Framework (SAFe) populair is. Geïnspireerd door het Manifesto (zie verderop in de tekst) is een Agile werkwijze en inrichting van de organisatie ontstaan. Bij SAFe bijvoorbeeld, wordt het werk over het jaar verdeeld in vier zogenaamde increments, die weer worden onderverdeeld in zogenaamde sprints van typisch 2-3 weken. De doelstelling is om idealiter na iedere sprint werkende productierijpe software op te leveren, geïntegreerd over alle Agile teams heen.
Om alvast duidelijk te zijn, we zijn een fan van Agile en we doen het zelf ook. Er zijn verschillende goede redenen voor bedrijven voor deze Agile transitie:
- De organisatie wil de samenwerking tussen verschillende afdelingen verbeteren. De aspecten van Agile brengen de verschillende disciplines meer bij elkaar.
- De behoefte aan inzicht in status en voortgang, zodat eerder bijgestuurd kan worden. Door het werken in sprints zijn er tussentijdse momenten waar bijgestuurd kan worden.
- De wens om sneller op te leveren. Meer en vaker naar productie omdat de markt erom vraagt. Door het inbrengen van een cadans kan er vaker gereleaset worden.
De praktijk blijkt vaak weerbarstiger dan de theorie. Regelmatig past een deel van de ontwikkeling niet in de sprints of in de increments. Een klassiek voorbeeld zijn de speciale sprints voor testen, integratie of acceptatie.
Manifesto
Een veelgehoorde klacht is dat Agile bochten in het ontwikkelproces afsnijdt om alles maar in sprints en increments te kunnen passen. De uitspraak: “Agile is hacken” is hier een voorbeeld van. Om te zien waar dat vandaan komt, gaan we terug naar het originele Manifesto waar Agile ooit in 2001 (!) mee begon:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Het Manifesto was destijds een reactie op de waterval methode van softwareontwikkeling die juist de nadruk legde op de zaken rechts in bovenstaand Manifesto. In de wens en de Agile drang om het werk toch maar in de sprints te passen zien we nu juist het omgekeerde: de zaken aan de rechterkant worden onvoldoende ingevuld. In het bijzonder zien we dat bezuinigd wordt op documentatie als requirements en specificaties. Maar ook op contractzaken, als afspraken met opdrachtgevers en op een planning en overzicht op globaal niveau. Dat vinden we een slechte ontwikkeling. Agile verandert de werkwijze, maar de complexiteit van het product en de IT-oplossing verandert echter niet. Daarnaast staat de rechterkant er niet voor niets. Iets dat de makers van het Manifesto onderkennen: “there is value in the items on the right”
Belang van documentatie
Agile of niet, belangrijk is dat de software die wordt geleverd doet wat het moet doen. Gestructureerd en goed vastleggen van requirements helpt dan enorm. Op deze manier zijn requirements en specificaties leesbaar en herbruikbaar voor anderen, tijdens bouw en niet onbelangrijk ook tijdens beheer. Wanneer je daarbij ook nog eens in staat bent om deze eenduidig vast te leggen, dan maak je het eenvoudiger voor degenen die het product moeten ontwikkelen, testen en toetsen. Dit stelt je in staat transparant te zijn naar interne en externe opdrachtgevers: je laat zien dat jullie elkaar begrijpen en je kunt het gesprek voeren over de inhoud (krijgen ze wat er is beloofd).
We horen vaak “Maar dit doen we toch juist met Agile? We leggen tijdens de sprints alles vast op een Kanban bord. En documentatie is achterhaald, die wordt toch niet gelezen!” De documentatie tijdens de sprints is echter vluchtige projectadministratie en echt onder de maat voor productadministratie (niet up to date, consistent en eenduidig). Na het einde van de sprint is het moeilijk, zo niet onmogelijk, om weer een integraal beeld van het product te krijgen.
En ja, goed documenteren is inderdaad moeilijk. Eenduidig vastleggen is niet allesomvattend, maar precies goed en genoeg. Te weinig, dan laat je te veel aan de interpretatie over. Te veel kost onnodig tijd en maakt het mogelijk te complex.
Wat werkt?
Een methode die werkt en erg goed past bij de Agile werkwijze is model-gebaseerd werken. SAFe adviseert dit ook onder de noemer MBSE (Model-Based System Engineering). Een vergelijkbare aanpak/insteek is MDD (Model Driven Design).
De vastlegging van de requirements en specificaties vindt in dit geval iteratief plaats in een model (voorbeelden zijn UML of SysML). Dit is een design artefact van het product dat ook na het project blijft bestaan. Op basis van dit model bouwt de ontwikkelaar de software en bedenkt de tester de testen. Door het creëren van deze Single Source of Truth kunnen veranderingen snel doorgevoerd worden, welke dan vervolgens eenvoudig kunnen worden verwerkt door de ontwikkelaars en testers.
Het Axini platform ondersteunt MDD/MBSE (inclusief Behavior Driven Design). Een belangrijke toegevoegde waarde is dat ons platform de testgevallen automatisch genereert en uitvoert. Vanuit het model worden testgevallen gegenereerd en via een adapter worden deze volledig geautomatiseerd en zeer grondig uitgevoerd tegen de system under test. Vastlegging van testgevallen en resultaten zijn overzichtelijk weergegeven en goed te gebruiken als audit trail. De dekkingsgraad en versie beheer zijn uitstekend te gebruiken als bewijsvoering om vol vertrouwen naar productie te gaan.
Wil je meer weten over hoe je met de Axini aanpak volledig MBSE ondersteund Agile kan werken? Neem contact met ons op of volg ons op LinkedIn.