loading

Le Blog

28
Nov

Ne laissez pas pourrir votre backlog

Le backlog est un anglicisme très employé par les agilistes et qui désigne la liste des exigences d’un projet ou d’un produit informatique. J’ai pu observer trop souvent que le backlog au cours de la vie d’un produit, fini par devenir une boîte à idées pour ne pas oublier et pour prévoir la prochaine itération de développement du produit. À noter que je parle là de produit au sens large, pas nécessairement un logiciel informatique.

Le pattern que j’observe est le suivant :

  • au début du cycle de vie du produit, ou au lancement du projet, on collecte ce que doit être le produit, la liste des exigences. Cette liste constitue le backlog initial.
  • si on pratique le développement produit en flux, on sait qu’il est préférable de commencer à spécifier et à coder les exigences au fur et à mesure, à partir du moment où on a identifié un minimum viable pour le produit et en commençant par les exigences à plus fort coût du retard et à plus court délai (priorisation suivant la méthode WSJF ou CD3). Si on ne pratique pas le flux, on a parfois tendance à collectionner l’exhaustivité des exigences, ce qui ne fait qu’empirer la situation.
  • au bout d’un an de vie, il n’est pas rare de trouver dans le backlog des exigences identifiées un an auparavant.
  • au bout de deux ans de vie, le backlog contient toujours des exigences identifiées 2 ans auparavant et l’utilisateur interne commence à voir le backlog comme une boîte à idées, un pense bête dans lequel il peut stocker ses idées géniales, mais qui ne sont jamais prioritaires.
  • au bout de 5 ans de vie, le backlog a continué de grossir indéfiniment, il contient des tas d’idées géniales jamais développées et il devient de plus en plus difficile de faire le tri parmi 200 exigences et +

Ça vous rappelle quelque chose ?

Invariablement les clients de ces produits, pourtant très satisfaits d’avoir une liste d’exigences exhaustive, ne sont pas satisfait des délais de livraison. L’équipe de développement (au sens large : Archi, MOA, MOE, etc.) constate des moments avec des pics de charge et d’autres où tout se passe bien, sans comprendre d’où ça vient. Elle a des relations difficiles avec son client : elle n’arrive pas à le faire prioriser et n’arrive pas à y voir clair dans la capacité de l’équipe.

Maintenant que je comprends mieux le travail de Don Reinertsen, il m’est évident que le pattern de gestion, ou plutôt de non gestion, de son backlog est directement relié aux effets négatifs sur les délais, la priorisation, les relations clients, et la charge de travail. Ce n’est pas le but de cet article que de clarifier ce lien, mais si vous souhaitez en savoir plus, lisez son livre, regardez ses conférences, à Lean Kanban France et sur internet, ou venez à sa formation que j’organise chaque année en automne.

Le but de cet article est de partager avec vous, des questions et pistes de réflexions pour améliorer la gestion de backlog, avec un impact économique et social positif (charge de travail soutenable et lissée dans le temps).

L’information périme, le stock d’exigence pourri avec le temps

Toute exigence déposée dans le backlog commence à périmer dès sa création. Plus on attend, moins elle est valable.

Il est donc important d’avoir une pratique équivalente à « jeter les stocks périmés ». C’est-à-dire à jeter les exigences datant de plus d’un an, 6 mois, voire 3 mois. Quelle est la bonne date de péremption ? Cela dépend du contexte, pour construire un avion, les exigences peuvent être valables plusieurs années, pour construire un algorithme de trading, la date de péremption peut être inférieure à la journée. Mais si vous ne jetez pas, vous risquez de développer des exigences avariées !

La priorisation doit prendre en compte le coût du retard

Une analyse de « coût du retard » est rarement faite en développement produit. Le coût du retard est la réponse à la question : « combien je vais perdre d’argent si je développe cette exigence avec x mois de retard ? ».

Sans analyse du coût du retard, c’est-à-dire de la sensibilité des bénéfices et des coûts par rapport au temps, la priorisation au pire est « à la criée », au mieux sur base d’un ROI qui présente l’illusion du statique.

Le backlog doit être limité en taille

Dans le monde du développement produit, les stocks sont de l’information, par nature immatérielle. Le coût de stockage de 200 exigences ou plus est assez faible, quasi nul (le coût des disques durs n’a fait que diminuer dans le temps), pour autant plus le temps passe, et plus la charge pour le nettoyer, pour jeter les exigences avariées, pour identifier le contenu de la prochaine itération, augmente.

Est-il réellement pertinent de revoir les 100 ou 200 exigences du backlog chaque mois ou semaine ? Faut-il le limiter en taille, en nombre d’exigences, ou grâce à la date de péremption, à chacun de décider en fonction de son contexte. Dans mon équipe entre 2010 et 2012, nous avions décidé de systématiquement jeter toutes demandes vieilles de plus de 3 mois.

La purge a un effet rapide sur le délai moyen de développement

La loi de little qui relie le délai total (c’est-à-dire le temps qui s’écoule du point de vue du client entre le moment où il fait sa demande, et le moment où la demande est effectivement en production) et la quantité du stock en cours (nombre total de demandes dans le processus), nous dit que plus le stock est faible, plus le délai va réduire.

Une gestion du backlog en flux impact la relation avec le client

Le client doit être intégré aux travaux d’amélioration, aux réflexions sur date de péremption et purge du backlog, aux calculs du coût du retard, etc. Le backlog est l’interface entre le client et le développement produit, l’amélioration de sa gestion doit être un travail conjoint et non une action d’amélioration en silo sans impact client.

 

Commentaires ( 0 )

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *