Agile systeemontwikkeling bestrijdt koloniale stijl van uitbesteden
In eerste instantie vooral gedreven door de hoop op kostenbesparing, hebben steeds meer organisaties in de afgelopen jaren de steven gewend richting offshore voor het ontwikkelen van hun systemen. De loonkosten liggen in India en vergelijkbare landen (hierna gemakshalve aangeduid als ‘het oosten’) nog altijd stukken lager dan in het westen, terwijl de kwaliteit van de systeemontwikkelaars op zijn minst van een vergelijkbaar niveau is. De IT is een vakgebied dat nog zo jong is, dat het vooral lijkt te worden geregeerd door snel opkomende trends en overspannen verwachtingen. Ook in het geval van offshore-ontwikkeling worden de cynici niet teleurgesteld. Veel pioniers geven aan niet tevreden te zijn met de resultaten. Een bedrijf in Nederland bekende zelfs ondertussen ‘vooral nog juridische documenten’ met India uit te wisselen.
Hoewel de loonkosten in de verre landen inderdaad een stuk lager liggen, zijn er veel verborgen kosten die een deel afknagen van de potentiële besparingen. Dat zit hem in het leggen van de eerste contacten, het opzetten van een ontwikkelorganisatie en -proces en het uitvoeren van pilotprojecten. Evenzeer wordt de tijd en aandacht die moet worden besteed aan kennisoverdracht snel onderschat.
De grootste tegenvallers schuilen echter in communicatiemisverstanden. De grote afstand, de vermeende cultuurverschillen en het feit dat het meestal om een externe partner gaat, zorgen voor een omzichtige strategie. Vanuit de overtuiging dat de ‘andere kant’ alleen kan worden gecontroleerd door de verwachte resultaten in marmer te houwen, wordt aan beide zijden een rigide houding aangenomen. De specificaties worden met overdreven detail opgesteld en geven dan nog wrijving - juist ook door taalbarrières, culturele verschillen en niet op elkaar aansluitende tijdzones.
Uitgerekend nu flexibiliteit de norm is geworden voor een moderne bedrijfsvoering, vallen organisaties voor hun IT terug op het vechtmodel van de klassieke watervalbenadering. Dat was in de jaren tachtig van de vorige eeuw al een model dat ongeschikt bleek voor de dynamiek van bedrijven en markten. En de pijn ervan wordt anno 2005 nog veel sterker gevoeld. Zeker als bedacht wordt dat veel van de communicatieve tekortkomingen van de lineaire aanpak alleen maar worden uitvergroot door de eigenschappen van offshore-ontwikkelen: nog grotere afstanden en nog meer overdrachtspunten. Offshore-ontwikkelen ‘oude stijl’ lijkt zo vooral een strafexercitie die bedoeld is om alle pijnlijke leermomenten van het snel groeiende IT-vakgebied nog eens intensief te herbeleven.
Koloniaal luchtje
Wie het strijdperk eens nader beziet, kan zich niet onttrekken aan het idee dat er een koloniaal luchtje uit opstijgt. Het westen houdt zich bezig met het veredelde denkwerk, in de vorm van architectuur, gebruiksspecificaties en functioneel en technisch ontwerp. In het oosten worden vervolgens de grote hoeveelheden saai routinewerk uitgevoerd; daaronder horen gemakshalve activiteiten als programmeren, unit-testen en converteren. Als het werk klaar is, kan het terug naar de opdrachtgever, die zich onledig kan houden met de acceptatietest.
Het is dan niet zo verwonderlijk dat het uitgerekend tijdens die acceptatietest vaak misgaat. Een formele, getrapte ontwikkelbenadering vraagt om een grote procesvolwassenheid van alle betrokkenen. En dat door de hele levenscyclus heen: van de opdrachtgever en de gebruikersorganisatie tot en met de programmeurs en database-experts. De veronderstelling daarbij is dat iedereen discipline betracht bij het gedetailleerd produceren van tussenresultaten en dat er een helder, gezamenlijk beeld is over wat die resultaten precies betekenen. Als die randvoorwaarden er niet zijn, ontstaat gaandeweg het project steeds meer ruis bij de overdrachtspunten. Tegen de tijd dat het systeem gereed is, is het nog maar een bleke afspiegeling van wat oorspronkelijk was bedoeld, voorzover men dat op dat moment zelf al wist.
Sleutelrol
Dit probleem is niet nieuw. Maar de scherpe randen ervan worden inderdaad nog veel meer gevoeld met het introduceren van een onbekende partij die zich ogenschijnlijk op grote afstand bevindt.
Een deel van de oplossing zit in het uitwisselen van sleutelrollen, zodat er meer wederzijds begrip ontstaat en er vloeiender kan worden gecommuniceerd. Maar naarmate er meer heen en weer wordt gereisd, komen de kostenbesparingen onder druk te staan. Een andere, regelmatig gekozen optie is het opvoeren van het formele gehalte: veel meer details in de specificaties en strenge kwaliteitscontroles bij overdrachtsmomenten. Dat is met recht het cultiveren van de koloniale stijl en er zijn grote investeringen mee gemoeid. Voorzover die ook al niet de vermeende kostenbesparingen teniet doen, ontstaat er vanzelf onvrede omdat de flexibiliteit en het reactievermogen van de IT-functie te veel worden aangetast.
Zoals gezegd: niets nieuws. En er zijn ook al langere tijd oplossingen en zelfs doorbraken bekend. Daarom is het opmerkelijk dat er bijvoorbeeld nog maar zo weinig verworvenheden van agile systeemontwikkeling zijn doorgedrongen tot de offshore-wereld. Al in het vorige decennium, met de komst van James Martin’s RAD (Rapid Application Development) werd het duidelijk hoe vroege, aansprekende prototypes de beperkingen van teveel formalisme konden opheffen. Tom Gilb en Barry Boehm deden er een schepje bovenop door een risicogedreven stijl voor te stellen: in korte iteraties naar het doel bewegen waarbij mogelijke problemen en misverstanden al in het vroegste stadium zichtbaar worden. En toen was er het ‘Agile Manifesto’, waarin de essenties van de nieuwe aanpak netjes werden weergegeven:
• -Individuen en interactie, liever dan processen en tools.
• -Werkende software, liever dan gedetailleerde documenten.
• -Samenwerken met klanten, liever dan het onderhandelen van contracten.
• -Reageren op verandering, liever dan het volgen van een plan.
• -De waarde van vroege, tastbare resultaten is groot. Vooral als er onzekerheid bestaat over afspraken en kwaliteit en er maar geen vat kan worden verkregen op wat er werkelijk aan ‘de andere kant’ gebeurt. Elke projectleider die maandenlang heeft doorgebracht in het warme bad van de begrijpende en sussende woorden van oosterse contactpersonen - om daarna ruw in de werkelijkheid terecht te komen - zal hierin meevoelen. De frequente oplevering van wérkende software, hoe onvolledig dan ook, geeft een realistisch idee van hoeveel greep er werkelijk over en weer is. Ook bij een wantrouwige klantenorganisatie neemt het vertrouwen snel toe als er concrete resultaten zijn die aan het beeldscherm kunnen worden beproefd. Als er dan misverstanden of kwaliteitsproblemen blijken te zijn, zullen ze zich op het best denkbare moment manifesteren: in de beginfase van het project als er nog volop gelegenheid is om de koers bij te stellen.
• -Het principe van ‘continue integratie’, zoals onder andere bekend van eXtreme Programming (XP), propageert dat systeemontwikkelaars voortdurend hun code integreren in nieuwe, werkende versies van het systeem, eigenlijk na het doorvoeren van elke verandering. Dit kan de vorm krijgen van een ‘nightly build’, maar er zijn zelfs uitstekende ervaringen met het produceren van vele nieuwe versies gedurende de dag. In het geval van offshore-ontwikkelen zullen alle teams hun code in hetzelfde, via internet benaderbare, configuratiemanagementsysteem opvoeren. Dit wordt voorafgegaan en opgevolgd door de bijbehorende unit-tests en geautomatiseerde functionele en regressietests. Als een test mislukt, is het aan de verantwoordelijke ontwikkelaars om de fouten op te lossen, waar ze zich ook ter wereld bevinden. Pas dan kan hun bijdrage definitief aan een volgende versie worden toegevoegd. Op deze manier worden de kleine hoofdpijntjes van integreren steeds in de kiem gesmoord, in tegenstelling tot een ‘big-bangbenadering’, waarin pas in de laatste fase van het project zou kunnen blijken dat er ernstige problemen zijn met integreren.
• -Een andere verworvenheid van onder andere eXtreme Programming zit hem in testgedreven specificaties. Volwassen XP-teams kennen al lang de kracht van het gebruiken van acceptatietests als specificatiemiddel. Voordat in een iteratie ook maar een regel code wordt geproduceerd, worden eerst uitgebreide acceptatietestscripts opgesteld (bij voorkeur van de geautomatiseerde soort). Dat geeft het ontwikkelteam niet alleen een helder doel om naar toe te werken, maar blijkt ook zeer verhelderend te werken op de functionele specificaties. Door de offshore-locatie de testscripts op te laten stellen - bijvoorbeeld op basis van use cases of een verbaal scenario - wordt zo snel meer onderling begrip gekweekt. En degenen die aan de offshore-kant de tests hebben opgesteld, blijken weer het vanzelfsprekende aanspreekpunt te zijn voor de lokale ontwikkelaars, als er toch nog onduidelijkheden zijn.
• -In een typische agile aanpak zijn de communicatielijnen zo kort dat er een grote mate van overlap ontstaat tussen de rollen in een ontwikkelteam. Een ontwikkelteam is verantwoordelijk voor het produceren van een resultaat en de benodigde activiteiten rond functioneel en technisch ontwerp, coderen, integreren en testen worden onderling verdeeld. Zo wordt het aantal overdrachtspunten teruggebracht, waardoor de ruis wordt beperkt. Dit principe werkt onverkort in een offshore-project. Hoewel de gebruikerseisen doorgaans nog wel in het westen zullen moeten worden opgesteld, kunnen veel van de andere activiteiten in hun geheel door een offshore-team worden opgepakt. Als er dan al een verdeling van werk tussen oost en west wordt opgesteld, heeft deze alleen betrekking op functionele modules, niet op de rollen. Deze aanpak wordt nog eens verder ondersteund door het eerder beschreven principe van continue integratie. Er hoeft dan geen overdreven aandacht te worden besteed aan het pijnlijk nauwkeurig beschrijven (en daarna bevriezen) van module-interfaces. De klassieke, semi-koloniale verdeling tussen de kampen in een offshore-project vervaagt zo grotendeels: er blijven programmeurs nodig in de ontwikkelteams in het westen, maar evenzeer krijgen de architecten en ontwerpers in het oosten de kans hun vaak uitstekende talenten te tonen.
Op elkaars schoot
Er zijn karakteristieken van agile ontwikkelen die eenvoudigweg niet passen in een offshore-project. De ‘dagelijkse scrum’ uit de Scrum-methode, waarin ontwikkelaars elkaar als in een kringgesprek vertellen wat ze gisteren hebben gedaan en wat ze vandaag gaan doen, is ontoepasbaar. Voor het bekende paarsgewijs coderen van XP (ontwikkelaars werken altijd met zijn tweeën aan code en zitten daarbij nagenoeg op elkaars schoot) geldt hetzelfde. Ook het inzetten van workshops om sneller beslissingen te nemen en specificaties af te stemmen zijn steeds slechts op een en dezelfde fysieke locatie mogelijk.
Toch moet de waarde van face-to-face-contact niet worden overschat, zeker nu er steeds betere software komt om via het internet te communiceren. Iedereen met puberende kinderen weet hoe fijnmazig er via chatprogramma’s als MSN kan worden gepraat, vaak veel diepgaander dan blijkbaar op het schoolplein mogelijk is. Verschijnselen als WiKi’s (systemen waarin gebruikers op een makkelijke manier webpagina’s kunnen maken en die naar elkaar kunnen publiceren) en weblogs bewijzen ondertussen volop hun waarde bij het creëren van wat letterlijk het ‘digitale geheugen’ van het project kan worden genoemd. En voor al die internationale projecten waarin als voertaal Engels wordt gebruikt terwijl het niemands moedertaal is, blijkt het toch al een betere strategie om op geschreven tekst terug te vallen: dat wordt beter begrepen dan het door lokale accenten geteisterde gesproken woord.
Agile ontwikkelen brengt de verschillende partijen in een offshore-project zeer dicht bij elkaar. Zó dicht, dat er geen ruimte meer is voor communicatiemisverstanden, grote afstanden of niet. Als een virtueel, gedistribueerd team op deze manier eenmaal op stoom is, zijn er hoogstens nog de maar al te bekende cultuurverschillen tussen de IT’ers en hun klanten. En die bevinden zich niet zelden op dezelfde verdieping van hetzelfde gebouw.
Ron Tolido is Chief Technology Officer van Capgemini, Noord-Europa/Asia Pacific.
Het Agile Manifesto (www.agilemanifesto.org) wordt beschouwd als de universele beginselverklaring van de principes achter agile ontwikkelen. ‘Zeventien wijze mannen’ in een blokhut in een wintersportgebied in Utah stelden de verklaring in 2001 op. Onder de opstellers bevonden zich bekende methodologen als Kent Beck, Alistair Cockburn en Martin Fowler.
Het manifest beschrijft vier grote basisprincipes van agile systeemontwikkeling:
• Individuen en interactie, liever dan processen en tools. ‘Too much process will kill you’: vanuit deze overtuiging legt het manifest grote nadruk op de werking van gemotiveerde, autonome teams en de waarde van dagelijks persoonlijk contact als communicatiemiddel. Ook worden de teams aangemoedigd om frequent het eigen functioneren te toetsen en waar nodig bij te stellen.
• Werkende software, liever dan gedetailleerde documenten. Het manifest gaat ervan uit dat klanten het meest tevreden zijn met de regelmatige levering van waardevolle software. Werkende software wordt beschouwd als de enige serieuze manier om de voortgang van een project in te kunnen schatten. Vroege versies helpen om projectrisico’s snel te kunnen detecteren en te neutraliseren.
• Samenwerken met klanten, liever dan het onderhandelen van contracten. De toekomstige gebruikers van het systeem moeten zo intensief als mogelijk samenwerken met het ontwikkelteam. Dit geeft de beste resultaten en de hoogste acceptatiegraad. De klantorganisatie maakt zich mede verantwoordelijk voor het eindresultaat.
• Reageren op verandering, liever dan het volgen van een plan. Veranderingen in de koers van het project worden omarmd, ook als ze zich in de laatste fasen aandienen. Zo is de competitieve waarde voor de klant optimaal, gegeven de springerigheid van de zakelijke omgeving. Om snel te kunnen reageren op verandering, propageert het manifest de uiterste nadruk op architectuur, ontwerp, kwaliteit en vooral simpelheid (‘de kunst van het maximaliseren van de hoeveelheid niet gedaan werk’).
Bekende agile methoden zijn eXtreme Programming, DSDM, Crystal en Scrum.