Wat is het release beleid van de RetailVista ERP software van NedFox?

Dit document beschrijft de manier waarop NedFox om gaat met aanpassingen in RetailVista ERP, toekomstige updates, bugfixes etcetera. RetailVista POS valt buiten deze documentatie, hiervoor is een separaat release document QA 367 beschikbaar. Ook pilot/test trajecten worden niet gedekt door dit release beleid. 

RetailVista wordt gehost aangeboden waarbij elke winkel organisatie in principe in een afzonderlijk te updaten eigen instantie draait. Dit geeft de mogelijkheid om instanties afzonderlijk te updaten, in een afzonderlijke ritme.

Taken

Om het ontwikkel traject gestroomlijnd te laten verlopen registreert NedFox alle aanpassingen verzoeken in de vorm van taken in eSocrates. In eSocrates is de status van alle taken door zowel klanten als resellers te volgen (voor klanten via de support website).

Gedurende het hele jaar worden uit allerlei contacten met klanten nieuwe taken toegevoegd aan  eSocrates. Deze taken worden voorzien van een applicatie, classificatie 1 en 2, prioriteit, impact, type taak (foutmelding, wens etcetera) en nog wat andere minder belangrijke attributen. Ook wordt bij elke taak de klant vastgelegd die hoort bij de taak. In sommige gevallen wordt ook al een uren indicatie vastgelegd wat de verwachting is hoe lang de realisatie van een taak gaat duren.

Backlog

De backlog is een selectie van taken van waaruit sprints gevuld gaan worden. De backlog bevat een beperkte selectie van alle aanwezige taken in eSocrates.

Op geregelde momenten worden bepaalde taken toegevoegd aan de backlog en voorzien van een geschatte uren indicatie (voor zover niet al aanwezig) en prioriteit/volgorde van uitvoeren. De taken die hiervoor in aanmerking komen zijn over het algemeen vanuit commercieel standpunt. Daarnaast worden taken van het type 'foutmelding' of 'foutieve werking' altijd overgenomen in de backlog en voorzien van een hoge prioriteit.

De taken met de hoogste prioriteit in de backlog worden voorzien van een testscript en indien nodig een storyline waarin beschreven wordt hoe de aanpassing er precies uit moet gaan zien en moet gaan werken.

Let op: Aan de aanwezige taken in de backlog zijn geen rechten te ontlenen! Als taken echt cruciaal zijn dan worden de kosten voor realisatie aan de klant in rekening gebracht, wordt de taak in de backlog voorzien van een zeer hoge prioriteit en zal deze daardoor in de eerstvolgende sprint gepland worden. Alleen dan is te garanderen dat een taak onderdeel zal zijn van de volgende release.

Sprint

Voor de werkelijke software aanpassingen wordt gewerkt met sprints. Elke sprint duurt 2 weken en bij de start van elke sprint wordt berekend hoeveel uren er beschikbaar zijn in de komende 2 weken. Met deze informatie worden de taken uit de backlog gehaald met de hoogste prioriteit, net zo lang totdat het aantal beschikbare uren in de sprint behaald is.

Soms valt de hoeveelheid werk in een sprint tegen. In eerste instantie wordt via overuren dan toch geprobeerd om de sprint toch volledig af te maken. Mocht dat niet lukken, dan wordt de scope van de sprint verkleind. Het kan dan voorkomen dat een aantal taken die in de sprint gepland stonden, die toch niet afgehandeld zijn. In de regel schuiven die taken dan automatisch op met de hoogste prioriteit naar de eerstvolgende sprint.

Ook gebeurt het soms dat de impact van een taak bij nader inzien te omvangrijk is en wordt een taak alsnog uit een sprint gehaald. Op dat moment is het streven om de taak in de eerstvolgende sprint dan alsnog te behandelen.

Bij de laatste sprint voor een finale release kan het dan wel gebeuren dat bepaalde taken de release niet gaan halen en onderdeel zullen zijn van de daarop volgende release.

Binnen elke sprint wordt een development en acceptatie test gedaan.

Testen na afloop van sprint

Na elke sprint worden testomgevingen op verzoek geüpdatet, voor zover aanwezig. Dat geeft resellers en klanten de mogelijkheid om kennis te nemen van de gemaakte wijzigingen en desgewenst test werkzaamheden uit te voeren.

Na installatie van deze update vindt bij NedFox nog een functionele test plaats.

Eventuele afkeur uit de functionele test of de reseller test worden verwerkt in de sprint ná de nieuwe sprint waar inmiddels mee gestart is. Uitgaande van een sprint van 2 week kan het dus voorkomen dat als een taak foutief getest wordt terwijl de nieuwe sprint net begonnen is, het nog ca 4 week kan duren voordat deze afkeur opgelost en beschikbaar gekomen is.

Uitrol van tussentijdse release

