Krijg je nu kwaliteit met DevOps of juist incidenten? Dat is een vraag die ik met regelmaat hoor of lees. Wat doet DevOps nu uiteindelijk met de kwaliteit? Een aantal weken geleden dook ik eens in de data van de incidenten van het afgelopen jaar. De twee grafieken die daaruit te voorschijn kwamen verrasten mij behoorlijk. Achter de vraag of je wel kwaliteit krijgt zitten verschillende veronderstellingen die met deze grafieken worden ontkracht. Ik hoor je denken N=1!
Veronderstelling achter de vraag
Door veel verandering te doen en weinig tijd vrij te maken voor het beheer ervan zou de kwaliteit van het totaal afnemen en daardoor het aantal incidenten toenemen.
Iets bouwen met beheer en onderhoudbaarheid in het achterhoofd is veel te duur.
Het resultaat
De drivers en instrumenten om hier te komen
- Captain of the day, iemand uit het team heeft die dag de verantwoording op binnenkomende incidenten te letten en de eerste acties uit te zetten zo blijven ze niet dagen liggen.
- Automatisering van het deployment proces, door dit te automatiseren worden er minder fouten gemaakt en kunnen gebouwde oplossingen ook snel in productie worden gezet.
- Flow en focus, pak iets op en maak het af.
- Versimpelen van de software door afscheid te nemen van stukjes maatwerk op het pakket (dit onderwerp is nog wel eens een aparte post waard).
- Monitoring van (stukken) software of proces om incidenten voor te zijn.
- Improve! Improve! Improve! Elke sprint opnieuw, keer op keer!
- Support en ruimte van en een goed begrip bij je product owner (ik startte met de opmerking dat ze willekeurige volgorde staan, deze is echter wel van cruciaal belang).
Wat doe jij er aan om je de kwaliteit omhoog te krijgen en je incidenten structureel naar beneden? Ik ben benieuwd naar je strategie op dit gebied.
Wil je een WhatsApp bericht ontvangen bij een nieuwe blog?
Stuur dan even een berichtje naar +31645112490
Andreas, kun je mij uitleggen waarom het nu lijkt of DevOps een totaal nieuwe ontwikkeling lijkt?
Ik weet van eind 70, begin 80-er jaren in de “vorige eeuw” al van deze manier van werken, alleen heten het toen niet zo..sterker, er was geen naam aangegeven, zo werd een projekt standaard altijd opgebouwd en uitgevoerd.
Ik ben ooit, bij een bank, 4 jaar projectleider Maintenace bankbreed geweest en dit was de manier van werken.
M.a.w. waar komt dit nu ineens vandaan??
Groet, Willem
Hoi Willem,
Dank voor je vraag, daar stel je nog al een vraag. Ik was eind 70 en 80 nog niet aan het werk dus daar kan ik weinig overzeggen. We uit de wandelgangen gehoord dat er eerder ook al rapid development frameworks waren.
Zelf denk ik dat zoiets op en neer gaat in golven van ongeveer 15 jaar. Zelf kende ik uit de afgelopen 10 jaar niet deze manier van werken. Waarom ik er fan van ben? Het werkt heerlijk, kleine vaste teams end-2-end verantwoordelijk.
Wat betreft je projecten verschilt dat nu ook van wat jij beschrijft. We brengen geen mensen naar werk maar werk naar mensen. Klinkt als een klein detail maar in mijn optiek een wereld van verschil.
Beantwoord dat je vraag een beetje?