Ticket un jour, bullshit toujours
Quelle part de votre capacité de développement part dans l’entretien de l’existant ? Un tiers ? Un quart ? Vous n’en savez rien, pour une raison simple : dans votre outil, tout s’appelle « ticket ».
Ne me parlez plus de « ticket ». Qu’est-ce qu’un ticket ? Une User Story ? Une tâche technique ? Une liste de courses ? Un contrat ? Un post-it collé sur le frigo ? Une lettre d’amour ? Un ticket avec quelqu’un ? Un ticket à l’élection présidentielle américaine ?
« Ticket », le mot parfait pour ne rien dire
Le mot désigne le support de l’information dans un outil de ticketing, c’est-à-dire « un outil logiciel utilisé par les entreprises pour suivre, gérer et organiser les demandes de service et les problèmes des clients, des employés ou des équipes internes » (définition : Zendesk). Vous pourriez donc remplacer « ticket » par « feuille » sans perdre de sens, vu que le mot ne dit rien du contenu.
L’usage de ce mot reflète par ailleurs une vision centrée sur l’exécutant et non sur l’utilisateur. C’est donc un sujet de gestion de la charge de travail. Ainsi, en caricaturant à peine, je vous imagine assis à votre petit bureau gris. Vous arrivez à 9h le matin, une pile de tickets vous attend, à votre gauche. À mesure que vous les traitez, d’autres arrivent et s’amoncellent. Quand l’horloge accrochée au mur d’en face daigne enfin indiquer 18h00, vous vous levez, fermez votre mallette et partez. Une belle journée, mais où est donc l’utilisateur, dans tout ça ?
Cette mise en situation n’est pas anodine. Le mot « ticket » implique un raisonnement en flux, dans lequel les critères de succès sont la file vide, le temps de traitement, le nombre de tickets clos, etc. A contrario, la vision produit s’intéresse à l’utilisateur et à l’actif utilisé pour le servir (output et outcome). La différence est fondamentale.
Vous direz que je pinaille, mais moi je ne crois pas : les mots ont leur importance. Un mauvais choix de mots nous enferme et entretient l’impensé. Des mots flous conduisent à une pensée floue qui a peu de chances de se traduire par des réalisations concrètes et utiles. Le flou ne va pas se dissiper par miracle (qu’est-ce qu’un « Chef de projet agile », par exemple ?).
Le problème n’est pas l’existence du terme générique en soi, c’est son usage indifférencié à la place de termes plus précis, au moment où la distinction importe. La plupart des outils, d’ailleurs, opèrent des distinctions. C’est à l’oral que tout se perd.
Reprenons à zéro. Lorsque vous vous apprêtez à développer, vous pouvez :
- Travailler dans l’intérêt immédiat de l’utilisateur : développement d’une User Story, résolution d’un bug
- Travailler dans l’intérêt futur de l’utilisateur : PoC ou A/B testing (production de savoir), mais aussi tâches techniques. Nous détaillerons ce point ultérieurement.
En disant cela, nous supposons que les intérêts de l’entreprise et ceux de l’utilisateur sont toujours alignés : pas de dark patterns ni de fonctionnalité court-termiste, qui attire mais ne retient pas l’utilisateur.
Une User Story apporte de la valeur à l’utilisateur
Une User Story, selon Kent Beck, est une unité de fonctionnalité apportant de la valeur à l’utilisateur, suffisamment petite pour être développée en une courte itération. Dans les faits, on essaie de la rendre aussi petite que possible (atomique) afin de minimiser l’effet tunnel.
Dans cette acception, une User Story est donc un développement qui : 1. Une fois mis en production, apporte de la valeur à l’utilisateur ; 2. Ne peut plus être découpé fonctionnellement (atomicité).
Libre à vous de créer des chapeaux (epics, fonctionnalités) pour regrouper différentes User Stories. Permettez-moi de ne pas détailler cela aujourd’hui, car la seule chose fonctionnelle que vous pouvez envoyer en production, c’est une User Story. Il faut donc bien commencer par cela.
Exemples :
- Permettre la comparaison champ à champ de 2 produits
- Permettre le tri des produits par ordre de prix croissant
- Améliorer le temps de chargement de la landing page
Améliorer le temps de chargement de la landing page est certes un cas limite (c’est une exigence non fonctionnelle), mais qui améliore l’expérience utilisateur et, par ricochet, diminue le taux de rebond et va dans l’intérêt de l’entreprise. C’est donc bien une User Story.
Par contre, « upgrader le schéma de base de données » (merci pour le franglais) ne sera jamais, sous aucune circonstance, une User Story. C’est une tâche technique nécessaire au développement d’une User Story, qui devra être mise en production en même temps que les autres tâches qui la composent.
D’expérience, si une User Story se décompose en beaucoup de tâches techniques, c’est probablement qu’elle pourrait être redécoupée fonctionnellement. Au-delà de 2 ou 3 tâches, posez-vous vraiment des questions.
La tâche technique, invisible et indispensable
Une tâche technique est un développement qui, s’il doit être mis en production seul, n’apporte pas de valeur à l’utilisateur. L’utilisateur ne connaît pas vos tâches techniques et n’en a que faire !
Il s’agit en premier lieu des tâches qui composent une User Story, nous l’avons vu. Ces dernières n’ont peut-être pas besoin d’être systématiquement formalisées, vu qu’elles n’ont pas d’existence propre, en dehors d’une User Story. C’est d’autant plus vrai qu’une User Story est petite.
Mais, hors User Story, vous trouverez également :
- Le refactoring, qui maintient la capacité du code à évoluer, et donc la capacité à livrer rapidement sur le long terme
- Les tâches améliorant la Developer Experience (DX), au premier rang desquelles la pipeline de CI/CD
- Les tâches ayant trait à la sécurité, pour éviter une fuite de données massive et un joli bad buzz
- Et même réduire la facture cloud : à la fin, c’est autant d’argent que vous pourrez investir dans de nouvelles fonctionnalités.
Cela pour dire que les tâches techniques préservent ou augmentent toutes la capacité future à produire de la valeur, perçue par l’utilisateur.
Conclusion
Votre backlog (backlog produit ou backlog de sprint si vous en faites) contient en majorité 2 types de travaux :
- Des User Stories, qui apportent de la valeur à court terme aux utilisateurs ;
- Des tâches techniques non rattachables à une User Story, qui ajoutent de la valeur à long terme aux utilisateurs.
Travailler les priorités du backlog revient donc à effectuer un arbitrage entre différents horizons de temps : livrer de la valeur maintenant aux utilisateurs, ou bien livrer de la valeur maintenant à l’entreprise afin qu’elle puisse en livrer ultérieurement aux utilisateurs.
Matérialiser les deux typologies indifféremment au travers de « tickets » rend cet arbitrage invisible. Pour qui pilote un actif informatique (CEO, CTO), cette réflexion est pourtant indispensable !