...
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.
...
Gewenste situatie
Door meer releasemomenten per jaar mogelijk te maken willen we de flexibiliteit omtrent de releases van minors en patches verhogen. Wij stellen voor om op regelmatige basis een stakeholder overleg in te plannen waar stakeholders inspraak hebben over de planning voor uitwerkingen van onderwerpen en de planning van releases.
Het proces zou als volgt in zijn werk gaan, als onderwerpen zijn 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. Bij dit overleg zijn de product owner, de medewerker die het onderwerp heeft uitgewerkt en de verschillende stakeholders aanwezig.
Tijdens het stakeholder overleg worden de volgende punten besproken:
...
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 publicatie 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 publicatiepre-release momenten 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.
...
Voor de verschillende oplossingsrichtingen hebben we bepaalde onderdelen gevarieerd. Deze onderdelen zijn:
- Publicatie moment: Seizoenseizoen, weeknummer of 4e dinsdag van de maand
- Publicatiefrequentie voor patches, minors en majors: in 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 combinaties hiervan
- Aantal verplichtstellingsmoment per jaar: 12x, 4x, 2x of 1x
- Hantering minimale duur tussen publicatie en verplichtstelling: Ja/Nee
- Indien minimale duur tussen publicatie en verplichtstelling wordt gehanteerd variatie in: 1 maand, 3, 4 en/of 6 maanden
Oplossingsrichting 1
Het verplichtingsmoment wordt bepaald in overleg met stakeholders, wel moet deze eens per seizoen plaatsvinden.
| Drawio | ||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Vraagstuk | Keuze | Voordeel | Nadeel |
Frequentie pre-release moment | Maandelijks |
|
|
Voorbespreking | Nee, wanneer nodig |
|
|
Verplichtstellingsmoment | Eén keer per seizoen, in overleg met stakeholder wordt de precieze datum |
gekozen. |
|
| Nu geven deelnemers al aan dat 2x per jaar verplicht stellen te veel |
| vinden, waardoor 4x per jaar een nieuwe versie publiceren mogelijk een probleem gaat zijn. | |
Behoud optionele versie | Ja, tijdens |
het stakeholder |
overleg wordt bepaald of de patch, minor of major wordt opgenomen in de volgende optionele - en/of verplichte versie. |
| Het gebruiken van een optionele versie maakt het voor deelnemers duidelijk welke van de onderwerpen die |
| in de pre- |
| release staan zijn ook verplicht gaan worden bij het volgende verplichtingsmoment. | Het is verwarrend als er 3 verschillende versies in omloop zijn, namelijk de pre-release, optionele en verplichte versie. | |
Minimum tijd tussen het stakeholder overleg en het verplicht worden | 3 maanden | De mogelijkheid om belangrijke veranderingen op korte termijn door te voeren blijft |
| behouden. | Deelnemer heeft mogelijk te |
| weinig tijd om de major wijzigingen te implementeren. |
...
Oplossingsrichting 2
| Drawio | ||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Bij deze oplossingsrichting wordt geen optionele versie gebruikt, daarom wordt niet de term publicatieoverleg maar stakeholderoverleg gehanteerd.
Overweging | Keuze | Voordeel | Nadeel |
Frequentie pre-release moment | Twee maandelijks |
|
|
Voorbespreking | Ja, 2 weken voor de pre-release |
|
|
Verplichtstellingsmoment | Eén keer per jaar | Deelnemers geven aan dat twee keer per jaar een nieuwe versie verplicht maken te veel is. Door slechts eenmaal per jaar een nieuwe versie verplicht te maken voldoen wij aan hun wens. |
|
Behoud optionele versie | Nee | Als er al pre-releases zijn en ze maandelijks gepubliceerd worden dan kunnen de deelnemers daar zien welke versie verplicht wordt bij de volgende verplichtstelling. | Aangezien de gepubliceerde majors tussen mei en oktober en van minors/patches tussen augustus en oktober pas bij de release van het volgende jaar worden meegenomen kan onduidelijk zijn welke van de gepubliceerde pre-releases dan wel of niet verplicht wordt tijdens het komende verplichtstellingsmoment. |
Minimum tijd tussen stakeholder overleg en verplicht worden a. Patches en Minors b. Majors | a. 3 maanden b. 6 maanden |
|
|
...