Het is in bijzondere gevallen mogelijk om na een sprint een release te plaatsen op een productie omgeving. Deze zal een lagere kwaliteit hebben als een definitieve release omdat integratie tests nog niet plaatsgevonden hebben.

Ook vertalingen van Engels naar bijvoorbeeld Nederlands kunnen nog ontbreken in deze releases. Dit wordt bij de definitieve release pas op orde gebracht.

Als een klant kiest voor een tussentijdse release dan is het gevolg hiervan dat de klant zich feitelijk verplicht om de hierna volgende tussentijdse releases ook te installeren, tot het moment dat de definitieve release geplaatst is. Zie ook de paragraaf 'bugfixes'.

Uitrol van definitieve release

NedFox kent op dit moment 2 definitieve releases van RetailVista per jaar. In de regel wordt er in Oktober en Februari een release gedaan. Een release bestaat in feite uit een hele serie sprints die achter elkaar zijn afgelegd, dit vormt de uiteindelijke update.

Om een definitieve release te kunnen doen zijn alle taken die onderdeel uitmaken van deze release functioneel getest door NedFox. Ook vinden er op belangrijke onderdelen integratie tests plaats om te kijken of de samenhang tussen de verschillende modules nog correct functioneert. Alle nieuwe gegevens zijn in deze release vertaald van Engels naar Nederlands. Door deze punten heeft een definitieve release een hogere kwaliteit als een tussentijdse release.

Na de laatste sprint voor de Oktober en Februari release is het aan de reseller (indien van toepassing) om groen licht te geven per instantie om de update uit te rollen. Zonder fiattering zal een instantie niet geupdated worden. Na ontvangst van de fiattering stemt NedFox met reseller een datum af. De fiattering per versie wordt op termijn onderdeel van eSocrates.

Het plaatsen van de updates wordt door NedFox uitgevoerd conform SLA (maintenance na 22:00u) en tot uiterlijk woensdagavond. Na woensdagavond worden er geen updates meer geplaatst, om redelijkerwijs een rustig weekend te kunnen garanderen. Bij het plaatsen van een update wordt uiterlijk 24 uur vooraf een announcement verstuurd. Afhankelijk van de SPOC (Single Point Of Contact) instellingen gaat dit bericht direct naar de betrokken klanten of naar de reseller. In dat laatste geval is reseller verantwoordelijk voor correcte communicatie met haar klanten.

Release documentatie

Bij elke officiele release wordt een release document gemaakt. Dit is een QA in eSocrates die ook vanuit RetailVista te lezen is. Hierin staan vrijwel alle taken genoemd die onderdeel zijn van de release. Het kan voorkomen dat sommige taken zo lastig te omschrijven zijn omdat ze een erg technisch probleem oplossen dat ze niet beschreven worden in de release documentatie.

Bij releases na een willekeurige sprint wordt geen release documentatie gemaakt. Dit vindt alleen plaats bij de twee jaarlijkse updates.

Bugfixes op test omgevingen

Geconstateerde fouten in de software op test omgevingen worden gepland en opgelost in de volgende sprint die nog moet beginnen. In tegenstelling tot fouten in productie omgevingen wordt voor een fout in een test omgeving geen bugfix gemaakt en geplaatst.

Bugfixes op productie omgevingen (tussentijdse sprint release)

Geconstateerde fouten in de software op productie omgevingen waar geen workaround voor bestaat en die echt storend zijn worden door middel van bugfixes opgelost. Het streven is om dit binnen enkele werkdagen op te lossen, enigszins afhankelijk van de complexiteit van de bug.

Is er goed om de bug heen te werken, dan zal dit opgelost worden in de volgende officiele release.

Voorwaarde voor het oplossen van een bug is wel dat de klant met de release van de laatste sprint werkt. Bugs kunnen alleen opgelost worden in de laatste sprint. Als klant niet de laatste sprint release gebruikt, dan zal de klant eerst moeten updaten. Het plaatsen van een update kan elke week plaatsvinden, maar wordt op maandagochtend ingepland.

Bugfixes op productie omgevingen (definitieve release)

Geconstateerde fouten in de software op productie omgevingen waar geen workaround voor bestaat en die echt storend zijn worden door middel van bugfixes opgelost. Het streven is om dit binnen enkele werkdagen op te lossen, enigszins afhankelijk van de complexiteit van de bug.

Is er goed om de bug heen te werken, dan zal dit opgelost worden in de volgende officiele release.

Voorwaarde voor het oplossen van een bug is wel dat de klant met de laatste officiele release versie werkt. Bugs kunnen alleen opgelost worden in de laatste officiele release. Als klant niet de laatste release gebruikt, dan zal de klant eerst moeten updaten. Het plaatsen van een update kan elke week plaatsvinden, maar wordt op maandagochtend ingepland.