Comme beaucoup d’autres, l’équipe de développement Akuiteo ne se résume pas au cliché du barbu grognon et pâlot qui code dans le noir, à la seule lumière de son écran. Le dév’, c’est avant tout un travail d’équipe, exigeant et codifié. Dans cet article, partez à la découverte des règles qui gouvernent cette communauté pas si étrange que ça !
L’équipe de développement d’Akuiteo travaille au quotidien sur les évolutions de l’ERP, depuis la création de nouvelles fonctionnalités, jusqu’à l’amélioration de la stabilité de l’outil. Elle fait aussi la chasse aux régressions logicielles, détectées lorsqu’une fonctionnalité cesse de fonctionner après le passage d’une nouvelle version, par exemple.
Chacun des développeurs est également responsable de la maintenance, tour à tour, un jour par semaine. Ce jour-là, il assure la correction de bugs sur des demandes clients qualifiées :
La création d’un nouveau test unitaire peut avoir lieu pendant la phase de maintenance ou lors d’un refactoring, qui consiste à simplifier le code tout en s’assurant que ce qu’il produira sera similaire – on parle de diminution de la dette technique. Il s’agit d’intervenir sur des bouts de code bien compris, en refactorant progressivement.
Lors de chacun de ces « nettoyages » du code, les développeurs d’Akuiteo s’efforcent de créer des tests qui permettent une amélioration incrémentale de l’ERP. Un test unitaire, en somme, c’est du code qui teste du code : une fois dans la journée par exemple, ou bien après chaque génération d’une nouvelle version de l’application, l’ensemble des tests unitaires est automatiquement lancé.
L’équipe Akuiteo a aujourd’hui mis en place des milliers de tests unitaires, en plus d’un suivi de la qualité du code (SONAR), de grands chantiers contre la dette technique et des règles de codage fondées sur une philosophie de développement décrite dans le Clean Code de Robert Cecil Martin.
En plus de faciliter la revue de code (code review), qui consiste en l’examen systématique du code source d’un logiciel par un développeur différent de celui qui l’a codé, les tests unitaires répondent à plusieurs objectifs :
Au quotidien, l’équipe de dév’ s’organise selon des méthodologies agiles. Les bases de ce mode de fonctionnement ont été posées en 2001 par 17 spécialistes du développement de logiciels informatiques, considérant qu’il fallait repenser le cycle de production des applications.
L’objectif de cette agilité ? Être capable de répondre rapidement aux besoins d’évolutions et d’ajustements identifiés avant la livraison du produit final. Pour ce faire, il s'agit d'encourager la collaboration entre développeurs, clients et consultants au fil du développement. Des livraisons intermédiaires permettent ainsi de s’assurer que le produit répondra parfaitement aux attentes des utilisateurs.
À lire aussi : Pourquoi vous ne devez surtout pas négliger l'agilité de votre éditeur d'ERP !Tous les 15 jours, l’équipe de développement se rassemble pour discuter des livrables du prochain sprint. Selon la méthode agile, un sprint, aussi appelé itération, correspond à une période de temps relativement courte (quelques semaines) permettant de produire un certain nombre d’évolutions. Chez Akuiteo, leur chiffrage a lieu en concertation avec les équipes de dév’.
Au cours de ces réunions de lancement de sprint, toute l’équipe est donc mise au courant de l’ensemble des évolutions demandées. Le transfert de compétences est fortement encouragé afin d’éviter que le développement ne repose sur des ressources critiques, en l’absence desquelles il serait impossible d’avancer. Un spécialiste des fonctionnalités de gestion des temps sera par exemple incité à travailler aussi sur la TVA.
En plus d’apporter beaucoup de visibilité aux développeurs, ce mode de fonctionnement évite d’être en production continue de nouvelles évolutions. Le sprint fait en effet office de contrat : pour les 15 prochains jours, il permet de décrire ce que l’on s’engage à produire. Et, si le contrat est rempli plus tôt que prévu, tant mieux ! Mais aucune demande supplémentaire, sans rapport avec le sprint actuel, ne sera intégrée.
Ce temps éventuellement gagné est l’occasion de travailler sur les évolutions des outils internes et de faire du refactoring, renforçant la démarche qualité dans laquelle est engagée Akuiteo.
Deux personnes sont dédiées à la recette de tous les développements. Le feedback est donc très rapide sur ce qui a été produit, évitant les retours sur une évolution un an après qu’elle ait été codée.
L’équipe qualité permet de faire le lien entre les développeurs et la personne qui a défini les spécifications fonctionnelles. Dans l’idéal, avant toute évolution un peu complexe, une présentation a lieu en amont avec le demandeur, éventuellement accompagné d’un développeur leader (« lead dev » dans le jargon), pour préciser les attentes et s’assurer que le développement aura lieu selon la philosophie de départ.
L’équipe de développement est régulièrement amenée à présenter les évolutions réalisées aux consultants en interne, ou encore directement aux chefs de projet ou aux clients, avec l’appui de l’équipe qualité.
À lire aussi : Comment je suis devenu Product Owner.En plus des réunions journalières qui ont lieu debout (on parle de « daily stand-up meeting ») et permettent d’améliorer la communication au sein de l’équipe et de faire remonter les éventuels problèmes, les développeurs échangent au cours de réunions mensuelles. Elles constituent l’occasion de retours d’expérience : développements qui ne se sont pas passés comme prévu, méthodologies de travail à améliorer ou à tester ou encore idées d’évolution de l’intranet.
Développeurs comme chefs de projet ne sont pas infaillibles. Refactoring, tests unitaires, réunions régulières et équipe qualité dédiée sont donc autant de filets de sécurité pour garantir la qualité des évolutions de l’ERP. L’objectif de l’équipe de développement Akuiteo, c’est finalement ça : améliorer chaque jour l’efficacité de la maintenance et les performances du logiciel, ligne de code après ligne de code et test unitaire après test unitaire !