...
Op dit in moment vind twee keer per jaar een release plaats, namelijk in week 14 18 en 44. In de huidige situatie bepalen de release moment de planning moeten onderwerpen uitgewerkt zijn voor het release moment anders kunnen de onderwerpen pas een halfjaar later gepubliceerd worden en pas een jaar later verplicht gesteld.
Het release moment bepaalt dus de planning, en dit werkt niet ideaal aangezien de onderstaande problemen optreden:
- Vaste releasemomenten, waarin zoveel mogelijk onderwerpen doorgevoerd moeten worden.
- Kleine correcties op het afsprakenstelsel worden zonder ophoging van het versienummer doorgevoerd, minors en majors worden niet op de voorgeschreven manier toegepast.
- Als er geen onderwerpen zijn om te releasen dan kunnen we of alleen óf de optionele versie verplicht maken en geen wijzigingen doorvoeren voor de nieuwe optionele versie of óf de release kan worden uitgesteld.
- Doordat er een volledige koppeling met de in de R& vastgelegde endpoints en de code van de R& is betekent dit dat er veel administratief werk verricht moet worden als er een wijziging plaatsvind.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 toegepastwerk verricht moet worden als er een wijziging plaatsvind.
Koppelingen
Wijzigingsverzoek
...
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 gepubliceerdzijn gepubliceerd één optionele en één verplichte versie. Op dit moment zijn dat de versies 1.5.1 en 1.6.0, waarbij de eerste versie 1.5.1. verplicht is voor alle deelnemers en de tweede optioneel. bij een nieuwe release verschuift alles. De verplichte versie wordt 1.6.0. optioneel. Bij het volgende release moment wordt de verplichte versie ingetrokken, de optionele release wordt verplicht en de nieuwe release optionele versie wordt optioneelgepubliceerd.
| Inc drawio | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
|
...
We willen meer flexibiliteit introduceren bij het releasen van minors en patches en meer rekening houden met de implementatietijd van deelnemers voor majors.
Daarnaast willen we de deelnemers meer gestructureerd meenemen in de analyses en uitwerkingen van onderwerpen.
Aannames
De gekozen nieuwe release cycle wordt ondersteunt door de (nieuwe manier van) versioning die nu wordt uitgewerkt.
- Op de verplichte stelselversie publicatie worden geen major aanpassingen doorgevoerd tenzij... (bijvoorbeeld o.b.v. security, regelgeving of major bug-fix)
- Op de verplichte stelselversiepublicatie wordt een minimum aan minor aanpassingen met functionele impact doorgevoerd. De scope van de verplichte functionaliteit blijft zover mogelijk gelijk (geeft wel de optie om bv extensie aan te passen).
- Op de verplichte stelselversiepublicatie kunnen patches met procedurele en tekst aanpassingen worden doorgevoerd. De scope van de functionaliteit blijft gelijk.
...
Indien het noodzakelijk is om vanwege een gedegen reden 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. omtrent de releases van minors en patches te verhogen willen we meer releasemomenten per jaar mogelijk maken. Wij stellen voor om een (twee) maandelijks publicatiemoment op regelmatige basis een stakeholder overleg in te plannen waar stakeholders inspraak hebben over de planning voor releases van onderwerpen.
Het proces zou als volgt in zijn werk gaan, zijn onderwerpen afgerond dan wordt binnen MedMij bepaald wat de impact van dit onderwerp is en op wat voor termijn volgens ons het onderwerp gereleased moet worden. Vervolgens wordt de uitwerking van het onderwerp gepubliceerd als een pre-release stuk. Stakeholders kunnen deze stukken lezen en bepalen of ze willen aansluiten bij het publicatie overleg.Twee weken voor het publicatiemoment is het publicatie overleg ingeplandstakeholder overleg. Bij dit overleg zijn de product owner de product owner, de medewerker die het onderwerp heeft uitgewerkt en de verschillende stakeholders aanwezig en komen .
Tijdens het overleg worden de volgende punten aan bodbesproken:
- er wordt 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 onderwerpwordt;
- 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 publicatie verplichtstelling kan plaatsvinden met de geplande onderwerpen.
De stakeholders hebben krijgen dus inspraak in wanneer onderwerpen gereleased worden, hier zit wel een grens aan. De inspraak van de stakeholders is wel dusdanig beperkt dat ze releases niet oneindig uit kunnen stellen.
Deelname aan het publicatie overleg is facultatief. Stakeholders hebben vooraf inzicht in de agenda en de pre-release stukken, waardoor ze zelf kunnen bepalen of ze wel of niet aanwezig willen zijn bij het overleg. Om te worden meegenomen in het publicatie stakeholder overleg moeten de stukken minimaal 2 weken ervoor 1 week van tevoren gepubliceerd zijn.
Ter verduidelijking, een publicatiemoment betekend niet vanzelfsprekend dat er ook een release plaats vindhet feit dat publicatie- en verplichtstellingsmomenten beschikbaar zijn betekend niet vanzelfsprekend dat deze ook gebruikt moeten worden.
Als er niets te publiceren is of binnen het stakeholderoverleg wordt bepaald dat we bij het volgende verplichtstellingsmoment geen onderwerpen verplicht willen stellen dan hoeft dit ook niet.
Openstaande vragen en overdenkingen
...
- Dat niet genoeg stakeholders (m.n. deelnemers) deelnemen aan de overleggen, waardoor we wijzigingen door gaan voeren op korte termijn waar uiteindelijk 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.
...
- Publicatie moment: Seizoen, weeknummer of 4e dinsdag van de maand
- Publicatiefrequentie voor patches, minors en majors gezamenlijk : combinaties of gesplitst
- Publicatiefrequentie: maandelijks, tweemaandelijks, per kwartaal of per halfjaar
- Voorbespreking: ja/nee, per maand of per kwartaal
- Behoud optionele versie: ja/nee
- Verplichtstellingsmoment: per patch/minor/major of alles gezamenlijkcombinaties hiervan
- Aantal verplichtstellingsmoment per jaar: 12x, 4x, 2x en of 1x
- Hantering minimale duur tussen publicatie en verplichtstelling: Ja/Nee
- Indien minimale duur tussen publicatie en verplichtstelling wordt gehanteerd variatie in: maandelijks1 maand, per 3, 4 en/of 6 maanden
Oplossingsrichting 1
| Drawio | ||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Vraagstuk | Keuze | Voordeel | Nadeel |
Frequentie publicatie moment | Maandelijks |
|
|
Voorbespreking | Nee, wanneer nodig |
|
|
Verplichtstellingsmoment | Eén keer per seizoen, in overleg met stakeholder de datum kiezen | Meer vrijheid voor stakeholders om te bepalen wanneer ze majors/minors/patches willen en kunnen implementeren. | Nu geven deelnemers al aan dat 2x per jaar verplicht stellen te veel is. Mogelijk wordt 4x per jaar een probleem. |
Behoud optionele versie | Ja, tijdens de stakeholder overleggen wordt bepaald of de patch, minor of major wordt opgenomen in de volgende optionele - en/of verplichte versie. | Dit maakt duidelijk voor deelnemers welke van de onderwerpen die al pre-gereleased zijn ook verplicht worden bij het volgende verplichtingsmoment. | Het is verwarrend als er 3 verschillende versies zijn, namelijk de pre-release, optionele en verplichte versie. |
Minimum tijd tussen het stakeholder overleg en het verplicht worden | 3 maanden | De mogelijkheid om belangrijke veranderingen op korte termijn blijft behoudt. | Deelnemer heeft te kort de tijd om major wijzigingen te implementeren. |
...
| Drawio | ||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Vraagstuk | Keuze | Voordeel | Nadeel |
Publicatie frequentie a. Patches b. Minors c. Majors | a. Maandelijks b. Per Kwartaal c. Per Halfjaar Telkens op de 4e dinsdag van de desbetreffende maand. |
|
|
Voorbespreking | Per Kwartaal |
|
|
Verplichtstellingsmoment | Tweemaal per jaar |
| Deelnemers geven nu al aan dat ze het teveel vinden dat twee keer per jaar een nieuwe versie verplicht worden. De vraag is of de voordelen t.g.v. meer inspraak in het release schema tot dusdanig positieve effecten leiden dat het twee keer per jaar verplicht stellen niet langer een probleem is. |
Behoud optionele versie | Ja, term veranderen | Door de optionele versie te behouden blijft het voor de deelnemers wel inzichtelijk welke versie verplicht gaat worden. Aangezien ze makkelijk in de optionele versie kunnen terugvinden wat er verplicht gaat worden tijdens het volgende verplichtingsmoment. | Mogelijkerwijs wordt het verwarrend voor stakeholders wat het verschil is tussen de optionele en de pre release versie. |
Minimum tijd tussen stakeholder overleg en verplicht worden |
| Door een minimum duur tussen publicatie overleg en de verplichtstelling te variëren is het wel mogelijk op korte termijn wijzigingen door te voeren zonder te veel druk op deelnemers te leggen om het te implementeren. |
|
...
| Drawio | ||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Vraagstuk | Keuze | Voordeel | Nadeel |
Publicatie frequentie pre-publicatie 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-publiceren wanneer het onderwerp is afgerond kunnen deelnemers eerder zien welke onderwerpen eraan komen en een betere afweging maken wanneer ze welke onderwerpen verplicht willen stellen. |
|
Voorbespreking | Maandelijks | In de publicatie overleggen wordt in overleg met de stakeholders bepaalt op welk moment minor en majors verplicht worden. Om duidelijk te hebben op welke momenten wijzelf deze minors en majors willen verplicht stellen (en hoe stevig wij hieraan vasthouden) is het vereist de publicatie overleggen voor te bespreken. Doen wij dit niet dan is er het risico dat we onderwerpen te laat verplicht stellen terwijl dat niet wenselijk zou zijn of dat we te stevig gaan staan voor relatieve kleine aanpassingen. | Het vergt tijd van de deelnemers van VZVZ en er zijn al veel standaard overleggen. |
Verplichtstellingsmoment a. Minors en patches b. Major | a. Patches maandelijks, voor minors ook maandelijks mits overlegt met stakeholders. b. Tweemaal per jaar, tenzij 70% van de stakeholders bij het verplichtingsoverleg het eens is dat er tussentijds een major verplicht wordt gesteld of het wegens een wetswijziging of security risico het vereist is om buiten de verplichtingsmomenten de Major verplicht te stellen. |
|
|
Behoud optionele versie | Nee | Door geen optionele versie te hanteren is het mogelijk op korte termijn aanpassingen door te voeren voor de verplichte versie. | Het kan onduidelijk zijn voor deelnemers welke minors en majors wanneer verplicht worden. |
Minimum tijd tussen stakeholder overleg en verplicht worden | Geen | Door geen minimum duur tussen het verplichtingsoverleg en het verplicht worden van het onderwerp te garanderen is er meer vrijheid om te bepalen welke onderwerpen wanneer verplicht worden. Hierdoor kunnen majors die weinig impact hebben voor deelnemers maar wel essentieel zijn voor een betere uitwisseling makkelijker doorgevoerd worden | Het kan zijn dat wijzigingen op te korte termijn worden verplicht gesteld wat een risico bij implementatie kan zijn. |
...