Digital Customer Experience Blog

Digital Customer Experience Blog

Meningen op deze blog weerspiegelen de opvattingen van de schrijver en niet per definitie die van de Capgemini Group

Agile kwaliteits- en productiviteitsverbetering: Quality-Driven Scrum


Het ‘agile’ proces en Scrum kennen grote voordelen, zowel voor de stakeholders als voor het ontwikkelteam. In betrekkelijk korte tijd wordt de belangrijkste functionaliteit geproduceerd waarbij de focus enerzijds ligt op de ‘backlog’ en anderzijds op de (geteste en becommentarieerde) code. De ‘brug’ tussen deze twee is de architectuur.

Door op belangrijke momenten code te ‘refactoren’, wordt de structuur van de code verbeterd. Daarbij kan het voorkomen dat de bij refactoring toegepaste ontwerpkennis impliciet blijft, doordat niet expliciet gebruik wordt gemaakt van kennis zoals ‘design principles’ en ‘design patterns’. In dat geval verbetert de structuur weliswaar vanuit een bepaald impliciet perspectief, maar wordt de code niet toegankelijk gemaakt via een hoger abstractieniveau.

Een tweede Scrum proces
Het voorstel is nu om, naar behoefte en parallel aan het ‘normale’ Scrum proces, een tweede Scrum proces te definiëren. Dit tweede proces richt zich op de totstandkoming van een expliciet design, met als doel om knelpunten in de structuur van de code uit het eerste proces op te lossen. Vanwege de hiermee beoogde kwaliteitsverbetering introduceer ik het proces hier onder de naam ‘Quality-Driven Scrum’. De output van Quality-Driven Scrum is design-informatie in plaats van code. Deze design informatie betreft hetzelfde product op een hoger abstractieniveau en doet uitspraken over de structuur van de code in het normale proces.

Voor het normale Scrum proces geldt:

  • backlog: geprioriteerde user stories;
  • output: executeerbare code;
  • ‘brug’: architectuur.

Voor het Quality-Driven Scrum proces geldt (*):

  • backlog: geprioriteerde knelpunten in de structuur van de code;
  • output: design specificatie;
  • ‘brug’: design patterns, design principles.

Quality-Driven Scrum toepassen
Scrum en Quality-Driven Scrum zijn gekoppeld omdat (a) de backlog voor Quality-Driven Scrum zich richt op knelpunten in de structuur van bestaande code, en (b) de ontwerpresultaten van Quality-Driven Scrum uiteindelijk dienen te worden vertaald naar een herstructurering van de code in het ‘normale’ Scrum proces. In koppeling (a) worden ‘as-built’ UML modellen gebouwd van de knelpunten in de code. Tijdens Quality-Driven Scrum worden op deze modellen ‘design principles’ en ‘design patterns’ toegepast om te komen tot UML specificaties. Tenslotte wordt in koppeling (b), op een geschikt tijdstip, de code in het normale Scrum proces in lijn gebracht met de ontwerpspecificaties.





De voordelen van Quality-Driven Scrum:

  • Er ontstaat (voor kritieke delen in de code) een ontwerp-specificatie;
  • Omdat het expliciete ontwerp de nadruk legt op hoger liggende principes en patronen, wordt de code toegankelijker via een hoger abstractieniveau (ook na lange tijd of voor andere developers);
  • Een verdere kwaliteitstoename resulteert naar verwachting in een productiviteitstoename van developers tijdens een vervolgontwikkeling;
  • Door een tweede Scrum proces op te richten voor design, blijven de voordelen van een ‘agile’ ontwikkeling voor het ‘normale’ proces behouden;
  • Omdat het expliciete design het resultaat is van een Scrum proces, gelden hiervoor de voordelen van een ‘agile’ proces; in betrekkelijk korte tijd wordt het belangrijkste deel van het design gerealiseerd.

Natuurlijk vereist bovenstaand voorstel een investering. Echter, de toegevoegde waarde van het toepassen van Quality-Driven Scrum zal meegroeien met de omvang van de codebase en de levensduur en wijzigingsgevoeligheid van de code. Vanaf een bepaald punt betaalt het zich terug in de kwaliteit van het eindproduct en de productiviteit van de betrokken ontwikkelaars.

(*): Het proces van Quality-Driven Scrum zoals hier beschreven kan naar behoefte worden uitgebreid naar andere aspecten van het product zoals UX, in combinatie met bijvoorbeeld style guides.

Over de auteur

Don Duell
Don Duell
Don is a consultant Online Technology at Capgemini, with a focus on front-end development. He has a solid background in software engineering and game design.
6 Reacties Plaats een reactie
dduell's picture
In lijn met IEEE 1471 en ISO 12207 omvat een architectuur de top-level ontwerp-beslissingen (betreffende fundamentele structuur en relaties, doelstellingen, eisen en strategieën). Quality-Driven Scrum richt zich op de latere ontwerp-beslissingen op detailed design niveau. Via Quality-Driven Scrum wordt er een extra accent gelegd op het detailed design, zonder de voordelen van een Agile proces te verliezen.
mkouwenb's picture
Vanuit ervaring passen we dit al vaak toe voor het UX deel. We maken dus de specificatie in sprint 1 zodat de realisatie in sprint 2 kan gebeuren. We zagen namelijk dat in een sprint de specificaties en keuzes van de business vrij laat nog veranderde of defintief werden. Dat had te veel discussie en gevolgen voor het ontwikkelde werk.
skranend's picture
Marcel, Ik denk dat wat je hier bedoelt meer een 'staggered' approach is, waarmee je ux/visual een sprint vooruit kunt laten lopen op realisatie. Het verschil is met name dat het door Don opgestelde idee in beide gevallen om technische sprints gaat, waarbij er extra aandacht is voor architectuur en design t.o.v. van de veel geziene 'eenvoudige' of 'get it done' aanpak, die enkel op functionele/technische realisatie van functionaliteit focust, waardoor het grotere geheel en technisch ontwerpplaatje in het gedrang komt (kan komen).
shsmith's picture
Hebben we hier niet gewoon een Software Architecture Document voor?
dduell's picture
Het QD-Scrum beschrijft het incrementeel totstandkomen van een ontwerp voor geïdentificeerde knelpunten, volgens een agile proces zoals dat ook geldt voor de code, waarbij de product owner zich kan uitspreken over de prioriteit en balans. De beschrijving van QD-Scrum als te onderscheiden proces is gerechtvaardigd omdat het ontwerp zich op een ander abstractieniveau bevindt dan de code. Bij het wegvallen van het onderscheid tussen de twee soorten sprints dienen naar mijn mening de verschillende doelstellingen nog steeds te worden onderkend om tot een heldere prioriteitsstelling te komen. Ook dient het wegvallen van het onderscheid niet te leiden tot een 'mini waterval proces' binnen een sprint, omdat dan de voordelen van een agile proces verloren gaan.
Don, ik vraag me af hoe makkelijk je draagvlak voor volledig technisch/QA-georiënteerde geregeld krijgt. Zou het niet veel makkelijker en logischer zijn om dit soort zaken onderdeel van het standaard development proces te maken en mee te nemen in een 'standaard' sprint? Dan blijf je qua delivery inhoud van een sprint de balans houden tussen functionaliteit en niet-functionaliteit.

Plaats een reactie

Uw e-mailadres wordt niet gepubliceerd. Verplichte velden zijn gemarkeerd met *.