« 2 jours ? C’est juste un petit truc ! Ça ne peut pas prendre si longtemps ! »

Réunion de planification Scrum, dans une PME d’une douzaine d’employés, dont 5-7 personnes dans l’équipe de devs. Elles passent en revue les stories en haut du backlog, par ordre de nombre de points descendant. Pour chaque, découpage en tâches techniques¹ et estimation grossière du nombre de jours de travail, pour déterminer ce qui devrait rentrer dans le sprint et quand arrêter d’en prendre².

Au bout d’un moment, l’équipe arrive à une story d’apparence simple : sur l’application mobile Android qu’elle maintient et édite en marque blanche pour ses clients B2B, il est demandé d’ajouter une pastille sur les contenus offerts avec l’appli, pour permettre aux utilisateurs (= les clients des clients de la PME) de mieux identifier ces cadeaux au milieu de leurs achats.

Vu de loin et sans entrer dans les détails, ça n’a pas l’air d’être une très grosse évolution et l’équipe estime qu’il y en a pour deux jours de travail.
Quelque chose comme 0,25 jour pour bien cadrer le besoin³ et déterminer quel pictogramme afficher, 0,25 jour pour monter un environnement de développement, 1 jour pour coder et tester/valider la fonctionnalité et 0,5 jour pour rebuilder les déclinaisons de l’application pour chacun des clients et les déployer sur le store Android.

Mais…

Le product-owner / chef de projet de l’équipe, qui a plein d’autres stories sous la main, se remémore la conversation qu’il avait eue avec le directeur commercial qui avait exprimé ce besoin… Il va le voir et les deux reviennent dans la salle de réunion. Le second annonce alors :

Ça ne peut pas prendre deux jours.
J’ai programmé un peu quand j’étais à l’école, ça ne peut pas prendre si longtemps !

Instant 🤯 des développeurs et développeuses.

La discussion tourne en rond pendant dix minutes⁴, le ton monte peut-être même, avant d’arriver, d’un côté, à :

Il faut implémenter ça, c’est promis à nos clients.
Tant pis si c’est pas super bien codé⁵, c’est pas grave.

De l’autre côté :

Oui ben on va faire au plus vite pour implémenter cette fonctionnalité dans l’application qu’on connait mal et ça ajoutera encore du temps sur toutes les prochaines évolutions, puisqu’on prendra des raccourcis…

On sent l’équipe un peu énervée et frustrée⁶. Et résignée.

Après quelques jours, elle attaque cette story. Ou, plutôt, pour une petite story estimée à seulement quelques jours de boulot, une personne de l’équipe attaque cette story.

Vous vous en doutez et ce ne sera pas non plus une surprise pour cette personne : la tâche ne sera pas instantanée…

Commençons par deux grosses heures pour monter un environnement de travail.

En effet, l’équipe est composée de développeurs et développeuses Web et, même si plusieurs ont des souvenirs de Java et des bonnes notions d’Android, c’est quelque chose qu’elle ne fait quasiment jamais. Pour ne rien arranger, cette application a été développée par une autre entreprise⁷ et l’équipe interne ne gère que sa maintenance et l’implémentation de fonctionnalités mineures une fois de temps en temps.
À chaque fois, donc, installer l’IDE, se taper parfois une montée de version obligatoire de certaines bibliothèques ou outils…

Vient ensuite l’étape où il faut entrer dans le code, comprendre comment il fonctionne, identifier l’endroit où afficher le pictogramme demandé. Puis trouver les bouts de Java et de XML qui gèrent la construction de cet écran. Entre 2 h et une demi-journée.

Après cela, dessiner un pictogramme⁸, puis l’embarquer dans les ressources de l’application marque-blanche parente pour qu’il soit intégré à ses déclinaisons.

Enfin, écrire le code qui l’affiche sur tous les contenus. Certes, ce n’est pas ce qui est demandé, mais ça donne un premier rendu visuel, pour confirmer que c’est bien ce qui est attendu.

Avec ce premier rendu, allons voir le product-owner, qui montrera aussi au directeur commercial…

Et là, le développeur va cramer pas loin d’une heure et demie à trois personnes (développeur + directeur commercial + DG⁹), à critiquer la couleur, la position, le texte du picto… Soit 4,5 heures.

Une fois à peu près d’accord sur le rendu (yeah 💪), mais en s’ajoutant du boulot parce qu’il faut désormais gérer le pictogramme dans les couleurs de chacune des déclinaisons de marques blanches, il est temps d’implémenter la condition pour n’afficher ce pictogramme que pour les nouveaux contenus offerts avec l’application. En effet, il ne doit pas être présent sur les achats du client !
Donc, créer un champ dans la base de données interne de l’application (avec une migration à jouer à la montée de version), le renseigner, l’exploiter pour conditionner l’affichage… Quelques heures de plus.

