Je voudrais connaitre vos bonnes pratiques pour la rédaction des User Story Technique (ou Technical Story ?).
Sur mon projet, nous avons beaucoup de dette technique qu’il faut résoudre avant d’ajouter des nouvelles fonctionnalités au produit, les utilisateurs ne verront pas d’évolution sur le produit.
Je vais créer les tickets (je suis PO) sur ces sujets mais je ne sais pas quoi choisir comme syntaxe/méthode. Le « En tant qu’utilisateur » n’a pas de sens dans cette configuration.
Merci d’avance pour vos conseils,
Nadège
Normalement les US, c’est fait pour les utilisateurs, en faisant justement une abstraction sur la technique et en se concentrant sur ce que veut le client. Pour la technique, de mon point de vue, ça n’a que peu de sens de l’utiliser tel quel.
Le plus simple, ce que je ferais, je demanderai aux devs leur avis ! C’est quand même eux, la technique. Donc de voir : comment ils aimeraient avoir des syntaxes pour des items qui sont purement techniques / refacto. Et toi, tu pourras après en tant que PO aider à organiser les tâches de refacto par rapport à leur appui.
En gros fais toi aider par ton équipe !
L’autre « bonne pratique », à l’avenir, c’est que les requis non-fonctionnels, tu peux demander à l’équipe de les mettre dans la DoD et de la respecter à l’avenir. Après c’est aussi à eux d’accepter cette demande.
Chez SAFe ils appellent ça des enablers
Ce sont en général des sujets techniques qui sont des prerequis pour de futurs sujets fonctionnels
En tant que PO je me refuse à décrire ce genre de « tickets » c’est les devs qui en prenne l’engagement et ils sont les mieux placés pour décrire ce qu’ils vont faire, et ça a le mérite d’initier une première spec technique peu importe sa forme
Je me répète toujours un peu j’ai l’impression mais… où est ce qu’il est marqué que le backlog produit est composé d’US ? C’est assez frustrant de constater cet automatisme en mode « un ticket = une US ». Le problème du formalisme d’un élément ne se pose pas si la nature de l’élément n’est pas dictée par un outil ou un process (merci Jira…)
Est-ce que vous ne pouvez pas découper les développements de manière à ce que la correction de la dette technique fasse partie des tâches techniques nécessaires pour livrer des choses qui ont de la valeur ?
Autrement dit, au lieu de faire un découpage « gros morceau de dette » puis « gros morceau de fonctionnalité », tu fais un découpage vertical « petit morceau de dette + petit morceau de fonctionnalité ». Si tu veux correctement gérer la dette, les petits morceaux de fonctionnalité ne seront pas spectaculaires, mais ils permettront de montrer que ça progresse dans le bon sens, et que les nouvelles fonctionnalités sont effectivement rendues possibles par le refactoring.
Sinon, l’alternative c’est d’arriver dans 3 mois, d’avoir fait toute la « dette » pour se rendre compte qu’en fait il y a encore des trucs à régler. Et pendant ce temps, le marché a changé, les utilisateurs ont changé, et en fait il n’y a plus besoin de faire ces fonctionnalités…
Pour moi, la bonne pratique, en absolue, est qu’un développeur professionnel ne devrait jamais plannifier de résorber la dette technique.
C’est une activité en continue, en grignotant la dette.
« Améliorer en continue la structure du code. »
Les montés de versions devraient aussi rentrer dans le cadre de cette activité.
Si il existe une suite de tests dont si elle passe, on peut livrer en prod en fermant les yeux, et avec une bonne architecture. Alors les montées de versions devraient être très rapide.
Avant d’arriver à ça, pour certaines base de codes, il y a du chemin à parcourir. Et la patience est d’or.
En pratique dans ton contexte
Il se peut que cela ne fonctionne pas.
Il faudrait à minima tendre vers, cette amélioration continue.
Nous utilisons un template différent pour les évolutions techniques (c’est pour faire plus joli car cela comprend les reworks mais également les bugs donc…) que pour les évolutions fonctionnelles.
Ensuite, vu que l’équipe va passer du temps sur ces tickets, elle le fera à la place d’autres tickets, donc impactera ton sprint et donc l’engagement pour ton objectif de sprint doit en tenir compte, vous aurez moins de temps pour travailler sur les évolutions fonctionnelles.
Le modèle que nous utilisons décrit les éléments suivants :
Contexte
Comportement obtenu
Comportement attendu
Pistes solutions techniques
En principe, ces tickets ne sont pas estimés…
Mais effectivement, je confirme que l’amélioration continue doit faire partie intégrante de votre organisation et que toute évolution doit avoir une part de refacto et que tout développeur se doit d’améliorer tout fichier qu’il ouvre sur lequel il apporte une modification.
C’est peut-être le moment de mettre en place des tests unitaires et des tests auto… si ça ne corrige pas de suite la dette technique déjà présente, au moins ça a le mérite d’être un garde fou pour tous les nouveaux développements.
Ces bonnes pratiques sont à suivre pour les exigences fonctionnelles mais également pour les non fonctionnelles.
Je viens de tilter aussi mais exigences non-fonctionnelles =/= ‹ user story technique ›.
Les exigences fonctionnelles non techniques sont des critères liés à des besoins business qui se retranscrivent pas dans une fonctionnalité, ex: downtime de 0.0001% max, lourdeur des fichiers en payload maximum transverse à l’appli, temps de responsivité de l’ihm max, standard wcag minimum à atteindre…
Merci à tous pour vos partages d’expérience.
Pour ce coup-là, ce sont les dev qui ont écrit les tickets.
@BenjaminF, je garde à l’esprit l’intégration dans la DoD pour plus tard, c’est une bonne idée.
Malheureusement, je ne vois pas de moyen pour le faire à ce stade.
@lprost, je vais réfléchir à ce mode de découpage pour ajuster la trajectoire utilisateur dès que possible
Encore une fois, je ne vois pas comment je peux le faire tout de suite
@Alexandre_Quercia L’équipe de dev est assez jeune au niveau de l’agilité, je ne crois pas qu’ils optimisent leur code à chaque passage. Je leur en parlerai.
@llr je garde ton modèle en tête, il peut aider à s’assurer d’une bonne description
@Samuel_Abiassi si tu as des définitions sur user story technique et exigences non-fonctionnelles, je suis preneuse, je n’ai pas trouvé de documentation pour théoriser ces sujets.
Cela me dérange que tu utilises le concept d’optimisation, car ce n’est pas l’idée que j’ai voulu partager. Je souhaite éviter toute confusion. Il s’agit de lisibilité et de comportement souhaité du code. L’explication que je te donne est intentionnellement simplifiée. Quand tu écris un email professionnelle, dans un premier temps tu fais un brouillon avec les idées que tu souhaites partager.
Puis, tu crées des paragraphes pour rendre le texte suffisamment lisible pour tes lecteurs.
C’est permettre de pouvoir facilement lire le code.
Pourquoi le code doit être lisible ?
Un développeur passe 10 fois plus de temps à lire du code qu’à l’écrire.
L’enjeu est de réduire tant que possible ce temps de lecture. Cela passe par une bonne structure du code.
Et l’optimisation dans tous ça ?
L’optimisation c’est accélérer l’exécution d’un comportement.
Il vient après le bon comportement et la bonne structure.
PS : Je n’ai pas structuré la première partie de ce message. Vois par toi-même, tu remarques que c’est plus facile à lire la seconde partie.
