[Besoin de conseils] Backlog produit, comment y inclure les demandes des développeurs?

Communauté Scrum Life
1

Bonjour à tous,

Je suis une ancienne développeuse et Scrum Master depuis peu de temps et je passe pas mal de temps à me renseigner pour aider au mieux le PO à construire son backlog produit en ce moment.
Aujourd’hui notre product backlog c’est un mélange de besoin Partie prenantes et de tâches techniques.
Plus je lis des choses ou regarde des vidéos sur le product backlog plus j’ai des questions qui me viennent. Et les échanges avec le PO ou les autres PO/Scrum de mon entreprises n’ont pas vraiment été concluant car pareil tout est un peu mélangé.
Je m’explique

Si je comprends bien on doit avoir présent dans le backlog produit :

  • Des user story qui décrivent les besoins métiers (c’est même user story qui seront traduites par des tâches techniques pendant le sprint planning et donc placées dans le backlog de sprint)
  • Les bugs

Il s’avère que dans l’équipe nous avons un projet très legacy où l’équipe a décidé de faire un gros changement et donc tout remettre dans l’ordre pour effacer la dette technique assez impressionnante du à se legacy. (c’est aussi dû au fait que les développeurs en charge de ce legacy ne sont plus dans l’équipe aujourd’hui et donc personne n’a la compétence)
Les nouvelles tâches des parties prenantes sont surtout des améliorations, ou des refontes graphiques ce qui fait que nous avons dans l’équipe largement la possibilité de travailler ce besoin en parallèle (et les PP ont vraiment conscience que nous avons besoin de rattraper cette dette technique et que l’équipe doit monter en compétence donc ils nous laisse aussi le temps pour)

Ma question est : comment peut-on inclure toutes ces tâches très techniques dans un product backlog?
Existe-t-il une autre forme de story ?
A noter qu’il y a aussi énormément de travail de recherche à faire pour comprendre correctement le legacy et donc du temps que l’équipe de développement doit prendre sur le sprint. Comment faire pour pouvoir inclure ces tâches de recherche dans le backlog ? Est-ce quelque chose qu’on ne place que dans le backlog de sprint, ou faut-il une tâche dans le product backlog ?

Je suis en train aussi d’essayer de faire comprendre au PO l’utilité des User story pour les demandes des parties prenantes, mais il trouve cela plus fastidieux qu’autre chose. C’est un ancien dev lui aussi et il a plus l’habitude de parler en fonctionnalité plutôt qu’en besoin. Des conseils pour bien l’aider à comprendre ce point ?

En vous remerciant et en vous souhaitant une bonne journée

2

Hello,
Bienvenue sur le forum !

C’est justement un point sur lequel j’avais moi aussi pas mal de problèmes.

C’est quand même pas une bonne pratique de dire qu’on va interrompre toute forme de travail sur les fonctionnalités utilisateurs parce qu’on résorbe la dette. D’un autre côté, on ne peut pas mettre la qualité technique sous le tapis indéfiniment et ne pas payer le gâteau à la fin. Mais, dans l’idéal, la résorption de la dette technique et la prise en compte des tâches techniques, même nouvelles, on voudrait bien les faire au fur et à mesure et pas tout avaler d’un coup.

Bien sûr, il y a les fameuses « Tech Stories » mais ça ne me satisfait pas vraiment.

  • Si on les priorise au même niveau que les US, ça veut dire que le PO a la main sur les TS.
    La plupart du temps il ne s’y intéresse pas, même en faisant preuve de pédagogie.
    Il y un risque élevé que le PO rejette des TS pourtant critiques du point de vue technique.

  • Si on les priorise séparément des US, le PO n’est plus maître de son backlog et de son produit

A titre personnel, j’aimerais essayer une nouvelle approche par la DOD.
Désolé, dans ma tête c’est encore expérimental, j’ai pas encore pu tester en pratique.

L’idée c’est que normalement c’est déjà la DOD qui pilote la qualité technique.
A mon sens c’est pertinent, en particulier pour les exigences des parties prenantes.
Par exemple, si la DSI impose de moderniser la version du runtime on ajoute ce critère à la DOD.
De cette manière, le runtime doit être mise à jour pour qu’un incrément soit « terminé ».
Par ailleurs, on peut tout à fait écrire dans une DOD que certains critères ne sont pas rétroactifs.
C’est la démarche proposée par SonarQube Clean as You Code par exemple.
Ensuite, quand on a un peu plus de temps on peut reprendre les vieilles fonctionnalités.

