Probleemstelling

Er wordt een gebrek aan flexibiliteit ervaren betreffende de releases van het afsprakenstelsel. Dit komt voort uit meerdere oorzaken:

Vaste releasemomenten, waarin zoveel mogelijk onderwerpen doorgevoerd moeten worden. Kleine correcties op het afsprakenstelsel worden zonder ophoging van het versienummer doorgevoerd, minors en majors worden niet op de voorgeschreven manier toegepast.
Volledige koppeling met de in de R&A vastgelegde endpoints en de code van de R&A. Bij iedere versiewijziging betekent dit veel administratief werk.

Bovenstaande problemen kunnen niet los van elkaar worden opgepakt, omdat de oplossing voor het eerste probleem en de uitwerking van versioning impact hebben op het tweede probleem.

Koppelingen

Wijzigingsverzoek

https://pim.vzvz.nl/browse/MO-30

Gekoppelde onderwerpen

MO-6, Versionering van het afsprakenstelsel

Huidige situatie

In de huidige situatie wordt twee keer per jaar een release uitgebracht. Deze staan gepland op 30 april en 30 oktober. Vooraf wordt bepaald welke onderwerpen in de volgende release moeten worden verwerkt. Hierbij hebben we te maken met het dakpanmodel, waarbij altijd twee releases van het afsprakenstelsel staan gepubliceerd. Op dit moment zijn dat 1.5.1 en 1.6.0, waarbij de eerste verplicht is voor alle deelnemers en de tweede optioneel. bij een nieuwe release verschuift alles. De verplichte versie wordt ingetrokken, de optionele release wordt verplicht en de nieuwe release wordt optioneel.

Gewenste situatie

We willen meer flexibiliteit introduceren bij het releasen van onderwerpen, waarbij meer rekening wordt gehouden met de implementatietijd van deelnemers. Daarnaast willen we de deelnemers gestructureerder meenemen in de analyses en uitwerkingen. Om dit voor elkaar te krijgen is het voorstel dat we naar intervallen van een maand gaan. Dit betekent dat iedere maand:

een update gegevens wordt betreffende de onderwerpen waaraan gewerkt is;
een verwachting wordt uitgesproken van grote onderwerpen waaraan de aankomende maand gewerkt wordt;
met stakeholders een publicatieplanning wordt bepaald per onderwerp;
een publicatie kan plaatsvinden met de geplande onderwerpen.

Publicatie

Per publicatieperiode wordt bepaald of een publicatie van toepassing is en wat de publicatie inhoudt. Dit kan bestaan uit updates van de bestaande publicatie, in de vorm van patches, minors en majors. Daarnaast kan ook een volledige nieuwe release nodig zijn.

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Probleem:

Op dit in moment vind twee keer per jaar een release plaats, namelijk in week 14 en 44. In de huidige situatie bepalen de release moment de planning en dit werkt niet ideaal aangezien de onderstaande problemen optreden:

Als er geen onderwerpen zijn om te releasen dan kunnen we of de optionele versie verplicht maken en geen wijzigingen doorvoeren voor de nieuwe optionele versie of de release kan worden uitgesteld.
Doordat er een volledige koppeling met de in de R& vastgelegde endpoints en de code van de R& is betekent dit dat er veel administratief werk verricht moet worden als er een wijziging plaatsvind.
Vaste releasemomenten, waarin zoveel mogelijk onderwerpen doorgevoerd moeten worden. Kleine correcties op het afsprakenstelsel worden zonder ophoging van het versienummer doorgevoerd, minors en majors worden niet op de voorgeschreven manier toegepast.

Huidige situatie:

In de huidige situatie wordt twee keer per jaar een release uitgebracht. Deze staan gepland op 30 april en 30 oktober. Vooraf wordt bepaald welke onderwerpen in de volgende release moeten worden verwerkt. Hierbij hebben we te maken met het dakpanmodel, waarbij altijd twee releases van het afsprakenstelsel staan gepubliceerd. Op dit moment zijn dat 1.5.1 en 1.6.0, waarbij de eerste verplicht is voor alle deelnemers en de tweede optioneel. bij een nieuwe release verschuift alles. De verplichte versie wordt ingetrokken, de optionele release wordt verplicht en de nieuwe release wordt optioneel.

Doel:

We willen meer flexibiliteit introduceren bij het releasen van minors en patches en meer rekening houden met de implementatietijd van deelnemers voor majors. Daarnaast willen we de deelnemers gestructureerd meenemen in de analyses en uitwerkingen.

