« 2 jours ? C’est juste un petit truc ! Ça ne peut pas prendre si longtemps ! »
9 août 2022 —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 techniques1 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 prendre2.
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 besoin3 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 minutes4, 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é5, 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ée6. 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 entreprise7 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 pictogramme8, 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 + DG9), à 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-être10…
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ès11, 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
-
Découper une story en tâches techniques, en équipe, peut être un moyen de se mettre d’accord sur ce qui est à faire, d’avoir une vue commune de haut niveau sur l’implémentation, d’identifier des pièges ou des solutions déjà exploitées ailleurs… Dans certaines équipes, c’est utilisé un peu comme du pair-architecturing en début de story. Ça ferait un sujet pour un autre article. ↩︎
-
Certains disent que l’équipe de dev s’engage sur des stories. En les prenant dans un sprint, l’équipe s’engage à les finir dans les deux ou trois semaines : à développer, tester, montrer au product-owner qui représente les clients / utilisateurs, déployer en production et confirmer que tout fonctionne comme attendu. Idéalement, d’une manière qui apporte de la valeur aux utilisateurs et à l’entreprise. En pratique, je n’ai jamais vu une équipe subir ou s’infliger de réelles conséquences si elle ne finissait pas, dans les deux ou trois semaines de sprint, les stories auxquelles elle s’était engagée. Tu parles d’un engagement. Ce terme est un mensonge. Mais c’est aussi un sujet pour un autre article ! ↩︎
-
Prévoir du temps pour bien cadrer le besoin montre souvent une certaine maturité de l’équipe de développement : à la fois, elle participe à la définition du besoin… Ou elle sait identifier une story écrite un peu à l’arrache par quelqu’un qui n’y a pas suffisamment réfléchi et/ou qui n’a pas eu le courage d’y passer du temps, peut-être en pair. Des fois, c’est facile : il n’y a que le titre 🤦♂️. ↩︎
-
10 minutes à 6-8 personnes dans une salle, c’est plus d’une heure de temps total ! ↩︎
-
Ça serait le moment de parler plus longuement de « dette technique », qui est en réalité souvent une dette « fonctionnelle » ou « commerciale » ou managériale… Et si c’est voulu et assumé, c’est acceptable, selon moi. Mais, dans ce cas, il faut également prévoir un moment pour rembourser une partie de cette dette, sinon tout développement prendra de plus en plus de temps et introduira de plus en plus de risque… Là aussi, ce serait un sujet pour un autre article. ↩︎
-
Beaucoup de développeurs et développeuses aiment leur métier, en tirent une certaine fierté, et n’aiment pas faire du mauvais travail, en fait… ↩︎
-
Le choix de développer cette application en externe était sans doute raisonnable : l’équipe technique interne était toute petite, elle avait plein d’autres choses à faire et n’avait pas d’expertise sur du développement mobile. ↩︎
-
Si la personne qui implémente cette fonctionnalité n’a aucun talent graphique et ne connait aucun outil plus avancé que Paint, dessiner un pictogramme qui soit facile à comprendre, accessible, déclinable en plusieurs couleurs et pas moche… Ça peut prendre un petit moment ! Depuis des années, je plaisante régulièrement en disant que mes collègues m’interdisent de faire quoi que ce soit de visible dans nos applications… Et bien, j’imagine à peu près comment ça se passerait si je devais dessiner ce pictogramme et je crois bien que, après, mes collègues m’interdiraient encore plus de faire quoi que ce soit de « visible » dans nos applications 🤣. ↩︎
-
Aller jusqu’au DG dans cette conversation ? Et bien, rappelez-vous le contexte : une petite entreprise, un seul open-space pour tout le monde sans doute. Donc, ça se peut. ↩︎
-
Et bien trop souvent dans des cas comme celui-ci, le commercial pense plus à ses clients qu’aux utilisateurs de l’application, clients de ses clients. D’ailleurs, j’ai beaucoup plus parlé de « story » que de « user story », dans cet article… ↩︎
-
Par exemple, si quelqu’un a acheté un des contenus qui est aussi offert, son achat portera le pictogramme indiquant que c’est un cadeau. Soyons francs, le cas doit être rare — même si vous ne prendrez pas le temps de plonger dans votre historique de ventes pour le confirmer. ↩︎