La discussion se fait alors en sprint planning, de savoir pour chaque sprint ce qu’on choisit comme objectif de sprint et comme altération de la DOD. Ensuite on établit un plan qui permet d’atteindre l’objectif, à savoir ajouter la fonctionnalité tout en améliorant la qualité technique du produit. Je pense que c’est plus facile de donner un sentiment d’effort partagé entre le métier et la technique.

Pour la correction des bugs, normalement il y a un impact utilisateur, donc un impact business.
Le PO doit donc savoir prioriser les bugfixes par rapport aux ajouts de fonctionnalités.
On peut donc plutôt les gérer de manière traditionnelle dans le sprint goal / backlog.

3

Bonjour et bienvenue

Ce sont des questions qui reviennent assez souvent

La product backlog doit amener transparence sur le futur état attendu du produit. C’est sa raison d’être.

Si on veut amener de la transparence pour les dev, le PO, les parties prenantes, tous les sujets doivent s’y trouver. Que ce soit de l’US, des améliorations techniques, voire même les bugs.

Pour le US rien n’oblige à utiliser ce concept, si l’équipe n’est pas prête à changer de format et que ça va à tout le monde autant rester sur ce que vous maîtrisez.
Pour la technique non il n’existe pas de technical story, des spec techniques peuvent très bien faire l’affaire, tout est aussi une question d’affinité avec l’expression du problème à résoudre ou des besoins.

L’important c’est que le travail à effectuer soit transparent, dans un lieu unique et que PO et dev travaillent ensemble pour établir les priorités au niveau résorption de la dette et nouvelles features.

4

Bonjour,
Déjà merci pour vos réponses et vos messages de bienvenue ;

Pour vous donner un peu plus de détails, le projet doit être remanier niveau technique de l’intérieur.
Aujourd’hui il y a beaucoup de duplicata de code entre les différents sites et le but pour l’équipe de dev est de créer une sorte de tronc puis uniquement gérée la customisation UI sur les sites.
On a donc un gros travail de remaniement architecturale du projet, mais ça ne doit rien changer pour l’utilisateur (à part améliorer les performances)
L’avantage que nous avons c’est que le PP sont complètement en accord avec ce point technique et nous donnent vraiment le temps de le faire. L’équipe n’a vraiment aucune pression actuellement justement pour avoir le temps de remanier tout ce projet.

@nicobiot Quand vous parlez de « spec techniques » comment les présenter dans un product backlog ? Sous quel forme va se composer le ticket ?
Je connais ce terme en tant que développeuse mais je ne vois vraiment pas comment il doit se traduire dans un backlog qui est censé être accessible aussi par nos PP non technique.

@ArwynFr Je suis plutôt d’accord que la qualité entre dans la DoD, c’est d’ailleurs un des gros points d’amélioration que nous avons avec l’équipe en ce moment. L’équipe veut mettre la qualité au centre aujourd’hui et nous sommes en train de retravailler la DoD en conséquence.
Et dans ce sens les nouvelles features respectent bien la nouvelle architecture mais aussi la nouvelle qualité de code que l’équipe de dev s’est fixée, mais comment introduire dans votre idée le changement de tout le legacy qui n’est pas forcément lié à des besoins des PP ? C’est un chantier qui devrait se traduire sur la totalité de l’année.

Merci beaucoup

5

Votre DOD actuelle doit se transcrire avec une forme du style : « Les nouveaux modules doivent respecter XYZ ». Ensuite vous pouvez progressivement ajouter les items « Le module hérité X doit respecter XYZ », et ainsi de suite jusqu’à « L’ensemble de l’application doit respecter XYZ ». Ceci reste un exemple, soyez cohérents avec la stratégie adoptée pour la résorption de la dette (par module technique, par fonctionnalité, etc …)

Le défaut de cette approche c’est que la DOD est un peu impérative.
Ca va bien pour des changements qu’on sait pouvoir faire pendant un sprint.
Pour une résorption de dette technique plus importante ça ne semble pas très approprié.

Le fait que vous ayez un problème sur les performances est une excellente nouvelle !

Ca peut paraître paradoxal au départ. En fait, un problème de performances c’est un bug. C’est juste que l’application viole un exigence non-fonctionnelle (qui n’a probablement pas été exprimée au départ). En effet, selon ITIL, une application doit respecter 3 exigences qualité :

  • Fonctionnelle : on obtient bien l’effet souhaité à la fin
  • Performante : l’effet souhaité est obtenu avec les ressources imparties (matériel, temps, volume)
  • Sécurisée : en respectant les critères de disponibilité, intégrité, confidentialité, traçabilité

