Van Waterval via Scrum naar DevOps

| auteur: Remco van Aarst

Remco van Aarst is Testcoördinator binnen Immune-IT en ingezet als Scrum Master bij een van onze klanten. In het artikel hieronder geeft Van Aarst zijn ervaring weer met de overgang van Scrum naar DevOps.

Remco van Aarst: “De klant waar ik ben ingezet heeft er recentelijk voor gekozen om grootschalig DevOps in te voeren. Een dergelijke verandering gaat natuurlijk niet zonder slag of stoot. Temeer omdat de klant een jaar eerder al was overgestapt van het ontwikkelen via de klassieke Watervalmethode naar Agile/Scrum. Tegelijkertijd kreeg het bedrijf ook nog eens te maken met een grote reorganisatie.”

De stap van Waterval naar Agile/Scrum
Agile/Scrum is eind 2011 door klant gekozen om de doorlooptijd van een software ontwikkeltraject te verkorten en daarmee de kosten terug te dringen. “More bang for your buck” is het credo.

Om de doelstelling te bereiken zijn er Scrum teams samengesteld, waarbij alle functies die nodig zijn voor een succesvolle oplevering vertegenwoordigd zijn. Een team bestaat uit minimaal één bouwer, minimaal één tester en minimaal één functioneel ontwerper. Daarnaast kunnen er binnen een team natuurlijk nog meer verschillende functies bestaan. Aan het hoofd van een team staat de Scrum Master. In totaal bestond ons scrumteam uit 9 personen.

Omdat alle disciplines binnen het team zelf aanwezig zijn heeft het team als enige focus het aan het team toegewezen project en kan er veel sneller gewerkt worden dan met een traditionele waterval ontwikkelmethodiek. Er wordt gewerkt via kleine iteraties (sprints) van 3 weken. Dit wordt onder meer gedaan om gevonden fouten in de ene iteratie of nieuwe inzichten na aanleiding van de eerste resultaten te herstellen in de volgende iteratie. Hierdoor worden nieuwe iteraties niet boven op “bestaande” fouten ontwikkeld.

Een nadeel van het testen in kleinere iteraties is dat er vaker een regressietest moet worden uitgevoerd. Na elke iteratie die een al eerder ontwikkeld stuk software raakt, moet er opnieuw een regressietest worden gedaan over het gedeelte dat al klaar was.

Omdat er bij de klant zo lang volgens de watervalmethodologie is gewerkt, was de neiging nog steeds groot om van de iteraties een serie kleine watervalletjes te maken. Met andere woorden: De ontwerper ontwerpt het proces, als het ontwerp volledig is gaat de bouwer bouwen en als de programmatuur klaar is gaat de tester testen. Binnen een sprint van maar 3 weken is hier eigenlijk geen tijd voor.  Ontwerpen, bouwen en testen moet dus parallel gaan plaatsvinden binnen de sprint. Zodra de ontwerper begint aan het ontwerp begint de bouwer alvast met de hoofdlijnen van de programmatuur op basis van wat de ontwerper vertelt te gaan doen. Gelijk begint ook de tester met het specificeren van de testgevallen. Er zijn veel teams tegelijkertijd met hun eigen sprint bezig; hierdoor kunnen er situaties ontstaan waarin wijzigingen in de programmatuur door één team de programmatuur bij een ander team raakt. Dit is precies waar nu problemen ontstaan in het ontwikkelproces.

In een organisatieonderdeel waar elk jaar vele wijzigingen worden doorgevoerd, is dit misschien ook niet verwonderlijk. Om problemen bij deze verweven wijzigingen te voorkomen is het belangrijk om altijd exact de kwaliteit van de software die onderhanden is te kunnen beoordelen. Niet alleen de kwaliteit van de onderhanden software van het eigen team maar ook die van de andere teams. Een fout gelopen wijziging op programmatuur zou een ander team immers compleet op een dwaalspoor kunnen brengen.

Om een goed gedetailleerd beeld te krijgen van de wijzigingen die worden gedaan, moet eigenlijk elke dag alle processen worden getest. Alleen dan zullen alle wijzigingen die het proces veranderen of verstoren direct aan het licht komen. Om meer grip te krijgen op dit proces heeft de klant besloten om de overstap te maken naar ontwikkelen volgens de DevOps-methode.

De stap van Agile/Scrum naar DevOps
Medio 2013 is de klant formeel overgestapt op DevOps. Op de vraag “Wat is DevOps?” wordt niet overal hetzelfde antwoord gegeven.

devopsIn het algemeen wordt DevOps gezien als: “Een combinatie van de concepten van development en operations. In de IT wordt de term gebruikt om te refereren naar rollen of processen die verschillende afdelingen overlappen, gewoonlijk development en operation teams, om een projectmanagement filosofie te bewerkstelligen waarin efficiëntere communicatie plaatsvindt tussen development teams en andere onderdelen van een groter proces of organisatie.”


Pragmatischer is misschien wel de volgende omschrijving van een bezoeker van een forum over DevOps: “The essence of DevOps, I believe, is to design a system in which people are held responsible for the consequences of their actions – and indeed, one in which the right thing to do is also the easiest thing to do.”

