Stakeholders – van ontwikkeling, testen, acceptatie tot productie met approvals

Binnen IT niks nieuws, de OTAP-straat. Waar een nieuw project start, worden requirements opgesteld om duidelijk te maken wat prioriteit heeft, wat op de backlog komt en wat de scope van het project is. Dit doen we om de verwachtingen naar zowel business als IT helder te communiceren en waar nodig te kunnen bijsturen.  

Wij gebruiken Azure DevOps om onze totale planning inclusief resultaten in kaart te brengen. Zo kun je makkelijk alle stakeholders aanhaken, ziet iedereen op een en hetzelfde bord de stand van zaken en houdt iedereen hetzelfde doel voor ogen. Belangrijk om te weten is dat niet iedere organisatie een test en acceptatie-omgeving heeft. Laatstgenomende is wat ons betreft zeer wenselijk, maar een fase ontwikkeling, testen en productie zijn wat ons betreft mimimaal nodig.

De Product Owner of een gedelegeerde (bijvoorbeeld een Business Developer) bewaakt het eindproducten is zowel aan het begin als het einde van het proces in de lead. In alle fasen is er een andere stakeholder verantwoordelijk voor de approval die nodig is om door te kunnen naar de volgende fase.

Ontwikkeling

Eén van de principes van het Golden Path is het 4-ogen principe. Wijzigingen die door een Developer gedaan zijn, worden altijd gereviewed door een collega-Developer (peer review). Door onze One Button Deploy is een automatische uitrol mogelijk op elke omgeving (Continuous integration and continuous delivery of CI/CD) zorgt ervoor dat de uitrol op elke omgeving op dezelfde, uniforme manier gebeurd waardoor de kans op fouten tot een minimum beperkt wordt. Een volgende fase, in dit geval ‘testen’, wordt vrijgegeven nadat er minimaal 4 ogen naar de software hebben gekeken. Het belangrijkste gegeven binnen dit proces is dat degene die de code heeft gewijzigd of een uitrol gestart heeft nooit dezelfde persoon mag zijn die de goedkeuring geeft voor productie.

Test en acceptatie fase

In deze fase is ofwel een gebruiker of een Technisch Applicatiebeheerder (of een gedelegeerde daarvan, zoals een Security Officer) aan zet. Dit is spreekwoordelijk het eerste stoplicht dat op rood staat. Het testen kunnen wezien als rondjes rijden over de rotonde waarna een succesvolle test resulteert in een groen stoplicht en er doorgereden kan worden naar de vogende rotonde/fase. Binnen grote projecten wordt getest op onder andere performance, er worden load testen uitgevoerd en een enkele applicatie kan wel op tien servers met op ieder een hondertal gebruikers worden getest. Ook dit wordt uiteraard volledig geautomatiseerd.

Een mooie maar vaak ook noodzakelijke bijkomstigheid van alles automatiseren is dat de time-to-market wordt verkort. Door approvals op de juiste plekken in-place te hebben wordt volledig voldaan aan de ISO- en security eisen voor certificering.

Productie

De Product Owner - die in het voorstadia ook de user story’s op de backlog heeft gezet is ook degene die de uiteindelijke goedkeuring geeft voor de productiefase. Zo zijn onze klanten in staat binnen no-time te releasen. Waarom het Golden Path van IT en de Business is? Simpel antwoord: business en IT zijn door deze manier van werken volledig aligned. Door het OTAP-proces via het Golden Path te volgen ben je stroperige processen voor en implementeer je van ontwikkeling tot aan productie een BizDevOps manier van werken. Hoe het proces tot aan productie er dan in het kort uitziet? Lees mee...

Het OTAP-proces in de praktijk

1. De Product Owner zet de user story’s op de backlog. Belangrijk hierin voor hem/haar is een korte time-to-market om de eventuele concurrentie voor te blijven.
2. Het development team commiteert zich tijdens de sprintplanning om enkele van de meest belangrijke user story’s op te leveren.
3. Een Developer maakt de code om de functionaliteit zoals die beschreven is in de user story te realiseren en maakt een pull request. Een mede-Developer voert een peer review uit waardoor het 4-ogen principe wordt gewaarborgd. Laatstgenoemde keurt het pull request na het afronden van de review en het verwerken van het eventuele review commentaar goed.
4. Er wordt een ‘pakketje’ van de software gemaakt welke automatisch uitgerold wordt op de development omgeving (CI/CD)/ Het ‘pakketje’ wordt vanaf dit punt doorgeschoven van de development omgeving naar de volgende omgevingen.
5. Binnen de testomgeving wordt idealiter niet handmatig getest in verband met de time-to-market. Omdat al met CI/CD isgestart kan dit automatisch en kan binnen een week een nieuwe feature worden uitgerold.
6. De tester geeft akkoord voor de volgende fase. Indien niet akkoord, herhalen de stappen 3 t/m 5 zich.
7. De Product Owner geeft akkoord voor productie.

Zowel de lead time (tijd tussen het moment dater iets op de user story op de backlog wordt gezet totdat de taak wordtopgepakt) als de cycle time (hoelang het duurt vanaf het moment van oppakken totaan productie) zijn veel korter dan ‘normaal’. Voor ons is deze geautomatiseerde manier van werken het ‘nieuwe normaal’ geworden.

Hoe development met onze way of work waarde levert voor de business

Onze way of work? The Golden Path. We horen je denken... wat is dat dan precies? ‘’Het best bewaarde geheim van een Azure Developer bij TeamValue’’, aldus Joost-Jan. We gaan natuurlijk niet alles verklappen maar geven je wel een kijkje in de keuken van Het Golden Path. Check 1:13 in de video... Met deze goudmijn aan kennis en ervaring automatiseren we alles, maar dan wel traceerbaar wie, wat en waarom heeft aangepast en op welk moment. Zo is een eerdere versie altijd op te roepen. Het einddoel van het Golden Path is One Button Deploy – releasen met één druk op de knop.

Als het goed is weet je nu of je jouw bedrijfskritische applicaties in Azure DevOps op orde hebt en of je het Golden Path volgt. Volg je deze nog niet maar ben je wel op zoek naar jouw goudmijn? Ga dan eens vrijblijvend met een van onze experts in gesprek. De volgende blogs? ‘Bouw everything-as-code' en ‘Waarom One Button Deploy jouw leven makkelijker maakt’ verschijnen binnenkort. Stay tuned!