En tant que partie prenante d'un projet de développement mobile, un des intérêts de développer un produit avec la méthode agile est de simplifier la communication au sein de l'équipe. Pour éviter le langage technique, l'équipe échange en utilisant des termes fonctionnels.

Mais, même en l'absence de termes techniques, la réussite de votre projet à moyen et long terme repose sur la qualité du code produit par les développeurs. Vous trouverez dans cet article des conseils pour piloter cette qualité au fil de votre projet.

Ne craignez pas la complexité technique de cet article, il est destiné à tous !

Votre mot clé est : agilité technique.

L'agilité technique a pour objectif de réduire la dette technique et de rendre le projet maintenable et reprenable. C'est-à-dire, s'assurer que la reprise du projet par une nouvelle équipe sera peu coûteuse. Par exemple lorsqu'un projet BAM prend fin, l'agilité technique permet à notre client de faire reprendre le projet par ses propres développeurs sans perdre de temps, et donc sans "gaspiller" d'argent. Mais l'agilité technique est tout aussi importante au cours des développements, car elle assure aux nouveaux développeurs qui viendraient renforcer l'équipe de pouvoir commencer à développer rapidement sans retarder le projet.

Comment piloter l'agilité technique de mon projet ?

Pour piloter l'agilité technique de votre projet, il vous faut "des standards".

Qu'est ce qu'un standard ? Le standard est un objectif défini par l'équipe qui lui permet de réussir le projet. Exemple : je souhaite développer une application mobile de manière agile avec des retours utilisateurs fréquents. Pour atteindre cet objectif, je me fixe comme standard d'avoir un test utilisateur par semaine. Toute les semaines je vais vérifier si mon standard est respecté ou non. Le suivi de ce standard peut être matérialisé comme ci dessous.

Le non-respect d'un standard représente un risque pour le projet. Il sert d'alerte et de point d'attention à l'équipe.

Les standards d'agilité technique chez BAM

Ce sont les standards qui aident les équipes BAM à piloter la qualité du code produit pour nos projets mobiles. Ces standards sont des indicateurs créés par expérience. Au fil des réussites et des échecs, nous avons appris que les 7 points suivants étaient cruciaux dans le succès d'un projet. C'est ainsi que sont nés nos 7 standards d'agilité technique. Ils peuvent évidemment être utilisés pour piloter un projet hors BAM.

Assurez-vous que ces 7 standards sont respectés et vous écarterez des risques importants de votre projet.

N°1 : Le vocabulaire code est identique au vocabulaire métier

Le code doit faire appel à des variables qui sont celles utilisées par celles du métier afin de prévenir des bugs ou de perte de temps en créant du travail supplémentaire . Exemple : Dans une application de diffusion d'informations locales, une métrique clé était le quartier des utilisateurs afin de leur diffuser les informations appropriées. L'équipe technique a créé une métrique "quartier" qui était en réalité le code postal. Au cours de projet, l'équipe s'est rendue compte que des personnes du même quartier pouvaient avoir des codes postaux différents (comme certains arrondissements parisiens). En plus d'une application qui ne délivrait pas les informations à l'ensemble de la cible, cela a engendré des bugs et donc du travail supplémentaire pour rendre l'application utilisable.

N°2 : Dépendances stables et à jour

Dans les applications, les développeurs ne codent pas à partir de rien, ils utilisent des "bibliothèques" disponibles à tous. Ces bibliothèques permettent d'accélérer les développements en capitalisant sur du code déjà écrit par d'autres développeurs. Mais celles-ci sont améliorées et enrichies continuellement, par conséquent, l'équipe doit mettre à jour le code avec les nouvelles mises à jour de la bibliothèque, sans quoi le "code emprunté" peut ne plus marcher.

L'intérêt de suivre ce standard semaine après semaine est de mettre à jour au fur et à mesure des évolutions de la bibliothèque, et donc éviter des mises à jour coûteuses et compliquées après plusieurs mois sans actualisation.

N°3 : Destruction de l'environnement

En détruisant son environnement chaque semaine et en le réinstallant en moins de 15 minutes les membres de l'équipe technique s'assurent que la documentation ajoutée au fur et à mesure de leurs développements permet à n'importe quel développeur de reprendre le projet facilement.

NB : l'environnement est l'ensemble des outils installés qui servent à développer.

N°4 : Au moins un refactoring par jour

Le refactoring consiste en à retravailler son code sans rajouter de fonctionnalités mais en le simplifiant. L'objectif est de garder un code lisible et plus facilement maintenable. En s'imposant au moins un refactoring par jour l'équipe technique s'oblige à travailler la lisibilité et la qualité de son code.

N°5 : Code coverage en augmentation

Code coverage = couverture de test(%). Exemple : j'ai 10 lignes de code et je teste 5 lignes. Ma couverture de test est de 50%.

L'équipe technique code des tests automatiques qui permettent de vérifier que le code de l'application écrit fonctionne correctement. Pour que la couverture de test soit en augmentation il faut donc en parallèle des développements coder des tests.

Plus ce qui a été créé est testé automatiquement, plus il est facile d'identifier les bugs et les régressions.

NB : Une régression est le fait qu'une fonctionnalité ne marche plus alors qu'elle fonctionnait avant.

N°6 : Build et déploiement en staging et en production en une commande

Le déploiement est l'action de faire passer le code de l'ordinateur d'un développeur à une application téléchargeable sur un smartphone. Il y a de très nombreuses d'étapes pour y arriver. L'objectif de ce standard est d'automatiser ce processus, afin de gagner du temps et d'éviter les erreurs humaines en chemin.

N°7 : intégration continue verte sur toutes les branches déployées

Quand les développeurs sont plusieurs à coder, ils créent des branches : chacun code de son côté. Le standard permet de s'assurer que le regroupement de ces branches se fasse sans bug et ne casse rien au code déjà existant. Afin d'éviter des régressions, toutes les branches développées par les membres de l'équipe technique doivent être testées et OK avant le déploiement.

Chez BAM nous pilotons ces 7 standards car ils garantissent la qualité du code produit tout au long du projet et permettent à nos clients de poursuivre leur aventure mobile facilement après le départ de nos équipes. Nous recommandons à chaque membre d'une équipe en développement mobile de suivre et de faire évoluer ces indicateurs en fonction des besoin. Si cet article vous a intéressé et que vous vous questionnez sur l'équipe idéale à former pour développer un projet de qualité, découvrez nos 5 conseils pour choisir une équipe de développement.