De architect en agile testen

De agile trend lijkt onomkeerbaar: in de financiële wereld en in de overheid schieten de agile pilots als narcissen uit de grond. Het nieuwe paradigma waar softwareontwikkeling aan onderhevig is, stelt nieuwe eisen aan mens en organisatie. Ook de (ICT-) architect ontkomt hier niet aan. In dit artikel willen we een lans breken voor een onverwachte plek voor de architect in het agile proces: namelijk in het testproces. Daar vindt de feedback op technische en functionele beslissingen plaats en daar is dus de plek waar de architect kan bepalen of en hoe het team voldoet aan zijn eisen.

De kern van agile

Veelal wordt de methode Scrum gezien als het symbool van wat agile is. Het softwareontwikkelproces is daarin gereduceerd tot drie rollen (product owner, ScrumMaster en teamlid), drie documenten (product backlog, iteration backlog, definition of done) en vier bijeenkomsten (sprint planning, daily scrum, demo en retrospective). Toch is dit proces sec niet de kern van agile, want die ligt in de waarden van agile. In het Agile Manifesto worden waarden als mensen en interacties hoger gesteld dan processen en tools, en waardeert men werkende software boven uitgebreide documentatie (zie www.agilemanifesto.org). Hier ligt de basis van de paradigmaverandering: willen we succesvollere ICT-projecten dan moeten we zaken fundamenteel anders aanpakken. We zullen nieuwe waarden moeten omarmen. Het was immers Einstein die zei: “Insanity is doing the same thing over and over again and expecting a different result”. De agile beweging zet mensen en werkende software op de eerste plaats, in een iteratieve, lerende omgeving waarin we ons richten op de waarden die echt het verschil maken.

De kern van architectuur

De ICT-architect is van oudsher gericht op de gewenste samenhang en consistentie tussen de verschillende gegevens, systemen, platformen en processen. Voor dat overzicht wordt vaak gebruik gemaakt van architectuurplaten. Consistentie wordt vaak beschreven in dikke documenten op een abstract niveau, want “de architect gaat niet over de details”. De rol van de architect is vaak die van het realiseren van functionele mogelijkheden binnen technische kaders en het toezien op de realisatie ervan binnen de vooraf vastgestelde kaders en richtlijnen. Er is een spanningsveld tussen een aantal beginselen van architectuur (lange termijn, vooraf consistentie borgen, abstract, randvoorwaardelijk) en de beginselen van agile (hier en nu, flexibel omgaan met veranderingen, concreet werkende software, in het team).

Agile en gespecialiseerde disciplines

Sommige agile teams hoor je roepen dat we in agile projecten geen specialisten meer nodig hebben. Dat alles ‘emerging’ is en dat voorbereiding verspilling is. Natuurlijk is dat onzin. Maar wanneer je vanuit het Scrum-proces naar de complexe wereld van softwareontwikkeling kijkt, dan raak je als ICT-specialist toch wat teleurgesteld: Scrum strijkt alle disciplines in het team over een kam en ziet iedereen als ‘teamlid’. In de eerste jaren van de agile beweging werd er gedacht dat er uitsluitend ontwikkelaars nodig waren in agile teams. Inmiddels is men volwassen geworden en zie je in veel agile teams ook ontwerpers, testers en anders specialisten hun rol pakken. Zij worden geacht multidisciplinair te denken en te werken door hun kennis met de teamleden te delen en het overzicht over hun specialisaties daarin te behouden. Daarmee verdwijnt langzamerhand de pure specialist die als enige persoon antwoord heeft op de vragen uit zijn discipline en vanuit een ‘kennissilo’ acteert. Wat we ervoor terugkrijgen zijn teamleden die een kernactiviteit hebben en zich daarnaast verder ontwikkelen op nevenaandachtsgebieden en die daarbij ondersteund worden door die kennisoverdragende specialist. Completere ICT’ers dus, die een discipline beheersen en het nodige afweten van de andere disciplines. Dat geldt dus ook voor de architect.

