Redactie: Gerben de la Rambelje
Auteur: Tony van der Zalm ● tonyvanderzalm@solcon.nl
Op 15 juni 2016 was het eindelijk zo ver en werd er bij TestNet de thema-avond over DevOPs gehouden. Twee sprekers gaven acte de présence namelijk Erik Peet, Manager Continuïteit bij de Rabobank en Pascal Dufour, werkzaam als testconsultant bij Stater (hypotheekbank).
De eerste sessie van de avond werd door Erik voor zijn rekening genomen. Het verhaal van Erik over DevOps ging voornamelijk over het managementniveau. Organisaties moeten steeds sneller reageren op de markt die constant in beweging is. Erik gaf diverse voorbeelden van ‘oude’ bedrijven zoals bijvoorbeeld V&D, die niet snel genoeg reageerden op de veranderende markt, zodat een reorganisatie of zelfs een faillissement het gevolg was. Ook zie je dat nieuwe bedrijven ontstaan, die snel groeien met een zeer snelle en goede service zoals Coolblue. Erik gaf aan dat de Rabobank op dit moment volledig overgaat van Scrum naar DevOps met sprints van 2 tot 4 weken. De bedoeling was/is om de klanten snel te bedienen met het slim toepassen van IT (ITforIT). Doelstelling is dan ook om de testen zoveel als mogelijk te automatiseren. Het gevolg hiervan is dat er volgens hem veel minder testers nodig zullen zijn in de nabije toekomst.
Voor meer informatie over de presentatie van Peter: https://www.testnet.org/testnetarchief/download/presentaties-thema-avond-devops-15-juni-2016/demystifying-devops-testnet-2016.pdf
De tweede sessie ging Pascal van start. Hij schetste het verhaal van Stater die overging naar de Agile/Scrum werkwijze met DevOps. Hij vertelde waar hij als testconsultant tegenaan liep en hoe dit opgelost werd.
Hij gaf het volgende aan:
- Zorg dat de Agile mindset een onderdeel van de cultuur blijft door een levende omgeving
- Adaptief reageren door meerdere niveaus van feedback
- Effectief ontwikkelen van software
- Evolutionair door snellere en frequente oplevering van software
- Vergroten van samenwerking en communicatie
Door het juist informeren door middel van beeldschermen, die onder andere een overzicht geven van statussen van de automatische testen, wordt het voor de gebruikers, medewerkers en managers duidelijker dat het testen de business op een hoger plan brengt. Pascal gaf ook concrete voorbeelden wat je wel en niet moet doen. De belangrijkste punten die hij noemde om wel te doen zijn:
- Open community
- Training while being coached
- Walk in sessies
- Explain what (test)automation can do for you, not to tell what it is
- Place improvements in the backlog 20%
- Deployment skills needed
Voor meer informatie over de presentatie van Pascal: https://www.testnet.org/testnetarchief/download/presentaties-thema-avond-devops-15-juni-2016/presentatieroad2devopsexport.pdf
Een goede definitie van DevOps vond ik in een recent artikel van Daan de Groot van 25 juli 2016 in de Computable (https://www.computable.nl/artikel/opinie/architectuur/5804090/1509029/impact-van-devops-op-de-it-architectuur.html). Hij schrijft daar: ‘DevOps is moeilijk te definiëren. In mijn optiek is DevOps een benadering van softwareontwikkeling die ervoor zorgt dat de time to market van applicaties en services korter wordt en meer Agile. Het cyclische proces van softwareontwikkeling wordt efficiënter door een betere samenwerking met operations, betere integratie en een hoge mate van automatisering.’
Dit kwam in het verhaal van Pascal goed uit de verf. Pascal merkte ook op dat testers nodig blijven, terwijl volgens Erik dit niet nodig zal zijn omdat alles ‘geautomatiseerd’ is. Dat laatste valt volgens mij nog te bezien. In beide verhalen kwam naar voren dat het lastig blijkt om alle neuzen dezelfde kant op te krijgen in een bestaande organisatie die voortdurend snel mee moet veranderen met de markt. Verander je niet snel genoeg, dan word je links of rechts ingehaald door andere bedrijven.
Onderstaande waarschuwingen van Patrick Lencioni (http://images.itrevolution.com/documents/ITRev_DevOps_Guide_5_2015.pdf ) zijn mijns inziens hierbij verder van belang: Five dysfunctions of a team are described as:
- Absence of trust—unwilling to be vulnerable within the group
- Fear of conflict—seeking artificial harmony over constructive passionate debate
- Lack of commitment—feigning buy-in for group decisions creates ambiguity throughout the organization
- Avoidance of accountability—ducking the responsibility to call peers on counterproductive behaviour which sets low standards
- Inattention to results—focusing on personal success, status and ego before team success
Kortom, de thema-avond over DevOps heeft mijn kennis over dit onderwerp verrijkt en mij genoeg stof tot nadenken gegeven.