Artikel

Complexiteit vs Agile

In dit artikel wordt ingegaan op wat de invloed is van de complexiteit van het probleem- en oplossingsdomein op het verloop van een Agile traject. Hoewel het Agile manifesto veel waardevolle en concrete aanwijzingen biedt, worden er in de praktijk helaas belangrijke inschattingsfouten gemaakt tijdens de uitvoer. Situaties waarbij Agile wordt ingezet om gewoon maar snel te kunnen beginnen met coderen en lekker bezig te zijn, zullen vroeg of laat slachtoffer worden van de “complexiteitspython”.

Een veel gemaakte inschattingsfout is het niet onderkennen van de complexiteit van het probleem dat dient te worden geautomatiseerd. Een andere belangrijke inschattingsfout is het onvoldoende managen van de ontstane complexiteit van de oplossing. Een goede inschatting maken van de complexiteit, of met andere woorden even de tijd nemen om te bepalen wat eigenlijk het probleem is en welke passende oplossing daarbij hoort, is essentieel voor het slagen van een Agile traject. Het is belangrijk om eerst een compleet overzicht te hebben van de totale oplossing, zodat het helder is wat in welke sprint kan worden gerealiseerd en waar de showstoppers uithangen.

De invloed van complexiteit op het succesvol doen slagen van een project

Complexiteit bestaat in hoofdlijnen uit 2 componenten:

  • De complexiteit van het domein. Sommige domeinen zijn van nature complex (denk hierbij in termen van fysica, mathematica, rekenregels of beslissingsstructuren). Als het domein niet genoeg wordt vereenvoudigd of de werkelijke complexiteit onvoldoende wordt onderkend, dan zal de oplossing automatisch moeilijk worden. Dit is te vergelijken met het atoommodel van Bohr, dat op zich goed werkt om belangrijke fysische eigenschappen van atomen en moleculen te beschrijven. Een modelbeschrijving die rekening houdt met meer eigenschappen van het atoom blijkt in werkelijkheid vele malen ingewikkelder te zijn, maar voor simpele vragen haar doel voorbij te schieten.
  • De complexiteit van de structuur van de oplossing. Zelfs een eenvoudig domeinmodel (bijvoorbeeld: classes en algoritmes) kan behoorlijk ingewikkeld worden indien deze wordt opgelost met een ingewikkelde oplossingsstructuur. Dit kan bijdragen tot een verhoging van de onderhoudskosten. Volgens Grady1 kost een softwaresysteem 2 tot 3 keer zoveel als dat het kostte tijdens de initiële ontwikkeling.

Inzicht in domeincomplexiteit

Het interessante is dat een applicatiebouwer op twee verschillende momenten in de tijd met deze twee soorten van complexiteit te maken krijgt. Het is dan ook zeer belangrijk om deze zo goed mogelijk in te schatten en te reduceren.

Hoewel dit geldt voor ieder procesmodel blijkt in de praktijk dat redelijk wat Agile bouwers hier onvoldoende rekening mee houden. In Rational Unified Process wordt bijvoorbeeld met domeincomplexiteit rekening gehouden in de elaboratiefase. Een elaboratiefase mag daardoor wel iets langer duren. In de Agile aanpak wordt over het algemeen een beperkt deel van het domeinmodel uitgewerkt, waardoor het coderen eerder kan beginnen, maar men later meer tijd kwijt is aan het refactoren van de code om nieuwe domeinelementen toe te voegen. De manier waarop de uiteindelijke complexiteit wordt benaderd kan grofweg volgens drie paden worden doorlopen. Deze zijn afgebeeld in het kader ‘Complexiteitscurven’.

 

Complexiteitscurven

 

Een vergelijking met de meet- en regeltechniek is op zijn plaats als het gaat om het bepalen van de complexiteit van een systeem. In de grafiek zijn 3 curven weergegeven. Uitgangspunt is dat ieder systeem een bepaalde complexiteit heeft.

 

