ORDINA BLOGT

Requirements en DevOps

Steeds meer bedrijven adopteren het Agile gedachtengoed. Ondertussen weet nagenoeg iedereen wat Agile werken is en hoe zijn expertise hierbij ingezet kan worden. Wat ik om me heen steeds meer hoor is DevOps. Ik ben requirements engineer en vraag me af in hoeverre DevOps mijn werkzaamheden gaat veranderen.

  • Linda Haak – van der Spek
  • 26 januari 2015

Wat ik vooral over DevOps hoor zijn dingen als automatisch deployment en automatisch testen. Wat heeft dat met requirements te maken? Ik neem jullie graag mee in mijn zoektocht naar het antwoord op de vraag: wat moet ik als requirements engineer anders gaan doen in een DevOps omgeving t.o.v. een Agile omgeving? Wat betekent DevOps voor mij?

 

Een paar gedachtenspinsels:

Ik moet beheer gaan betrekken als stakeholder.

DevOps haalt de muur tussen de ontwikkelaars en de beheerders. Dat betekent dat beheerders ook veel meer in het team worden betrokken dan voorheen. Sommige mensen zeggen: “Jij als requirements engineer moet nu beheer gaan betrekken.”
Dat vind ik een belediging: beheer betrek ik al jaren, het is een van mijn stakeholders en die moet je dus betrekken en ondervragen. Zij hebben wensen en eisen aan het systeem en zijn daarmee stakeholder. Als ze niet betrokken zijn kan dat meerdere redenen hebben, wellicht zijn er meer stakeholders ‘vergeten’. \

 

Bij beheer denk ik wel aan non-functional requirements, en omdat je met DevOps continu blijft ontwikkelen en in productie blijft zetten, zullen non-functional requirements zoals uitbreidbaarheid, testbaarheid, installeerbaarheid en beveiliging veel belangrijker worden. Je gaat vaker uitbreiden, testen en installeren, dus zorg ervoor dat deze stappen goed en gemakkelijk doorlopen worden, want als het niet goed is geregeld dan zul je dat snel ondervinden. Hier kan ik me wel in vinden, ik denk dat non-functional requirements al jaren het onderspit delven. Dit is iets waar een requirements engineer in een DevOps team veel aandacht aan moet besteden, en dat is meer dan alleen beheerders betrekken.

 

Ik moet kennis vergaren over automatisch deployment en test tools.

“Automatisch deployen en testen zijn belangrijke voorwaarden voor DevOps werken. Daarom moet jij daar ook kennis van hebben”. Tja, het eerste deel ben ik het zeker mee eens, met het tweede deel niet helemaal. Aangezien ik geen kennis heb van dit mechanismen zou een basis hiervan handig zijn (hoe werkt een regressietest bijvoorbeeld). Net zoals dat het als requirements engineer goed is om enige know-how van programmeren te hebben. Maar ik hoef dan toch niet te weten hoe ze allemaal heten en wat de voordelen van de ene tool t.o.v. de andere is en hoe je zoiets inricht? Ik hoop dat die kennis gewoon bij de betreffende specialisten zit, tenslotte maakt het mij ook niet uit of we iets in Java of Cobol programmeren.

 

Tot nu toe kan ik concluderen: beheer blijf ik gewoon betrekken en ik ga meer met non-functionals gaan doen. Daarnaast wil ik wat leren over hoe automatisch deployen en testen in zijn werk gaat. Dit klinkt nog wel als te doen.
Is dat het? Het voelt nog wat magertjes. Is er niet nog meer wat ik onder de knie moet krijgen voordat ik als requirements engineer goed in een DevOps team kan meedraaien? Ik ben nog zoekende en kijk uit naar meningen van anderen! Als ik nieuwe inzichten heb, schrijf ik een nieuwe blog!