Development

Software-ontwikkeling
Scrum board

Het schijnbare 
tekort van Scrum

© Shutterstock
31 mei 2013

 

Het tekort van Scrum’ was de titel van een artikel van Chris Verhoef in de AutomatiseringGids van 13 september 2012. In dit artikel stelt Verhoef dat agile ontwikkelmethodes, zoals Scrum, niet geschikt zijn voor het ontwikkelen van stabiele en betrouwbare software. Met andere woorden, dat deze methodes dus niet geschikt zijn voor veiligheidskritische software, zoals bijvoorbeeld voor medische apparatuur. Zulke zogenaamde ‘gereguleerde domeinen’, zoals de auto-industrie, gezondheidszorg en farmaceutische industrie, worden streng bewaakt door regulerende autoriteiten, bijvoorbeeld de Amerikaanse Food & Drug Administration (FDA). Verhoef zegt dat andere beroepen in zulke domeinen (medici, piloten) continu bijscholing vereisen, en suggereert dat overheden en toezichthouders softwareontwikkeling zouden moeten reguleren om te voorkomen dat ‘iedereen aan software (kan) zitten’. Het artikel concludeert: ‘Het goede voorbeeld is de FDA en niet Scrum.’

Verhoef noemt een aantal problemen, zoals instabiele eisen en wensen van de klant en een continu tekort aan tijd voor testen. Hij heeft natuurlijk gelijk dat dit twee veelvoorkomende problemen zijn. Bovendien worden de complexiteit en de subtiliteit van softwareontwikkeling vaak onderschat door managers, die de softwareontwikkelafdeling beschouwen als een productieafdeling. Echter, Verhoefs betoog haalt een aantal dingen door elkaar, en als gevolg daarvan worden agile methodes ten onrechte beschouwd als ‘chaotisch’ of ‘ongedisciplineerd’. Deze tegenstelling tussen agile en zogenaamde plangestuurde methodes, zoals de watervalmethode en het V-model, wordt door sommige experts wel gekarakteriseerd als ‘agile versus gedisciplineerd’. Maar dit is in beginsel onjuist.

 

Geen tegenstelling

Softwareontwikkeling is inderdaad complex en lastig. Naast de genoemde problemen in softwareontwikkeling noemt Verhoef nog dat 7,7 procent van de product-recalls te wijten was aan softwareproblemen en dat 79 procent van die recalls te wijten was aan defecten geïntroduceerd na oplevering. Deze cijfers zijn niet zo vreemd, gezien het toenemende gebruik van software in alledaagse producten – denk aan moderne tv’s, magnetrons en koffiezetapparaten. Daarnaast vindt het merendeel van softwareonderhoud plaats na oplevering, dus ook dat is niets nieuws. Bovendien wordt onderhoud vaak gedaan door anderen dan de oorspronkelijke ontwikkelaars; het corrigeren van fouten in een groot en complex softwaresysteem is lastig genoeg, laat staan als je het niet zelf hebt geschreven.

Het zou inderdaad kunnen dat deze defecten het gevolg zijn van het ‘even snel’ aanpassen, zoals Verhoef suggereert. Maar de conclusie dat daarom agile methodes niet geschikt zijn, is ongegrond. Als we kijken naar het Agile Manifesto (zie kader), dan lijkt agile inderdaad minder geschikt dan plangestuurde methodes. Vooral het V-model wordt veel gebruikt in veiligheidskritische softwareontwikkeling omdat het zich uitstekend leent voor verificatie van de software op verschillende niveaus. Echter, er is geen enkele regel of standaard die dit model voorschrijft, alleen maar dat er een gedefinieerd proces is. Een mogelijke oorzaak van de slechte naam van agile methodes is dat zij (ten onrechte) als ‘ongedisciplineerd’ worden gekarakteriseerd. Maar ‘agile versus gedisciplineerd’ is in beginsel een onjuiste tegenstelling. Bovendien hebben veel IT’ers wel van agile methodes gehoord, maar zich er nooit in verdiept; veel ontwikkelteams die geen formeel proces volgen, noemen zichzelf ‘agile’. De Scrum-methode bijvoorbeeld, is een welgedefinieerd raamwerk dat structuur aanbrengt in het ontwikkelingsproces. Het implementeren en volgen van dit raamwerk vereist wel degelijk discipline, en is zeker geen vorm van ‘Cowboy Coding’. Je zou Scrum zelfs kunnen beschouwen als een serie ‘V’s’ (zie kader).

 

Extra aandacht

Het standaardraamwerk Scrum biedt voldoende houvast aan ontwikkelteams voor ‘normale’ softwareontwikkeling. Voor het ontwikkelen van veiligheidskritische software is het verstandig om extra aandacht te geven aan een aantal zaken.

Een van de belangrijkste aandachtspunten in gereguleerde domeinen is traceerbaarheid van het ontwikkelproces, en dit is waarschijnlijk een van de bronnen van Verhoefs zorgen over het gebruik van Scrum. Het traceren van het hele proces, vanaf de gebruikerseisen tot aan implementatie en de testresultaten, kan bijzonder ingewikkeld worden. Het gebruik van tabellen die manueel worden bijgehouden, is niet ongewoon. Om dit te doen in een iteratief ontwikkelproces zoals Scrum, is schijnbaar nog lastiger, omdat het in elke iteratie gedaan moet worden. Om traceerbaarheid onder controle te houden, is goede toolondersteuning absoluut een vereiste. Een goede toolset bestaat uit een geïntegreerde set van componenten voor issue en defect tracking, integratie van de sourcecoderepository, een wiki, projectbeheer en code-inspectie. Zo’n uitgebreide toolset voorkomt het manueel moeten aanleggen van alle ‘links’, die automatisch worden gelegd tussen alle artefacten (zoals ontwerpdocumentatie en broncode). Dit faciliteert volledige transparantie van het ontwikkelproces.