DevOps bepaalt nu bij mijn opdrachtgever de samenstelling van de ontwikkelteams. Dit houdt voor de teams in dat er naast de product owner, Scrum Master, programmeurs en testers er ook een functioneel beheerder in het team komt.  DevOps staat immers voor het integreren van development- en operationsfuncties in één team.  De teamleden zijn naast het ontwikkelen van nieuwe software ook verantwoordelijk voor het beheer van de software en het oplossen van incidenten en problems die zijn voortgekomen uit de geleverde software.

Binnen de klant wordt dit heel pakkend omschreven als “eat your own dogfood”. Dit motiveert natuurlijk om kwalitatief goede software te leveren. Doordat er tegelijkertijd een bezuinigingsslag werd doorgevoerd, is het nieuwe team even groot gebleven als voorheen, maar dit is nu inclusief de functioneel beheerder. Met een Dev-medewerker minder en in totaal het zelfde aantal medewerkers moet dus het normale werk worden verzet maar ook de incidenten worden behandeld en de software beheerd.

Om met het zelfde aantal teamleden meer werk te verzetten is het nodig om een automatiseringsslag door te voeren. Het ontwerpen van de software en het bouwen blijft veelal handwerk, maar het compileren, testen en deployen dient zoveel mogelijk geautomatiseerd te worden zodat er tijd over blijft voor het behandelen van incidenten en het ontwikkelen van nieuwe software. Het automatisch compileren, testen en deployen en dus continu kunnen leveren zonder overdrachtsmoment naar functioneel beheer buiten het team, zoals in de Waterval- en Agile/Scrum-methode, wordt Continuous Delivery genoemd. Deel oplossingen heten Continuous Integration.

Continuous Integration en Continuous Delivery
Onder Continuous Integration (CI) verstaan we snelle, geautomatiseerde deployments van de ene omgeving naar de andere. Dat kan de traditionele ontwikkeling, test, acceptatie en productie (otap)-straat zijn, maar ook het kortcyclisch verbinden van ‘zij-straten’ valt hier onder. Dit geeft de mogelijkheid om snel de kwaliteit van de nieuwe software te testen en te toetsen. Op zich wordt dit binnen Agile projecten ook vaak al gedaan om de afstand tussen ontwikkelaars en testers te verkleinen. Continuous Delivery (CD) hanteert min of meer hetzelfde principe, alleen is er sprake van nog meer automatisering en nog minder afbakening van een release. Feitelijk is er een volledig geautomatiseerde gang naar productie, zonder menselijk ingrijpen. Alle stappen worden namelijk geautomatiseerd getest in een framework. CD stelt je in staat om zeer frequent in zeer kleine batches software op productie te releasen. Soms zelfs meerdere keren per dag. Die updates zijn zo klein dat de impact van een fout vaak nihil is. Dit wordt ‘geharnast’ door een uitgebreide set aan geautomatiseerde tests die de belangrijkste risico’s afvangen.

Het automatiseren van het software ontwikkelproces resulteert in het sneller kunnen leveren van software die voortgekomen is uit een proces met lagere kosten en in het sneller kunnen inspelen op vragen van de klant. Dit sluit volledig aan bij de missie van de klant, het leveren van producten en diensten met een uitstekende service, gebruiksgemak en tegen concurrerende tarieven. Het is dan ook niet vreemd dat het hogere management, inspelend op de veranderende markt, opdracht heeft gegeven om te bouwen aan een Continuous Delivery straat die bij moet dragen aan het realiseren van de bedrijfsdoelstellingen.

In mijn Devops team wordt er veel tijd gestoken in het ontwikkelen van een Continuous Delivery straat. Dit gebeurt op dit moment voornamelijk door de testers in het team, waarbij er getracht wordt ook de rest van het team hierbij te betrekken. Daarnaast wordt regelmatig overlegd met andere teams over de te nemen vervolgstappen. Uiteraard zijn we er nog lang niet. Om echt van Continuous Delivery te kunnen spreken moeten er nog een aantal zaken worden gedaan.
Daarbij treden vragen op zoals:

  • Wie gaat de tooling gebruiken? En wie gaat de gemaakte scripts beheren?
  • Is er voldoende draagvlak onder de scrumteams voor geautomatiseerd testen en de nieuwe tooling die daarvoor nodig is?  Hoe is het aanwezige draagvlak te maximaliseren?
  • Wat is het toolbeleid van de organisatie met het invoeren van testtools
  • Hoe wordt het benodigde kennisniveau geborgd?
  • Wat zijn de opleidingsmogelijkheden?
  • Voor wie zijn die opleidingen dan?
  • Hoe moet de roadmap naar volledig geautomatiseerd testen / ontwikkelen eruit zien?
  • Met het samenstellen van DevOps teams is er al een belangrijke stap gezet, maar hoe nu verder?
  • Hoe worden de verschillende soorten (project/proces) risico’s afgedekt?

Op deze vragen wordt nu gaandeweg antwoord gegeven.