Aannames

De nieuwe release cycler wordt ondersteunt door de (nieuwe manier van) versioning.
Op de verplichte stelselversie publicatie worden geen major aanpassingen doorgevoerd tenzij... (bijvoorbeeld o.b.v. security, regelgeving of major bug-fix)
Op de verplichte stelselversiepublicatie wordt een minimum aan minor aanpassingen met functionele impact doorgevoerd. De scope van de verplichte functionaliteit blijft zover mogelijk gelijk (geeft wel de optie om bv extensie aan te passen).
Op de verplichte stelselversiepublicatie kunnen patches met procedurele en tekst aanpassingen worden doorgevoerd. De scope van de functionaliteit blijft gelijk.

Voorbehoud

Indien het noodzakelijk is om op korte termijn af te wijken van het release schema vanwege een gedegen reden dan kan er worden afgeweken van het release- en verplichtstellingsschema. Deze beslissing kan alleen worden gemaakt door productowners/productmanager/MT lid?

Oplossingsrichtingen

Om de flexibiliteit voor m.n. releases van minors en patches te verhogen willen we meer releasemomenten per jaar mogelijk maken. Wij stellen voor om een (twee) maandelijks publicatiemoment in te plannen waar stakeholders inspraak hebben over de planning voor releases van onderwerpen.

Het proces zou als volgt in zijn werk gaan, zijn onderwerpen afgerond dan wordt binnen MedMij bepaald wat de impact van dit onderwerp is en op wat voor termijn volgens ons het onderwerp gereleased moet worden. Vervolgens wordt de uitwerking van het onderwerp gepubliceerd als een pre-release stuk. Stakeholders kunnen deze stukken lezen en bepalen of ze willen aansluiten bij het publicatie overleg.

Twee weken voor het publicatiemoment is het publicatie overleg ingepland. Bij dit overleg zijn de product owner en de verschillende stakeholders aanwezig en komen de volgende punten aan bod:

een update wordt gegeven betreffende de onderwerpen waaraan gewerkt is;
een verwachting wordt uitgesproken van grote onderwerpen waaraan de aankomende maand gewerkt wordt;
met stakeholders een publicatieplanning wordt bepaald per onderwerp;
of de publicatie kan plaatsvinden met de geplande onderwerpen.

De stakeholders hebben dus inspraak in wanneer onderwerpen gereleased worden, hier zit wel een grens aan. De inspraak van de stakeholders is wel dusdanig beperkt dat ze releases niet oneindig uit kunnen stellen. Deelname aan het publicatie overleg is facultatief. Stakeholders hebben vooraf inzicht in de agenda en de pre-release stukken, waardoor ze zelf kunnen bepalen of ze wel of niet aanwezig willen zijn bij het overleg. Om te worden meegenomen in het publicatie overleg moeten de stukken minimaal 2 weken ervoor gepubliceerd zijn.

Ter verduidelijking, een publicatiemoment betekend niet vanzelfsprekend dat er ook een release plaats vind.

Openstaande vragen en overdenkingen

Vragen

Een paar vragen is geen duidelijk antwoord op, daarom zijn er verschillende oplossingsrichtingen uitgewerkt. Deze vragen zijn:

Hoeveel publicatiemomenten per jaar willen we inplannen?
-> maandelijks: ruimte om ook op regelmatige basis kleine wijzigen door te voeren
-> twee maandelijks: minder druk op de stakeholders. Er is al gemorrel vanuit deelnemers dat de tijdsinvestering te groot is. De vraag is wegen de voordelen om kleine wijzigingen door te voeren op tegen de kosten voor en bezwaren van de deelnemers. Een vraag hieronder is moeten kleine wijzigen worden doorgevoerd op releasemomenten en als ze zo dringend zijn deze wijzigingen dan niet een minor of een patch?
Willen we de optionele versie bewaren?
Wanneer worden gereleasde versies verplicht en hoe vaak per jaar willen we dit doen?
Hoeveel tijd moet er minimum zitten tussen de release en de verplichtstelling hiervan?
Willen we een voorbespreking voor het publicatie overleg?
Zo ja is deze op een vast moment of wanneer nodig?
Wie moeten erbij aanwezig zijn naast de schrijver van het stuk en de productmanager?

Nog nadenken over

