May

Fort d’un partenariat Product - Tech, nous créons des binômes Développeur - Product Owner pour chacune des features développées au sein d’une grande squad multidisciplinaire.

Conscients du temps de chacun, nous rythmons nos sprints de 2 semaines avec le minimum de rituels d’équipe nécessaires :

• Un kick-off de 30 minutes le lundi matin, 
• Un daily stand-up de 15 minutes maximum les autres jours, 
• Un weekly poker planning d’une heure le mardi
• Une rétro toutes les deux semaines.

Notre gestion de projet se fait principalement sur Notion, outil que nous faisons évoluer progressivement pour répondre à nos besoins et suivant une démarche d’amélioration continue de nos process.  

Le cœur de l’application May est son moteur de règle : sa capacité à attribuer des avantages en temps réel lors d’un paiement. Ces règles sont en constantes évolutions et sont régies par de nombreuses variables (limite journalière, jours autorisés, plafond) qui changent dans le temps, par salarié et par employeur !  

Afin de suivre les évolutions réglementaires de nos différents avantages salariés nous avons créé un DSL (Domain Specific Language) extensible. Chacune de nos règles est configurable dynamiquement via celui-ci.

Afin d’améliorer notre Developer Expérience nous opérons des changements clefs dans nos process de gestion de code et de déploiement : 

• En implémentant un système de Feature Flags, nous permettons d’appliquer des changements sur notre codebase sans que ceux-ci soient actifs. En décorrélant merge, déploiement et activation de features nous pouvons adopter le “Trunk Based Development”.
• Le “Trunk Based Development” permet d’avoir une seule source de vérité linéaire sur l’état actuel de la codebase, il simplifie les opérations git et les déploiements.
• Enfin, afin de garantir l’intégrité de notre système lors de merge fréquents, nous ajoutons des tests end-to-end automatisés.