DevOps – een samenstelling van de termen ‘development’ en ‘operations’ – is de nieuwste trend in agile werken. Elders in het blad kunt u lezen over de DevOps-praktijk bij financieel dienstverlener Stater. In dit artikel spreken we met twee experts over de struikelblokken die it-afdelingen en software-ontwikkelbedrijven zoal tegenkomen als zij de stap naar DevOps wagen?
Het samenvoegen van de traditioneel gescheiden afdelingen Ontwikkeling en Beheer – wat de crux is van DevOps – heeft nogal wat voeten in de aarde. Het verklaart grotendeels waarom DevOps nog nauwelijks in de praktijk wordt toegepast, zo blijkt uit een gesprek met Bert van der Zee en Roger Wouterse. Van der Zee doceert als LEAN-specialist aan de Universiteit van Amsterdam en werkt als zelfstandig consultant op het gebied van DevOps, big data en procesmanagement. Wouterse is productmanager bij SYSQA, een onafhankelijk bureau op het gebied van software testing en business IT alignment, ook wel quality assurance (QA) genoemd.
Roger Wouterse
DevOps: de kern
Het snelle ontwikkelen van software volgens Agile Scrum vraagt om een even snelle in productie name. Het vele handwerk in het proces van testen, accepteren en in productie nemen sluit niet langer aan op Agile Scrum, dus die drie elementen van de OTAP-straat moeten het liefst op volledig geautomatiseerde wijze verlopen. Alleen dan kan er snel worden gereleasd. Dit vergt een technologische en procesmatige integratie van ontwikkeling en beheer. Dat is de kern van DevOps.
De hele organisatie
Beide experts zien dat Agile Scrum weliswaar populair is, maar dat het vaak ten onrechte een it-feestje blijft. “Het gaat juist om het leveren van een hogere kwaliteit software door een betere samenwerking tussen IT en de business,” zegt Van der Zee. “Ik zie teveel organisaties die Agile Scrum alleen inzetten om sneller en daardoor goedkoper te ontwikkelen. Dat is zeker een voordeel, maar wie focust op kostenbesparing beknibbelt op kwaliteit.”
Dat betekent dat een bedrijf moet veranderen, in alle geledingen. Wouterse: “Zoals je niet een beetje zwanger kunt zijn, kun je ook niet een beetje Scrum doen. Je hele organisatie moet veranderen. Als je alleen het software-ontwikkelteam op een nieuwe manier laat werken, dan leg je als het ware een V8-motor in een DAF-je: de auto is helemaal niet ontworpen voor de snelheid die een V8-motor ontwikkelt. Het gevolg: dramatisch rijgedrag waarbij je bij het minste of geringste uit de bocht vliegt. Als je in tweewekelijkse sprints software gaat opleveren, betekent dit bijvoorbeeld dat de business ook tweewekelijks die nieuw ontwikkelde functionaliteit moet beoordelen. Ook moet men bedenken aan welke nieuwe functies daarna de meeste behoefte bestaat. Je kunt niet meer werken met een traditionele backlog waarbij je de items stuk voor stuk afwerkt, je moet steeds opnieuw prioriteiten stellen. Ook dat is een continuproces geworden.”
Peter van der Zee
Welke methode?
De indruk bestaat wellicht dat iedere organisatie op een Agile Scrum-manier ontwikkelt, maar de praktijk is anders. Bovendien, zo waarschuwt Van der Zee, is Agile Scrum helemaal niet voor ieder software-ontwikkelproject geschikt. “Als je specs duidelijk zijn, dan werkt de watervalmethode sneller. En ook in organisaties met veel legacy-systemen kun je vaak beter andere software-ontwikkelmethoden hanteren. IT-managers zouden hier veel meer oog voor moeten hebben en veel nadrukkelijker moeten stilstaan bij de vraag welke methode je in welke situatie inzet.” Agile Scrum werpt bijvoorbeeld wel zijn vruchten af bij de ontwikkeling van front-end applicaties. Omdat je op voorhand niet precies weet welke wensen klanten hebben en je dit vaak ook heel lastig goed kunt uitvragen, is het beter om via korte sprints steeds nieuwe functionaliteit te ontwikkelen en op te leveren, om vervolgens in een productie-omgeving te meten hoe goed deze wordt gebruikt (zie kader ‘Machine learning’).
Machine learning
IT-organisaties meten en verbeteren de kwaliteit van de door hen ontwikkelde software door te testen. Je weet dan echter nog niet hoe de externe klant het systeem werkelijk ervaart. Binnen DevOps heb je die snelle feedback wel nodig. Bert van der Zee adviseert grote software-ontwikkelafdelingen om op basis van data te analyseren wat de kwaliteit is van de opgeleverde functionaliteit. Dit kan met ‘machine learning’: algoritmen die leren van data en daardoor steeds beter worden. “Met deze vorm van big data analytics vertaal je de beleving van de externe klant van de nieuwe software naar interne metingen. Op deze manier krijg je een veel realistischer beeld over zaken als gebruiksgemak en dus klanttevredenheid, dan wanneer je de klantbeleving uitvraagt via enquêtes.”
You build it, you run it
In de traditionele OTAP-straat staat de O vaak behoorlijk ver af van de TAP-processen. In een DevOps omgeving liggen ontwikkelen, testen, accepteren en in productienemen en het beheren van de software dicht bij elkaar. DevOps gaat namelijk uit van het principe: you build it, you run it. Ontwikkeling en beheer komen in één hand te liggen, waardoor de ontwikkelaar veel nauwer betrokken is bij de kwaliteit van de applicatie. Hierdoor moet hij bij de ontwikkeling al nadenken over aspecten als security en beheer van de applicatie. “Traditioneel gingen software-ontwikkelafdelingen vaak uit van het principe: de kwaliteit testen we er wel in,” weet Wouterse. “Met andere woorden: we herstellen de fouten wel achteraf. Maar iedereen weet: voorkomen is beter dan genezen. Mijn advies is daarom: hou bij de ontwikkeling al rekening met de kwaliteitsaspecten. Bovendien leidt alleen slim testen zo vroeg mogelijk in het ontwikkelproces tot betere kwaliteit. Het testen in DevOps-projecten kan dan ook worden beperkt tot de meest kritische functionaliteit, mede dankzij het principe van Continuous Delivery: zeer kleine updates van software, vaak meerdere keren per dag. Doordat de updates klein zijn, is de impact van een fout vrijwel nihil.”
Ruimte voor fouten
Binnen DevOps werken ontwikkelaars, testers en beheerders samen in één team dat nauwe aansluiting heeft met de business. Dit verandert het speelveld volkomen, weet Wouterse. “Je kunt niet simpelweg de traditionele functies vertalen naar een rol in een Agile DevOps-team. Je kunt veel beter kijken naar de vaardigheden en expertises van de mensen in je team en aan de hand daarvan de rollen bepalen.” Van der Zee gebruikt voetbal als metafoor: “Als je de taken goed hebt verdeeld en iedereen weet wat hij moet doen, dan loopt het gesmeerd. Je kunt echter niet te strak vasthouden aan de rollen. Een aanvaller moet immers ook wel eens verdedigen en soms heeft een verdediger kans om te scoren. Die ruimte moet er zijn en die ruimte moeten de spelers durven te nemen. Dit vereist goede onderlinge communicatie, anders loopt het mis. Zoals je van de F-jes geen hogeschool positiespel kunt verlangen, kun je ook van een beginnend Agile team niet verwachten dat ze dit vanaf de eerste dag meteen in de vingers hebben. Dit vergt maanden-, zo niet jarenlange training, waarbij je steeds opnieuw in een trainingssituatie de spelpatronen herhaalt, net zolang tot ze zodanig zijn ingesleten dat ze onder hoogspanning in een wedstrijd automatismen zijn geworden.” Met andere woorden: je brengt dit een team niet in drie maanden op niveau. “Het vergt minimaal twee jaar om tot een mager zesje te komen,” schat Wouterse in. “Neem die tijd en geef je DevOps-teams de ruimte om fouten te maken. Want fouten maken is de enige manier waarop je snel leert en waarbij datgene wat je leert ook écht beklijft. Dit is geen boekjeskennis, je moet het in de praktijk gewoon gaan doen. Dat betekent ook dat de teams moet worden aangestuurd op een manier die bij deze lerende ontwikkeling hoort. Manage je dit op traditionele wijze – met KPI’s gericht op voorspelbaarheid, stabiliteit en het voorkomen van fouten – dan wordt het nooit wat.”
