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
Gekoppelde onderwerpen
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.
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------
To do:
- uniform woordgebruik
- controleren overeenkomen tabellen en afbeeldingen
- zins- en taalgebruik
Probleem:
Op dit in moment vind twee keer per jaar een release plaats, namelijk in week 18 en 44. In de huidige situatie moeten onderwerpen uitgewerkt zijn voor het release moment anders kunnen de onderwerpen pas een halfjaar later gepubliceerd worden en pas een jaar later verplicht gesteld.
Het release moment bepaalt dus de planning, en dit werkt niet ideaal aangezien de onderstaande problemen optreden:
- 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.
- Als er geen onderwerpen zijn om te releasen dan kunnen we alleen óf de optionele versie verplicht maken en geen wijzigingen doorvoeren voor de nieuwe optionele versie óf 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.
Koppelingen
Wijzigingsverzoek
Gekoppelde onderwerpen
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 zijn gepubliceerd één optionele en één verplichte versie. Op dit moment zijn dat de versies 1.5.1 en 1.6.0, waarbij versie 1.5.1. verplicht is voor alle deelnemers en 1.6.0. optioneel. Bij het volgende release moment wordt de verplichte versie ingetrokken, de optionele release wordt verplicht en de nieuwe optionele versie wordt gepubliceerd.
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 meer gestructureerd meenemen in de analyses en uitwerkingen van onderwerpen.
Aannames
De gekozen nieuwe release cycle wordt ondersteunt door de (nieuwe manier van) versioning die nu wordt uitgewerkt.
- 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 vanwege een gedegen reden op korte termijn af te wijken van het release schema dan kan worden afgeweken van het release- en verplichtstellingsschema.
Oplossingsrichtingen
Om de flexibiliteit omtrent de releases van minors en patches te verhogen willen we meer releasemomenten per jaar mogelijk maken. Wij stellen voor om op regelmatige basis een stakeholder overleg 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 stakeholder overleg. Bij dit overleg zijn de product owner, de medewerker die het onderwerp heeft uitgewerkt en de verschillende stakeholders aanwezig.
Tijdens het overleg worden de volgende punten besproken:
- er wordt een update gegeven betreffende de onderwerpen waaraan gewerkt is;
- een verwachting wordt uitgesproken van grote onderwerpen waaraan de aankomende maand gewerkt wordt;
- toelichting welke onderwerpen tijdens de volgende release (indien van toepassing) worden opgenomen in de optionele versie en/of verplicht worden gesteld
- met stakeholders wordt per onderwerp bepaald op welke termijn de uitgewerkte onderwerpen worden opgenomen in de optionele versie (mits de optionele versie nog bestaat) en/of verplicht worden;
- of de verplichtstelling kan plaatsvinden met de geplande onderwerpen.
De stakeholders krijgen 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 stakeholder overleg moeten de stukken minimaal 1 week van tevoren gepubliceerd zijn.
Ter verduidelijking, het feit dat publicatie- en verplichtstellingsmomenten beschikbaar zijn betekend niet vanzelfsprekend dat deze ook gebruikt moeten worden.
Als er niets te publiceren is of binnen het stakeholderoverleg wordt bepaald dat we bij het volgende verplichtstellingsmoment geen onderwerpen verplicht willen stellen dan hoeft dit ook niet.
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?
- 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.
- Wat gaat het effect van de gekozen oplossingsrichting op de R&A zijn
Risico's
- Dat niet genoeg stakeholders (m.n. deelnemers) deelnemen aan de overleggen, waardoor we wijzigingen door gaan voeren op korte termijn maar vervolgens blijkt dat het niet mogelijk is en dit voorkomen had kunnen worden als de juiste stakeholders aan tafel hadden gezeten.
- In hoeverre zijn wij en de stakeholders goed in staat om te bepalen wat de impact van bepaalde wijzigingen en/of onderwerpen voor deelnemers gaat zijn.
Toegepaste variaties
Voor de verschillende oplossingsrichtingen hebben we bepaalde onderdelen gevarieerd. Deze onderdelen zijn:
- Publicatie moment: Seizoen, weeknummer of 4e dinsdag van de maand
- Publicatiefrequentie voor patches, minors en majors: combinaties of gesplitst
- Publicatiefrequentie: maandelijks, tweemaandelijks, per kwartaal of per halfjaar
- Voorbespreking: ja/nee, per maand of per kwartaal
- Behoud optionele versie: ja/nee
- Verplichtstellingsmoment: per patch/minor/major of combinaties hiervan
- Aantal verplichtstellingsmoment per jaar: 12x, 4x, 2x of 1x
- Hantering minimale duur tussen publicatie en verplichtstelling: Ja/Nee
- Indien minimale duur tussen publicatie en verplichtstelling wordt gehanteerd variatie in: 1 maand, 3, 4 en/of 6 maanden
Oplossingsrichting 1
Vraagstuk | Keuze | Voordeel | Nadeel |
Frequentie pre-release moment | Maandelijks |
|
|
Voorbespreking | Nee, wanneer nodig |
|
|
Verplichtstellingsmoment | Eén keer per seizoen, in overleg met stakeholder de datum kiezen | 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, tijdens de stakeholder overleggen wordt bepaald of de patch, minor of major wordt opgenomen in de volgende optionele - en/of verplichte versie. | 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 stakeholder 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
Het verplichtingsmoment wordt bepaald in overleg met stakeholders, wel moet deze eens per seizoen plaatsvinden.
Bij deze oplossingsrichting wordt geen optionele versie gebruikt, daarom wordt niet de term publicatieoverleg maar stakeholderoverleg gehanteerd.
Overweging | Keuze | Voordeel | Nadeel |
Frequentie pre-release moment | Twee maandelijks |
|
|
Voorbespreking | Ja, 2 weken voor de pre-release |
|
|
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. |
|
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 overleg en verplicht worden a. Patches en Minors b. Majors | a. 3 maanden b. 6 maanden |
|
|
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
Vraagstuk | Keuze | Voordeel | Nadeel |
Pre-release frequentie a. Patches b. Minors c. Majors | a. Maandelijks b. Per Kwartaal c. Per Halfjaar Telkens op de 4e dinsdag van de desbetreffende maand. |
|
|
Voorbespreking | Per Kwartaal |
|
|
Verplichtstellingsmoment | Tweemaal per jaar |
| Deelnemers geven nu al aan dat ze het teveel vinden dat twee keer per jaar een nieuwe versie verplicht worden. De vraag is of de voordelen t.g.v. meer inspraak in het release schema tot dusdanig positieve effecten leiden dat het twee keer per jaar verplicht stellen niet langer een probleem is. |
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 ze makkelijk in de optionele versie kunnen terugvinden wat er verplicht gaat worden tijdens het volgende verplichtingsmoment. | Mogelijkerwijs wordt het verwarrend voor stakeholders wat het verschil is tussen de optionele en de pre release versie. |
Minimum tijd tussen stakeholder overleg en verplicht worden |
| Door een minimum duur tussen het stakeholder 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
Bij deze oplossingsrichting is het dakpan model losgelaten, hiervoor is gekozen omdat:
- het dakpanmodel niet in uitwerking van deze oplossingsrichting past,
- deelnemers in de huidige situatie geen gebruik maken van de optionele versie, omdat twee versies van hun systeem in de lucht houden teveel geld kost en
- ook binnen de rest van VZVZ geen gebruik wordt gemaakt van het dakpanmodel
Als het dakpan model geen waarde toevoegt, afwijkt van de rest van de organisatie en niet past binnen deze uitwerking waarom zouden we deze dan behouden.
Het zou als volgt in zijn werk gaan, wanneer onderwerpen zijn afgerond en het is een minor of major dan worden ze aangedragen bij de voorbespreking.
Bij de voorbespreking wordt besproken:
- Het belang van het onderwerp
- De impact van het onderwerp
- In hoeverre het onderwerp samenhangt met andere onderwerpen die gereleased moeten worden of waar nu aan gewerkt wordt
- Op welke termijn we het onderwerp willen doorvoeren
- Hoe vast we willen houden aan deze deadline
Als over de bovenstaande punten duidelijkheid bestaat en willen we het onderwerp pre-releasen op het eerst volgende moment dan wordt één week later het onderwerp gepubliceerd.
Twee weken daarna vindt het verplichtstellingsoverleg plaats hier wordt samen met de stakeholder bepaald wanneer we dit onderwerp verplicht willen laten worden.
In deze oplossingsrichting heeft het stakeholderoverleg een andere vorm. Bij het maandelijkse stakeholder overleg zijn in deze oplossingsrichting aanwezig:
- ZN
- VWS
- MM beheer
- Stichting MM
Verder is er een deelnemersoverleg waar naast de stakeholders ook de deelnemers aanwezig mogen zijn. Eventueel zou deze gecombineerd kunnen worden met de expertsessies om de overlegdruk op deelnemers te verminderen.
In deze uitwerking is gekozen voor de 3e donderdag, omdat het deelnemersoverleg na het stakeholderoverleg plaats dient te vinden en het plannen van het overleg op de 4e dinsdag van de maand is onwenselijk wegens de vakantieperiodes in december en juni.
Vraagstuk | Keuze | Voordeel | Nadeel |
Publicatie frequentie pre-release Patches & Minors & Majors | Maandelijks | Bij deze oplossingsrichting is er geen optionele versie meer en wordt in overleg met de stakeholders bepaald wanneer een onderwerp verplicht wordt. Hierdoor maakt het minder uit wanneer een stuk gepubliceerd wordt aangezien in samenwerking met stakeholders bepaald wordt wanneer een onderwerp verplicht wordt. Door te pre-releasen wanneer het onderwerp is afgerond kunnen deelnemers eerder zien welke onderwerpen eraan komen en een betere afweging maken wanneer ze welke onderwerpen verplicht willen stellen. |
|
Voorbespreking | Maandelijks | In de publicatie overleggen wordt in overleg met de stakeholders bepaalt op welk moment minor en majors verplicht worden. Om duidelijk te hebben op welke momenten wijzelf deze minors en majors willen verplicht stellen (en hoe stevig wij hieraan vasthouden) is het vereist de publicatie overleggen voor te bespreken. Doen wij dit niet dan is er het risico dat we onderwerpen te laat verplicht stellen terwijl dat niet wenselijk zou zijn of dat we te stevig gaan staan voor relatieve kleine aanpassingen. | Het vergt tijd van de deelnemers van VZVZ en er zijn al veel standaard overleggen. |
Verplichtstellingsmoment a. Minors en patches b. Major | a. Patches maandelijks, voor minors ook maandelijks mits overlegt met stakeholders. b. Tweemaal per jaar, tenzij 70% van de stakeholders bij het verplichtingsoverleg het eens is dat er tussentijds een major verplicht wordt gesteld of het wegens een wetswijziging of security risico het vereist is om buiten de verplichtingsmomenten de Major verplicht te stellen. |
|
|
Behoud optionele versie | Nee | Door geen optionele versie te hanteren is het mogelijk op korte termijn aanpassingen door te voeren voor de verplichte versie. | Het kan onduidelijk zijn voor deelnemers welke minors en majors wanneer verplicht worden. |
Minimum tijd tussen stakeholder overleg en verplicht worden | Geen | Door geen minimum duur tussen het verplichtingsoverleg en het verplicht worden van het onderwerp te garanderen is er meer vrijheid om te bepalen welke onderwerpen wanneer verplicht worden. Hierdoor kunnen majors die weinig impact hebben voor deelnemers maar wel essentieel zijn voor een betere uitwisseling makkelijker doorgevoerd worden | Het kan zijn dat wijzigingen op te korte termijn worden verplicht gesteld wat een risico bij implementatie kan zijn. |