DevOps, buzz of blijvertje?

Ontwikkelen door middel van de waterval methode is te duur en de oplossing is DevOps. Een gedachte die inmiddels in hoog tempo de IT industrie overneemt. Ook ik zie om mij heen de transitie plaatsvinden en vroeg me af wat DevOps inhoud en waarom dit zoveel beter is dan de oude methoden.

DevOps is met name een uitbreiding op of aanvulling van de al eerder in gang gezette trend naar Agile werken. Waarbij alle processen in de waterval wereld: requirements, ontwerp, ontwikkeling, test en implementatie in een vaste volgorde werden uitgevoerd en wijzigingen gedurende dit proces duur, zo niet onmogelijk (b)leken, geeft Agile en daarmee DevOps veel meer vrijheid om een stapje terug te doen en gedurende het ontwikkel proces het pad te wijzigen. Doordat de processen min of meer parallel plaatsvinden en ook de business en operations integraal deel uitmaken van het ontwikkel team, is de kans bij in productie name veel groter dat er daadwerkelijk gemaakt wordt wat gewenst is en daarbij ook nog eens goed te beheren zal zijn.

In vergelijking met Agile geeft DevOps een uitbreiding op de methode door in het voor- en na traject de business en operations expliciet erbij te betrekken. Waarbij Agile nog kan worden

ingezet als onderdeel van een waterval ontwikkel methode, de zogenaamde Agile of Scrum-fall, is er bij DevOps geen plaats meer voor de oude denkwijze. Mede hierdoor is DevOps naast een andere manier van werken ook een culturele omslag, waarbij de besliskracht en manier van werken in de teams getrokken wordt. De rol van het management wijzigt daarmee tot een veel meer ondersteunende rol. De nadruk ligt dan ook veel meer op het scheppen van mogelijkheden en wegnemen van barrières, in plaats van het aangeven op welke wijze een organisatieverandering of software implementatie moet toepassen. De rol verschuift bij DevOps van direct sturend naar sturend ondersteunen.

Belangrijke aandachtspunten in de organisatieverandering, want dat is het, van waterval naar DevOps zijn:

  1. De start en eerste stap. Gezien het team in control is moet het
    management durven loslaten. Dit noodzaakt erop te vertrouwen dat de DevOps teams, met daarin professionals die heel goed weten hoe hun werk georganiseerd moet worden, de juiste werkzaamheden verrichten. Wil je de omslag naar DevOps maken dan moet je op een zeker moment gewoon starten. De eerste stap is dan om een DevOps team neer te zetten en het team gewapend met de nodige Agile bagage hun gang te laten gaan.
  2. Automatiseren is belangrijk in Agile en nog belangrijker in DevOps. Gezien een DevOps team, net als in Agile, iteratief te werk gaat en vele kleine wijzigingen uitvoert moet er nadruk op automatisering gelegd worden. Dit voert veel verder dan het automatiseren van een regressietest, maar omvat ook het automatisch deployen, direct controleren en automatisch testen van ingecheckte code. Zo leidt dit tot het sneller achterhalen of de juiste werkzaamheden uitgevoerd worden en of het geheel goed werkt, wat de kwaliteit en voorspelbaarheid juist ten goede komt.
  3. Meten is weten en daarmee verbeteren. Zoals hierboven aangegeven kan je door continue te meten, zowel in het team als op de productieomgeving, problemen vroegtijdig zien aankomen en passende maatregelen treffen. De hierdoor verkregen feiten helpen het team (de Product Owner) prioriteiten te stellen en de juiste keuzes te maken en uitvoeren. Hierdoor wordt de code beter begrepen, minder kosten gemaakt in foutherstel en wordt er efficiënter gewerkt.
  4. De wijzigende organisatie en organisatiecultuur is een belangrijke pijler in de overgang naar het DevOps werken. Er worden andere eisen gesteld aan hoe mensen denken over verandering en doordat teams zelfsturend zijn moet je als medewerker omschakelen vanuit het opvolgen van opdrachten of een werkwijze naar het zelf nadenken over een aanpak en proactief te werk gaan. Hierbij hoort het signaleren van zaken die volgens jou niet goed lopen, een continue drive tot verandering en een proactieve houding bij uitvoeren van de veranderingen. Doordat teams zelf bepalen hoe het werk wordt aangepakt verliest het management een deel van de sturende rol en moet veel meer overgaan op een model van servant-leadership. De focus ligt daarbij op het scheppen van omstandigheden en wegnemen van belemmeringen. Ook vergt het samensmelten van de veranderings-organisatie en de operationele- en business onderdelen in een bedrijf de nodige aanpassing van de medewerker. Deze moet veel meer dan voorheen in staat zijn om verschillende disciplines uit te voeren en op zijn minst kunnen meepraten over zaken die niet zijn of haar kern competentie zijn (T-shaped). Een tester zal zich in deze omgeving veelal op zijn gemak voelen, al verwacht ik dat met name de technische competenties een update kunnen gebruiken. Een automatische test opbouwen of een visie op testen na een automatische deploy vergt immers andere vaardigheden dan het uitvoeren van handmatige functionele tests. Daarnaast zie je de testinspanning dichter naar de techniek toe zakken. Vandaar zal er dus meer aandacht voor unit en interface testen komen, ten koste van uitgebreide user-interface en volledige ketentesten.