Een ander aandachtspunt is de rol van kwaliteitszorg (Quality Assurance, QA). De beslissing om Scrum in te voeren kan niet alleen gemaakt worden door het ontwikkelteam. Veel standaarden vereisen dat QA bestaat uit een apart team, dat losstaat van het ontwikkelteam. Waar QA bij een klassieke watervalaanpak het hele softwareproduct in één keer moet controleren, komt het bij Scrum veel vaker in actie. Mocht er iets niet in orde zijn, dan kan dit middels een ‘non-conformance’-rapport worden vastgelegd, wat dan zo snel mogelijk moet worden opgelost. Zo wordt het kwaliteitsproces getransformeerd van een aparte fase tot een iteratief proces. Het resultaat is ‘continuous compliance’: het product is altijd compliant met de vereiste regels.

Binnen Scrum wordt het werk opgedeeld in een aantal taken, die worden vastgelegd in een productbacklog. Om ervoor te zorgen dat elke taak correct is uitgevoerd (om non-conformance te voorkomen) is het verstandig om een extra ‘peer-review’ uit te voeren nadat de taak klaar is.

Voordat het product wordt afgeleverd aan de klant kan een ‘hardening’ sprint worden uitgevoerd. Hierbij ligt de nadruk op het verzekeren van de compliance en het volledig klaarmaken van het product. Omdat hier voortdurend aandacht voor is (continuous compliance), is dit voornamelijk een controleronde, in tegenstelling tot een kritische fase van het watervalmodel.

Een laatste aanpassing van het standaard-Scrum-model is een extra rol binnen het ontwikkelteam, die verantwoordelijk is voor de productdocumentatie. Dit is een extra mechanisme om ervoor te zorgen dat de documentatie altijd up-to-date is.

Scrum biedt veel voordelen boven het watervalmodel, die zeker ook binnen gereguleerde domeinen kunnen worden gerealiseerd. Het is wel belangrijk om Scrum eerst goed te begrijpen, en vervolgens uit te breiden waar nodig, om extra ondersteuning te bieden.

Noodzakelijke uitbreidingen

  1. Geïntegreerde en uitgebreide toolondersteuning voor traceerbaarheid.
  2. De hele organisatie moet worden betrokken bij het proces, zoals bijvoorbeeld kwaliteitszorg.
  3. Een non-conformance report wordt onderdeel van de Scrum-review.
  4. Peer-review na elke taak.
  5. Een ‘hardening’ sprint voor productoplevering.
  6. Een specifieke rol voor documentatie.

Waterval, V-Model en Scrum

  • De watervalmethode is een van de oudste methodes om het softwareontwikkelingsproces in te richten. Het proces bestaat uit een aantal fasen. Elke fase moet eerst volledig worden afgerond voordat de volgende fase kan beginnen. De meest voorkomende fases zijn: gebruikerseisen, architectuurontwerp, gedetailleerd ontwerp, implementatie, integratie en testen. Na het testen wordt het systeem opgeleverd en bevindt het systeem zich in de onderhoudsfase
  • Het V-model is in feite een watervalmethode, maar met een expliciete focus op verificatie. Elke fase in de ontwikkeling heeft een tegenhangende fase om de ontwikkelingsfase te verifiëren.
  • Scrum is een metafoor uit de rugbywereld. Het is een iteratief en incrementeel proces, waarbij het product stap voor stap wordt ontwikkeld, in plaats van een ‘big bang’-aanpak zoals bij de watervalmethode. Scrum is een van de meest populaire agile methodes en bestaat uit 3 x 3 elementen: drie rollen: Scrum-master, product owner en het team; drie ceremonies: sprint planning, dagelijkse Scrum en sprint review (retrospective); drie artefacten: product backlog, sprint backlog en burndown chart.

Agile Manifesto

Wanneer we kijken naar het Agile Manifesto dat ten grondslag ligt aan agile methodes, lijkt de conclusie dat deze methodes niet geschikt zijn voor gereguleerde domeinen, voor de hand te liggen:

  • ‘Individuen en interacties’ boven ‘proces en tools’.
  • ‘Werkende software’ boven ‘uitgebreide documentatie’.
  • ‘Samenwerking met de gebruiker’ boven ‘contractbepalingen’.
  • ‘Reageren op verandering’ boven ‘het volgen van een plan’.

Voorstanders van agile bekennen dat de elementen aan de rechterkant belangrijk zijn maar dat de focus moet liggen op de elementen aan de linkerkant. Echter, de elementen aan de rechterkant zijn juist heel belangrijk in gereguleerde omgevingen. Bijvoorbeeld, een gedefinieerd proces, uitgebreide proces- en productdocumentatie, contractvoorwaarden met betrekking tot aansprakelijkheid, en het volgen van een gepland ontwikkelproces staan hoog in het vaandel bij regulerende autoriteiten zoals de Amerikaanse FDA. En dus: deze snelle en oppervlakkige vergelijking geeft inderdaad de indruk dat agile methodes niet geschikt zijn voor gereguleerde softwareontwikkeling.

 
Lees het hele artikel
Je kunt dit artikel lezen nadat je bent ingelogd. Ben je nieuw bij AG Connect, registreer je dan gratis!

Registreren

  • Direct toegang tot AGConnect.nl
  • Dagelijks een AGConnect nieuwsbrief
  • 30 dagen onbeperkte toegang tot AGConnect.nl

Ben je abonnee, maar heb je nog geen account? Laat de klantenservice je terugbellen!