...
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 (in week 18 en week 44) 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.
januari
februari
maart
april
mei
juni
juli
augustus
september
oktober
november
december
Week 18
Week 44
...
| Drawio | ||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Probleem
We kunnen binnen het afsprakenstelsel onvoldoende snel inspringen op de veranderende vraag uit de praktijk, doordat:
...
- Nu worden wijzigingen die alsnog op korte termijn buiten de twee releasemomenten doorgevoerd moeten worden doorgevoerd als correcties, terwijl dit eigenlijk geen correcties zijn.
- Op de vaste releasemomenten moeten zoveel mogelijk onderwerpen doorgevoerd worden.
- 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.
- Zijn de geplande onderwerpen niet op tijd uitgewerkt voor het volgende release moment, dan kunnen de onderwerpen pas een halfjaar later gepubliceerd worden en pas een jaar later verplicht gesteld, dit is onwenselijk omdat:
- het voor bepaalde onderwerpen belangrijk is om deze op korte termijn op te nemen in het afsprakenstelsel. Als deze onderwerpen dus niet tijdens het geplande releasemoment gepubliceerd worden dan betekent dat een vertraging van minimaal een halfjaar.
- het de betrouwbaarheid van MedMij richting de deelnemers kan ondermijnen. Als wij beloven bepaalde stukken op te nemen in de optionele versie van het afsprakenstelsel en vervolgens leveren wij dit niet op dan kan dat de relatie van MedMij met de deelnemers schaden.
- 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
Hoe kunnen wij de huidige wijze van release cycle management aanpakken zodat we beter kunnen inspringen op de continue veranderende vraag uit het dynamische Zorg ICT Landschap en MedMij zelf?
...
Doel:
Door het release cycle management aan te pakken willen we 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.
...
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.
5. 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.
Geven interne en/of externe stakeholders aan dat de impact van een minor wel dusdanig groot is dat deze voor hen niet backwardscompatible is dan wordt deze wijziging alsnog als een major geclassificeerd.
...
Majors
...
Wijzigingen die wel invloed hebben op de functionaliteit en die niet backwards compatible zijn.
...
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 om te bepalen 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 inzichtelijk zijn voor interne- en externe stakeholders maar 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 releasemoment
...
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. Als het is opgenomen in het afsprakenstelsel kan erop geaccepteerd worden.
...
6. Gewenste situatie
Voor de gewenste situatie willen wij:
- Meer publicatiemomenten 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
6.1. Usecase
De nieuwe wijze van release cycle management gaat als volgt in zijn werk. Tijdens het uitwerken van een wijzigingsstuk worden al de (interne) stakeholders betrokken op wie deze wijziging invloed gaat hebben, zodat zij alvast hun input kunnen leveren. Wanneer een stuk is uitgewerkt wordt in de voorbespreking besproken wanneer o.a. acceptatie, ketenregie en R&A verwachten de wijzigingen in hun processen doorgevoerd hebben aan de hand daarvan wordt bepaald wanneer de stukken gepubliceerd worden in de aankomende versie. Zijn de stukken gepubliceerd in de aankomende versie dan kunnen deelnemers al wel ontwikkelen en testen in de zandbakomgeving en/of Mock DVP/DVA, maar de wijzigingen mogen nog niet live gezet worden. Tijdens het stakeholderoverleg wordt bepaald wanneer de wijzigingsstukken worden opgenomen in de actuele versie van het afsprakenstelsel. Wanneer de stukken zijn opgenomen in de actuele versie van het afsprakenstelsel dan mogen de wijzigingen daadwerkelijk live gezet worden.
We zijn ervan bewust dat nog steeds alle deelnemers tegelijkertijd live moeten gaan, echter hebben ze tijdens hun ontwikkelfase al kunnen testen of dit gaat lukken met de Mock DVP/DVA die ontwikkeld gaat worden. Ongeacht het uitgewerkte scenario in alle gevallen bleef een Big Bang het geval, zelfs al veranderen we niets. Doordat deelnemers niet langer twee versies naast elkaar klaar te hoeven hebben te staan maar dat deelnemers wel vooraf kunnen testen mititgeren wij dit risico.
6.2. Oplossingsrichting
januari
februari
maart
april
mei
juni
juli
augustus
september
oktober
november
december
2e dinsdag: Pre-release moment & patches opnamemoment
...
Legenda
...
Stakeholder overleg
...
1e dinsdag: Voorbespreking
3e Dinsdag
Stakeholder overleg
3e Dinsdag
Stakeholder overleg
3e Dinsdag
Stakeholder overleg
...
Definities
Bij deze uitwerking wordt het dakpanmodel losgelaten en afscheid genomen van de optionele versie en een paar nieuwe termen geïntroduceerd. Om verwarring rondom de gebruikte definities te voorkomen wordt in deze paragraaf toegelicht welke termen gebruikt worden en welke definities hieraan hangen.
| Werkwoord | Moment | Onderwerp |
|---|---|---|
| Opnemen | Release (moment) | Het Afsprakenstelsel |
| Publiceren | Publicatie moment | Aankomende (wijzigingen) |
Voorbeeld:
- Tijdens de release wordt een wijziging opgenomen in het afsprakenstelsel.
- Tijdens het publicatiemoment wordt een wijziging gepubliceerd in de Aankomende Wijzigingen versie.
| Wijzigingen | Dit zijn onderwerpen die zijn uitgewerkt door MedMij Ontwikkeling om aan het afsprakenstelsel toe te voegen, om het afsprakenstelsel aan te passen of zelfs stukken uit het afsprakenstelsel verwijderen. |
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. Geven interne en/of externe stakeholders aan dat de impact van een minor wel dusdanig groot is dat deze voor hen niet backwardscompatible is dan wordt deze wijziging alsnog als een major geclassificeerd. |
Majors | Wijzigingen die wel invloed hebben op de functionaliteit en die niet backwards compatible zijn. |
| Het Afsprakenstelsel | Dit is de versie waarop geaccepteerd wordt, oftewel de versie waaraan de deelnemers moeten voldoen. Deze heette voorheen de verplichte versie. |
| Release (moment) | Tijdens het release moment kunnen wijzigingen worden opgenomen in het het afsprakenstelsel. |
| Aankomende Wijzigingen | Dit is het overzicht van alle gepubliceerde wijzigingen (met de opnamedatum voor de geldende versie) voor het afsprakenstelsel. Deelnemers kunnen deze stukken inzien, alvast gaan ontwikkelen en deze live zetten maar mogen pas endpoints aangaan met de R&A na de acceptatie datum. |
| Publicatie moment | Het moment waarop een wijziging wordt gepubliceerd in de omgeving Aankomende Wijzigingen waar deze zichtbaar is voor de externe stakeholders. |
| Vanaf Datum voor Acceptatie | Vanaf dit moment kunnen deelnemers op de nieuwe functionaliteit accepteren en R&A endpoints toevoegen. Deze datum ligt op of na het publicatie moment en voor het release moment |
Gewenste situatie
Voor de gewenste situatie willen wij:
- Meer publicatie- en 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
Usecase
De nieuwe wijze van release cycle management gaat als volgt in zijn werk. Tijdens het uitwerken van een wijzigingsstuk worden al de (interne) stakeholders betrokken op wie deze wijziging invloed gaat hebben, zodat zij alvast hun input kunnen leveren. Wanneer een stuk is uitgewerkt wordt in de voorbespreking besproken wanneer o.a. acceptatie, ketenregie en R&A verwachten de wijzigingen in hun processen doorgevoerd dit wordt de Vanaf Datum voor Acceptatie. De wijzigingen worden gepubliceerd in de Aankomende Versie met de bijbehorende Vanaf Datum voor Acceptatie. Vanaf dit moment kunnen deelnemers gaan ontwikkelen, wijzigingen live zetten, endpoints klaarzetten maar deze nog niet aangaan met de R&A. Pas na de Vanaf Datum voor Acceptatie mogen deelnemers endpoints aangaan met de R&A. Tijdens het stakeholderoverleg wordt bepaald wanneer de wijzigingen worden opgenomen in het Afsprakenstelsel.
Oplossingsrichting
| Drawio | ||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Vraagstuk | Keuze | Voordeel | Nadeel |
Voorbespreking | Maandelijks |
|
|
|
|
|
|
|
| |||
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. |
Publicatie frequentie |
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.
| Voor stakeholders kan het verwarrend zijn dat er meerdere wijzigingen in Aankomende Wijzigingen staan, waar ieder een eigen releasedatum en Vanaf te Accepteren Datum heeft. |
Releasemoment a. Patches b. Minors c. Major | a. Patches 1x p.m. b. Minors 2x p.j in overleg met stakeholders kan opname ook buiten de twee |
releasemomenten. c. Majors 2x p.j., tenzij het wegens een wetswijziging of security risico het vereist is om buiten de |
releasemomenten de Major |
in het Afsprakenstelsel op te nemen. | a. De verwachting is dat patches weinig invloed hebben op de stakeholders en dat |
planning van het releasemoment voor de patch onnodig is. Door de |
releasemomenten voor patches maandelijks |
te |
laten plaatsvinden is het mogelijk om kleine veranderingen op korte termijn door te |
voeren. b. In principe worden minors doorgevoerd tijdens de |
tweejaarlijkse releasemomenten. In overleg met stakeholders |
kunnen de wijzigingen ook tijdens |
de patch releasemomenten worden opgenomen in het Afsprakenstelsel. Zo is er duidelijkheid voor |
alle stakeholders maar is de optie er om indien nodig op korte termijn wijzigingen door te voeren. c. In principe |
hebben majors |
twee keer per jaar |
releasemomenten. Indien noodzakelijk kunnen majors eerder verplicht |
worden gesteld. Het voordeel hiervan is dat het wel duidelijkheid |
creëert voor stakeholders, maar dat we nog wel op korte termijn noodzakelijke wijzigingen door kunnen voeren |
. | 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. | ||
Minimumduur tussen stakeholder overleg en verplicht worden | Geen | Door voor wijzigingen geen minimumduur te hanteren tussen het stakeholderoverleg en het opnemen in het afsprakenstelsel is er meer vrijheid om te bepalen welke wijzigingen wanneer accepteerbaar zijn. Hierdoor kunnen minors en majors die weinig impact hebben op deelnemers maar die wel essentieel zijn voor een betere uitwisseling eerder doorgevoerd kunnen worden. | Het kan zijn dat |
de implementatietijd wordt onderschat, waardoor de wijzigingen |
te |
vroeg worden opgenomen in het |
Afsprakenstelsel wat problemen kan veroorzaken. Om dit risico te mitigeren zijn in de voorbespreking en stakeholder overleggen ook evaluaties |
ingepland. |
In de nieuwe release cycle 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. Hier wordt ook besproken hoeveel tijd interne stakeholders nodig hebben om de wijzigingen door te voeren in hun processen.
...
- De stakeholders krijgen dus inspraak in wanneer onderwerpen worden opgenomen in het afsprakenstelsel, hier zit wel een grens aan. De inspraak van de stakeholders is wel dusdanig beperkt dat ze de opname van het stuk in het afsprakenstelsel 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.
- 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.
Moet | Productie | Gepubliceerd in de Actuele versie |
|---|---|---|
| Mag | Zandbak/ Mock DVP/ Mock DVA | Gepubliceerd in de Aankomende versie |
...
Uitwerkingen n.a.v. feedback 1-11-22
...
Loslaten dakpan model
...
Argumenten voor het afschaffen van dakpanmodel
Bij deze oplossingsrichting is het dakpan model losgelaten, hiervoor is gekozen omdat:
- het behouden van het dakpanmodel ervoor zorgt dat de gewonnen flexibiliteit om wijzigingen door te voeren op de korte termijn weer ongedaan maakt,
- 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.
- een vorm van een bigbang voor minimaal een van de betrokken partijen is niet te voorkomen. Zelfs in de huidige situatie hebben we een bigbang effect. Zouden we de Bigbang in zijn totaliteit willen voorkomen dan moeten dusdanig veel controlemechanismes ingebouwd worden dat we er zelfs op achteruit zouden gaan qua flexibiliteit. Wat ook tegen het streven van afdeling ontwikkeling in zou gaan om juist de flexibiliteit en het beter inspringen op het veranderende zorg IT landschap te vergroten tegen zou gaan.
...
Ontwikkeltijd nodig voor Acceptatie
De optionele versie bood het team acceptatie de mogelijkheid om de wijzigingen aan het afsprakenstelsel door te voeren in de acceptatieprocessen voordat deze wijzigingen werden opgenomen in de verplichte versie van het afsprakenstelsel. Als de optionele versie weggaat moet het team acceptatie op één of andere manier toch voldoende tijd krijgen om wijzigingen van het afsprakenstelsel te implementeren in het acceptatieproces voor (kandidaat-)deelnemers. Hiermee is omgegaan door de wijzigingen pas te publiceren in de aankomende versie als acceptatie ze heeft doorgevoerd in zijn/haar processen.
...
Deelnemer ontwikkeltijd
De vraag werd gesteld of deelnemers nog wel genoeg tijd zouden hebben om de wijzigingen door te voeren voordat ze in het afsprakenstelsel worden opgenomen en in hoeverre er rekening wordt gehouden met hun ontwikkeltijd
Volgens ons is met het nieuwe systeem juist beter inzicht hoe het gaat met het ontwikkelproces van deelnemers, doordat de deelnemers meebepalen wanneer de aanpassingen worden opgenomen in het afsprakenstelsel, we regelmatig evalueren met deelnemers hoe het met het implementatieproces gaten dat we bij vertraging de planning aanpassen. Hierdoor krijgen deelnemers een ontwikkelduur die voor hen passend is.
...
Implementeren nieuwe versies afsprakenstelsel in o.a. R&A
Hoe kan voorkomen worden dat tijdens het opname moment alle deelnemers tegelijkertijd hun wijzigingen willen/moeten doorvoeren waardoor er problemen optreden bij bijvoorbeeld de R&A?
In de tijd tussen de publicatie in de aankomende versie en publicatie in de actuele versie kan R&A alvast de wijzigingen klaar zetten en dat deze wijzigingen pas live worden gezet tijdens de publicatie.
...
Uitfaseren oude versies afsprakenstelsel
Tijdens het stakeholder overleg wordt voor de uit te faseren optionele functionaliteiten bepaald hoeveel tijd de stakeholders nodig hebben voor uitfasering. De uit te faseren functionaliteit wordt verplaatst naar de extensie en de minimumduur uit het stakeholder overleg wordt gebruikt als einddatum van de de functionaliteit. De periode tussen verplaatsing en beëindiging is de periode van uitfasering.
...
Openstaande vragen en overdenkingen
...
Nog nadenken over
- Hoe bepalen we of iets een major of minor 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
- Big bangs
...