ORDINA BLOGT

Requirements en DevOps deel 2

In mijn vorige blog startte ik mijn zoektocht naar wat DevOps voor requirements engineers betekent. Gezien het aantal reacties op mijn vorige blog trek ik de conclusie dat jullie ook niet direct het antwoord hierop hebben en meneer Google helpt mij evenmin.

  • Linda Haak – van der Spek
  • 24 februari 2015

Ik kwam in mijn blog wel tot de conclusie dat je veel aandacht moet besteden aan non-functionals en dat basiskennis van automatisch testen en deployen nodig is. Maar er lijkt meer te zijn om aan te denken.

Levenscyclus denken i.p.v. projectmatig denken

Als requirements engineer ben ik gewend om in een project te werken. Als de applicatie klaar is,  is het voor mij ook gedaan en ga ik naar mijn volgende opdracht. Werken in een DevOps team is heel anders: ik ben betrokken in de levenscyclus van een applicatie en ik kan me in elk stadium van deze cyclus bevinden. Dat betekent dat er niet een vast einddoel (of tijd) is waar we naar toe werken, maar ik ben onderdeel van de lijnorganisatie en we zijn continu bezig met nieuwe dingen ontwikkelen. Waarschijnlijk blijf ik daardoor langer op een klus zitten dan voorheen. Een aantal zaken om bij stil te staan:

Mijn eigen requirements ga ik weer tegenkomen in een later stadium

Vroeger documenteerde ik voor het moment, m.a.w. als je kort daarna het document weer inkeek, was alles nog duidelijk voor alle projectleden. Maar hetzelfde document is na maanden al minder vanzelfsprekend en duidelijk. Bijvoorbeeld omdat bepaalde termen niet meer zo helder in je hoofd zitten en je de reden waarom dit zo belangrijk was vergeten bent. Vanwege het continu ontwikkelen grijpen we vaker terug naar oude documentatie: dan is het veel belangrijker om onbegrip achteraf te voorkomen en zal ik hier dus meer aandacht aan moeten geven.

Continu dialoog met stakeholders

Vaak krijg ik met moeite alle stakeholders gedurende een project aan tafel. Met DevOps wil je niet alleen gedurende een bepaalde tijd beroep op de stakeholders doen, maar gedurende de hele levenscyclus van de applicatie. Daarom moet ik een stakeholder proces optuigen. Dit proces zorgt ervoor dat ik hun capaciteit geregeld is, dat de stakeholders betrokken zijn, dat we gezamenlijk naar de toekomst kijken en dat zij mij input geven waar nodig.

Bedrijfsprocessen

Met DevOps werken ben ik niet alleen betrokken met het optuigen van een systeem (en omliggende zaken), ik ben onderdeel van de lijnorganisatie. Dat betekent dat lijnprocessen ook belangrijker zijn dan voorheen. Voor mij is het dan nodig dat ik de processen doorgrond en kijk waar verbeteringen mogelijk zijn.

Conclusie

Dingen om als requirements engineer mee rekening te houden zijn: non-functionals, basiskennis automatisch testen en deployen en werken in een lijnfunctie. Kijkend hierna heeft de omschakeling van projectmatig denken naar levenscyclus denken voor mij de grootste impact. Ik word echt onderdeel van de organisatie, ik bouw een goede langdurige band op met mijn stakeholders en ik heb meer factoren om rekening mee te houden. Dit spreekt mij erg aan.

Moet ik nu een grote transformatie door staan? Nee, dat valt wel mee, maar het is wel fijn om te weten wat er anders is in een DevOps opdracht dan ik gewend ben.