- Afdrukken
- DonkerLicht
- Pdf
Wat is het release beleid van de RetailVista POS software van NedFox?
RetailVista POS wordt aangestuurd via versiebeheer in eSocrates, waarbij klanten in klant groepen zijn verdeeld. Het beheer en inrichting van deze groepen vindt plaats door NedFox.
Om het ontwikkel traject gestroomlijnd te laten verlopen voert NedFox alle aanpassings verzoeken op 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).
Eenmaal per jaar, in Oktober, vindt overleg plaats met de resellers en winkel organisaties over de roadmap voor het daarop volgende jaar. Uit het resultaat van die besprekingen wordt een roadmap document op hoofdlijnen samengesteld en worden er een aantal specifieke taken op detailniveau ingepland in een roadmap sprint. De inhoudt van die roadmap sprint is via eSocrates zichtbaar. Let wel: Aan de roadmap zijn geen rechten te ontlenen! Als taken echt cruciaal zijn dan worden de kosten voor realisatie aan de klant in rekening gebracht en alleen dan is te garanderen dat een taak onderdeel zal zijn van de volgende release.
De uitrol van updates van RetailVista POS wijkt af van de RetailVista ERP omgeving, omdat de POS software lokaal geinstalleerd wordt. Om die reden is het veel eenvoudiger om een versie gefaseerd uit te rollen. Er is daarom ook geen sprake van een vaste release frequentie, updates van RetailVista POS kunnen vaker of minder vaak plaats vinden.
Om te komen tot deze releases wordt gewerkt met sprints van telkens 4 weken waarin wij telkens delen uit de roadmap sprint van dat jaar inplannen. De sprints worden verder aangevuld met taken die naar voren zijn gekomen uit de supportdesk van NedFox, welke ook de reseller tickets behandeld.
Van tijd tot tijd worden POS updates gemaakt welke zichtbaar zijn in versiebeheer van RetailVista. Op verzoek van een reseller kan een specifieke POS versie worden vrijgegeven aan bijvoorbeeld alleen de reseller zelf. Dat geeft resellers de mogelijkheid om kennis te nemen van de gemaakte wijzigingen en desgewenst test en acceptatie werkzaamheden uit te voeren.
Soms valt de hoeveelheid werk in een sprint tegen en 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 naar de volgende sprint. Zeker bij de laatste sprint voor een finale release kan het dus gebeuren dat bepaalde taken de release niet gaan halen en onderdeel zullen zijn van de daarop volgende release. Ook gebeurd het soms dat de impact van een taak bij nader inzien te omvangrijk is en wordt een taak alsnog uit een sprint gehaald.
Uiteindelijk is het aan de reseller om groen licht te geven per klant groep om de update uit te rollen. Zonder fiattering zal een klantgroep niet geupdated worden. De fiattering per versie en klantgroep wordt op termijn onderdeel van eSocrates.