Niet iedereen is al bezig of klaar met Agile implementeren of er is een ‘new sheriff in town’ als het gaat om ‘continious delivery’ van goede software genaamd DevOps. Zegt je niets? Begin te lezen zou ik zeggen. Waar Agile (vooral bekend om de Scrum aftakking) een organisatie potentieel achterliet met talloze verschillende scrum-teams die op eigen houtje software ontwikkelden gaat DevOps een stap verder – de technologische en procesmatige integratie tussen ontwikkeling en beheer.
DevOps is de integratie tussen (en vandaar de naam) Development en Operations. De kernprincipes zijn gestoeld op Continuous Integration en Continuous Delivery. CI (Continuos Integration) betekent het snel en geautomatiseerd kunnen deployen van releases op andere omgeving. Dit kan binnen de OTAP straat zijn, maar ook op zijstraten hiervan, net wat nodig is. Snel testen en de afstand tussen ontwikkelaars en testers zo klein mogelijk houden is het doel. De overlap met Scrum is groot.
CD (Continuous Delivery) daarentegen gaat een stap verder. De afbakening tussen releases vervaagt en het release van een nieuwe ‘versie’ gebeurt vrijwel automatisch – inclusief het standaard testen binnen een automatisch testframework. Op deze manier worden ‘micro-increments’ potentieel meerdere keren per dag gereleased en is de kans op een verstoring klein. Yahoo bijvoorbeeld heeft inmiddels 10 releases per dag, maar vaker kan in theorie ook. Een release wordt automatisch getoetst tegen een testframework om de standaard risico’s eruit te filteren en als het voldoet volgt de release in productie direct.
Waar beginnen?
Relatie tussen Agile, Scrum, ALM en DevOps in IT organisatie
Om te beginnen is het überhaupt nodig (en mogelijk) om releasemanagement te automatiseren. Zowel vanuit Scrum als DevOps zinvol, maar zelfs zonder dat moet het releasen van een volgende iteratie een tweede (automatische) natuur worden. Wat we verder kunnen leren van Scrum in combinatie met traditionele beheerteams is dat software nu snel ontwikkeld kan worden door efficiënte Scrumteams, maar er nog steeds vanuit losse eilandjes wordt gewerkt – aan het zelfde doel. Beheer gaat op incidentbasis (ITIL, ISM), software ontwikkeling in sprints (Scrum) en dat botst.
Uiteindelijk dient alles in het teken te staan van de klantwensen (vertaald in businesswensen) en een beheersde deployment van implementatie van deze klantwensen. Dat vergt dus 1 team met 1 doel.
Alles is beheer!
Een uitspraak die rondom DevOps de laatste tijd veel wordt gemaakt wordt is alles is beheer. Er is feitelijk geen onderscheid tussen ‘ontwikkeling’ en ‘beheer’ als beiden 1 doel voor ogen hebben: continu leveren van uitstekende diensten. Dat betekent dus EN continuiteit EN korte ontwikkelcycli van nieuwe functionaliteit. Business bepaalt prioriteit op basis van businesswaarde voor de klant en zo tekent zich langzaam één keten af waarin IT opereert mét de business. Klassiek beheer staat in het teken van continuïteit en een release wordt gezien als een flinke operatie (danwel: last).
Begin met 1 team aan 1 product te werken
ALM to Agile to DevOps
Er zijn talloze boeken, seminars en ‘thought leaders’ met een visie op hoe te beginnen en te implementeren. Tussen alle beoogde toegevoegde waarde van tools, methoden en certificeringen vond ik de kern in een reactie in een discussieforum: Begin met 1 team aan 1 product te werken. Uiteraard is het verdiepen in een methodiek niet verkeerd, maar dat is niet het doel – het doel is om sneller goede software aan de business te kunnen bieden.
Tenslotte blijft de rol van de feitelijke klant onderbelicht; wel wordt de focus verschoven naar businesswensen, maar dan gaan we er dus vanuit dat de business weet wat de klant wenst. Zorg dat de klant aan boord komt en blijft, en de keten is pas echt compleet.
