Development proces
Sprints
We werken met sprints van twee weken waarbinnen we zo veel mogelijk werk proberen te verzetten. Op de eerste dag van de sprint kijken we welke werkzaamheden of projecten prioriteit hebben en vullen de sprint met taken uit de backlog of eventueel andere lijsten zoals bugs of projectlijsten. Voor verschillende taken wordt overlegd wat de ureninschatting is om zo ook de juiste hoeveelheid taken in een sprint te kunnen plaatsen.
Backlog
De backlog wordt zoveel mogelijk onderhouden door de product owner. In overleg met customer succes manager en management wordt er gekeken welke taken de meeste waarde hebben in een volgende sprint. Volgorde en invulling ervan zullen nauwkeurig in de gaten worden gehouden en moeten overeen komen met de roadmap van gewenste functionaliteiten die er ligt.
Bugs
Wanneer een bug binnenkomt kijkt de product owner hoe kritiek de bug is voor het systeem of de klant waarna de bug naar de backlog gaat of in de sprint wordt gezet. Vaak kan er gevraagd worden aan een developer om kort te kijken wat het probleem is en een tijdsindicatie te geven voor het oplossen ervan.Criteria bij beoordelen van een bug:
- Hebben meer klanten er last van
- Is het een visueel iets wat aan te passen is of een probleem wat het project onwerkbaar maakt.
Kwaliteit
Voor een developer aan een taak begint neemt hij contact op met een collega om even kort te bespreken hoe hij de taak gaat aanpakken. De taken staan op “to do” en worden op “in progress” gezet wanneer een developer eraan werkt. Wanneer hij de taak heeft afgerond doet hij zelf een check en zet hij de taak op “needs testing”. Een collega wordt gevraagd hetgeen te testen en een code-review te doen. Vervolgens kan de taak op “ready to go” of terug naar “pending” of “to do” als het niet goed is. Wanneer een taak gereed is en actief staat voor klanten kan hij op “done”.
Uren
De gewerkte uren worden op de taak geboekt zodat er ook inzicht is in de uren per project of taak.
Communicatie
Wanneer een bug is opgelost wordt dit door de product owner gecommuniceerd met de customer succes manager of direct met de klant. In het geval van nieuwe functies communiceert de product owner met de customer succes manager over een release log, blog post of nieuwsbrief.
Kennisdeling
Developers bepalen samen wie welke taken oppakt om zo ook nieuwe dingen te leren. Door bespreken en code reviews komen ze meer te weten over de verschillende onderdelen van Maglr en de gebruikte technieken. Wanneer er nieuwe techniek gebruikt wordt moet dit altijd in overleg gebeuren. Nieuwe techniek waarmee gewerkt wordt kan gedeeld worden met collega’s in een kennissessie.
Retrospective
Na iedere sprint overleggen over wat beter kan, opbouwende kritiek geven op elkaar.