devops, agile, samenwerken, productiviteit, software

DevOps en productiviteit hand in hand

DevOps, Agile en Scrum zijn veel gehoorde termen maar wat houden die nu eigenlijk in? Zeker bij de ontwikkeling van software zijn dit termen die samen met stevige beloftes komen. Een belangrijk aspect is samenwerken. Laat ik over dat thema vorig jaar het nodige hebben geschreven, mijn persoonlijke kreet is ‘extreem samenwerken’. Dat geldt wat mij betreft niet alleen voor mensen onderling, laat ook verschillende organisaties met elkaar samenwerken, verschillende producten en andere oplossingen.

DevOps is een gecombineerde term bestaande uit ‘development’ en ‘operations’. Het is een methode waar de nadruk ligt op samenwerking en communicatie tussen softwareontwikkelaars en andere IT-specialisten. Kortom een multidisciplinaire agile wijze, waarbij geen enkele IT-vaardigheid superieur is aan de andere. De hele ontwikkelcyclus komt bij DevOps aan bod: product aflevering, doorlopende controle, kwaliteitstests, ontwikkeling van nieuwe functionaliteiten en onderhoud van releases. Het lijkt misschien een open deur, maar om problemen te voorkomen heb je al deze aspecten nodig. Alles om de betrouwbaarheid en veiligheid te verbeteren, en te zorgen voor snellere ontwikkeling en implementatie van cycli in het proces. Een bijwerking hiervan is, dat je in een vast stramien nieuwe functies kunt blijven toevoegen aan je product. En dat je sneller naar de markt kunt met bepaalde onderdelen.

Omdat de rode draad samenwerken is, heb je goede teams nodig. Idealiter met meerdere rollen. Denk hierbij aan de ontwikkelaar, tester, systeembeheerder en projectmanager. Namelijk als een systeembeheerder de software beschikbaar moet maken zonder dat er kennis is van hoe de code werkt, gaan mensen langs elkaar heen praten én vertraag je de levering aan je gebruikers. En dus neemt de tevredenheid af.

DevOps als nieuwe cultuur

devops, agile
Watervall process vs Agile werken

De DevOps-manier van werken is meer dan een methodologie voor het ontwikkelen van software. Iedereen die ik spreek en vraag naar de DevOps-manier geeft aan dat het een cultuur is. DevOps loopt als het ware als bloed door je aderen. En omdat je samen aan hetzelfde doel werkt beantwoord dat in een behoefte die je kan toepassen bij het ontwikkelen van websites, apps en andere ontwikkelingen. Bovenstaande illustratie laat mooi de verschillen in aanpak tussen de traditionele waterval-model en het agile-model zien. Bij het waterval-model waren de eisen voor hetgeen ontwikkeld moest worden op voorhand duidelijk en vastomlijnd als één groot geheel. De doorlooptijd van zo’n groot project is langer en moeilijker te overzien. Bovendien kan het zijn dat wanneer je klaar bent je niet meer relevant bent.

De wereld (en zeker de IT-wereld) evolueert steeds sneller. De consument is ook veranderd. De circulaire economie groeit sneller en het aanbod neemt toe. Dat betekent dat we sneller naar de markt zouden moeten. Daardoor veranderen de eisen sneller én vaker. Dit geldt als geen ander bij het ontwikkelen van software. En software zie je overal, zo komt Nike met schoenen die zichzelf strikken. Het is daarom wenselijk de ontwikkeling behapbaar te maken. Kleine stapjes. Hierdoor ben je in staat om delen naar de markt te brengen die je voortdurend kan aanpassen. Gebruikersadoptie is daarbij een toverwoord – waar ik al langer graag over schrijf. Kleine wijzigingen adopteren makkelijker dan hele grote. Echter ook fouten wil je snel kunnen oplossen. Als je dan steeds moet wachten op die ene grote release gaat dat ten koste van tevredenheid en gebruik. Deze wensen leidde tot het Agile Development model.

Is dat de nieuwe DevOps cultuur dan?

Oké dat is een deel. Maar dan zijn we er nog niet. Want leuk nu zijn de ontwikkelaars in staat om snel en wendbaar te reageren. Alleen de nieuwe functionaliteit, de foutoplossingen en nog veel meer wil je ook nog beschikbaar stellen aan je gebruikers. Je wilt de beschikbaarheid monitoren, en het platform laten mee groeien en krimpen. Kortom het operationele team moet net zo wendbaar en snel worden. Deze twee teams wil je laten samenwerken en niet met elkaar laten strijden. Dit principe leidde tot de DevOps aanpak. Ik hoor wel eens dat DevOps wordt uitgelegd als een “term” voor samenwerking tussen de ontwikkelaars, de bedenkers van een product, en ops (het operationele team dat zorgt voor de release, het uitrollen, het opereren en monitoren van de software).

Hoewel de definitie niet onjuist is, doen we DevOps hiermee te kort. DevOps is veel meer, een cultuur een manier van denken, het samensmelten van doelen en niet langer wijzen naar elkaar. Hiermee gaat deze aanpak verder dan een technische definitie. Het is een bedrijfsbrede aanpak waarbij alle lagen betrokken zijn. Dus ook finance en marketing. Communicatie is levensbelangrijk en de essentie van deze cultuur. Wellicht een open deur, want dit is altijd belangrijk. Toch verwarren we communicatie met iets melden van boven naar beneden.

Deze cultuur resulteert enerzijds dat echt iedereen – van ontwikkelaar, tot systeembeheerder, tot marketing, de business analist en de netwerk mensen – tot hetzelfde team behoren. Met elkaar dienen zij een gemeenschappelijk doel. Het tot een enorm succes maken van het continue proces. Dus geen ge-jullie en hun maar wij!

Hoe doe je dat DevOps dan?

Hoe jij het zou moeten doen past hier niet. Ik wilde deze blog rond de 1000 woorden houden :-). Bovendien schrijf ik dat DevOps een cultuur is, dus dan kan ik niet zomaar even opschrijven hoe jij dat dan moet doen. Een belangrijke stap in de richting van DevOps is de traditionele silo’s tussen ontwikkelaars, testers, release managers, product management, projectmanagers en systeembeheerders af te breken. Deze groep rollen wil je laten samenwerken, gedurende het hele proces van ontwerp, ontwikkeling tot uitrollen en marketing, en dat continu. Kortom investeer in teamvorming. Ga de kwaliteiten van je mensen optimaal benutten.

Continue proces van DevOps

Met als doel dat wanneer het hele projectteam agile samenwerkt, je de code voor bijvoorbeeld een nieuwe functie of bugfix snel in productie brengt je dit en ook weer snel kan terugdraaien. In tegenstelling tot het eerste plaatje, hoe kleiner de sprint, hoe kleiner de impact is van een eventuele fout. Kortom hanteer de “fail fast, fail cheap” benadering. En dat in een continu proces zoals weer hierboven geïllustreerd.

Onderstaand een korte video hoe Microsoft naar dit proces kijkt. Wellicht leuk om eens te bekijken :-).

De volgende blog staat in het teken van de 6 principes van DevOps.

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

Delen mag 🙂

Lees ook