Koppelingen
Wijzigingsverzoek
Gekoppelde onderwerpen
- MO-6, Versionering van het afsprakenstelsel
- MO-17, Change Request, Aanpassing stelsel versienummer op basis van hybride epoch label plus SemVer
Inleiding
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:
...
Voorafgaand aan het release moment wordt bepaald welke onderwerpen in de volgende release moeten worden verwerkt.
Probleem
We kunnen binnen het afsprakenstelsel onvoldoende snel inspringen op de veranderende vraag uit de praktijk, doordat:
...
- Deelnemers geven aan dat de termijn van een halfjaar tussen het opnemen in de optionele en het opnemen in de verplichte versie te kort is om impactvolle wijzigingen in het afsprakenstelsel door te voeren.
Probleemstelling
Met huidige de vorm van release cycle management kunnen we onvoldoende inspringen op de veranderende vraag uit het dynamische Zorg ICT landschap en de wijzigingen binnen de MedMij zelf.
Doel:
Meer flexibiliteit introduceren bij het releasen van minors en patches en meer rekening houden met de implementatietijd van stakeholders voor majors.
Subdoelen
- Deelnemers en MedMij medewerkers meer gestructureerd meenemen in de analyses en uitwerkingen van onderwerpen.
- Pas de opname in het afsprakenstelsel plannen als het onderwerp al is uitgewerkt en daarmee de betrouwbaarheid richting deelnemers verhogen.
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 dat de impact van deze wijziging dusdanig groot is dat deze als major behandeld wordt. In de voorbespreking wordt bepaald of een wijziging als major geclassificeerd wordt. |
Publicatiemoment | Het moment waarop een stuk wordt gepubliceerd in een omgeving die zichtbaar is voor de externe stakeholders. |
Pre-release moment | Het (twee-)maandelijks moment waarop de uitgewerkte onderwerpen gepubliceerd worden op de pre-release omgeving, hier kunnen de externe stakeholders zien welke stukken zijn uitgewerkt waarvoor of bepaald kan worden wanneer deze worden opgenomen in het afsprakenstelsel of wanneer deze al op planning staat om te worden opgenomen in het afspraken stelsel. |
Pre-release stukken | Dit zijn de onderwerpen die zijn uitgewerkt die nog niet zijn opgenomen in het afsprakenstelsel |
Optionele Versie | Alleen van toepassing als het dakpanmodel gehanteerd wordt. Dit is de versie van het afsprakenstelsel die verplicht wordt tijdens het volgende ............. moment |
Opname in het afsprakenstelsel | Dit betekent dat het uitgewerkte onderwerp wordt opgenomen in wat nu de verplichte versie van het afsprakenstelsel heet. Wanneer het is opgenomen in het afspraken stelsel dan kunnen deelnemers erop getoetst en geaccepteerd worden. |
Aannames
- De gekozen nieuwe release cycle wordt ondersteunt door de (nieuwe manier van) versioning die nu wordt uitgewerkt.
- Op de verplichte stelselversiepublicatie kunnen patches met procedurele en tekst aanpassingen worden doorgevoerd. De scope van de functionaliteit blijft gelijk.
Gewenste situatie
Voor de gewenste situatie willen wij:
- Meer releasemomenten per jaar mogelijk maken om zo de flexibiliteit omtrent de releases van minors en patches verhogen
- Meer regie voor stakeholders door ze inspraak te geven in de planning wanneer de uitgewerkte onderwerpen worden opgenomen in het afsprakenstelsel
Oplossingsrichting
| Drawio | ||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
In de nieuwe situatie zou het proces als volgt in zijn werk gaan, wanneer een onderwerp is afgerond dan wordt tijdens de voorbespreking van MedMij bepaald wat de verwachte impact van dit onderwerp gaat zijn en op wat voor termijn volgens ons het onderwerp moet worden opgenomen in het afsprakenstelsel. Bij de voorbespreking zijn ten minste aanwezig:
...
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.
Loslaten dakpan model
Bij deze oplossingsrichting is het dakpan model losgelaten, hiervoor is gekozen omdat:
...
- 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.
De voorbespreking
Bijde maandelijkse voorbespreking zijn aanwezig:
...
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. | 1. 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 | 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. Patches b. Minors c. Major | 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. | 1. 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. 2. In principe worden minors doorgevoer tijdens de verplichtstellingsmomenten. In overleg met stakeholders kan deze ook tijdens één van de pre-release momenten verplicht worden. 3. 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. | 1. Als we teveel tijd en middelen vragen van deelnemers dan kan dit leiden tot een afname in draagvlak onder deelnemers. 2. In deze oplossingsrichting kan de mogelijkheid in flexibiliteit in het verplichtstellingsmoment tot verwarring leiden over welke onderwerpen wanneer verplicht worden. 3. 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 | 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. |
Loslaten dakpan model
Argumenten voor het afschaffen van dakpanmodel
Bij deze oplossingsrichting is het dakpan model losgelaten, hiervoor is gekozen omdat:
- het dakpanmodel de flexibiliteit voor wijzigingen door te voeren op de korte termijn tegengaat.
- 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 beperkt gebruik wordt gemaakt van het dakpanmodel
Argumenten voor het behouden 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 alsnog 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.
- Het dakpanmodel biedt MedMij en deelnemers de kans om pilots te laten plaatsvinden. Door een optionele versie in de lucht te houden is experimenteren mogelijk zonder dat deelnemers meteen aan deze nieuwe afspraken moeten voldoen en zonder dat ze hierop geaccepteerd worden. Dit zou een valide reden om te overwegen het dakpanmodel te behouden. Echter kunnen wij de mogelijkheid tot het doen van een pilot ook behouden door het schrijven van een addendum aan het hoofdstuk Beleid van het afsprakenstelsel.
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.
- Dat we onvoldoende in kunnen schatten wat de effecten voor acceptatie en ketenregie zijn
...