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 !
Évolutions et maintenance du code : les deux rôles principaux du développeur
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 :
- prise de connaissance de la demande remontée par l’équipe support (quelle version et quelle base ont été utilisées ? s’agit-il d’une branche métier ? d’un développement spécifique ?) ;
- reproduction du problème à partir de l’environnement client ;
- analyse du problème et identification de son origine ;
- correction du bug ;
- vérification de la présence ou non du bug dans la dernière version stable du logiciel – auquel cas, correction du bug ;
- report de la correction dans la version en développement ;
- mise en place d’un test unitaire afin d’éliminer la dette technique.
Les tests unitaires : filets de protection du code
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 :
- En maintenance, ils permettent de s’assurer qu’un bug réglé une fois ne se reproduise jamais, faisant à terme considérablement diminuer le nombre de problèmes remontés.
- En développement, il s’agit cette fois de conserver la maîtrise du code et de créer un garde-fou pour les futures évolutions et corrections, mais aussi d’identifier le code critique et de l’endiguer pour mieux le protéger.
- Ces tests ont enfin un rôle de spécification fonctionnelle (de « spéc ») : ils permettent de comprendre quel était l’objectif qu’avait en tête le développeur lors du codage de la fonctionnalité.
L’agilité au cœur du développement d’Akuiteo
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 !
Le sprint
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.
L’équipe qualité
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.
Daily stand-up meetings et réunions mensuelles
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 !
À propos de l'auteur :
Par Julien Costerg
Directeur des opérations - Akuiteo SAS
