Sander Hoogendoorn  |
 |
Sander Hoogendoorn werkt als Principal Technology Officer bij Capgemini, en is verantwoordelijk voor Capgemini’s agile Accelerated Delivery Platform. Adviseert organisaties en projecten op het gebied van software development. Auteur van talrijke boeken, artikelen en columns. Bekende spreker op internationale conferenties en seminars. Gespecialiseerd in van agile, Scrum, Smart, requirements, smart use cases, UML, software architecture, design patterns, model driven development en .NET. Columnist voor Software Release Magazine en SDN Magazine, lid van de Partner Advisory Council .NET bij Microsoft. |
08 juni 2010 - Vloeken in de kerk
Al sinds jaar en dag houd ik mij bezig met het begrip agile. Mijn team en ik schreven de eerste versie van de agile-methodiek Smart bijvoorbeeld al in 1998, in eerste instantie als extensie voor DSDM. In het afgelopen decennium heb ik dan ook talrijke agile-projecten meegemaakt, uitgevoerd door uiteenlopende organisaties, van universiteiten en softwarehuizen, tot overheidsinstellingen, grote banken en verzekeraars. In de eerste jaren was het vooral zaak het agile-gedachtengoed te evangeliseren.
Op dit moment ruilen echter meer en meer organisaties hun klassieke aanpakken voor een agile-aanpak – al dan niet gedwongen door de economie. Scrum is daarbij veruit de favoriet. Doordat steeds meer projecten toch al starten met agile, kan ik mijn pijlen inmiddels richten op agile anti-patterns. De dingen die misgaan in agile-projecten. Ook een erg leuk onderwerp, want er gaat ook in agile projecten meer dan genoeg mis. Ook agile is geen silver bullet.
DE agile methodiek
Voorbeelden? Alhoewel je steeds meer mensen hoort zeggen dat ze DE agile-methodiek gebruiken, soms zelfs met een hoofdletter geschreven, bestaat er helemaal niet zoiets als DE agile-methodiek. Wel zijn er een heleboel agile werkwijzen, zoals Scrum, XP, Smart, FDD en Kanban. Elk met hun eigen voorgangers, en hun eigen discipelen en volgelingen, om in de evangelisatie-metafoor te blijven.
Helaas constateer ik dat de agile-comminity langzaam maar zeker dogmatischer wordt. Calvinistischer. Populariteit verstart nu eenmaal. Al meerdere malen heb ik discussies meegemaakt over dat ik geen smart use cases mag gebruiken in agile projecten of dat een stand-up meeting geen facilitator mag hebben. Zeggen dat er in de diverse agile werkwijzen elementen ontbreken die broodnodig zijn in projecten, is dan ook vloeken in de kerk.
De meeste agile-processen focussen namelijk maar op één klein deel van wat er in systeemontwikkelprojecten allemaal gebeurt. Er is terecht veel aandacht voor het schrijven van goede code, maar er is helaas veel minder aandacht voor toch ook tamelijk relevante zaken als software-architectuur, analyse, ontwerp en zeker voor testen. Alhoewel de meeste agile werkwijzen wel over unit testing spreken, onderscheiden ze geen aparte rol voor testers. En unit testing is toch nog altijd een techniek voor developers, waarbij kort gezegd testcode wordt geschreven voor de eigenlijke code.
Tussen hemel en aarde
Wanneer we echter grote agile projecten doen voor grote organisaties speelt in mijn optiek de tester een cruciale rol. Er is namelijk meer tussen hemel en aarde dan unit testing. Zo coachte ik recent een complex servicegeoriënteerd agile SAP-project. Een unieke aangelegenheid, waarschijnlijk het eerste in zijn soort in Nederland, maar als het aan het team ligt zeker niet het laatste. In dit project speelden de testers een cruciale rol. Omdat we in korte iteraties software analyseren, ontwerpen, bouwen, testen en opleveren, maken de testers vanaf dag één deel uit van het project. Dat biedt perspectieven!
Godgegeven talent
De unieke kijk op de wereld die testers namelijk aan de dag leggen, onderscheidt ze sterk van ontwikkelaars. Ontwikkelaars merken vaak niet of niet snel genoeg de uitzonderingen op die testers als het ware vanzelfsprekend wel herkennen. In complexe projecten maken we graag en dankbaar gebruik van dit godgegeven talent.
Onze testers zijn dan met de ontwikkelaars medeverantwoordelijk voor het ontwerp van de software. Op deze manier voorkomen we veel fouten in het schrijven van de software nog voordat we ze maken. Eigenlijk een functionele vorm van unit testing.
Helaas focussen veel agile werkwijzen en agile projecten zich (voorlopig) vooral op het schrijven van de juiste code en is er, mede door het ontbreken van de rol tester in de meeste werkwijzen, nog onvoldoende aandacht van de positieve rol die testers in projecten kunnen spelen. En dat is, om in de evangelisatie-metafoor te blijven: zonde. Amen.