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:
...
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 | ||||||||
|---|---|---|---|---|---|---|---|---|
|
Probleem
We kunnen binnen het afsprakenstelsel onvoldoende snel inspringen op de veranderende vraag uit de praktijk, doordat:
...
Ten gevolge hiervan treden verschillende kleinere problemen op namelijk:
- Eventuele Nu worden wijzigingen die alsnog op korte termijn buiten de twee releasemomenten doorgevoerd moeten worden worden nu 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.Vaste releasemomenten, waarin zoveel mogelijk onderwerpen doorgevoerd moeten worden.
- Zijn de geplande onderwerpen niet volledig op tijd uitgewerkt voor het eerst 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
Met In de 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.
Hoe kunnen wij de huidige vorm van release cycle management zo aanpassen dat we kunnen inspringen op de continu veranderende vraag uit het dynamische Zorg ICT landschap en de wijzigingen binnen de MedMij zelf?
Doel:
Meer Door het release cyclemanagement aan te pakken 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 |
een wijziging als major geclassificeerd wordt. | |
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. |
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
We willen meer Voor de gewenste situatie willen wij:
- Meer releasemomenten per jaar mogelijk maken om zo de flexibiliteit omtrent de releases van minors en patches verhogen
...
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 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 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.
Toegepaste variaties
Voor de verschillende oplossingsrichtingen hebben we bepaalde onderdelen gevarieerd. Deze onderdelen zijn:
...
- Seizoen
- Weeknummer
- 4e dinsdag van de maand
...
- Patch
- Minor
- Major
- Alle drie tegelijkertijd
...
- Maandelijks
- Tweemaandelijks
- Per kwartaal
- Per halfjaar
...
- Geen
- Maandelijks
- Per kwartaal
...
- Ja
- Nee
...
- Patch
- Minor
- Major
- Combinaties hiervan
...
- 12x
- 4x
- 2x
- 1x
...
- Geen
- 1 maand
- 3 maanden
- 4 maanden
- 6 maanden
Oplossingsrichting 1
Het verplichtingsmoment wordt bepaald in overleg met stakeholders, wel moet deze eens per seizoen gepland worden.
...
Vraagstuk
...
Keuze
...
Frequentie pre-release moment
...
Maandelijks
...
- Door maandelijks een pre-release moment 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 stakeholder 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
...
Eén keer per seizoen, in overleg met stakeholder wordt de precieze datum gekozen.
...
- Meer vrijheid voor stakeholders om te bepalen wanneer ze majors/minors/patches willen en kunnen implementeren.
- Aangezien er maandelijks publicatiemomenten zijn en niet per se elk verplichtstellingsmoment gereleaset wordt is het niet nodig om een vaste maandelijks een interne voorbespreking plaatsvinden
...
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.
...
Minimum tijd tussen het stakeholder overleg en het verplicht worden
...
3 maanden
...
Oplossingsrichting 2
...
Overweging
...
Keuze
...
Frequentie pre-release moment
...
Twee maandelijks
...
- Door de pre-release eens in de twee maanden te laten plaatsvinden kunnen we behouden we de mogelijkheid om kleine wijzigingen (minors en patches) 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. Door tweemaandelijkse pre-release momenten te gebruiken vragen we minder tijd van deelnemers.
...
- Vergt alsnog veel tijd van stakeholders om de stukken te lezen en tweemaandelijks aanwezig te zijn bovenop de huidige overleggen.
- Vergt tijd van medewerkers van VZVZ
- Minder flexibiliteit voor het doorvoeren van patches en minors dan bij de maandelijkse release momenten
...
Voorbespreking
...
Ja, 2 weken voor de pre-release
...
- Voorbespreking biedt de kans vooraf te bepalen welke positie we willen innemen voor bepaalde onderwerpen en welke tijdslijn we willen hanteren.
- 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 voor de voorbespreking gebruiken voorkomt dat we de pre-release moeten uitstellen als een voorbespreking wel noodzakelijk is maar dat er geen ruimte in de roosters is om de voorbespreking daadwerkelijk in te plannen.
...
- Er zijn al veel overleggen en we proberen als VZVZ onnodige overleggen te beperken.
- Wordt er bij het opstellen en reviewen van nieuwe onderwerpen eigenlijk al niet bepaald hoe essentieel het desbetreffende onderwerp is en wanneer deze volgens ons gepubliceerd moet worden?
...
Verplichtstellingsmoment
...
Eén keer per jaar
...
- Maar één verplichtstellingsmoment per jaar 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 minimaal een jaar wachten voordat het kan worden verplicht gesteld.
- In de huidige situatie voeren deelnemers pas optionele versies door als ze verplicht zijn. Zeer waarschijnlijk verandert dit gedrag niet als we onze wijze van release cycle management wijzigen. Als we vervolgens elke twee maanden patches en minors publiceren maar vervolgens alsnog (meer dan) een jaar moet wachten voordat deelnemers de wijzigingen doorvoeren, bereikt het wijzigen van de release cycle dan ook het beoogde doel.
...
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.
...
Minimum tijd tussen stakeholder overleg en verplicht worden
a. Patches en Minors
b. Majors
...
a. 3 maanden
b. 6 maanden
...
- Aangezien er geen optionele versie is en deelnemers pas korter van te voren weten welke wijzigingen verplicht worden tijdens het volgende verplichtstellingsmoment heeft de deelnemer in deze oplossingsrichting extra tijd 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 de pre-release en verplicht worden 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 tijd tussen het stakeholder overleg en het verplicht worden van patches, minors en majors worden verschillende duren gehanteerd afhankelijk van de soort wijziging.
...
Vraagstuk
...
Keuze
...
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.
...
- Door verschillende pre-release 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 publicatiemomenten zijn en wat wanneer gepubliceerd wordt.
...
Voorbespreking
...
- 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.
- Door eens per kwartaal een voorbespreking te houden blijft de vinger aan de pols aangaande de planning voor uitwerking van onderwerpen, de publicatie van onderwerpen en opname in de optionele en verplichte versie.
- Door onderwerpen voor te bespreken kunnen we een betere afweging maken over welke onderwerpen we wanneer willen releasen en hoe sterk we aan onze tijdslijn willen vasthouden.
...
- Mogelijkerwijs is eens per kwartaal voorbespreken te weinig.
...
Verplichtstellingsmoment
...
- Door tweemaal per jaar een verplichtstellingsmoment beschikbaar te maken zijn deelnemers niet continue bezig met het doorvoeren van wijzigingen en tegelijkertijd heeft MedMij nog wel de mogelijkheid om met enige regelmaat wijzigingen in het afsprakenstelsel door te voeren en verplicht te stellen.
...
Behoud optionele versie
...
Minimum tijd tussen stakeholder overleg en verplicht worden
...
- Patch: 1 maand
- Minor: 2 maanden
- Major: 4 maanden
...
- Het kan verwarrend zijn dat er verschillende deadlines worden gebruikt.
Oplossingsrichting 4
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 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.
De voorbespreking
...
- 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.
Stakeholderoverleg
Bij het maandelijkse stakeholder overleg zijn in deze oplossingsrichting aanwezig:
- ZN
- VWS
- ?NICTIZ?
- MM beheer ( productmanager, MM ontwikkeling)
- Stichting MM
Deelnemers overleg
Bij het deelnemersoverleg mogen naast de stakeholders ook de deelnemers aanwezig mogen 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
Oplossingsrichting 4 in beeld
...
Vraagstuk
...
Keuze
...
Publicatie frequentie pre-release
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% 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.
...
- 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.
...
- Als we teveel tijd en middelen vragen van deelnemers dan kan dit leiden tot een afname in draagvlak onder deelnemers.
- In deze oplossingsrichting kan de mogelijkheid in flexibiliteit in het verplichtstellingsmoment tot verwarring leiden over welke onderwerpen wanneer verplicht worden.
- 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 stakeholder overleg en verplicht worden
...
Geen
...
Het kan zijn dat wijzigingen op te korte termijn worden verplicht gesteld wat een risico bij implementatie kan zijn.
Oplossingsrichting 5
Loslaten dakpan model
- Meer regie voor stakeholders door ze inspraak te geven in de planning wanneer de uitgewerkte onderwerpen worden opgenomen in het afsprakenstelsel
Oplossingsrichting
| 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. | 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. |
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 maandelijkse voorbespreking worden ten minste de volgende collega's uitgenodigd:
- Product manager
- MM ontwikkeling
- MM Ketenregie
- MM Loket
- MM Acceptatie
- Stichting MM
- NICTIZ
- R&A
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 keten - In hoeverre het onderwerp samenhangt met andere onderwerpen die gereleased moeten worden of waar nu aan gewerkt wordt
- Hoelang het team acceptatie nodig heeft de wijziging te integreren in het acceptatietraject
- 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.
Vervolgens wordt de uitwerking van het onderwerp gepubliceerd als een pre-release stuk, waarbij:
- Patches bij publicatie direct worden opgenomen in het afsprakenstelsel.
- voor Minors tijdens de voorbespreking en het stakeholderoverleg wordt besproken op welke termijn deze 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, wel kan in samenspraak met stakeholders hiervan worden afgeweken.
- voor Major in de voorbespreking en het stakeholderoverleg wordt besproken tijdens welk verplichtstellingsmoment de major worden opgenomen in het afsprakenstelsel. Stakeholders 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.
Stakeholders kunnen deze stukken lezen en bepalen of ze willen aansluiten bij het stakeholder overleg.
Bij het driemaandelijkse stakeholder overleg zijn aanwezig:
- ZN
- VWS
- NICTIZ
- MM beheer (productmanager, MM ontwikkeling)
- Stichting MM
- DVA's
- DVP's
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.
Punten ter verduidelijking:
- 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.
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
...
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.
De voorbespreking
...
- 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 keten - 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
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
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.
Oplossingsrichting 5 in beeld
...
Vraagstuk
...
Keuze
...
Publicatie frequentie pre-release
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. 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.
...
- 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.
- In principe worden minors doorgevoer tijdens de verplichtstellingsmomenten. In overleg met stakeholders kan deze ook tijdens één van de pre-release momenten verplicht worden.
- 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.
...
- Als we teveel tijd en middelen vragen van deelnemers dan kan dit leiden tot een afname in draagvlak onder deelnemers.
- In deze oplossingsrichting kan de mogelijkheid in flexibiliteit in het verplichtstellingsmoment tot verwarring leiden over welke onderwerpen wanneer verplicht worden.
- 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 stakeholder overleg en verplicht worden
...
Geen
...
- 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.
Pilots
De vraag werd gesteld hoe in binnen de nieuwe release cycle management men om zou gaan met pilots. Hier zouden wij mee om kunnen gaan door in het hoofdstuk beleid een addendum te schrijven waarin we voor pilots in bepaalde situaties uitzonderingen maken binnen het afsprakenstelsel.
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.
Er zijn meerdere opties om hiermee om te gaan, hieronder heb ik er een paar uitgewerkt.
Optie 1
In de voorbespreking wordt aan acceptatie gevraagd hoelang ze nodig hebben voordat de wijzigingen geïmplementeerd zijn in het acceptatieproces. De stukken worden tijdens het pre-release moment gepubliceerd als de benodigde wijzigingen aan het acceptatieproces zijn doorgevoerd. Daarna wordt in samenspraak met de stakeholders bepaald wanneer we het stuk willen opnemen in het afsprakenstelsel.
- Het voordeel hiervan is dat acceptatie voldoende tijd heeft om het te implementeren in hun processen.
- Het nadeel is dat er de kans is dat we dubbele implementatietijd moeten inbouwen voor deelnemers en het team acceptatie. Namelijk dat we het team acceptatie eerst x maanden nodig heeft en vervolgens tijdens het stakeholder overleg blijkt dat de deelnemers ook nog y maanden nodig hebben voor implementatie.
Optie 2
Tijdens de voorbespreking met acceptatie bespreken we hoeveel tijd het team acceptatie nodig heeft om de wijzigingen aan het afsprakenstelsel door te voeren in de acceptatieprocessen.
- Heeft het team acceptatie weinig tijd (bijvoorbeeld 3 maanden) nodig voor de implementatie dan worden de stukken gepre-released en wordt bij het stakeholder overleg aangegeven dat de wijziging pas na minimaal 3 maanden wordt opgenomen in het afsprakenstelsel.
- Betreft het een grotere wijziging waarvoor het team acceptatie meer tijd nodig heeft (bijvoorbeeld 9 maanden) dan wordt ook meegewogen hoeveel tijd de deelnemers nodig gaan hebben voor de implementatie. Is de verwachting dat het team acceptatie meer tijd nodig heeft dan de deelnemers dan wordt het pre-release stuk gepubliceerd en tijdens het stakeholderoverleg wordt bepaald wanneer we het pre-release stuk wordt opgenomen in het afsprakenstelsel. Vervolgens wordt wederom bij het stakeholder overleg aangegeven dat wij het stuk pas minimaal over 9 maanden willen opnemen in het afsprakenstelsel.
- Gaat het om grotere wijzigingen waarvoor het team acceptatie en de deelnemers veel tijd nodig hebben om deze te implementeren (bijvoorbeeld 9 maanden), dan wordt het pre-release stuk gepubliceerd en wordt tijdens het stakeholderoverleg bepaald wanneer het pre-release stuk wordt opgenomen in het afsprakenstelsel (minimaal 9 maanden weg) en wordt een aparte datum aangegeven vanaf welk moment deze stukken geaccepteerd kunnen worden.
Het voordeel van deze werkwijze is dat het het team acceptatie de tijd geeft om de aanstaande wijzigingen aan het afsprakenstelsel door te voeren in hun processen en MM ontwikkeling krijgt de gewenste flexibiliteit voor het doorvoeren van wijzigingen aan het afsprakenstelsel. Ook deelnemers krijgen inzicht welke wijzigingen doorgevoerd gaan worden.
Het nadeel van deze werkwijze is dat het extra data toevoegd aan de extra data die nu al zijn toegevoegd, dit kan voor verwarring zorgen. De verwarring zou verminderd kunnen worden door de acceptatiemomenten samen te laten vallen met de stakeholderoverleggen. Verder plaatst het veel verantwoordelijkheid op alle partijen over in hoeverre zij instaat zijn in te schatten hoeveel implementatietijd zijzelf en de andere stakeholders nodig gaan hebben. Daarnaast lopen twee verschillende werkwijzes door elkaar heen waardoor het ook binnen MedMij verwarrend kan zijn.
Optie 3
Hierbij wordt toch een vorm van een optionele versie behouden, namelijk dat voor minors en majors er die worden opgenomen in het afsprakenstelsel 3 maanden van te voren geaccepteerd kan worden.
Gedurende de voorbespreking worden de uitgewerkte stukken besproken, hier wordt bepaald hoeveel implementatietijd nodig is voor deelnemers en het team acceptatie om deze wijzigingen te implementeren. Vervolgens tellen we drie maanden bovenop de tijd die acceptatie nodig heeft voor implementatie. Deze tijd wordt gebruikt als minimumduur voor opname in het afsprakenstelsel tijdens het stakeholderoverleg. In het stakeholderoverleg wordt weer bepaald op welke termijn de wijzigingen opgenomen moeten worden in afsprakenstelsel. Drie maanden voor deze datum kunnen deelnemers al accepteren en hun aanpassingen live zetten.
Dit kan natuurlijk ook 1 maand van tevoren.
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?
Om dit vraagstuk aan te pakken zijn verschillende opties uitgewerkt.
Optie 1
Hierbij wordt toch een vorm van een optionele versie behouden, namelijk dat voor minors en majors 1 maand voor opname in het afsprakenstelsel dat de deelnemers hun softwarewijzigingen live kunnen zetten en wijzigingen aan R&A al doorgevoerd kunnen worden.
Gedurende de voorbespreking worden de uitgewerkte stukken besproken, hier wordt bepaald hoeveel implementatietijd nodig is. Vervolgens tellen we 1 maand bovenop de benodigde tijd voor implementatie. Deze duur wordt gehanteerd als minimumduur voor de opname in het afsprakenstelsel tijdens het stakeholderoverleg. Wel wordt in het stakeholderoverleg bepaald op welke termijn de wijzigingen opgenomen worden in het afsprakenstelsel met de opmerking dat de wijzigingen 1 maand voor opname in het afsprakenstelsel al live gezet kunnen worden.
Optie 2
Accepteren dat iedereen tegelijkertijd live gezet moeten worden.
Optie 3
Optionele versie behouden
Uitfaseren oude versies afsprakenstelsel
Optie 1
De vraag is in hoeverre het nodig is om de oude versies uit te faseren omdat we dit nu ook niet doen en niet tegen problemen aanlopen. De eerste optie is de situatie te laten zoals het nu is dus hier niet voor aan te passen. Indien uitfaseren nodig is dan is het namelijk ook mogelijk om de datum van opname in het afsprakenstelsel verder weg te plaatsen.
Optie 2
Toch behouden van een optionele versie waar de tijd tussen de overgang van optioneel naar verplicht gebruikt wordt om de oude versie uit te faseren.
Optie 3
Een uitfasering versie hanteren voor stukken die uitgefaseerd moeten worden. Indien een stuk verwijderd wordt uit het afsprakenstelsel waarvoor uitfasering vereist is, dan wordt tijdens de voorbespreking en het stakeholderoverleg besproken dat dit het geval is en hoeveel tijd hiervoor nodig is, in plaats van een opname datum wordt er dan een verwijderdatum ingepland. Dan wordt het stuk pas verwijderd uit het afsprakenstelsel.
Openstaande vragen en overdenkingen
Vragen
Een paar vragen is geen duidelijk antwoord op, daarom zijn er verschillende oplossingsrichtingen uitgewerkt. Deze vragen zijn:
...
vragen zijn:
- 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 onderwerpenOf 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
...