Halverwege de jaren negentig ontstond Agile als een alternatief voor de traditionele, plan gestuurde benadering van software ontwikkeling. Agile is bedoeld om beter te voldoen aan de eisen van de klant. Wanneer eisen in een vroeg stadium in detail worden gespecificeerd en vastgesteld, blijkt in de praktijk dat de eisen in de loop van de tijd veranderen, omdat zowel de klant als de ontwikkelaar zich bewust worden van nieuwe kansen, behoeften en/of beperkingen.
De Agile praktijk behelst lichtgewicht en incrementele processen die de klant volledig en continu betrekken en aanpasbaar zijn aan veranderende omstandigheden. In 2001 formuleerde een groep software-ingenieurs het agile manifest, waarin diepgaande principes van agile ontwikkeling werden opgetekend. Er bestaan meerdere ​​uitwerkingen en specialisaties van de agile praktijk. Twee populaire uitwerkingen die agile ontwikkeling vastleggen zijn Scrum en Extreme Programming (XP).
Scrum is een empirisch procesmodel dat rollen en activiteiten definieert in een organisatorisch raamwerk. Een Scrum team is grotendeels autonoom en werkt in iteratieve stappen (sprints) van twee tot vier weken. XP richt zich op hechte klant-ontwikkelaar relaties en communicatie in korte iteraties. In plaats van een organisatorisch raamwerk beschrijft XP praktische ontwikkelactiviteiten met enig detail, zoals pair programming, continuous code review, testing en refactoring.
Deze twee uitwerkingen zijn uitermate goede aanvullingen op elkaar. We zullen enkele aspecten verder uitlichten die niet zouden misstaan op een Definition of Done van een software ontwikkelteam.
Test eerst
Test eerst gaat over het verkrijgen van vroegtijdige feedback van de codekwaliteit. Dit principe heeft een enorm positief effect op de kwaliteit van de software architectuur. Het helpt om software van werkend naar werkend te ontwikkelen en iedere sprint een kwalitatief werkend resultaat te tonen in de sprint review.
Continue integratie
Continue integratie vermijdt of detecteert problemen in een vroeg stadium. Integratie is een activiteit van "betaal nu of betaal later meer". Dat wil zeggen, als continu in kleine hoeveelheden wordt geïntegreerd, zal aan het einde van het traject niet wekenlang gezwoegd worden om het geheel van features te integreren, terwijl ondertussen de deadline van de sprint is verstreken.
Binnen tien minuten bouwen
XP schrijft voor dat code continu wordt geïntegreerd en dat de build minder dan tien minuten mag duren. Wanneer de bouwtijd langer dan tien minuten duurt, moeten de ontwikkelaars ervoor zorgen dat de bouwtijd wordt verkort. Anders zullen ontwikkelaars terughoudender zijn om hun code continu te blijven integreren. Wanneer ontwikkelaars hun code niet continu integreren, verliezen ze feedback en is het lastiger om binnen een sprint kwalitatief werkende software te blijven leveren.
Refactor voor incrementeel ontwerp
Ontwikkelaars blijven vaak gebruik maken van code die niet meer onderhoudbaar is, omdat het werkt. Helaas zijn ontwikkelaars voorzichtig om dit soort code aan te passen, omdat de gevolgen daarvan niet te overzien zijn. Door de code te blijven refactoren blijft de code onderhoudbaar. Onnodige complexiteit wordt vermeden en daarmee worden de kosten om fouten te herstellen lager. Fouten worden immers vaker opgemerkt en/of zijn eenvoudiger op te lossen. Er blijft meer tijd over voor het bouwen van nieuwe features wat ten goede komt aan de velocity van het team.
Geautomatiseerde testen
Het toepassen van unit testen heeft veel voordelen. Het bevordert bijvoorbeeld het toepassen van refactoring of continu integreren. De kwaliteit van de code wordt continu geborgd, omdat de unit testen tijdens de bouw worden uitgevoerd en direct feedback geeft aan de ontwikkelaar over de kwaliteit van de code-wijziging.
Dagelijks uitrollen
Idealiter ontstaat er een situatie waarin de software aanpassingen dagelijks uitgerold kunnen worden in productie. Als de code onderhevig is aan kwalitatief goede en dekkende automatische testen en er geen handmatige stappen (meer) nodig zijn om de code te testen kan code dagelijks worden uitgerold in productie. Dit geldt met name bij bijvoorbeeld webapplicaties. Bij missie-kritische software, die op specifieke hardware draait, is het niet altijd mogelijk om dit te bereiken, maar het is een goed streven.
Pair programming
Pair programming verhoogt het aantal directe uren om code te leveren ten opzichte van een individuele programmeur. Daar staat tegenover dat de code kwalitatief veel beter is en minder fouten bevat.
Het toepassen van pair programming is zeer geschikt voor complexere onderdelen van de software. Sommige onderdelen vereisen verschillende inzichten en ontwikkelaars met verschillende achtergronden. Het helpt ook om kennis te delen binnen het team, zodat er geen individueel eigenaarschap ontstaat op delen van de code, maar eigenaarschap blijft bij het team.
Informatieve Werkruimte
Scrum hecht waarde aan transparantie. Het is een pijler van Scrum. De Scrum guide beschrijft het hebben van een sprint doel en backlog, maar schrijft niet voor hoe de informatie transparant gedeeld moet worden.
XP vereist dat een team een informatieve werkruimte heeft, zodat iedereen die in de ruimte is de voortgang van de ontwikkeling ziet. XP teams tonen het werk voor de volgende drie maanden en de komende week. Het is voor Scrum teams een goede praktijk om hun werk te tonen op een fysiek bord op een centrale plek in de werkruimte.
Tot slot
Agile in Focus is bezig met de ontwikkeling van een Agile software vakmanschapstraining. We hopen deze training in 2022 aan te bieden aan softwareontwikkelaars die willen ontwerpen, implementeren en/of testen op basis van de Agile praktijk.
Bij Agile in Focus zijn we gecommitteerd om uw software ontwikkelorganisatie verder te helpen om competitief te zijn in een snel veranderende markt. Wij kunnen u hierbij adviseren.
Comments