De link met de planning voor het uitwerken van onderwerpen
Of we de planning uitwerking en planning release momenten willen splitsen
Hoe bepalen we of iets een major of minor is?
Wat doen we als iets vanuit ons een minor of patch is maar voor de deelnemer veel werk is.

Oplossingsrichting 1

Vraagstuk	Keuze	Voordeel	Nadeel
Frequentie publicatie moment	Maandelijks	Door maandelijks een publicatiemoment beschikbaar te stellen kunnen we wijzigingen op korte termijn doorvoeren, waardoor we minder lang hoeven te wachten op het volgende releasemoment.	We vragen veel tijd van stakeholders doordat ze vooraf de stukken moeten lezen en regelmatig aanwezig te moeten zijn bovenop de overleggen waar we ze nu al vragen bij aanwezig te zijn. Het voorbereiden en maandelijks bijwonen van de overleggen vraagt tijd van de medewerkers van VZVZ.
Voorbespreking	Nee, wanneer nodig	Er wordt bij het prioriteren voor het uitwerken van onderwerpen al bepaald hoe essentieel het onderwerp is en wanneer deze gepubliceerd moet worden. Is het voor alle onderwerpen dan nodig standaard een overleg in te plannen. Bij belangrijke onderwerpen blijft het mogelijk om een voorbespreking voor het publicatie overleg in te plannen, om vooraf te bespreken op welke termijn we de onderwerpen op de agenda willen behandelen en hoe sterk we achter de gekozen tijdslijn willen staan. Het voorkomt dat er onnodige overleggen worden ingepland.	Het is misschien lastig om op korte termijn dergelijke overleggen in te schieten i.v.m. drukke agenda's. Er is een risico dat stukken onbelangrijk lijken maar dat niet zijn waardoor er niet vooraf besproken wordt welke positie we willen innemen aangaande de wijzigingen.
Verplichtstellingsmoment	Vier keer per jaar	Meer vrijheid voor stakeholders om te bepalen wanneer ze majors/minors/patches willen en kunnen implementeren.	Nu geven deelnemers al aan dat 2x per jaar verplicht stellen te veel is. Mogelijk wordt 4x per jaar een probleem.
Behoud optionele versie	Ja	Dit maakt duidelijk voor deelnemers welke van de onderwerpen die al pre-gereleased zijn ook verplicht worden bij het volgende verplichtingsmoment.	Het is verwarrend als er 3 verschillende versies zijn, namelijk de pre-release, optionele en verplichte versie.
Minimum tijd tussen het publicatie overleg en het verplicht worden	3 maanden	De mogelijkheid om belangrijke veranderingen op korte termijn blijft behoudt.	Deelnemer heeft te kort de tijd om major wijzigingen te implementeren.

Aangezien er maandelijks publicatiemomenten zijn en niet per se elk moment gereleaset wordt is het niet nodig om een vaste maandelijks een interne voorbespreking plaatsvinden

Oplossingsrichting 2