Et là, c’est certainement le moment où le développeur va poser une question innocente :

Et on fait quoi pour les gens qui avaient déjà l’application ?

Dans les versions précédentes, il n’existait pas de champ dans la base de données pour tracer les contenus offerts ou achetés… Et les interlocuteurs clients de notre commercial ont déjà toutes et tous l’application et voudront peut-être voir le pictogramme sans la désinstaller et la réinstaller ? Pareil pour les utilisateurs finaux, peut-être¹⁰…

Après un moment de réflexion, la solution la moins galère, peut-être la seule identifiée : se baser sur les SKU des contenus offerts. La liste est différente pour chaque déclinaison en marque blanche, mais ça marchera à peu près¹¹, même si c’est un peu moche.

Bien sûr, juste après, vous allez vous rappeler que la liste de contenus offerts a évolué plusieurs fois. Tant pis, ça fait déjà à peu près deux jours qu’on bosse sur cette fonctionnalité, donc on va admettre que, pour des utilisateurs de longue date, les pictos ne seront pas toujours affichés.

Mais bon, quelques heures de plus, encore.

Une fois ces développements faits, l’équipe enchaine avec une petite passe de tests. Elle va impliquer une seconde personne, qui pensera peut-être à des cas que la première n’aurait pas envisagés. Sur plusieurs appareils de tailles et de marques différentes. Sur des installations et sur des mises à jour. Encore quelques heures.

Puis la pull-request — un peu grosse. Donc du temps de relectures par d’autres collègues. Peut-être même un moment de revue en pair, pour faciliter la communication ? Deux heures ?

Et, enfin, viennent les étapes de distribution : recompiler chacune des déclinaisons en marque-blanches, avec les bons certificats. Puis les uploader sur le store Android, sans se tromper entre deux variantes bien sûr.

Oh, à ce moment-là, nouvelle question :

Tu as le changelog que tu veux qu’on écrive sur le store ?

Sans doute, l’équipe de devs aurait pu anticiper cette question, la poser plus tôt, pour éviter de perdre du temps en bloquant les déploiements à la toute fin de la chaine… Mais d’autres aussi, dont le PO ou le demandeur, auraient dû y penser avant, non ? Ce n’est pas nouveau qu’il faille un changelog, c’est exigé à chaque mise à jour 😫…

Alors, au final, est-ce que cette nouvelle minuscule fonctionnalité, ce « juste un picto à ajouter », aura pris moins de deux jours ?

Non.

Un peu plus de deux jours, si on calcule la somme des chiffres ci-dessus.

Et le développeur qui a travaillé sur cette évolution ne s’est pas tourné les pouces et n’a pas trainé des pieds.
J’en sais quelque chose : j’ai déjà été dans des situations de ce type !

La morale de cette histoire ?

Le mot « juste » est à bannir lors de la présentation d’un besoin, d’une (User) Story.

En effet, derrière « juste une petite chose », il y a plein d’autres questions, auxquelles on ne pense pas tout de suite — qu’on soit directeur commercial, product owner, ou membre de l’équipe qui va coder !

Mais, s’il vous plait : faites confiance à vos développeurs et développeuses.

Leur demander pourquoi quelque chose nécessite du temps, OK, c’est normal.
Mais croyez-les quand ils et elles vous expliquent : c’est leur métier, après tout !

Cette histoire, inspirée de faits réels et de plusieurs anecdotes, est bien sûr un peu romancée pour cet article.

P.S.: Oh, et la discussion « ça peut pas prendre deux jours » peut se conclure par une déclaration du style « je vais finir par demander à une SSII, ça ira plus vite »… Alors, déjà, le temps de trouver la SSII en question, négocier un contrat, surtout pour quelques jours de développement tous les quelques mois, j’ai un doute — et j’ai bossé en SSII… Mais, ensuite, toutes les questions qui se sont posées au fil de l’eau, il aurait fallu combien d’heures (facturées !) en plus pour y répondre, avec un intervenant externe ?

P.P.S: Par contre, quelques années après, lors d’une refonte majeure de cette application, externaliser le développement et la maintenance de sa nouvelle version pourrait être une bonne idée. En effet, les développeurs back et front web apportent sans doute plus à l’entreprise en se concentrant sur leurs centres d’expertise — et ils ont largement de quoi s’occuper avec ceux-ci — que lorsqu’ils et elles luttent sur une appli qu’ils ne connaissent pas, dans une techno qu’ils ne manipulent jamais !

Source de l’illustration de cet article : Stillness InMotion sur Unsplash