...
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 binnnen binnen MedMij verwarrend kan zijn.
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.
Implementeren nieuwe versies afsprakenstelsel
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 er die worden opgenomen in het afsprakenstelsel 3 maanden van te voren
Tijdens de voorbespreking worden de wijzigingen op de agenda besproken, hier wordt bepaald hoeveel implementatietijd nodig is voor deelnemers en het team acceptatie om de wijzigingen te implementeren. De
wr voor minors en majors drie maanden voor het opname in het afsprakenstelsel
Optie 2
...
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
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
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
...
- 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
...