Ce qui est compliqué dans la résorption de la dette technique c’est quand on essaye de réduire des problèmes de maintenabilité dont le seul impact est de rendre plus compliqué, plus long, plus cher de modifier ou d’ajouter de nouvelles fonctionnalités. C’est le problème classique de la dette (financière) ou du climat: on a vécu a crédit pendant 60 ans, on ne comprend pas que ça ne sera un jour plus possible. C’est là qu’il faut parfois un peu forcer le destin et investir dans l’application, ce qui peut être une grosse épreuve de foi pour le métier et la direction. C’est dans ce cadre que la DOD prend tout son sens.

Mais qui dit performances dit chronomètre, et qui dit chronomètre dit KPI. Donc normalement, ça ne devrait pas être très compliqué pour le PO de comprendre les impacts métier des problèmes de performances. Un problème de performance est assez facile à traduire en PBI ou même en US :

En tant que X, je souhaite Y en moins de (durée), afin de Z

Et dans ce contexte, la réponse de l’équipe de développement peut être : ça nécessite une grosse refonte technique. Et donc oui, parce qu’on s’y est pris d’une certaine manière jusqu’à présent, gagner quelques secondes sur tel cas d’usage peut occuper une dizaine d’experts pendant plusieurs semaines et coûter très cher.

En revanche, il ne faut pas partir du problème technique mais du problème métier. On ne fait pas une refonte technique parce qu’on en a envie, mais bien parce qu’il y a des problèmes de performances. Donc c’est au PO, avec l’aide de l’équipe, d’identifier les fonctionnalités qui sont trop lentes et de fixer des objectifs réalistes. On peut commencer par résoudre le problème de performance sur un premier site, puis pour le second voir comment on peut remplacer l’ancien code dupliqué par une référence au niveau code factorisé. De cette manière, c’est bien le métier qui pilote la technique et non l’inverse. On commence donc la refonte par une livraison de valeur.

Si besoin de détailler ce dernier point, je te renvoie au live de la chaine avec Arnaud LEMAIRE:

1 « J'aime »
6

Quand vous parlez de « spec techniques » comment les présenter dans un product backlog ? Sous quel forme va se composer le ticket ?
Je connais ce terme en tant que développeuse mais je ne vois vraiment pas comment il doit se traduire dans un backlog qui est censé être accessible aussi par nos PP non technique.

Typiquement des spécifications concernant des changements important dans le système : nouvelle interface entre applications, changement de base de donnée, mise en place de cache, de bus de données etc.

En gros les sujets que l’on voit de temps en temps sous forme de : « en tant que serveur je souhaite avoir du cache pour être plus performant »

Ces sujets doivent être dans le backlog et devront être affinés au fil du projet pour les découper et les ajouter just in time dans les sprints.

7

Je pense que c’est prendre le problème à l’envers. Le raisonnement normal c’est d’expliquer que l’opération X prend du temps => on veut améliorer les performances sous X secondes => on va introduire du cache. La spec technique vient d’une exigence métier.

Si les performances actuelles conviennent au métier, pourquoi introduire des changements structurants susceptibles d’introduire des régressions ? Car ajouter du cache, par exemple, ça peut effectivement améliorer les performances de certaines requêtes, mais ça se fait au détriment de l’intégrité de la donnée et entrainer des effets de bord. Le temps de réponse n’est pas toujours l’enjeu majoritaire de l’architecture !

Concernant le patrimoine technique (dossier technique contenant le plan d’architecture, les spécifications d’interface), savoir où le ranger est un sujet vieux comme les projets. Beaucoup de forges logicielles modernes ont un module de GED pour les gérer. Avant cela, on avait un espace de partage documentaire et on faisait le versionnement à la main (ça se fait hélas ! toujours sur certains projets).

Aujourd’hui, j’essaye de pousser mes collègues à adopter une approche docs-as-code. On versionne les documentations sous forme de fichiers asciidoc ou markdown directement dans un dossier /doc sur le repo de code source. Cela implique de permettre de faire des pull requests, un historique, etc … et ce patrimoine peut être build et déployé sous forme de site web dans le cadre du processus de livraison continu.

8

Ce sujet a été automatiquement fermé après 5 jours. Aucune réponse n’est permise dorénavant.