J'ai ajouté quelques histoires d'utilisateurs qui traitent de certaines dettes techniques à mon tableau Pivotal Tracker. Dois-je les considérer comme des fonctionnalités (garder mon niveau de vélocité) ou comme des tâches / bugs (abaisser ma vélocité)? Je comprends que cela ne fera aucune différence à long terme si je fais l'un ou l'autre de manière cohérente, mais chaque fois que j'ajoute une histoire de dette technique, je dois prendre la décision.

Quelques idées:

• Ce ne sont pas vraiment des bugs, ils ne cassent rien
• Les utilisateurs n'ont rien demandé car c'est une implémentation de bas niveau qui ne les affecte pas, mais cela facilitera le développement à long terme
• Si vous définissez les fonctionnalités comme des histoires qui ajoutent de la valeur aux utilisateurs, eh bien a) ce n'est pas le cas, car les utilisateurs ne verront aucun avantage direct, mais b) ils le font parce qu'ils rendent possible le développement / la maintenance future, ce qui ajoute de la valeur, juste pas maintenant

Je ne décide pas si je dois réellement faire le travail ou quand le planifier, je veux juste savoir ce que je devrais appeler la dette technique dans mon outil de gestion de projet, et pourquoi.

C'est une caractéristique.

As a [Developer], 
I want to [refactor the whizbang library] 
in order to [simplify maintenance and speed execution]

Il est défini et planifié et suivi comme toutes les autres fonctionnalités.

Si l'implémentation de cette fonctionnalité n'est pas suffisamment valable (pour le client ou pour vous) pour qu'elle soit planifiée, c'est un problème différent.

(Le remboursement) de la dette technique n'est pas une caractéristique , car le client n'est pas qualifié pour prendre des décisions à ce sujet . Plus important encore, le client ne peut pas décider quand il a terminé, et en outre, le client dépend totalement de vous pour expliquer les avantages. À votre avis, il existe une dette technique, et c'est à vous de décider comment la réparer et quand vous avez terminé. La dette technique affecte votre vitesse (future), pas la perception du logiciel par les clients. S'il n'y avait pas de dette, vous seriez plus productif. Et la vitesse que vous avez mesurée jusqu'à présent est fausse, car vous auriez dû prendre plus de temps pour garder le code en forme.

Je pense que vous devriez communiquer cela avec votre client, mais ce n'est pas quelque chose qu'ils contrôlent. Vous pourriez dire quelque chose comme ceci: «Jusqu'à présent, nous avons pris quelques raccourcis que nous devrons corriger. Cela signifie que notre vitesse baissera un peu au cours des prochaines itérations, mais c'est pour s'assurer que nous avons un logiciel maintenable à long terme.

La poursuite du travail sur la fonctionnalité du client vous aidera également à vous concentrer sur l'amélioration du logiciel pour le client, au lieu de devenir une sorte d'exercice académique pour trouver la conception parfaite (c'est quelque chose avec lequel je me bats parfois).

À mon humble avis, la tâche d'éliminer la dette technique n'est certainement pas une caractéristique. Il pourrait être transféré dans le département "bug", mais il élargirait la définition des termes, car là encore, il n'entraîne pas de changements de comportement observables par les utilisateurs.

Je dirais simplement que c'est une tâche de maintenance. Dans tout projet de développement, il existe de nombreuses tâches telles que la mise en place d'un environnement de développement / test, l'assemblage des données de test, la fusion de branches dans SCM, etc. coûts et taux de bogues à long terme.

Cependant, il peut ne pas être nécessaire de les gérer comme des tâches distinctes (à moins qu'elles ne soient énormes et / ou que vous n'ayez aucune pression pour implémenter de nouvelles fonctionnalités en ce moment). Habituellement, il peut être préférable de simplement identifier quand une nouvelle fonctionnalité nécessite une refactorisation / écriture de tests unitaires, etc. et de les gérer dans le cadre du développement de la nouvelle fonctionnalité. Cela peut être plus facile à expliquer à la fois à la direction et aux utilisateurs finaux (s'ils veulent savoir sur quoi vous passez votre temps). Mise à jour: De plus, cela aide les développeurs à se concentrer également sur la valeur du refactoring. Il est facile de se laisser entraîner dans le refactoring pour le bien du refactoring, donc se concentrer sur la valeur ajoutée apportée par un refactoring spécifique du point de vue du client est à mon humble avis.

Je l'appellerais un improvement.

Pas un bug car rien n'est cassé.

Ni une fonctionnalité car le refactoring ne sera pas une demande de votre client. (parce que ça marche!).

La plupart des systèmes de suivi prennent en charge un type de problème improvementpar défaut, sinon vous pouvez probablement modifier les types de toute façon.