Curve 1 (onderschatting) stelt het bepalen van de complexiteit voor indien hiervan geen inschatting is gemaakt en er verder ook geen onderzoek naar is gedaan. Een voldoende goed ontwerp (hoe simpel ook) ontbreekt. Het gevolg is dat het systeem nooit tot een goed einde komt. Regelmatig duiken er onverwachte problemen op. In casu: Tijdens de ontwikkeling is een constant aanpassen van essentiële onderdelen in de architectuur noodzakelijk. Met nieuwe requirements is geen rekening gehouden.

 

Bij curve 2 (overschatting) is de complexiteit overschat. Dit kan op verschillende manieren, bijvoorbeeld:

  • te snel opschalen van het aantal projectmedewerkers omdat het een moeilijk traject gaat worden;
  • te veel technologie, middleware, third party oplossingen inzetten;
  • te veel rekening gehouden met onvoorziene requirements.

Projecten die aan deze curve voldoen blijken erg instabiel te zijn. Projectmedewerkers hebben het soms erg druk, soms juist niet en er wordt vooral gewacht op anderen. De architectuur van de oplossing wordt over het algemeen te complex en moeilijk onderhoudbaar.

 

Bij curve 3 is het verloop optimaal. Er wordt een juiste inschatting gemaakt van de complexiteit, door bijvoorbeeld voldoende tijd te nemen om een correct data-/domeinmodel te ontwerpen. Gedurende de tijd tot het Eurekapunt (4) zijn voldoende mensen bezig om na te denken over de oplossing. Het modelleren helpt om inzicht te krijgen in de complexiteit van de oplossingsarchitectuur. Het Eurekapunt wordt bereikt indien bij de ontwerpers het signaal ontstaat waarbij duidelijk doordringt: “Oh zit het zo! Ach het valt wel mee.” Er zal duidelijkheid bestaan over releases en resources. Als het Eurekapunt bereikt is valt de oplossing, maar ook het vervolgtraject, als een puzzelstukje in elkaar. Vanaf nu geldt nog maar één ding, de implementatie gaat bewijzen dat de oplossing correct is.

 

Uiteraard is het Eurekapunt een utopie, maar het mag duidelijk zijn dat curve 1 en 2 niet wenselijk zijn. Met name curve 1 is een traject dat voor Agile projecten een gevaar vormt en één van de belangrijkste redenen is dat Agile projecten falen.
 

Het gevaar bestaat dat er begonnen wordt met de implementatie op een moment dat er onvoldoende inzicht is in de omvang van de doelen, context, scope, domeinelementen, structuren en benodigdheden. Soms zelfs onder druk van het beschikbaar zijn van te veel projectmedewerkers. Meestal leidt dit tot ontwikkeling van softwareonderdelen die achteraf gezien niet gerealiseerd hadden hoeven worden. Een van toepassing zijnde metafoor is ‘het reeds begonnen zijn met metselen terwijl men eigenlijk nog niet precies weet waar de ramen moeten komen of erger nog: de deur’.

Het is dus zaak dat het bouwteam gespitst blijft op het verkrijgen van voldoende inzicht in de domeincomplexiteit zodat de meest ideale lijn om hier te komen genomen wordt. Men weet pas of dit werkelijk gelukt is als er tijdens de eerste sprints geen compleet nieuwe ideeën en inzichten naar boven zijn gekomen en de refactoring dus minimaal geweest is. Om de ideale lijn überhaupt te kunnen volgen is het onder andere van belang dat:

  • De betrokkenen exact dezelfde domeintaal spreken. Hiervoor is een gedetailleerde woordenlijst, een voldoende detaillistisch domeinmodel of een conceptmap2 een waardevol instrument.
  • Wordt er modelmatig gewerkt, dan kan het aantal classes een leidraad zijn. Het is prettig als alle betrokkenen dit model begrijpen. Het model kan eenvoudig gecommuniceerd worden door het model bijvoorbeeld door middel van post-it notes op een voor iedereen toegankelijke plek te hangen. Neemt het aantal gele briefjes af of blijf het aantal al een tijdje stabiel, dan is dit een goede indicatie dat er voldoende inzicht is in de domeincomplexiteit.
  • Neemt het aantal Use Cases of Scenario’s nog steeds toe in aantal of dekken zij nog niet de totale functionele scope, dan is er nog voldoende reden om nog niet met coderen te beginnen.
  • De architectuurblauwdruk voldoende concreet is. Met andere woorden zijn de gekozen concepten en principes correct en voldoende uitgewerkt.

