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
...
1. Koppelingen
1.1. Wijzigingsverzoek
1.2. Gekoppelde onderwerpen
2. Inleiding
2.1. Huidige situatie:
Twee keer per jaar (op 30 april en 30 oktober) vindt een release voor afsprakenstelsel van MedMij plaats. In de huidige situatie wordt gewerkt met het dakpanmodel. Het dakpanmodel houdt in dat op het releasemoment altijd twee releases van het afsprakenstelsel worden gepubliceerd, namelijk één optionele en één verplichte versie. Bij het volgende release moment wordt:
de verplichte versie ingetrokken,
de optionele release wordt verplicht en
de nieuwe optionele versie wordt gepubliceerd.
Op dit moment zijn dat de versies 1.5.1 en 1.6.0, waarbij versie 1.5.1 voor alle deelnemers verplicht is en 1.6.0. de optionele versie is.
Voorafgaand aan het release moment wordt bepaald welke onderwerpen in de volgende release moeten worden verwerkt.
| Inc drawio | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
|
2.2. Probleem
In de huidige situatie wordt vindt twee keer per jaar een release uitgebracht. Deze staan gepland nieuwe release plaats, namelijk op 30 april oktober 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.
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.
...
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 cycle 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?
- 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
Toegepaste variaties
Voor de verschillende oplossingsrichtingen hebben we bepaalde onderdelen gevarieerd. Deze onderdelen zijn:
- Publicatie moment: Seizoen, weeknummer, 3e dinsdag van de maand of 4e dinsdag van de maand
- Publicatiefrequentie voor patches, minors en majors gezamenlijk 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 alles gezamenlijk
- Aantal verplichtstellingsmoment per jaar: 12x, 4x, 2x en 1x
- Hantering minimale duur tussen publicatie en verplichtstelling: Ja/Nee
- Indien minimale duur wordt gehanteerd variatie in: maandelijks, per 3, 4 en/of 6 maanden
Oplossingsrichting 1
...
Vraagstuk
...
Keuze
...
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. Wegen de voordelen van het doorvoeren van kleine wijzigingen op de korte termijn op tegen de nadelen hiervan.
- 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
...
Behoud optionele versie
...
Ja
...
Minimum tijd tussen het publicatie overleg en het verplicht worden
...
3 maanden
...
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
...
> 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?
...
Overweging
...
Keuze
...
Frequentie publicatie moment
...
Twee maandelijks
...
- Door tweemaandelijks een publicatiemoment beschikbaar te maken kunnen we kleine wijzigingen (minors en patches) ook op korte termijn uitvoeren, 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
...
- 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
...
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:
...
Vraagstuk
...
Keuze
...
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 korte termijn grote wijzigingen door te voeren.
...
- Het kan verwarrend zijn voor stakeholders (waaronder deelnemers) dat er veel verschillende versies zijn.
...
Voorbespreking
...
- Door per kwartaal een voorbespreking te houden blijft de vinger aan de pols aangaande de planning uitwerking onderwerpen, publicatie van onderwerpen en opname in de optionele en verplichte versie.
- Door voor te bespreken kunnen we betere afwegingen maken in wanneer we wat willen releasen en hoe sterk we hieraan vasthouden.
- Aangezien patches weinig impact hebben is maandelijks voorbespreking niet nodig. Minors hebben wel impact en daarom is volgens ons het wel gewerkt om per kwartaal een voorbespreking te houden.
...
- Mogelijkerwijs is eens per kwartaal voorbespreken te weinig.
...
Verplichtstellingsmoment
...
Behoud optionele versie
...
Minimum tijd tussen publicatie overleg en verplicht worden
...
- Patch: 1 maand
- Minor: 2 maanden
- Major: 4 maanden
...
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.
...
Vraagstuk
...
Keuze
...
Publicatie frequentie pre-publicatie
Patches & Minors & Majors
...
Maandelijks
...
- Het kan verwarrend zijn voor stakeholders (m.n. voor deelnemers) dat er veel verschillende onderwerpen in de pre-release staan waarvan niet duidelijk wanneer ze verplicht zijn.
...
Voorbespreking
...
Verplichtstellingsmoment
a. Minors en patches
b. Major
...
a. Patches maandelijks, voor minors ook maandelijks mits overlegt met stakeholders.
b. Tweemaal per jaar, tenzij 70% 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.
...
- De verwachting is dat patches weinig invloed hebben op de stakeholders en dat daarom stakeholders geen inspraak hoeven te hebben in de Verplichtstelling hiervan. Door de verplichtstelling van patches maandelijks mogelijk te maken is het mogelijk kleine veranderingen op korte termijn door te brengen.
- Door stakeholders inspraak te geven in het moment dat minors verplicht worden kunnen minors met instemming van stakeholders ook eerder gepubliceerd worden waardoor we niet hoeven te wachten op de halfjaarlijkse verplichtstelling.
- Om duidelijkheid te creëren behouden we de twee verplichtstellingsmomenten per jaar. Om wel ruimte te hebben om indien gewenst majors toch eerder verplicht te stellen dan de twee jarige verplichtstellingsmomenten is de optie ingebouwd om bij een goedkeuring van minimaal x% door stakeholders alsnog majors tussen twee verplichtstellingsmomenten alvast verplicht te stellen. Het voordeel hiervan is dat we wederom op korte termijn ook wijzigingen door te kunnen voeren die wenselijk zijn voor het merendeel van de stakeholders.
...
- Te veel tijd en middelen vragen van deelnemers te vragen kan dit leiden tot een afname in draagvlak.
- Flexibiliteit t.o.v. het verplichtstellingsmoment kan verwarrend zijn.
- Het is de vraag in hoeverre de stakeholders gebruik willen maken van het vroegtijdig verplicht maken van Majors en als dit het geval is is het dan de moeite waard deze optie te creëren.
...
Behoud optionele versie
...
Minimum tijd tussen verplichtingsoverleg en verplicht worden
...
Geen
...
april. Zijn de onderwerpen niet volledig uitgewerkt voor het eerst volgende release moment, dan kunnen de onderwerpen pas een halfjaar later gepubliceerd worden en pas een jaar later verplicht gesteld. Nu bepaalt het release moment dus de ontwikkel 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, ook 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.
Bij versiewijzigingen moet veel administratief werk verricht worden omdat er een volledige koppeling is met de code van de R&A en de in de R&A vastgelegde endpoints.
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.
Doordat we nu anderhalf jaar van tevoren bepalen wat er gereleased wordt kunnen we onvoldoende inspringen op de veranderende vraag uit het dynamische zorg ICT landschap en de wijzigingen binnen de VZVZ zelf.
2.2.1. Probleemstelling
Met de huidige release cycle kunnen we niet dynamisch inspringen op de veranderende vragen vanuit de praktijk.
De huidige methode van versienummering sluit niet aan bij de major-, minor- en patch nummering waardoor de traceability van wijzigingen moeilijk te herleiden is
Doordat we foutief gebruik van oplopende versienummers combineren met twee gepubliceerde versies van het afsprakenstelsel, kunnen wij major en minor wijzigingen niet zomaar doorvoeren.
3. 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.
4. Aannames
De gekozen nieuwe release cycle wordt ondersteund door de (nieuwe manier van) versionering 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 kunnen patches met procedurele en tekst aanpassingen worden doorgevoerd. De scope van de functionaliteit blijft gelijk.
Patches kunnen met procedurele en tekst aanpassingen worden doorgevoerd. De scope van de functionaliteit blijft gelijk.
4.1. 4.1. Definities
Patches: Kleine wijzigingen die geen invloed hebben op de functionaliteit en wel backwardscompatible zijn.
Minors: Wijzigingen die wel invloed hebben op de functionaliteit en die wel backwardscompatible zijn. De impact van een minor kan dusdanig groot zijn dat besloten wordt deze als major te behandelen. In de voorbespreking wordt bepaald of dit het geval is.
Majors: Wijzigingen die wel invloed hebben op de functionaliteit en die niet backwards compatible zijn. Een major kan ook wel backwards compatible zijn, maar de impact van deze wijziging kan dusdanig groot zijn dat deze als major behandeld wordt. In de voorbespreking wordt bepaald of een wijziging als major geclassificeerd wordt.
5. Gewenste situatie
Door meer releasemomenten per jaar mogelijk te maken willen we de flexibiliteit omtrent de releases van minors en patches verhogen. Wij stellen voor om op regelmatige basis een stakeholder overleg in te plannen waar stakeholders inspraak hebben over de planning voor uitwerkingen van onderwerpen en de planning van releases.
Het proces zou als volgt in zijn werk gaan, wanneer een onderwerp is 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.
Tijdens het stakeholder 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 die 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 dusdanig beperkt dat ze releases niet oneindig uit kunnen stellen.
Deelname aan het stakeholder 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 pre-release momenten en verplichtstellingsmomenten beschikbaar zijn betekent niet vanzelfsprekend dat deze ook gebruikt moeten worden.
Als er niets te publiceren is of er binnen het stakeholderoverleg wordt bepaald dat we bij het volgende verplichtstellingsmoment geen onderwerpen verplicht willen stellen dan hoeft dit ook niet.
5.1.1. Toegepaste variaties
Voor de verschillende oplossingsrichtingen hebben we bepaalde onderdelen gevarieerd. Deze onderdelen zijn:
Variabele | Opties |
|---|---|
Publicatie moment |
|
Publicatiefrequentie voor patches, minors en majors |
|
Publicatiefrequentie |
|
Voorbespreking |
|
Behoud optionele versie |
|
Verplichtstellingsmoment per |
|
Aantal verplichtstellingsmoment per jaar: |
|
Minimale duur tussen publicatie en verplichtstelling wordt gehanteerd variatie in: |
|
5.1. Oplossingsrichting 1
Het verplichtingsmoment wordt bepaald in overleg met stakeholders, wel moet deze eens per seizoen gepland worden.
| Drawio | ||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Vraagstuk | Keuze | Voordeel | Nadeel |
Frequentie pre-release moment | Maandelijks |
|
|
Voorbespreking | Nee, wanneer nodig |
|
|
Verplichtstellingsmoment | Eén keer per seizoen, in overleg met stakeholder wordt de precieze datum gekozen. |
| Nu geven deelnemers al aan dat 2x per jaar verplicht stellen te veel vinden, waardoor 4x per jaar een nieuwe versie publiceren mogelijk een probleem gaat zijn. |
Behoud optionele versie | Ja, tijdens het stakeholder overleg wordt bepaald of de patch, minor of major wordt opgenomen in de volgende optionele - en/of verplichte versie. | Het gebruiken van een optionele versie maakt het voor deelnemers duidelijk welke van de onderwerpen die in de pre-release staan zijn ook verplicht gaan worden bij het volgende verplichtingsmoment. | Het is verwarrend als er 3 verschillende versies in omloop 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 door te voeren blijft behouden. | Deelnemer heeft mogelijk te weinig tijd om de major wijzigingen te implementeren. |
5.2. Oplossingsrichting 2
| Drawio | ||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Overweging | Keuze | Voordeel | Nadeel |
Frequentie pre-release moment | Per twee maanden |
|
|
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 | In de pre-release staan al de stukken weergegeven welke tijdens de tweemaandelijkse pre-release momenten gepubliceerd zijn en wanneer deze onderwerpen verplicht worden. | 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 het onduidelijkheid veroorzaken welke van de gepubliceerde onderwerpen uit de pre-release verplicht worden tijdens het komende verplichtstellingsmoment. |
Minimum tijd tussen stakeholder overleg en verplicht worden a. Patches en Minors b. Majors | a. 3 maanden b. 6 maanden |
|
|
5.3. 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 tijd tussen het stakeholder overleg en het verplicht worden van patches, minors en majors worden verschillende doorlooptijden gehanteerd afhankelijk van de soort wijziging.
| Drawio | ||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
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 twee keer per jaar een nieuwe versie verplicht stellen teveel vinden. De vraag is of de voordelen - zoals meer inspraak in het release schema - voor hen dusdanig positieve effecten hebben dat ze het twee keer per jaar een verplichtstellingsmoment niet langer een probleem vinden. |
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 dan in de optionele versie kunnen terugzien 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 de verplichte minimum duur tussen het stakeholder overleg en de verplichtstelling van patches/minors/majors te variëren is het mogelijk op korte termijn wijzigingen door te voeren zonder te veel druk op deelnemers te leggen. |
|
5.4. Oplossingsrichting 4
5.4.1. Loslaten dakpan model
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:
Patch, dan is het pre-release moment tegelijkertijd het verplichtstellingsmoment.
Minor, dan wordt het onderwerp aangedragen bij de voorbespreking en stakeholderoverleg om te bepalen op welke termijn deze verplicht wordt. Stel we kiezen het eerst volgende verplichtingsmoment, dan zou het onderwerp een maand later tegelijkertijd met de pre-release verplicht gesteld worden.
Major, dan wordt deze besproken tijdens voorbespreking, stakeholderoverleg en deelnemersoverleg. Gezamenlijk wordt bepaald wanneer deze verplicht wordt gesteld (deelnemers mogen niet oneindig majors uitstellen). In principe is de eerste optie tot verplichtstelling het eerst volgende verplichtstellingsmoment. De major kan ook eerder verplicht gesteld worden mits er of een gedegen reden is om hiervan af te wijken (bijv. i.v.m. security redenen of een wijziging in wetgeving) of als minimaal 70% van alle aanwezige stakeholders en deelnemers hiermee instemmen.
5.4.2. De voorbespreking
Bijde voorbespreking zijn aanwezig:
Productmanager
MM ontwikkeling
MM Acceptatie
MM Ketenregie
MM Loket
? Stichting MM?
De voorbespreking is alleen intern en hier wordt besproken:
Het belang van het onderwerp
De impact van het onderwerp (Binnen MM o.a. ketenregie, acceptatie en loket- en de impact van de aanpassing voor deelnemers)
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 in de overleggen met stakeholders/deelnemers
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.
Eén week daarna wordt in het stakeholderoverleg gezamenlijk bepaald wanneer we dit onderwerp verplicht willen laten worden. In deze oplossingsrichting heeft het stakeholderoverleg een iets andere vorm dan in de voorgaande oplossingsrichtingen.
Betreft het een major, dan vindt er ook een deelnemersoverleg plaats waar de deelnemers invloed kunnen uitoefenen op de release planning.
5.4.3. Stakeholderoverleg
Bij het maandelijkse stakeholder overleg zijn in deze oplossingsrichting aanwezig:
ZN
VWS
?NICTIZ?
MM beheer ( productmanager, MM ontwikkeling)
Stichting MM
5.4.4. Deelnemers overleg
Bij het deelnemersoverleg mogen naast de stakeholders ook de deelnemers aanwezig zijn. Eventueel zou deze gecombineerd kunnen worden of met de stakeholder overleggen of 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.
De 3e donderdag van de maand is een tijdelijke keuze en deze wordt nog gewijzigd door of in deze maanden de stakeholder en deelnemer overleggen te combineren, de deelnemers overleg frequentie omlaag te brengen of een andere dag te kiezen. Bij de Deelnemers overleggen zijn aanwezig :
Productmanager & MM ontwikkeling
DVA's
DVP's
Wie wil van de bovenstaande stakeholders
5.4.5. Oplossingsrichting 4 in beeld
| Drawio | ||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
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 bepaald op welk moment minor en majors verplicht worden. Om duidelijk te hebben op welke momenten wijzelf deze minors en majors verplicht willen 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 MedMij en er zijn al veel standaard overleggen. |
Verplichtstellingsmoment a. Minors en patches b. Majors | 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. |
5.5. Oplossingsrichting 5
5.5.1. Loslaten dakpan model
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
Een voordeel van het dakpanmodel is dat de optionele versie het team acceptatie de kans biedt om hun acceptatieproces aan te passen voor de volgende verplichte versie van het afsprakenstelsel. In deze oplossingsrichting wordt de optionele versie wel verwijderd. Om het team acceptatie de tijd te gunnen om de benodigde wijzigingen door te voeren hebben ze tijdens de voorbespreking een belangrijke stem in de planning van het moment van verplichtstelling voor minors en majors.
Wanneer zijn onderwerpen zijn afgerond zou het als volgt in zijn werk gaan bij een:
Patch is het verplichtstellingsmoment moment meteen tegelijkertijd met de pre-release.
Minor wordt tijdens de voorbespreking en het stakeholderoverleg besproken op welke termijn deze minor verplicht moet wordt. Stel we kiezen het eerst volgende verplichtingsmoment, dan zou het onderwerp een maand later tegelijkertijd met de pre-release verplicht gesteld worden. De minor dient in principe binnen twee verplichtstellingsmomenten verplicht gesteld worden, in samenspraak met stakeholders kan hiervan worden afgeweken.
Major wordt in de voorbespreking, het stakeholderoverleg en het deelnemersoverleg besproken tijdens welk verplichtstellingsmoment de major verplicht wordt gesteld. Stakeholders en deelnemers mogen niet oneindig majors uitstellen. In principe worden majors verplicht gesteld tijdens de verplichtstellingsmomenten, hiervan kan worden afgeweken mits er een gedegen reden hiervoor is (bijv. i.v.m. security redenen of een wijziging in wetgeving) of als minimaal 70% van alle aanwezige stakeholders en deelnemers hiermee instemt.
5.5.2. De voorbespreking
Bijde maandelijkse voorbespreking zijn aanwezig:
Productmanager
MM ontwikkeling
MM Acceptatie
MM Ketenregie
MM Loket
Stichting MM
De voorbespreking is alleen intern en hier wordt besproken:
Het belang van het onderwerp
De impact van het onderwerp op
- MedMij intern, bijvoorbeeld op ketenregie, acceptatie en loket
- De impact van de aanpassing voor deelnemers
- De impact van de aanpassing op de ketenIn 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 in de overleggen met stakeholders
Als over de bovenstaande punten duidelijkheid bestaat en willen we het onderwerp pre-releasen op het eerst volgende pre- release moment dan wordt één week later het onderwerp gepubliceerd.
In het driemaandelijks stakeholderoverleg wordt gezamenlijk bepaald wanneer we de minors en majors uit de pre-release verplicht willen laten worden.
Bij het driemaandelijkse stakeholder overleg zijn aanwezig:
ZN
VWS
NICTIZ
MM beheer (productmanager, MM ontwikkeling)
Stichting MM
DVA's
DVP's
VZVZ?
Tijdens het stakeholder 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.
5.5.3. Oplossingsrichting 5 in beeld
| Drawio | ||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
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 bepaald 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 MedMij en er zijn al veel standaard overleggen. |
Verplichtstellingsmoment a. Patches b. Minors c. Majors | a. Patches 1x p.m. b. Minors in principe 2x p.j. In overleg met stakeholders kan ook eerder of later. b. Majors 2x p.j., 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 verplicht worden gesteld wat een risico bij implementatie kan zijn. |
5.6. Openstaande vragen en overdenkingen
5.6.1. Vragen
Er zijn nog een paar vragen waarop geen duidelijk antwoord is, 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?
5.6.2. 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
Hoe stemmen we e.e.a. af op de totaal verschillende releases van componenten uit de standaarden stack (in de verschillende lagen van het z.g. 5 lagen model)?
5.6.3. 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?
Dat we onvoldoende in kunnen schatten wat de effecten voor acceptatie en ketenregie zijn.
Dat we worden overvleugeld door aanpassingen in de standaarden stack, b.v. zib publicaties, FHIR releases, certificaten aanpassingen etc.