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:

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:

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

  1. 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