Inzicht in structuurcomplexiteit

Wanneer het probleemdomein voldoende is onderkend en er wellicht een sprint is gestart, dan krijgt het ontwikkelteam te maken met structuurcomplexiteit. Zijn de juiste modules, lagen en bouwblokken in een goede hiërarchische structuur opgebouwd en blijft dat ook zo? Iedere sprint voegt elementen toe die deze structuur mogelijk kunnen ondermijnen. Een goed doordachte structuur kan enorm helpen om problemen te voorkomen. Onvoldoende inzicht, in combinatie met time-to-market, zijn dodelijke vijanden van het behoud van een eenvoudig te begrijpen structuur. Het bewaken van deze structuur is dus ook van belang3.

Voor het toevoegen van iedere nieuwe functionaliteit geldt: Make it work, make it, make it readable. Met andere woorden besteed tijd aan het begrijpbaar houden van de oplossing. Worden hierop concessies gedaan omwille van time-to-market dan zal dit bijdragen aan de Technical Debt4. Over de diverse sprints heen zal dus een constante monitoring moeten worden gedaan om architectuurerosie te voorkomen. Tijdelijke erosie kan omwille van time-to-market worden toegestaan, maar zal later moeten worden teruggebogen.

Hulpmiddel om complexiteit te bewaken

Voor de eerder genoemde vormen van complexiteit zijn technieken en tools op de markt beschikbaar. Sommige zijn gebaseerd op het bijhouden van metrieken, anderen zijn gebaseerd op basis van visualisaties bijvoorbeeld door middel van dependency graphs of matrices. Met name de trending van de resultaten van deze technieken zijn interessant om gedurende de applicatie ‘life cycle’ te volgen. Zij verschaffen belangrijke informatie over:

  • Wordt het systeem complexer?
  • Welk deel van het systeem wordt complexer?
  • Waar moeten wij onze focus leggen als we willen/moeten refactoren?

Een van de meest waardevolle en veelbelovende technieken is het volgen en sturen van de applicatieontwikkeling en het onderhoud door middel van de Dependency Structure Matrix. Met behulp van deze matrix is het mogelijk om de complexiteit van de oplossing op eenvoudige wijze op verschillende abstractieniveaus te visualiseren in een vierkante matrix. Voor verschillende programmeertalen en databases zijn tools beschikbaar. Een voorbeeld wordt in meer diepgang besproken in het kader ‘Voorbeeld Dependency Structure Matrix’.

 

Voorbeeld Dependency Structure Matrix

