Werken aan een nieuwe manier met DevOps

Geplaatst door Ernst Veen

In mijn vorige blog schreef ik dat DevOps dus een soort cultuur – een manier van werken – is. En hoewel ik vind dat je een cultuur niet kan opleggen, zijn er wel enkele gemene delers die ik in deze blog uiteen probeer te zetten. Het maken van software doen we al vele jaren op verschillende manieren. We kennen allemaal de voorbeelden van onze overheid waar dit jaren duurt, miljoenen euro’s kost en uiteindelijk niets van de grond komt. In veel gevallen omdat we meteen van het begin af aan die Ferrari willen bouwen terwijl dat niet meteen nodig is. Ook omdat we tijdens de bouw rekening proberen te houden met de veranderde omstandigheden in de markt. Alleen de traditionele waterval-methode is hiervoor niet geschikt. Daardoor krijgen we falende softwareprojecten in heel veel branches.

Traditioneel verdrinken we ook geregeld in roadmaps en backlogs. Dat ontstaat omdat we nu al denken te weten wat eind volgend jaar nodig is. Hierdoor duurt het soms te lang voor een functionaliteit beschikbaar komt, en op dat moment is de vraag er niet meer of de concurrent was wel wendbaarder. De tijd dat we voor 1, 3 of 5 jaar een roadmap maken tot in detail ligt achter ons. Natuurlijk kan je de contouren bepalen en heb je echt wel een idee waar je naar toe gaat. De framework gedachte is heel handig. Echter de detail-invulling komt tijdens de reis. Op die manier heb je ook tijd om gave functionaliteit toe te voegen op het moment dat de markt of je klanten daaraan toe zijn.

Groot voordeel van deze aanpak is dat je relevante uitstapjes kunt maken naar marktomstandigheden, branchewijzigingen, politieke impact of andere wijzigingen of wensen die jouw klanten nodig hebben.

Werk komt nooit meer af

Een veel gehoord credo. We krijgen het nooit af. Weer een voordeel van de DevOps manier. Omdat je dan ook nooit klaar bent. Werken volgens de DevOps manier betekent dat je in een vast stramien terecht komt. Deze manier laat zich illustreren als een symbool voor oneindigheid. Kortom een continu proces van ontwikkelen, testen, integreren, implementeren en monitoren. Oftewel DevOps benut de krachten van een ieder optimaal.

Wanneer je in de DevOps levenscyclus stapt, ga je van het plan-stadium naar het monitoringstadium en weer terug. Het blauwe deel verwijst naar de ontwikkelfase, het gele gedeelte naar het operationele gedeelte, maar door de steeds weerkerende wisselwerking vloeien beiden ineen. Onderstaande illustratie laat mooi zien dat je heel snel je ontwikkelproces doorloopt en op die manier de frequentie enorm opvoert. Daarbij is het ook minder erg als een ontwikkelsprint een keer niet lukt. Zo kan je ook wanneer er zich een fout voordoet in de beschikbare functionaliteit die heel snel weer oplossen. Of weghalen.

Snelheid neemt toe dankzij de DevOps manier van werken

De principes van werken met DevOps

Dat het niet alleen een tool installeren is om succesvol van DevOps gebruik te maken is nu wel duidelijk. Dat er meer bij komt kijken – en dat gebruikersadoptie van wezenlijk belang is – blijkt uit de zes principes.

Principe 1: Klantgericht werken. In korte cyclus lever je sneller nieuwe functies op. Omdat de feedback rondes korter zijn kan je echt luisteren naar je klanten en eindgebruikers waardoor zij zich meer dan een ambassadeur voelen.

Principe 2: Geen waterval model. Dus afdelingen werken niet meer apart van elkaar. Het verschil tussen de verschillende methode is in mijn vorige blog geïllustreerd. Omdat je nu samen (alle afdelingen) aan hetzelfde werk. Je deelt met dezelfde mindset bij aan een werkend en mooi product.

Principe 3: Verticaal georganiseerde teams. Teams die aansprakelijk zijn ‘from concept to grave’. Dus niet een manager die bepaald. Samen verzamel je de feedback en bepaal je de reis.

Principe 4: Allround profielen. Geen hokjes of aparte silo’s. Samen werken in autonome teams waar men zich persoonlijk kan ontwikkelen.

Principe 5: Voortdurende optimalisatie. Uiteraard wil je dat mensen zich blij en verbonden voelen. Dat is enorm belangrijk. Dit principe gaat over de as van snelheid (time to market), kosten (tijd) en het product zelf dat relevant is en aansluit bij je doelgroep.

Principe 6: Automatisering. Alles wat geautomatiseerd kan worden zou ik automatiseren, ook de infrastructuur, door bijvoorbeeld te kiezen voor container gebaseerde cloud platformen.

Versnel de tijd naar de markt voor je applicaties

De DevOps aanpak heeft gevolgen voor de hele delivery pipeline van een project. De bedoeling is dat je sneller naar de markt kunt met functies. De grootste wijziging daarin is dat als je kijkt naar je lifecycle management dat je niet meer met compleet nieuwe versies komt. Bij wijze van elke week met een nieuwe kleine aanpassing. Een andere positieve wijziging is dat dit met lagere foutpercentages kan. Elke x.0 versie keek ik vroeger altijd heel huiverig naar. Ik wacht wel op versie x.1 of versie x.2 want dan zijn er al wat fouten opgelost. Omdat je nu zo snel kan reageren ervaren gebruikers geen nieuwe releases-stress meer.

Werken aan meetbare resultaten

Hoe ideaal is dat? Als we eindelijk allemaal op meetbare resultaten worden afgerekend. Geen interpreteerbare KPI meer. Iedereen kan de resultaten volgen en inzien. Transparantie ten top. Er zijn bedrijven waar dit al volop in het DNA zit. Terwijl er ook nog genoeg zijn die liever het een en ander verbergen. Echter wanneer DevOps goed geïntegreerd is en volledig wordt gedragen door de organisatie, zal dat bevordelijk werken. De doelstellingen en verwachtingen kan je bijvoorbeeld met gamificatie leuk en effectief inzichtelijk maken zodat de adoptie goed werkt en er een soort competitie onderling ontstaat.

Welke meetbare resultaten bedoel ik dan? Denk bijvoorbeeld aan het aantal cases voor de supportafdeling. Die zal je zien dalen als DevOps geïntegreerd is. Een ander punt is klanttevredenheid. Klanten zullen je de dienstverlening positiever ervaren dan voor de implementatie van DevOps. Daarvoor moet je natuurlijk al wel eerder klanttevredenheidsonderzoeken hebben gedaan, om goed te kunnen vergelijken. Ook dit proces zou een continu proces moeten worden, in plaats van dat jaarlijkse verplichte nummertje omdat het in je ISO-handboek staat.

Samenvattend kan het invoeren van de DevOps-methode een nieuwe wind laten waaien in je organisatie. In de volgende blog sta ik stil bij wat ik de elementen van DevOps noem.

Referenties

[1] TechCrunch (2016). Software is still eating the world
[2] Microsoft (2016).  Application Development: DevOps and open source solutions
[3] Microsoft (2017). What is DevOps Culture?
[4] InfoWorld (2018). What is CI/CD? Continuous integration and continuous delivery explained
[5] Medium (2018). Contrasting the Waterfall Model, Agile, Lean and DevOps
[6] Ganttpro (2016). Agile vs Waterfall: Pros and Cons, Differences and Similarities


Begin » Optimaliseren van processen » Werken aan een nieuwe manier met DevOps