Open-sourceaanpak ideaal voor offshoreprojecten

Het werkelijk verlagen van de kosten van ontwikkelingsprojecten blijkt in de praktijk vervolgens niet eenvoudig, vooral vanwege communicatiemisverstanden. Gefrustreerde projectmanagers wijzen op de wrijving die ontstaat door de grote fysieke afstand, de cultuurverschillen tussen ‘oost’ en ‘west’ en de verschoven tijdzones. Om toch maar greep te houden op de voortgang van het project wordt teruggegrepen op de bewezen middelen van rigide specificaties, formele processen en dik aangezette overdrachtsmomenten. Dat zijn dan wel bewezen middelen van ver terug in de vorige eeuw; voorzover ze zich toen al bewezen. Gedetailleerde documentatie bleek ook toen al vooral schijnzekerheid te bieden, waardoor een project uitgerekend in de latere fasen van een project steeds meer vertraging opliep. Deze ingebouwde narigheid van het klassieke ‘watervalmodel’ wordt verder uitvergroot in een offshore-context, waarin het potentieel voor onderlinge misverstanden alleen maar groter is. En dat alles in een tijd waarin bedrijven optimaal flexibel moeten zijn en de richting van een project vaak gaandeweg het traject - al lerend - moet worden bijgesteld. Een van de sleutels tot de oplossing ligt in de principes van ‘agile’-methoden voor systeemontwikkeling. Waar het verder aanschroeven van het formele gehalte niet op applaus van de betrokken IT’ers hoeft te rekenen, worden de principes van een cyclische en interactieve projectvoering vaak omarmd. Ook op offshorelocaties is de acceptatie hoog, al is daar gewenning nodig aan de ogenschijnlijk vrijgevochten, semi-chaotische uitgangspunten van agile systeemontwikkeling. Critici onderkennen grootmoedig de voordelen van de aanpak maar zetten vraagtekens bij de schaalbaarheid: agile ontwikkelen doet het vooral leuk voor een klein project met enkele teamleden. Tevens wordt gewezen op de problemen die ontstaan door meerdere locaties en verschoven tijdzones: frequente, ‘face to face’-communicatie - ook met de gebruikers - is onmogelijk waardoor het ontbreken van gedetailleerde documentatie fataal zou zijn voor het bereiken van het gewenste resultaat. In dat licht is het goed te leren van de open-sourcegemeenschap: die bewijst hoe software op grote schaal kan worden ontwikkeld door verspreid opererende teams waarvan de individuele leden elkaar zelden of nooit direct in de ogen zien. En dat die software tegelijkertijd complex en van hoge kwaliteit is bewijzen de successen van oprukkende producten als Linux, Apache, MySQL, OpenOffice, Snort en Eclipse. Een aantal kenmerken van de open-sourceaanpak leveren bij uitstek de innovatieve impulsen op die offshoreprojecten nodig hebben (zie kaders): 1. Virtuele teams werken intensief samen via op internet gebaseerde ‘collaboration platforms’. 2. Gebruikers vormen een dominant deel van het ontwikkelteam. 3. Ontwikkelaars opereren vaak tegelijk in verschillende teams, meestal in verschillende rollen. 4. Er is een sterke nadruk op cruciale architectuur- en ontwerpkwaliteiten. 5. Transparantie is de culturele norm. Holistische stranden Niet alle verworvenheden van open source laten zich zomaar vertalen naar offshoreprojecten. Het gemoedelijk delen van alle projectresultaten met de buitenwereld zal niet altijd de bedoeling zijn. Evenzeer is het goed om te realiseren dat veel helden van de open source bovenmatig worden gemotiveerd door erkenning van hun vakgenoten. In die queeste zijn ze bereid zeer ver te gaan, desnoods maandenlang tot diep in de nacht, elke dag weer. Dat hoeft niet het motivatiepatroon te zijn waar opdrachtgevers of gebruikers bij gebaat zijn. Ook het feit dat open-sourceontwikkelaars vaak vrijwilligers zijn die geheel zelf bepalen aan welke project ze willen meedoen, is een weinig realistisch uitgangspunt voor professionele IT-organisaties. Toch kunnen de bakens zich sneller verzetten dan gedacht. Bandbreedte en alomtegenwoordige toegang tot het netwerk leverden de doorbraak van open source. Individuen kregen de kans hun waarde te bewijzen op basis van hun feitelijke prestaties, niet gehinderd door barrières van landsgrenzen, tijdzones of vermeende cultuurverschillen. Ook offshoreprojecten worden snel populairder doordat breedbandige netwerken de wereld ‘plat’ maken. De transparantie die open source bracht, lijkt zich daarmee verder te verspreiden. Op welk strand je je precies bevindt, maakt dan straks niet veel meer uit. Een ieder als een ware holist op zijn eigen strand: de term ‘offshore’ zullen we snel weer alleen met olieboringen associëren. Ron Tolido is Chief Technology Officer van Capgemini, Noord-Europa/Asia Pacific.Virtuele teams De natuur van open-sourceprojecten is per definitie gedistribueerd: ontwikkelaars kunnen zich over de hele wereld bevinden en niet zelden is er sprake van honderden verschillende locaties. De bijdragen kunnen komen van individuele hobbyisten maar evenzeer van keurige ‘fabrieksteams’ van bijvoorbeeld IBM of HP. Het is niet verwonderlijk dat de opkomst van open source gelijk opliep met die van het internet: pas met de beschikbaarheid van een open, ‘collaborative’ platform dat iedereen kon gebruiken om informatie te delen en uit te wisselen, trad het vliegwiel in werking. Open-sourceprojecten zijn daarmee sterk afhankelijk van de beschikbaarheid van geautomatiseerde tools om te communiceren. De hoge mate van automatisering zorgt ervoor dat een groot deel van het gevolgde ontwikkelingsproces zonder handmatige inbreng wordt vastgelegd. Dat scheelt het team veel werk, hoewel bepaalde grootheden - specificaties, ontwerpen, plannen - altijd nog op de ambachtelijke manier gecreëerd zullen moeten worden. Een ‘digitaal projectgeheugen’ is verder een effectief middel voor kennismanagement, en dat is hard nodig in een situatie waarin nieuwe teamleden veel sneller komen en gaan dan gemiddeld (Bangalore, Mumbai en Hyderabad zijn de nieuwe jachtgronden voor headhunters). Betrokken gebruikers Linus Torvalds maakte school door te stellen dat een groot team van betrokken gebruikers belangrijker is voor succes dan de beschikbaarheid van ontwikkelaars. En ook Eric Raymond, schrijver van de onofficiële open-sourcebijbel ‘De Kathedraal en de Bazaar’ onderstreept het belang van een grote, actieve basis van potentiële afnemers: "Given enough eyeballs, all bugs are shallow": als er maar genoeg ogen meekijken tijdens het specificeren, ontwikkelen en testen zullen er weinig fouten verborgen blijven. Het is in open-sourceprojecten daarom de norm om de toekomstige gebruikers van een systeem in alle fasen van de systeemontwikkeling te betrekken, vanaf de functionele specificaties via ontwerp-reviews en testsessies tot de installatie aan toe. Een goede maatstaf voor de impact van een open-sourceproject is het aantal gebruikers dat zich betrokken toont bij het project en veel ontwikkelaars geven aan hun voornaamste motivatie te halen uit het binden van zoveel mogelijk potentiële afnemers. Ook hier helpen collaborative platforms om zelfs binnen het meest gedistribueerde offshoreproject gebruikers actief te betrekken. Vroege versies die via het internet beproefd kunnen worden, leveren veel waardevolle feedback op. Wiki’s, nieuwsgroepen en discussieforums brengen gebruikers en ver verwijderde ontwikkelaars veel dichter bij elkaar. En door actieve inbreng ook werkelijk te honoreren - bijvoorbeeld door het regelmatig overnemen van wijzigingsvoorstellen en het inbouwen van gesuggereerde nieuwe functionaliteit - zullen gebruikers zich veel meer eigenaar voelen van het project. Zelfs als de software door een aan de andere kant van de wereld opererend team wordt ontwikkeld. Ontwikkelaars in teams Een bekend verschijnsel uit de open-sourcegemeenschap is dat van de zogenaamde ‘halo’: letterlijk een stralenkrans (of zwerm) van ontwikkelaars die zich om een project verzamelen. In het middelpunt van de stralenkrans bevindt zich een kleine groep van kernontwikkelaars. Deze zijn verantwoordelijk voor het ontwerp en de richting van het project. Door hun senioriteit en betrokkenheid bij het project vormen ze het baken voor de doorgaans veel grotere groep van ‘donerende’ ontwikkelaars die zich gaandeweg aansluit. De buitenste kant van de stralenkrans bestaat uit de actieve gebruikers van het systeem, zoals in een eerdere paragraaf beschreven. Een speciale groep binnen het team van kernontwikkelaars wordt gevormd door de ‘code committers’: zij kunnen als enigen nieuwe of gewijzigde code definitief doorvoeren in het systeem. Daarmee vormen ze niet alleen de administratieve ruggengraat van het systeem, maar brengen ze ook de visie en het leiderschap die kenmerkend is voor succesvolle open-sourceprojecten. Code committers geven een project ziel. En dat is hard nodig in situaties waarin het team over de hele wereld is verspreid en ogenschijnlijk aan geen van de kanten de echte betrokkenheid wordt gevoeld bij het eindresultaat. Door verschillende code committers te benoemen, bijvoorbeeld een in het westen en een in het oosten, wordt de wederzijdse verbondenheid verder opgevoerd; afgezien van het feit dat het ‘rond de klok’ werken - met de tijdzones mee - beter mogelijk wordt. Door ontwikkelaars aan verschillende teams deel te laten nemen (bijvoorbeeld afwisselend als intensief bijdragende kernontwikkelaar en als ad-hoc ‘donerende’ ontwikkelaar) ontstaan eerder standaards in methoden en aanpakken door de hele populatie heen. De waarde van individuele bijdragen van ontwikkelaars aan de verschillende projecten kan overigens in deze stijl van werken goed worden gemeten en daarmee ook worden opgenomen in de prestatiedoelstellingen. Architectuur en ontwerp Ontwikkelaars die deelnemen aan open-sourceprojecten zijn niet zelden echte vakidioten die er onderling pijnlijk scherp aangezette mores op nahouden. De nadruk op architectuur, ontwerp en kwaliteit wordt nog sterker in situaties waarin de teamleden elkaar niet persoonlijk kennen en codecontributies potentieel vanuit elke bron - vertrouwd en niet vertrouwd - kunnen komen. Het principe van ‘peer reviews’ - waarin teamleden elkaars specificaties, ontwerpen en code nauwkeurig onder de loep nemen - wordt daarom als noodzakelijk beschouwd, en deze noodzaak geldt evenzeer voor offshoreprojecten. Ook de vertrouwde discipline van modulair ontwerp (een minimale kern creëren en nieuwe functionaliteit toevoegen in de vorm van aparte, losgekoppelde modules of services) wordt in open-sourcekringen enthousiast gepraktiseerd, alleen al om het mogelijk te maken om op vele plekken tegelijkertijd aan het systeem te kunnen werken. Voor offshoreprojecten geldt dat daarmee de module de eenheid van werk wordt om te distribueren: een team krijgt de verantwoordelijkheid voor het ontwikkelen van alle aspecten van een module - vanaf ontwerp tot en met testen en documentatie - en zal dus op één locatie steeds alle rollen invullen. Dat staat haaks op de klassieke beeldvorming rond offshoreprojecten waarin de specificaties en ontwerpen aan de ene kant worden gemaakt om daarna aan de andere kant van het bamboegordijn omgetoverd te worden tot code. Zelfstandig opererende teams met de verantwoordelijkheid voor complete modules hebben veel minder te maken met lastige overdrachtsmomenten: die groeperen zich vooral rond de interfaces tussen modules. En als die gestandaardiseerd zijn en losgekoppeld, is de wrijving minimaal. Cultuur van transparantie Transparantie is een cultureel verschijnsel dat hoort bij open source. De code wordt beschouwd als het gemeenschappelijke eigendom van alle teamleden (‘collective code ownership’) en iedereen wordt gestimuleerd om een kijkje te nemen in de resultaten van anderen. Een typerend open-sourceproject heeft een uitgebreide website waarop niet alleen de nieuwste versies van het product kunnen worden gevonden, maar ook discussies over nieuwe functionaliteit, projectplannen, voortgangsrapportages, ontwerpen, testresultaten en ervaringen uit de praktijk van gebruikers. Een blik op Sourceforge.net - een van de grootste open source portals - leert onmiddellijk welke projecten het meest actief zijn en welke producten het meest worden gedownload, maar evenzeer welke projecten al maandenlang stilstaan. Zo’n transparante cultuur kan ook een doorbraak opleveren in offshoreprojecten, waarin de betrokkenen elkaar vaak niet goed genoeg kennen. Alleen al een bijna overdreven goed inzicht in de projectvoortgang via een project portal zal helpen om meer vertrouwen op te bouwen. Overigens wordt transparantie toch al steeds meer een vereiste voor IT-projecten, voortgedreven door de toenemende druk van wet- en regelgeving zoals de Amerikaans Sarbanes Oxley-act. De nood wordt dan snel een deugd. Digitaal geheugen Alleen al door het intensieve gebruik van e-mail ontstaat letterlijk een ‘digitaal geheugen’ van het project. Alle specificaties die worden afgesproken, maar ook de beslissingen die zijn genomen, de planningen die zijn gemaakt en de voortgang die is gemeld, bevinden zich in het e-mailarchief. Dat effect wordt versterkt met de toepassing van nieuwere, meer interactieve tools zoals wiki’s, weblogs en elektronische teamruimtes. Als al die tools bij elkaar worden gebracht, samen met de ontwikkeltools, ontstaat een waar ‘collaborative platform’ voor offshoreprojecten. Producten als SourceForge en CollabNet zijn ontstaan in de open-sourcegemeenschap maar zijn ook cruciaal bij het neutraliseren van de ontkoppeling van tijd en locatie in offshore. Ze brengen bovendien alle gradaties van beveiliging en robuustheid die nodig zijn voor professionele ontwikkelomgevingen.