De Dependency Structure Matrix geeft de afhankelijkheden weer tussen elementen van een systeem. Toegepast op software en meer specifiek op een programmeeroplossing worden de relaties getoond tussen classes (zoals in het diagram). De rijen en kolommen zijn gelijk, de getallen in de cellen geven het aantal afhankelijkheden weer die tussen een element uit de kolom ligt naar de rij. In het voorbeeld is de matrix verrijkt met de volgende informatie:

 

  1. Logisch bij elkaar horende elementen zijn gegroepeerd in de eerste kolom. Bijvoorbeeld ChooseMediaDialog, ImageCanvas en SendDialog horen logisch gezien in de laag UI Layer. Dat het drie in principe losstaande dialog boxes zijn blijkt uit het feit dat geen onderlinge relaties zijn. Dit is wat we zouden kunnen verwachten. Zo zijn er in dit voorbeeld 4 verschillende lagen gedefinieerd. Met andere woorden de logische opbouw (softwarearchitectuur) is ingebracht in de matrix. Dit is gebeurd op basis van drag-and-drop en heeft minimaal tijd gekost.
  2. (In de toekomst) ongewenste afhankelijkheden zijn gemarkeerd (kleine gele driehoekjes) en afwijkingen daarop worden weergegeven met kleine rode driehoekjes. Het resultaat is dat binnen de matrix de werkelijke koppelingen en dus ook eventuele afwijkingen nu eenvoudig zichtbaar gemaakt worden. Afhankelijkheden boven de diagonaal doorkruizen de hiërarchie en geven cyclische relaties aan.
  3. Als de architect ervan overtuigd is dat de linkerkolom de juiste oplossingsarchitectuur representeert, dan wordt het interessant om naar de Metrics waarden te kijken. In dit voorbeeld (een Java Applet van 9 classes) blijkt de System Stability lager te zijn dan 50%, hetgeen betekent dat 1 op de 2 aanpassingen een totale systeemtest verlangd om juist functioneren nog te kunnen garanderen.
  4. Het belangrijkste doel van deze applet, namelijk het herstartbaar kunnen uploaden van grote mediafiles naar een server, wordt echter niet gerealiseerd. Deze functie, onderdeel van ChunkedInputStream, is wel geïmplementeerd, maar wordt niet aangeroepen.

In de praktijk blijken DSM’s een grote bijdrage te leveren in het inzicht verkrijgen en houden van applicaties. Door de laagdrempelige toepasbaarheid is het met name een prima inzetbare manier in Agile projecten waarbij refactoring over het algemeen vaker plaatsvindt.
 

Conclusie

Enige waarschuwing is op zijn plaats. Het is belangrijk te onderkennen dat het juist inschatten en managen van complexiteit cruciaal is voor het slagen van een project. Dit geldt voor ieder procesmodel, maar wordt regelmatig onderschat in Agile projecten waar de filosofie is dat er niet meer aan architectuur gedaan moet worden dan strikt noodzakelijk. Inzicht behouden in de structuur van de oplossing is van nog meer belang. Met behulp van visualisaties kunnen onvolkomenheden in de oplossing worden blootgelegd en ze vormen de basis voor inhoudelijke discussies en resultaatgerichte refactoringslagen. Een goede structuur zorgt voor een lagere totale complexiteit en dus ook voor lagere onderhoudskosten en een kleiner onderhoudsteam.

Categorie:   
Auteur(s)
afbeelding van hanvanroosmalen
Han van Roosmalen
Han van Roosmalen Softwarediensten - Softwarearchitect

Han van Roosmalen is zelfstandig softwarearchitect. Sinds 1986 werkt hij aan grote en kleine innovatieve softwareprojecten in de embedded en de back-office omgeving. Als architect is hij met name geïnteresseerd in de realisatie van systemen conform de juiste structuur, waarbij inzicht, toezicht en overzicht een essentiële rol spelen. Sinds vier jaar werkt hij samen met Lattix, één van de leveranciers van Dependency Structure Matrix tools om snel inzicht te krijgen in de structuur van bestaande applicaties. Han levert verschillende diensten om de toepassing van DSMs snel en effectief te implementeren. Han van Roosmalen is te bereiken via: han@hanvanroosmalen.nl.

Nieuwe reactie inzenden

De inhoud van dit veld is privé en zal niet openbaar worden gemaakt.
Indien het niet lukt om een reactie te plaatsen, stuur dan uw reactie naar redactie@xr-magazine.nl.
Alle inzendingen dienen correct, professioneel en beschaafd te zijn. IP-adressen worden gelogd, maar niet gepubliceerd. De redactie van XR Magazine behoudt zich het recht voor om anonieme reacties (niet op naam) of zonder geldig e-mailadres, te verwijderen zonder kennisgeving. Ook reacties waarin commerciële uitingen worden gedaan en/of commerciële producten en diensten worden aangeboden worden door de redactie verwijderd of ontdaan van commerciële uitingen zonder kennisgeving.