Que se passe-t-il à Coop IT Easy entre le moment où une structure cliente, appelons la SuperCoop, fait une demande, et le moment où sa demande est disponible sur sa base de données ? Quelles sont les étapes du développement ? Et quels métiers interviennent pour le mener à bien ?
A Coop IT Easy, nous sommes très soucieux d’être transparents et inclusifs avec nos clients et clientes. C’est pourquoi Victor, un développeur, prend la plume pour vous expliquer son point de vue…
Demande et spécification fonctionnelle
Le processus démarre lorsque SuperCoop émet une demande. Cette demande peut être une nouvelle fonctionnalité, une amélioration d’une fonctionnalité existante, ou la correction d’un bug.
Prenons un exemple très simple: SuperCoop souhaite ajouter un champ « Bière préférée » dans les contacts, pour pouvoir leur en offrir le jour de leur anniversaire. Notons que cet exemple est excessivement simplifié pour permettre d’en suivre facilement le déroulé. C’est pour des demandes plus complexes que le processus décrit ici prend tout son sens.
L’analyste reçoit la demande, s’assure de l’avoir bien comprise et réfléchit avec SuperCoop à la meilleure manière d’arriver à satisfaire la demande.
Avant de se lancer dans une analyse détaillée, le premier réflexe est de chercher si un module de l’Odoo Community Association (OCA) ou un module réalisé par Coop IT Easy pour une autre structure cliente permettrait de répondre au besoin.
Si ce n’est pas le cas, le client ou la cliente peut alors écrire une spécification fonctionnelle. C’est simplement une description du besoin de la structure cliente, une description de l’état actuel des choses, et une description de l’état attendu. Le tout est souvent agrémenté de captures d’écran avec de jolies flèches colorées. Cela permet d’expliquer la demande de la manière la plus claire possible pour être sûr que le développeur ou la développeuse la comprenne bien.
Par exemple
- Besoin de SuperCoop : Avoir une information sur la bière préférée du contact pour lui en offrir une le jour de son anniversaire.
- État actuel : Il n'y a pas de champ "Bière préférée".
- État attendu : il doit y avoir un champ "Bière préférée" en dessous du champ "Implantation". Ce champ doit apparaître pour tous les contacts. Il doit être possible de le faire filtrer sur la valeur de ce champ depuis la liste des contacts. Il s'agit d'un champ texte libre.
La spécification fonctionnelle est validée par SuperCoop, et est ensuite envoyée à l’équipe de développement pour estimation.
Estimation du temps de développement
Une personne de l’équipe de développement est chargée d’estimer le temps de travail nécessaire. Iel planifie le développement à faire et essaye d’anticiper les potentielles difficultés. Iel donne un nombre d’heures (toujours multiple de 4 : 4h, 8h, 16h…) estimé. Un développement n’est jamais estimé en dessous de 4h. En effet, comme cela est expliqué plus loin, toutes les étapes du processus sont nécessaires et demandent un certain temps à être accomplies.
L’estimation est parfois difficile : une tâche qui paraît simple à première vue peut parfois comporter un détail qui va compliquer le travail à faire et fausser l’estimation !
Dans notre exemple, le développeur ou la développeuse estimera quatre heure de travail, car la tâche est simple à réaliser. Mais iel doit faire très attention à des détails qui pourraient compliquer la tâche.
- Est-ce que le champ sera encodé manuellement ou calculé automatiquement?
- Est-ce que des règles de sécurité doivent s’appliquer?
- Est-ce que le champ fera partie d’un nouveau modèle ?
Le chemin d’un développement est semé d’embûches, c’est à la personne qui estime le temps de développement de les repérer et d’en avertir l’analyste.
Une fois l’estimation faite, l’analyste la transmet à SuperCoop pour la discuter et la valider. Si elle ne convient pas, on modifie la demande pour refaire une estimation qui soit satisfaisante.
Développement de la fonctionnalité
Bon, la demande est bien comprise, son temps à été estimé et le travail à faire à été analysé. Maintenant on va écrire du code, non ? Et non, pas tout de suite ! Le développeur ou la développeuse assignée ne se jette pas à corps perdu dans ses lignes de code ! Il lui faut d’abord reproduire l’état initial de la demande sur son propre ordinateur. En particulier, installer les modules nécessaires. Sans ça, on travaille à l’aveugle, sans savoir si le code fonctionne comme attendu.
En effet, le développement est souvent un travail itératif : on code un premier morceau, on lance Odoo pour vérifier que ça fonctionne, puis on code un deuxième morceau, etc.
Si le développement contient des conditions logiques complexes, on écrit aussi des tests automatisés qui vérifient que la logique est toujours valide. Ces tests sont particulièrement importants pour s’assurer que les développements futurs ne “cassent” pas le code qui a déjà été écrit.
Quand tous les morceaux ont été codés, on clique sur “déployer dans la base de données de SuperCoop” et va s’acheter une glace. Ce serait trop beau non ? C’est surtout trop risqué ! Car les chances d’introduire des bugs seraient très fortes.
En fait c’est à partir d’ici que commence une démarche de contrôle qualité en deux volets :
- La revue du code
- Les tests fonctionnels
la Revue du code
Une fois le code écrit, une autre personne de l’équipe de développement le lit pour vérifier plusieurs points.
- S’assurer que la logique du code est correcte.
- Vérifier que certaines bonnes pratiques sont appliquées : nommer les choses de manière cohérente et compréhensible, éviter les répétitions, découpler le code, commenter les parties moins évidentes à comprendre, etc. Cela permet d’avoir un code plus simple à maintenir sur le long terme, et que les changements futurs puissent être faits facilement.
- Vérifier l’adéquation avec les conventions de l’Odoo Community Association (OCA), afin de faciliter une éventuelle inclusion du code à l’OCA. Cela correspond en effet à une de nos stratégies 2022 !
On va demander des changements à la personne qui a écrit le code. Une fois les changements apportés, une nouvelle revue est faite, jusqu’à ce que le développement soit validé. Il est rare qu’il y ait besoin de plus de deux phases de revue. Cette pratique est courante dans les logiciels open source comme Odoo Community.
La revue du code de l’ajout du champ « Bière préférée » devra s’assurer que cela a été fait dans le bon module, que le nom technique du champ est bien choisi, etc.
les Tests fonctionnels
En parallèle de la revue du code, le développeur ou la développeuse déploie son code sur le serveur de test pour que l’analyste vérifie que le développement qui a été fait correspond exactement à la demande de SuperCoop, et que cela s’intègre bien dans leur base de données. De plus, iel s’assure que le développement n’introduit pas de nouveaux bugs.
De la même manière que la revue de code, les tests fonctionnels se font de manière itérative : si les tests ne sont pas concluants, le développeur ou la développeuse revoit son code, puis le soumet à nouveau pour être testé, etc.
Dans notre exemple, l’analyste vérifiera que le champ a été mis au bon endroit, qu’il apparaît bien pour tous les contacts, etc. L’analyste demande aussi à SuperCoop de vérifier et de valider que tout est bien conforme à sa demande.
le Déploiement
Ça y est ! Tous les voyants sont au vert, on peut apporter les modifications sur la base de données de SuperCoop.
Une personne de l’équipe des analystes prend en charge l’organisation du déploiement sur la base de données de SuperCoop. Ces déploiements sont faits une fois par mois minimum. L’analyste crée aussi une « release note » (une liste de toutes les nouveautés qui seront déployées sur les serveurs de production). Les fonctionnalités sont documentées sur notre outil en ligne et un mail d’information est envoyé à tous les clients et clientes pour les avertir de la mise en production.
C’est un membre de l’équipe “infra” (pour infrastructure informatique) qui effectue le déploiement. Iel met à jour ou installe les modules développés sur la base de données de SuperCoop. Cette tâche est faite pendant la nuit ou en dehors des heures d’activités des clients et clientes, pour ne pas interrompre Odoo en pleine journée de travail.
Au petit matin, SuperCoop pourra alors trouver la fonctionnalité demandée intégrée à sa base de données, encore chaude et prête à être utilisée !
conclusion
Le processus peut sembler long mais toutes les étapes ont un sens :
- Les tests fonctionnels permettent de minimiser les risques d'introduires des bugs dans les bases de données des clients et clients et de s'assurer que tout le développement s'intègre bien dans la version existante.
- Les revues de code permettent d'améliroer la qualité de code pour faciliter les développements futurs et d'intégrer potentiellement nos modules à l'OCA.
- Plusieurs étapes sont validées par le client ou la cliente. Cela permet de réagir rapidement en cas de mauvaise compréhension de la demande, ou si la demande est modifiée en cours de développement (ce qui arrive régulièrement !).
Comment améliorer ce processus ? Est-ce qu'il devrait être adapté pour les demandes simples, comme celles de SuperCoop qui voudrait ajouter un simple champ ? Nous réfléchissons régulièrement à améliorer ce processus pour le rendre plus rapide, plus sûr, ou plus inclusif. Si vous avez des conseils, des idées ou des réaction suite à la lecture de cet article, n'hésitez pas à nous en faire part.