Proces realisatie koppelvlakwijzigingen

Doelstelling

Om tot een soepele implementatie te komen zijn kwalitatief goede specificaties nodig en deelnemers en dienstverleners die de nieuwe functionaliteit willen gebruiken. De ingrediënten voor succes zijn grondige kennis wat er moet gebeuren in combinatie met een heldere bussinesscase.

Door met elkaar (deelnemers, dienstverleners en BO) meer energie te steken in de voorkant van het totstandkomingsproces is het de verwachting dat de kwaliteit van specificaties, use- en testcases en ondersteunde tooling zullen toenemen en de doorlooptijd en impact van de implementatie verkorten.

Door daarnaast gebruik te maken van de Agile/Scrum methodiek bij het schrijven van specificaties is het de verwachting dat vergelijkbare voordelen worden behaald als bij het ontwikkelen van software.

Deze voordelen zijn:

de nauwe betrokkenheid van de belanghebbenden
de input vanuit meerdere disciplines
snel schakelen bij veranderingen
inzicht in de voortgang en de focus op een werkend product

Het ontwikkelen van testfaciliteiten, testberichten en testcases vormen een integraal onderdeel van het voortbrengingsproces van RFC’s. Het doel van deze werkwijze is om te komen tot specificaties van hogere kwaliteit (vooral meer eenduidig en compleet) die testbaar zijn en in kortere cycli opgeleverd kunnen worden.

Verantwoordelijkheden

In het worden de volgende verantwoordelijkheden onderscheiden:

Het Leveranciersoverleg is een stakeholder : Voor aanpassingen in het koppelvlak is dit de initiële plek om veranderbehoefte te agenderen mbt businesscase en prioriteit. De veranderbehoefte is afkomstig van de klant, de dienstverlener, waar een leverancier een relatie mee heeft. De leverancier en dienstverlener stellen samen de behoeftestelling op en die wordt door de overige deelnemers besproken op haalbaarheid en marktpotentie. Het leveranciersoverleg beslist of een werkgroep start met het uitwerken van de oplosrichting. Het leveranciersoverleg benoemt de productowner om een deel van de veranderbehoefte klaar te maken voor bouw.
De productowner is verantwoordelijk voor het beheer van de productbacklog. Deze persoon geeft met input van het LO aan welke RFC's het refinementteam oppakt en bepaalt of deze producten gereed zijn voor implementatie door de deelnemers. De productowner handelt met een zekere zelfstandigheid om de snelheid van bouw optimaal te laten verlopen. De rol van de governance is het meedenken en helpen bij het weghalen van belemmeringen.
Het refinementteam bestaat uit belanghebbenden (o.a. dienstverleners, deelnemers en BO) waarbij het principe geldt dat diegene die het ook wil de inspanning levert om het te realiseren en daarbij draagvlak organiseert bij de betrokken. De samenstelling ligt niet vast en is afhankelijk van de fase waarin het zich bevindt of het onderwerp wat besproken wordt. Het team bestaat uit specialisten vanuit verschillende disciplines: architect, security officer, tester, jurist, ontwerper, bouwer en projectleiding. De agile /scrum methodiek wordt toegepast om de producten te realiseren.
Het Operationeel Beraad is een stakeholder en toetst of de initiële oplosrichtingen qua functionaliteit past in de bestaande architectuur en bepaalt eventueel de impact. Het Operationeel beraad geeft hierover advies aan het Tactisch Beraad.
Het Tactisch Beraad is een stakeholder en beoordeelt of het voorstel past bij de ambitie en strategie van het stelsel.

Proces ontwerp koppelvlak RFC

Dit proces is van toepassing op RFC's die deel uit maken van een koppelvlakrelease en implementatie vanuit een duidelijke behoeftestelling en opdracht van het leveranciersoverleg. Het moet worden gezien als een voortraject op het Proces change en release.

Toelichting processtappen

Veranderbehoefte bespreken en actie bepalen
Input	De stakeholders van het stelsel zijn divers. De praktijk is dat de stakeholders haar weg vinden naar het Tactisch Beraad en/of het Leveranciersoverleg cq dat het Tactisch Beraad en Leveranciersoverleg de rol vervullen van stakeholder. Uit deze gremia komen de plannen wat de ambities zijn van komende periode zoals in een jaarplan. Als de stakeholders de handen op elkaar hebben om een wijziging komende periode te implementeren dan stellen ze hiervoor een productowner aan.
Activiteit	De stakeholders prioriteren en communiceren van de veranderbehoefte. Denk aan een jaarplan en besluiten wat in een komende release als nieuwe functionaliteit gewenst is. De stakeholder leveranciersoverleg stelt een productowner aan.
Output	Jaarplan Aanstellen productowner Backlog met gewenste functionaliteit
Wie?	Stakeholders (combinatie van Leveranciersoverleg en Tactisch Beraad.

2. Opstarten refinement team
Input	Backlog met gewenste functionaliteit
Activiteit	De betrokken partijen (waaronder deelnemers en BO) leveren teamleden voor het refinement team. De BO vervult de rol van scrummaster. De productowner vervult zijn/haar rol volgens de definitie genoemd volgens scrum.
Output	Team Backlog voor team
Wie?	Deelnemers Productowner

3. Uitvoeren refinement
Input	Backlog voor team
Activiteit	Bepalen van de definition of done Het team werkt de veranderbehoefte uit in een RFC die klaar is om gebouwd te worden door de deelnemers. Dit is inclusief de beschrijving voor de benodigde veranderingen voor aanpalende systemen zoals de aggregator, simulator etc. en inclusief de beschrijving van testcases.
Output	Een RFC waarbij de deelnemers aangeven dat die voldoet aan de defintion of done.
Wie?	Team Operationeel Beraad

4. Opleveren van RFC en doorgeleiden governance via changeproces
Input	RFC opgesteld door team
Activiteit	De productowner toets de defintion of done en meldt het als gereed. Hij ziet toe dat de RFC wordt doorgeleid aan de governance.
Output	Besluit Tactisch Beraad
Wie?	Operationeel Beraad Tactisch Beraad Voorzitter werkgroep