Verwerking AuditCase verzoeken en ontwikkelcyclus

Om verschillende redenen krijgen wij regelmatig het verzoek bepaalde wijzigingen door te voeren in AuditCase. Dit kan soms zijn omdat bepaalde functionaliteit niet werkt zoals deze moet werken of omdat er een wens ontstaat voor een bepaalde functie. In dit artikel willen we dieper ingaan op de redenen om wijzigingen wel of juist niet te verwerken. Om dit in de juiste context te plaatsen zullen we ook in het kort wat vertellen over de ontwikkelcyclus van AuditCase en de ontwikkelmethode die we gebruiken. We starten met de uitleg hoe de verwerking van verzoeken verloopt omdat dit het meest interessant is.

 

Verwerken verzoeken / fouten

Nadat een update is uitgevoerd, beschikt het kantoor over de nieuwste versie van AuditCase. Deze is tijdens de ontwikkeling getest volgens een uitgebreid testscript en nogmaals middels een basistest na de update. Het is mogelijk dat er ondanks de verschillende tests nog fouten in de versie zitten. Wat gebeurt er met deze fouten, en wanneer en hoe worden ze verwerkt? Of een fout wordt opgelost in de huidige versie hangt af van een aantal zaken.

Tickets en issues...

De gevonden fouten worden als tickets aangemaakt in Zendesk. Wanneer deze tickets gereproduceerd en als bug/fout gekwalificeerd zijn, als issues aangemaakt. Deze issues worden door Change to Comm ingepland op een volgende versie van AuditCase.

 

Onwerkbaar of workaround...

Om te bepalen of een fout direct (= zodra verwerkt) wordt opgelost, onderscheiden we verschillende typen fouten/verzoeken. 

  • onwerkbare of flink verstorend fout: deze wordt zo snel mogelijk in een punt release opgenomen en verwerkt op productie (=geïnstalleerde versie) 
  • overige fouten / bugs: in de meeste gevallen is er een workaround en wordt de fout op een volgende versie ingepland, en niet verwerkt in productie (zie onderstaande risico's)
  • wens: wensen voor nieuwe functies of aanpassingen worden altijd bekeken en bepaald of deze waardevol zijn voor AuditCase (en andere klanten)

 

Fouten die ernstig verstorend zijn zullen wij indien mogelijk trachten op te lossen en door te voeren door middel van fixes. In andere gevallen zal bepaald worden of deze via een workaround toch werkbaar zijn of, in sommige gevallen, toch verwerkt worden omdat deze in combinatie met andere wijzigingen mogelijk zijn. Ook kan het zijn dat de impact niet groot is waardoor een fix mogelijk is. Wensen zijn altijd welkom en worden mogelijk meegenomen in een nieuwe versie.

 

Risico's
De reden dat wij niet altijd alle fouten kunnen/zullen verwerken in productie is voornamelijk vanwege het risico dat het met zich meebrengt. Het verwerken van losse wijzigingen heeft als risico dat deze niet de normale ontwikkelcyclus hebben doorlopen en niet zijn meegetest. Dit kan als gevolg hebben dat andere functies niet werken en dat de gevolgen nog vervelender zijn dan ze in eerste instantie waren.

Wanneer een issue in een volgende versie meekomt doorloopt deze de normale cyclus. De functie wordt niet alleen beter getest, maar wordt ook in combinatie met andere verwerkingen opgelost en getest (en ook beter uitgedacht). Normaal gesproken wordt een wijziging enkele malen in het proces getest.

 

AuditCase ontwikkelcyclus en versies

Er werd al gesproken over de cyclus, maar hoe verloopt deze cyclus? Iedere 3 weken wordt er een nieuwe AuditCase versie gemaakt en deze ontwikkelen we door middel van de SCRUM ontwikkelmethode. Bij deze methode wordt gewerkt met een korte (ontwikkel)cyclus om zo beter in te kunnen spelen op veranderende wensen / omstandigheden. De voordelen die wij inmiddels ervaren hebben... 

  • Wensen kunnen snel verwerkt worden in versies 
  • Het (ontwikkel)traject blijft goed beheersbaar en er is duidelijkheid in planning / wijzingen / nieuwe functies etc.
  • Versies kunnen snel gemaakt worden door het continue verbeteren van het proces en het wegnemen van belemmeringen

 

Ontwikkeltraject

Het proces dat gedurende de 3 weken doorlopen wordt, geschiedt in de volgende stappen..

 

  1. Bij de start van de 'sprint' wordt bepaald wat er verwerkt wordt in de versie.
  2. De versie wordt ontwikkeld door het verwerken van losse issues (en per issue getest).
  3. De versie wordt aan het einde van de sprint getest.
  4. De versie wordt 'gebuild' en is klaar voor uitlevering.

 

De versie die wij uitleveren / installeren tijdens de geplande update is de laatst ontwikkelde, beschikbare versie (indien gebruik wordt gemaakt van een testomgeving zal dit de versie van de testomgeving zijn).

 

Hebt u meer vragen? Een aanvraag indienen
Mogelijk gemaakt door Zendesk