Je fais partie d'une équipe de projet de 4 développeurs, moi y compris. Nous avons eu une longue discussion sur la façon de gérer le travail supplémentaire qui survient au cours d'un seul élément de travail.
Ce travail supplémentaire est généralement des choses qui sont légèrement liées à la tâche, mais pas toujours nécessaires pour atteindre l'objectif de l'élément (qui peut être une opinion). Les exemples incluent mais ne sont pas limités à:
- refactoring du code modifié par le work item
- refactoring de code voisin du code modifié par l'article
- ré-architecturer la zone de code plus large autour du ticket. Par exemple, si un élément vous fait changer une seule fonction, vous réalisez que la classe entière pourrait maintenant être refaite pour mieux s'adapter à ce changement.
- améliorer l'interface utilisateur sur un formulaire que vous venez de modifier
Lorsque ce travail supplémentaire est petit, cela ne nous dérange pas. Le problème est lorsque ce travail supplémentaire entraîne une extension substantielle de l'élément au-delà de l'estimation du point de caractéristique d'origine. Parfois, un élément de 5 points prend en fait 13 points de temps. Dans un cas, nous avions un élément de 13 points qui, rétrospectivement, aurait pu être de 80 points ou plus.
Il y a deux options dans notre discussion pour savoir comment gérer cela.
Nous pouvons accepter le travail supplémentaire dans le même élément de travail et l'écrire comme une erreur d'estimation. Les arguments pour cela ont inclus:
- Nous prévoyons un "rembourrage" à la fin du sprint pour tenir compte de ce genre de chose.
- Laissez toujours le code en meilleure forme que vous ne l'avez trouvé. N'enregistrez pas de travail à demi-cul.
- Si nous laissons le refactoring pour plus tard, il est difficile de planifier et peut ne jamais se faire.
- Vous êtes dans le meilleur "contexte" mental pour gérer ce travail maintenant, puisque vous êtes déjà profondément ancré dans le code. Mieux vaut le supprimer maintenant et être plus efficace que de perdre ce contexte lorsque vous reviendrez plus tard.
Nous dessinons une ligne pour l'élément de travail en cours et disons que le travail supplémentaire va dans un ticket séparé. Les arguments incluent:
- Avoir un ticket séparé permet une nouvelle estimation, donc nous ne nous mentons pas sur le nombre de points, ni ne devons admettre que toutes nos estimations sont terribles.
- Le "rembourrage" de sprint est destiné aux défis techniques inattendus qui sont des obstacles directs à l'accomplissement des exigences de ticket. Il n'est pas destiné aux articles secondaires qui sont juste "beaux à avoir".
- Si vous souhaitez planifier une refactorisation, placez-la simplement en haut de l'arriéré.
- Il n'y a aucun moyen pour nous de bien tenir compte de ces éléments dans une estimation, car cela semble quelque peu arbitraire quand il se présente. Un réviseur de code pourrait dire "ces contrôles d'interface utilisateur (que vous n'avez pas réellement modifiés dans cet élément de travail) sont un peu déroutants, pouvez-vous résoudre ce problème aussi?" ce qui est comme une heure, mais ils pourraient dire "Eh bien, si ce contrôle hérite maintenant de la même classe de base que les autres, pourquoi ne pas déplacer tout ce code (des centaines de lignes de) dans la base et recâbler tout ce genre de choses , les changements en cascade, etc.? " Et cela prend une semaine.
- Il "contamine la scène du crime" en ajoutant un travail sans rapport avec le ticket, ce qui rend nos estimations de points de fonctionnalité originales sans signification.
- Dans certains cas, le travail supplémentaire reporte un enregistrement, provoquant un blocage entre les développeurs.
Certains d'entre nous disent maintenant que nous devrions décider d'une coupure, comme si les choses supplémentaires sont inférieures à 2 FP, elles vont dans le même ticket, si c'est plus, faites-en un nouveau ticket.
Étant donné que nous n'utilisons que Agile depuis quelques mois, quelle est l'opinion de tous les vétérans agiles les plus expérimentés ici sur la façon de gérer cela?