Koppelingen

Wijzigingsverzoek

• https://pimvzvz.vzvzatlassian.nlnet/browse/MO-30

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:

...

1. Nu worden wijzigingen die alsnog op korte termijn buiten de twee releasemomenten doorgevoerd moeten worden doorgevoerd als correcties, terwijl dit eigenlijk geen correcties zijn.
2. Op de vaste releasemomenten moeten zoveel mogelijk onderwerpen doorgevoerd worden.
3. 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.
4. Vaste releasemomenten, waarin zoveel mogelijk onderwerpen doorgevoerd moeten worden.
5. 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:
   1. 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.
   2. 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.
6. 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. 

...

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.

Doel:

Meer flexibiliteit introduceren bij het releasen van minors en patches en meer rekening houden met de implementatietijd van stakeholders voor majorsHoe 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:

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.

...

• Product manager
• MM ontwikkeling
• MM Ketenregie
• MM Loket
• MM Acceptatie
• Stichting MM
• NICTIZ
• R&A

De voorbespreking is alleen intern en hier wordt besproken:

...

• 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:

1. het behouden van het dakpanmodel ervoor zorgt dat de gewonnen flexibiliteit om wijzigingen door te voeren op de korte termijn weer ongedaan maakt,
2. 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 
3. ook binnen de rest van VZVZ beperkt gebruik wordt gemaakt van het dakpanmodel

 Argumenten  Argumenten voor het behouden van het dakpanmodel

1. 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. 
2. 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:

...

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:

• Willen we de optionele versie bewaren?
• 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

...