Belangrijk bij bovenstaande aandachtpunten is dat alle genoemde onderdelen integraal deel uitmaken van DevOps en er geen stappen kunnen worden overgeslagen. De DevOps methode zorgt er wel voor dat het niet in één keer hoeft te staan en de verandering organisch plaats kan vinden. Maar onthoudt dat je niet een onderdeel kan negeren, alle stappen moeten worden doorlopen!

Om terug te komen op de openingsvraag: “Heeft iedere organisatie behoefte aan werken volgens DevOps en is het meer dan een buzzwoord?” Ik denk dat DevOps in iedere organisatie, ongeacht de omvang, kan worden toegepast. Wel zal door de vaak informelere manier van werken in een kleine organisatie en het feit dat in een kleine organisatie de verschillende rollen vaak al worden uitgevoerd door één persoon de noodzaak om op een andere manier te werken kleiner kunnen zijn. Middel en grote organisaties, mits geschikt qua structuur, kunnen veel baat hebben bij DevOps werken. Voornamelijk gezien het flexibiliteit bevordert, de medewerkers veel meer betrokken zijn bij de gang van idee naar eindproduct en de waarde die wordt toegevoegd. Ook is het tussentijds bijsturen gedurende de verandering eenvoudiger geworden. De prijs die daarvoor betaald moet worden is dat het management de directe controle inlevert en er meer op metaniveau richting gegeven wordt. Ook zal in grotere organisatie de wens bestaan voor een meta-framework, om de verschillende teams samen te laten werken en globaal dezelfde richting op te laten gaan. Voorbeelden hiervan zijn Nexus (scrum.org) en LeSS (Large Scale Scrum) of SAFe (Scaled Agile Framework).

Een bedrijf met een sterke top-down structuur zal door het ’los moeten laten’ meer moeite hebben met DevOps. Hierdoor past het DevOps werken ook meer bij organisaties waar (hoger opgeleide) professionals werken en sluit het minder goed aan bij (machine) bureaucratische organisaties. Hiermee is DevOps een vraagstuk van zowel de juiste mensen aan boord hebben (het juiste type bedrijf?) als de wil of noodzaak om anders te werken en het durven loslaten.

Zoals te verwachten, is DevOps geen wondermiddel dat alle problemen oplost en blijft het afhankelijk van de keuzes die een organisatie maakt en de mensen die er werken. Wel is DevOps meer dan een buzz en lijkt de trend waarbij bedrijven DevOps toepassen steeds sterker te worden.



Johan Telkamp:
Test Consultant

 

 

SOCIAL MEDIA

NEEM CONTACT MET ONS OP

CloseSure Noord BV
de Vos van Steenwijklaan 75
7902 NP Hoogeveen
+31 (0)88 383 01 20

CloseSure Utrecht BV
Landjuweel 5A-5B
3905 PE  Veenendaal
+31 (0)88 383 01 10

CloseSure West BV
Europalaan 16
2408 BG  Alphen a/d Rijn 
+31 (0)88 383 01 50

CloseSure Oost BV
Hazenweg 70
7556 BM  Hengelo
+31 (0)88 383 01 00

CloseSure Zuid BV
Noord Brabantlaan 265
5652 LD  Eindhoven
+31 (0)88 383 01 40

CloseSure Services BV
Hazenweg 70
7556 BM Hengelo
+31 (0)88 383 01 60

(c) Copyright 2017-2020 CloseSure Nederland B.V. - Privacyverklaring

SHARE THIS!