Suite à la fusion de deux grands groupes français du secteur de la distribution, les équipes Daveo sont intervenues pour rassembler et regrouper des projets internes. Un des projets mis en place a été le développement d’un nouveau circuit de paiement, rassemblant les deux entités.
Cette fusion s’est donc accompagnée de la création de feature teams, c’est-à-dire d’équipes dédiées aux différents besoins du client. L’objectif était de mettre en production une nouvelle application, et ce en respectant un délai d’un an.
Sébastien Robalo, consultant chez Daveo, partage avec nous son expérience.
- Le projet paiement
Avant ce projet, l’équipe de chaque groupe gérait sa propre application de paiement de son côté. Lorsqu’il y avait besoin de rajouter un nouveau mode de paiement, tout était développé et géré individuellement. Avec cette fusion, l’entreprise dépensait un budget trop important en développant deux fois le même produit.
L’équipe Daveo a donc créé from scratch un module interne de paiement commun, qui s’interfaçait avec les différents partenaires de paiement (Ogone, Sips,…) afin d’émettre les actions de débits et de remboursements des clients.
Voici schématiquement la représentation d’un exemple de paiement :
- Lancement du projet
La première chose à faire était de réfléchir à la structure de l’application, son fonctionnement, comment elle communiquerait avec les applications des deux entités du groupe et avec les partenaires de paiement.
Il fallait ensuite construire la structure de la base de données. S’en est suivi beaucoup de réunions, de questions, de brouillons, avant d’avoir quelque chose de stable. L’équipe a été confrontée à quelques difficultés, car les applications déjà en place chez le client, qui doivent communiquer avec le nouveau module paiement pour effectuer des demandes bancaires, n’étaient pas conçues de la même façon. Ils ont donc dû trouver des solutions pour que la nouvelle application de paiement puisse ingérer les données de ces deux différentes applications.
Sébastien ajoute : “Il est nécessaire d’avoir un numéro de commande afin de pouvoir le rattacher à un paiement. Au sein de la première entité, ce numéro était composé uniquement de chiffres, sur 8 caractères. Chez l’autre, il comportait 32 caractères alphanumériques. Toutes ces petites différences ont dû être prises en compte dans la création de la nouvelle solution.”.
Après environ 1 mois, la première structure de base de données sur laquelle développer était prête. Peu de temps après, étant donné l’étendue du projet, l’équipe initialement composée de 3 membres est passée à 10 personnes. Une très bonne ambiance régnait, et il y avait beaucoup de communication, ce qui a permis d’avancer rapidement sur l’application.
- Défis et évolutions en équipe
Un point d’amélioration auquel l’équipe a dû faire face est la réduction du temps passé sur du refactoring, c’est-à-dire sur la révision d’un code déjà écrit afin de l’améliorer et optimiser sa lisibilité.
Un changement de stratégie a été réalisé, notamment en faisant des descriptions plus claires et plus approfondies des besoins.
Le système de réunion a été revu, afin de passer plus de temps sur certains sujets et faire en sorte que chacun soit en mesure d’apporter des solutions. L’équipe a aussi ressenti le besoin de mettre en place des réunions techniques entre développeurs, afin de valider les architectures de développement sur les sujets qui en avaient besoin.
“Nous avons également instauré du pair programming : au lieu de mettre un développeur sur un sujet, ils travaillaient désormais en équipe de deux. Le développement se faisait alors plus rapidement, en confrontant plusieurs visions de développement. Cela nous a permis de limiter les retours techniques sur le code, et donc gagner du temps pour travailler sur d’autres sujets”, continue Sébastien.
Afin de ne développer que ce qui était nécessaire pour les tests et d’éviter d’écrire du code qui ne serait pas utilisé, les développement se faisaient désormais en TDD, c’est-à-dire en écrivant des tests unitaires avant procéder au développement.
Toutes ces modifications dans leur façon de travailler ont permis à l’équipe d’avancer plus efficacement. Quelques jours après la mise en place de ces nouveaux modes de fonctionnement, ils ont pu remarquer une baisse drastique du nombre de retours de bugs.
Extraire le paiement de ces deux applications, qui existent depuis plus de 10 ans, était un challenge. Mettre en production cette nouvelle application sur une période de 12 mois, en la créant from scratch accentue d’autant plus ce défi. Le charme de ce projet résidait dans le fait que l’équipe a été force de proposition, et que le client était à l’écoute sur les choix techniques. Ces derniers ont pu être facilement mis en place, grâce à une forte agilité dans l’équipe.