Overweging	Keuze	Voordeel	Nadeel
Frequentie publicatie moment	Twee maandelijks	Door tweemaandelijks een publicatiemoment beschikbaar te maken kunnen we kleine wijzigingen (minors en patches) ook op korte termijn uitvoerbaar, waardoor we minder lang hoeven te wachten op het volgende releasemoment. Het vergt veel tijd van stakeholders om de stukken te lezen en maandelijks aanwezig te zijn bovenop de huidige overleggen. Met tweemaandelijkse publicatie momenten vragen we minder tijd van deelnemers.	Vergt alsnog veel tijd van stakeholders om de stukken te lezen en maandelijks aanwezig te zijn bovenop de huidige overleggen. Vergt tijd van medewerkers van VZVZ
Voorbespreking	Ja, 2 weken voor de pre-release	Door een vast moment voor de voorbespreking in te plannen is het mogelijk vooraf te bespreken op welke termijn wijzelf patches/minors/majors willen invoeren. Een vast moment voorkomt dat indien een voorbespreking noodzakelijk is er geen ruimte in de roosters is waardoor pre-publicatie uitgesteld moet worden.	Er zijn al veel overleggen en we proberen als VZVZ onnodige overleggen te beperken. Wordt er bij het opstellen en reviewen van nieuwe onderwerpen niet al bepaald hoe essentieel het onderwerp is en wanneer deze volgens ons gepubliceerd moet worden
Verplichtstellingsmoment	Eén keer per jaar	Deelnemers geven aan dat twee keer per jaar een nieuwe versie verplicht maken te veel is. Door slechts eenmaal per jaar een nieuwe versie verplicht te maken voldoen wij aan hun wens.	Het biedt weinig ruimte om wijzigingen door te voeren. Loopt het uitwerken van een onderwerp dan vertraging op en wordt deze te laat gepubliceerd dan moeten we een jaar wachten voordat het kan worden doorgevoerd. In de huidige situatie voeren deelnemers pas optionele versies door als ze verplicht zijn, we kunnen er vanuit gaan dat met de nieuwe releasecycle dit gedrag niet verandert. Als we twee maandelijks patches en minors publiceren maar vervolgens alsnog (meer dan) een jaar moet wachten voordat deelnemers het implementeren, draagt het wijzigen van de releasecycle dan ook genoeg bij?
Behoud optionele versie	Nee	Als er al pre-releases zijn en ze maandelijks gepubliceerd worden dan kunnen de deelnemers daar zien welke versie verplicht wordt bij de volgende verplichtstelling.	Aangezien de gepubliceerde majors tussen mei en oktober en van minors/patches tussen augustus en oktober pas bij de release van het volgende jaar worden meegenomen kan onduidelijk zijn welke van de gepubliceerde pre-releases dan wel of niet verplicht wordt tijdens het komende verplichtstellingsmoment.
Minimum tijd tussen stakeholder en overleg en verplicht worden a. Patches en Minors b. Majors	a. 3 maanden b. 6 maanden	Aangezien er geen optionele versie is en deelnemers dus pas korter van te voren weten welke aanpassingen verplicht worden tijdens de volgende release is in deze oplossingsrichting deelnemer extra tijd gegeven om de minors en patches te implementeren voordat ze verplicht worden. Vanwege de impact van Majors (m.n. het non- backwards compatible zijn) is hiervoor een extra 3 maanden aan de minimum duur tussen publicatie en verplicht toegevoegd.	Wordt de gewonnen flexibiliteit in releases voor minors en patches niet teniet gedaan door een minimum duur van 3 maanden voor minor/patches. Deelnemers vinden 6 maanden al te kort om majors door te voeren. De minimum termijn van 6 maanden veranderd hier niets aan.

Oplossingsrichting 3

Voor de derde oplossingsrichting is gespeeld met het idee om verschillende publicatie frequenties te gebruiken voor patches, minors en majors.
Ook voor de minimum duur tussen het publicatieoverleg en het verplicht worden van de betreffende versie wordt

NOG INVULLEN
Ook nog toevoegen variatie datum en weekdag

nog optionele combi volgens mij maken

Vraagstuk	Keuze	Voordeel	Nadeel
Publicatie frequentie a. Patches b. Minors c. Majors	a. Maandelijks b. Per Kwartaal c. Per Halfjaar	Door verschillende publicatie frequenties te gebruiken is het mogelijk wel kleine veranderingen door te voeren op korte termijn zonder teveel druk aan te brengen op deelnemers om in korter termijn grote wijzigingen door te voeren.	Het kan verwarrend zijn voor stakeholders (waaronder deelnemers) dat er veel verschillende versies zijn.
Voorbespreking	Maandelijks
Verplichtstellingsmoment	Tweemaal per jaar
Behoud optionele versie	Ja, term veranderen	Door de optionele versie te behouden blijft het voor de deelnemers wel inzichtelijk welke versie verplicht gaat worden. Aangezien de wisseling
Minimum tijd tussen publicatie overleg en verplicht worden	Patch: 1 maand Minor: 2 maanden Major: 4 maanden	Door een minimum duur tussen publicatie overleg en de verplichtstelling te variëren is het wel mogelijk op korte termijn wijzigingen door te voeren zonder te veel druk op deelnemers te leggen om het te implementeren.

Oplossingsrichting 4

Vraagstuk	Keuze	Voordeel	Nadeel
Publicatie frequentie pre-publicatie Patches & Minors & Majors	Maandelijks		Het kan verwarrend zijn voor stakeholders (waaronder deelnemers) dat er veel verschillende versies zijn.
Voorbespreking	Maandelijks
Verplichtstellingsmoment a. Minors en patches b. Major	a. Maandelijks b. Tweemaal per jaar, tenzij x% het eens is dat er tussentijds een major verplicht wordt gesteld
Behoud optionele versie	Nee
Minimum tijd tussen publicatie overleg en verplicht worden	Geen

MO-30, Release Cycle Management