Hoe omgaan met het spanningsveld?

Om als architect waarde te kunnen leveren binnen een agile team, moet een manier gevonden worden om op een effectieve manier om te gaan met het spanningsveld tussen randvoorwaarden creëren en waarde toevoegen voor het team tijdens het project. Natuurlijk moeten we het kind niet met het badwater weggooien: een belangrijk deel van de randvoorwaardelijke rol van architect blijft ook bestaan in de agile context. Lange termijn visie en consistentie zijn niet ineens onbelangrijk geworden doordat je in de uitvoering van het project iteratief gaat werken.

De focus zal daarbij echter wel verschuiven van “in beton gegoten” abstracte architectuur uitgangspunten naar architectuur principes die flexibiliteit faciliteren en inspelen op voortschrijdend inzicht mogelijk maken. De focus zal komen te liggen op praktische en direct toepasbare concrete richtlijnen die tijdens het project in dialoog met het team verder worden verfijnd. Zeker wanneer er meerdere agile teams aan het werk zijn, moet de ICT-architect overzicht bewaren over de schuivende onderdelen en de principes op de juiste manier bewaken.

De architect en agile testen

Daar waar de ontwerper houvast heeft aan het uitgangspunt “papier is geduldig” en de bouwer zich kan richten op het werkend krijgen van zijn stukje functionaliteit in zijn ontwikkelomgeving, is testen de plaats “where the rubber meets the road”. Bij het testen – van unittest tot acceptatietest – komt de waarde en de waarheid van de oplossing naar boven. Testen is feedback, niets meer maar ook zeker niets minder! De vraag is: wat doe je als architect met die feedback? Uit de testresultaten moet blijken dat de functionaliteit past in het grotere geheel (overzicht) en dat de interactie tussen de systemen, gegevens, platformen en processen plaatsvindt zoals de bedoeling is (consistentie). Dit is dus DE plaats waar de architect kan vaststellen of de architectuur voldoet aan zijn verwachtingen en of zijn richtlijnen voor ontwerp en bouw het gewenste effect hebben opgeleverd. Kortom: in een agile team kan de architect door nauwe samenwerking met de testers een belangrijk aspect van zijn rol invullen.

Figuur 1: In een agile proces vindt het testen parallel aan ontwerp en bouw plaats

Het grote voordeel van de agile testen aanpak ten opzichte van de traditionele aanpak is, dat het testen nu continu en parallel aan het ontwerp en bouwproces gebeurt. Dat betekent dat de feedback uit het testproces iedere dag nieuwe informatie oplevert. Iedere dag is er een check op consistentie en iedere dag bestaat de kans dat de vooraf bedachte oplossing misschien niet de beste is… Daar moet de architect dus bij zijn!

Ergo: de architect moet gaan ‘connecten’ met het team en moet zich vaker op de werkvloer van het agile project laten zien om zijn rol effectiever uit te voeren. Of hij dat nou leuk vindt of niet!

Met dank aan: Jan Campschroer, Willem Krijgsman, Willem van Pruijssen en Herm Wijgergangs.

Bron: xr-magazine.nl

Over Anko Tijman

Managing Consultant on Agile & DevOps at Ordina. Connector. Listener. Thinker. Collaborator. Pianist. Dad. http://nl.linkedin.com/in/ankotijman
Dit bericht werd geplaatst in Agile Requirements, Testen3.0 en getagged met , , , , , , , , , , , , , , , , , , , , , , . Maak dit favoriet permalink.

Geef een reactie

Vul je gegevens in of klik op een icoon om in te loggen.

WordPress.com logo

Je reageert onder je WordPress.com account. Log uit / Bijwerken )

Twitter-afbeelding

Je reageert onder je Twitter account. Log uit / Bijwerken )

Facebook foto

Je reageert onder je Facebook account. Log uit / Bijwerken )

Google+ photo

Je reageert onder je Google+ account. Log uit / Bijwerken )

Verbinden met %s