Een gewichtige paradox
Voor organisaties die zich serieus bezighouden met moderne, lichtgewicht ontwikkelprocessen zoals eXtreme Programming, Scrum of ook wel het meer gangbare DSDM, is het dilemma ongetwijfeld herkenbaar. Deze op zich sympathieke methodieken zijn bij uitstek bruikbaar voor het oplossen van relatief overzichtelijke problemen. Projecten die je met een stuk of 6 medewerkers kunt realiseren zijn ideaal. Echter, zelfs in zulke betrekkelijk overzichtelijke projecten moet je toch wel over de nodige talenten beschikken om goed met de dynamiek in het project om te kunnen gaan. Je hebt heel wat ervaring nodig om op basis van een beknopte user story in korte tijd een voorspelbaar en bruikbaar deelresultaat op te leveren. Een deelresultaat dat bovendien in de toekomst nog moet passen in het grotere systeem, waarvan aanvankelijk alleen nog maar vage contouren bekend zijn. Want dat is immers de crux van Agile Development: alleen het hoogst noodzakelijke wordt gepland, er wordt liefst vanaf dag 1 met bouwen begonnen en er wordt heel snel productie geleverd. Er wordt wel een intensieve betrokkenheid van de klant verwacht om het project in goede banen te leiden. De klant is idealiter dagelijks aanwezig op de werkvloer, hij bepaalt zelf – op basis van de informatie uit het team – waaraan het team moet werken, en vooral ook waaraan niet. Dus als de klant het nut van formele documentatie niet ziet, geen prioriteit geeft aan stresstesten, of niet bereid is om te investeren in uitwijkprocedures, so be it.
Zo’n wendbaar project kan niet alleen op ieder gewenst moment een andere richting ingestuurd worden, maar het kan ook op ieder gewenst moment gestopt worden en desondanks toch een zinvol resultaat opleveren. In de praktijk wordt er natuurlijk pas gestopt als de opdrachtgever tevreden is of als hij om een andere reden stopt met het sponsoren van het project. Er zijn twee duidelijke voordelen: een opdrachtgever kan de ontwikkeling stoppen op het moment dat het systeem precies goed genoeg is; en het wordt makkelijker om de ontwikkeling van een half af systeem om welke reden dan ook een poosje te bevriezen en daarna zonder al te veel problemen weer op te pakken. Dit principe maakt dit type projecten overigens ook wel eXtreem kwetsbaar voor herprioritering, pardon, bezuinigingsoperaties, maar dat terzijde.
Als deze manier van werken goed wordt beoefend, dan levert het volgens ingewijden bovengemiddeld elegante oplossingen op en hebben de bouwers bovendien tijdens het project veel fun gehad. Geen wonder dat de populariteit van deze manier van werken vooral onder geeks zo groot is.
Er is ook een downside. Goed beschouwd is complexiteit dodelijk voor lichtgewicht ontwikkelprocessen – die om die reden ook wel magere processen worden genoemd. Dergelijke processen zijn immers vanuit hun aard beperkt schaalbaar. Als je met meer mensen samen moet werken, dan krijg je vanzelf behoefte aan meer ceremonie – de span-of-control van zelf-sturende teams is immers vrij beperkt. En of je nu kiest voor meerdere parallelle teams, of grotere teams, of allebei, er ontstaat onvermijdelijk meer behoefte aan overleg en coördinatie. Trouwens, als de benodigde investeringen groter worden, dan worden de belangen en reputaties die in het geding zijn navenant groter, en zal er ook vanuit die hoek al gauw behoefte zijn aan meer sturing, control of governance.
Nou is er natuurlijk ook in de Agile methodieken wel nagedacht over het omgaan met afstemmingsproblemen bij het ontwikkelen van complexe systemen. Het basisidee is dat je niet alles van te voren probeert op te lossen, en de software die je maakt is dankzij de gekozen aanpak zo goed onderhoudbaar is dat je voortschrijdend inzicht heel makkelijk kunt verwerken. Op die manier kun je door refactoring de veranderingen doorvoeren om allerhande aansluitingsproblemen en voortschrijdend inzicht te verwerken. Dat klinkt heel goed, maar of je nou op die manier een echt ingewikkeld, bedrijfskritisch project tot een goed einde zou kunnen brengen…?
Het minste wat je kunt stellen is dat bovengemiddeld hoog gekwalificeerde, ervaren en gemotiveerde ontwikkelaars vereist zijn om succesvol systemen Agile te ontwikkelen. Ontwikkelaars die al het een en ander hebben meegemaakt, waardoor ze een mate van vakkundigheid hebben ontwikkeld die hen behoedt voor het maken van fundamentele ontwerpfouten. Teamspelers bovendien, die zonder al te veel sturing toch onderling effectief samenwerken - ook met klanten. Eigenlijk meer het type software architecten, die wat ze bedenken zelf bouwen, en wat ze bouwen goed doordenken. Korte lijntjes en zo min mogelijk overdrachtsmomenten, want hoe minder functiescheiding, hoe lichter het gewicht van het proces.
Maar al je daar even over doordenkt, dan betekent dat eigenlijk impliciet dat u uw beste mensen moet inzetten op niet al te complexe projecten! Zwaargewichten inzetten op lichtgewicht uitdagingen. Maar dat ligt niet onmiddellijk voor de hand! Zou u de beste ontwikkelaars die u in huis heeft, echt willen inzetten op eenvoudige klussen, omdat ze daar fun hebben en veel productiever zijn? Maar wie doen dan de complexere, mission critical projecten? Is dat geen schrijnend dilemma?
De uitweg
Gelukkig is er een uitweg uit deze paradox. Agile programmeren kan heel succesvol zijn, mits er een gezonde basis voor is gelegd. Daarmee bedoel ik een rijk platform met generieke enterprise en platform services die het leven van de ontwikkelaars makkelijk maken. En een set van standaarden, richtlijnen en best practices om die servicelaag goed te gebruiken. Minder ervaren ontwikkelaars kunnen zich toeleggen op het realiseren van specifieke functionaliteiten en de enterprise architecten waken over de generieke services. Waar nodig zullen ze deze services pro-actief onderhouden, maar doorgaans begeleiden ze de ontwikkelteams bij het gebruik van deze servicelaag.
De inzet van talent wordt dan overzichtelijk. De zwaargewichten houden zich bezig met de analyse van een complex problemen en de opdeling ervan in een aantal overzichtelijke deelproblemen. Voor de oplossing van deze deelproblemen schetsen ze de contouren en leggen ze principes en regels vast. En binnen zulke duidelijke kaders kunnen minder ervaren of getalenteerde collega’s, uiteraard onder de regie van de enterprise architecten, eXtreem succesvol zijn.
Er is wel een voorwaarde. Het vereist namelijk dat er strategisch geïnvesteerd is in een rijke collectie generieke services. Want alleen dan kan het ontwikkelen van een nieuwe, rijke functionaliteit relatief eenvoudig zijn. Een collectie services die bovendien voortdurend up-to-date gehouden wordt – achterstallig onderhoud in de generieke services zet projecten meteen op achterstand. En dat vereist niet alleen visie, maar ook een masterplan. Een Enterprise Architectuur. Want, om zoveel mogelijk vrijheid te kunnen bieden, moeten nou eenmaal duidelijke lijnen worden gesteld. Enterprise architecten zijn heel goed in staat om het nodige ceremonieel te betrachten in de richting van kritische stakeholders, en tegelijkertijd om op een meer informele manier effectief samen te werken met vakkundige ontwikkelaars en testers. Durf de bouwvergunningen af te schaffen, en schakel in plaats daarvan over op coaching en training-on-the-job.
Kortom: Met de best practices van Agile Development kunt u vooral heel effectief zijn als u ze combineert met de best practices van Werken onder Architectuur. Separation of concerns is het geheim achter de opschaling van lichtgewicht ontwikkelmethoden. En voor ieder viewpoint moet de hoeveelheid ceremonie voortaan afgestemd worden op de daarbij betrokken stakeholders. Logisch toch?
In deze paradox wordt algemeen aanvaarde best practices ter discussie gesteld. Het is de 2de in een reeks 'uncommon sense' die op dit weblog gepubliceerd zal worden
Posts
Geen opmerkingen:
Een reactie posten