Onder de motorkap: De processen achter technologie bij Shoprocket

Dit is het eerste artikel in een nieuwe serie waarin we onthullen hoe we dingen doen in de techafdeling van Shoprocket. We zijn trots op de systemen en processen die we hebben, maar we zijn altijd op zoek naar verbetering en ontwikkeling. We horen dan ook graag hoe jullie dingen doen.

Vandaag gaan we kijken naar hoe een sprint wordt opgezet bij Shoprocket.

We hebben een sprintproces van 10 dagen. Hier is hoe een gemiddelde dag eruitziet voor een van onze ontwikkelaars:

• 4 uur sprint
• 2 uur foutoplossingen
• 2 uur vrije tijd

Dat betekent dat elke ontwikkelaar 40 uur per sprint heeft om aan zijn sprinttaken te werken. Elk uur vertegenwoordigt één story point en deze zijn als volgt verdeeld:

Story Grootte

• klein = 5 story points
• gemiddeld = 10 story points
• groot = 20 story points
• extra groot = 40 story points

We gebruiken story points om onze burndown en geschatte leveringen te beheersen. We beloven nooit een afleverdatum, aangezien mensen daar gewoon slecht in zijn. In de toekomst zijn we van plan om de metadata in onze sprinttool te gebruiken en deze te koppelen aan de storygrootte om historische gemiddelden te berekenen over hoe lang het kostte om X te doen, aangezien dit een goede indicator is voor hoe lang het zal duren om soortgelijke taken uit te voeren. We hebben deze tool nog niet, dus als iemand het leuk vindt om het te bouwen (ik kijk naar jou sprint.ly), zou dat geweldig zijn.

In deze sprint was het een zeer standaard aangelegenheid. We zijn begonnen met het oplossen van bugs en het schrijven van systeemupdates zoals gebruikelijk.

Een van die updates was voor orderrapportage. Door ondersteuning voor lijnitems aan te bieden, kunnen gebruikers nu zien uit welke onderdelen een order bestaat in plaats van alleen het orderbedrag te zien. Op het eerste gezicht lijkt dit een erg eenvoudige taak, maar in werkelijkheid is het behoorlijk lastig, omdat het rapport op een manier moet worden opgebouwd die compatibel is met de talloze boekhoudprogramma's die er zijn. Daarnaast moet het werken met onze volledige database die een heel jaar teruggaat en in real time een volledig rapport binnen ongeveer één seconde exporteren.

Wat betreft de kerntechnologie is Winston bezig geweest met het splitsen van onze eerste microservice en deze te integreren met onze bestaande applicatie. De eerste die we hebben gekozen, was een Sessie Beheer Systeem, dat de code genereert voor een unieke GUID die tijdens de levensduur van een order wordt gebruikt (of deze nu is voltooid of verlaten). We zijn van plan om een hele serie te schrijven over ons microservice-avontuur, dus we zullen hier niet te veel in detail treden; het is voldoende om te zeggen dat de overgang van monolithisch naar microservice uitdagend maar leuk is.

Alex is bezig geweest met een back-endtool voor het omgaan met UTM's. Marketing dringt al lange tijd aan op deze tool en we zijn verbaasd dat iets als dit momenteel niet in het wild bestaat (we zullen het waarschijnlijk open-source maken zodra het klaar is), omdat het een relatief eenvoudige en zeer noodzakelijke tool is.

Shashi is deze week on fire geweest. Hij heeft zijn cadeauverpakkingsmodule afgerond, die nu bij product is en in wezen de gebruiker in staat stelt om zeer snel cadeauverpakkingsopties aan zijn winkelwagentje toe te voegen. Daarna ging hij snel verder met het bouwen van onze Google Analytics-integratie. Dit is iets dat absoluut niet op onze radar stond, maar een van onze partners heeft ons benaderd met het verzoek, en vertelde ons hoe belangrijk dit was voor hun productlevenscyclus. Als de meegaande techteam die we zijn, hebben we het erin geperst. Het ziet er al cool uit en volgt moeiteloos alle belangrijke elementen van een winkelwagentje. We wijken nooit echt af van een sprint zodra deze ingesteld is, maar we laten de flexibiliteit in de sprint om dit te kunnen doen.

Hier is hoe een van onze Sprint.ly-taken eruitziet.

Het proces voor het creëren hiervan is ook vrij eenvoudig: iemand die de leiding neemt, schrijft de initiële specificatie en vervolgens springen we allemaal op een Google Hangout om deze verder uit te werken. Het wordt vervolgens naar externe partijen gestuurd voor feedback en wordt door de rest van het bedrijf gecheckt op de juiste zin. 

En dan bouwen we het. Simpel, hè?