Product Owner et Dette Technique

Telle que présenté par Ward Cunningham, le pattern Dette Technique est un curseur avec lequel l’équipe peut “jouer” : face à un objectif intermédiaire important et urgent, elle peut décider de déroger temporairement à son état de l’état de l’art, quitte à réaliser par la suite un effort supplémentaire pour revenir au standard.

Exemple :

▶️

PO : La démo est vendredi, et la story qu’on avait décidé de montrer n’est pas prête, on est d’accord ?

D1 : Techniquement, la story est prête, mais la BD migrée au nouveau schéma ne sera pas disponible d’ici vendredi.

PO : Donc, prête ou pas prête ?

D2 : Si on n’avait pas besoin de la BD, la story serait déjà pratiquement démontrable.

PO : Je vois. C’est dommage. C’est une démo attendue par le Métier.

D2 : Et si on disait, le temps de la démo, que les données saisies sont enregistrées en local, dans un fichier plat ?

D1 : Tu veux dire qu’on sérialise les objets directement ? C’est crade.

PO : Ça nous permettrait de ne pas annuler la démo ?

D1 : Oui, mais c’est crade.

D2 : Et ensuite on remet en place la persistance normale. Qu’est-ce que vous en pensez ?

⏸

Dans cet exemple ce qui va se produire pour le projet vendredi dépend crucialement de la dette technique :

  • scénario A : l’équipe explique que la démo doit être annulée ou déroulée incomplètement pour des raisons technique diverses.

  • scénario B : l’équipe déroule la démo, reçoit des félicitations et des encouragements, et inscrit une tâche de désendettement dans sa todo du prochain sprint.

💡 Conséquence :

Si la dette technique est un curseur avec lequel l’équipe Technique peut moduler la rapidité avec laquelle elle produit, alors elle va immanquablement devenir un LEVIER pour le Métier (tel que représenté par le PO).

⬆️ En poussant le curseur DT vers le haut, l’entreprise peut se doter plus rapidement d’un logiciel moins pérenne, moins robuste, moins stable, etc.

⬇️ En tirant le curseur DT vers le bas, elle concède des délais (bien souvent des délais imprévus au départ) et “donne du temps au temps” afin de se doter d’un logiciel de meilleure qualité, plus conforme à ses besoins à moyen et long terme.

On voit assez bien comment l’entreprise peut passer d’un usage raisonné de ce curseur à un abus chronique :

  1. un projet démarre, sur la base d’un cadrage “optimiste” (complexité sous-estimée)
  2. l’équipe Technique prend du retard (en fait, recadre la complexité réelle du projet)
  3. elle fait, sous la pression, le choix de se sur-endetter techniquement
  4. le retard est aggravé par le paiement des intérêts (le code est plus difficile à changer)
  5. la pression augmente; l’équipe prend de nouveaux expédients, etc.

et le tour est joué !

La dette technique est un levier de productivité. Dans le monde complexe du développement logiciel, nous jouons avec ce levier et nous en tirons avantage, à nos risques et périls.

🙏 Merci @ArmelleLelarge pour ta suggestion d’hier, qui a déclenché cette réflexion.

Stay Tuned ! 📡

publié sur Linked In le 26/01/2023