Gestion du travail «connexe» dans un seul élément de travail agile

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.

1. 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.

2. 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?

La planification agile et les récits d'utilisateurs sont axés sur la fourniture de valeur et de transparence aux parties prenantes du projet et aux utilisateurs du logiciel. C'est une bonne chose, mais elle ne doit pas et ne doit pas remplacer, inclure ou rétrograder l'importance de bonnes directives architecturales, la bonne gestion de la conception, les bonnes pratiques de développement et le maintien de la dette technique.

Agile ne fait pas bien ce dernier parce qu'il n'a pas été conçu comme une réponse à ces problèmes et problèmes principalement techniques.

Sachant que je suis fortement en désaccord sur le fait que les tâches de refactoring, le traitement technique de la dette et le travail de conception devraient représenter des user stories distinctes dans un sprint donné. Ce ne sont que des tâches qu'un développeur peut entreprendre pour aider à répondre à la user story de ce sprint.

N'oubliez pas qu'une tâche est une unité de travail assignable qui aide à faire avancer une histoire utilisateur donnée dans les lignes directrices architecturales et à maintenir les bonnes pratiques de conception et de développement du logiciel dans son ensemble.

C'est pourquoi l'estimation des heures devrait être sur des tâches et non sur des user stories. C'est aussi pourquoi certaines tâches sont essentielles à la réalisation de plusieurs user stories.

Rouge, vert, refactor. C'est la portée d'un seul élément de travail. Écrivez une suite de tests défaillants couvrant la portée du changement, codez le montant minimum requis pour réussir votre test, puis refactorisez pour répondre aux normes de codage tout en réussissant les tests. Ces trois étapes sont nécessaires; vous ne pouvez pas coder la solution jusqu'à ce que vous ayez défini le problème, si vous refactorisez en écrivant la ligne de code, vous violerez invariablement YAGNI, mais si vous n'intervenez pas derrière vous et ne refactorisez pas après avoir passé les tests, par définition vous contractez une dette technique que vous devrez éventuellement rembourser.

Étant donné cette définition et qu'elle a été suivie, un pointeur à 5 points qui se révèle être un pointeur à 13 points était une erreur d'estimation. Ce que vous considéreriez comme un travail de refactoring ressemblait probablement davantage à une restructuration; vous avez dû réorganiser une zone assez importante de la base de code pour que la nouvelle fonctionnalité soit incluse de manière compréhensible et maintenable. Cela indique généralement un échec de l'équipe à comprendre la voie générale future du développement, conduisant à ce que quelque chose soit implémenté très simplement dans une itération précédente alors qu'il serait éventuellement nécessaire d'être très SOLIDE. Une meilleure communication entre les BA et le PM, qui savent ce qui se trouve plus loin dans l'arriéré, et l'équipe de développement qui se concentre généralement sur le sprint actuel, peut atténuer cela. Alternativement, cette histoire a révélé une grande quantité de dette technique contractée dans le développement passé, et il a simplement rattrapé l'équipe. De meilleurs processus d'examen du code, en plus d'une meilleure connaissance conceptuelle des modèles de conception et de la trajectoire future générale du projet, peuvent aider à réduire de telles occurrences.

Une chose à garder à l'esprit est que le refactoring est un travail "non idéal". Dans Agile SCRUM, les tâches sont estimées en "heures idéales"; c'est-à-dire le nombre d'heures passées tête baissée à écrire du code flambant neuf qui n'a jamais existé et renforce la base de fonctionnalités du projet. Une journée de développement de 8 heures pourrait en réalité n'avoir que 5 heures idéales; parfois on peut compter sur 6, surtout dans le "bout droit" d'un projet où l'équipe fredonne vraiment. Refactoriser, ou revenir en arrière et apporter des modifications qui n'affectent pas la fonctionnalité du projet mais qui améliorent la base de code par d'autres moyens, n'est pas un travail idéal, tout comme la planification, la conception, la communication, la révision, les pauses ou les temps d'arrêt techniques. Outre les temps d'arrêt techniques, le travail non idéal est important, mais ne progresse pas aux yeux du propriétaire du produit.

Donc, à condition que le refactoring ne double pas les heures réellement passées, une certaine quantité de travail de refactoring est à prévoir lorsque vous estimez en heures idéales. Disons, parce que je ne sais pas exactement comment l'échelle de points de votre équipe est calibrée, qu'un pointeur à 5 points équivaut à une semaine de développeur idéale, soit environ 25 heures idéales. Ce 5, qui s'est transformé en 13 (plus de deux semaines de développement à la même échelle), est une cause de rétrospection sur ce qui a causé la complexité du ballon. Peut-être que la base de code n'avait pas besoin d'autant de refactoring que ce qui avait été fait, peut-être qu'une grande quantité de dette technique s'était accumulée à l'insu de l'équipe qui devait être résolue pour que les nouvelles fonctionnalités fonctionnent,

Dans un univers alternatif, imaginons qu'un 5 estimé en heures idéales est devenu un 7 (~ 35 heures) basé sur les heures réelles, car vous avez besoin de 10 heures de refactoring supplémentaire pour mettre le nouveau code et quelques bits précédents dans un modèle correctement structuré. architecture de conception. Dans ce cas, le supplément se situe dans l '«écart» entre les heures idéales et totales pendant le nombre de jours-développeur que l'histoire était censée prendre. Donc, en tant que chef de projet, j'appellerais un 5 qui est devenu un 7 une estimation raisonnable et continuer.

Les points d'histoire sont une estimation de la complexité relative d'une histoire d'utilisateur donnée. Il semble que vous utilisiez des points d'histoire pour dire que cela prendra X jours / heures. Au lieu de cela, visez deux objectifs

1. Décomposez les histoires jusqu'à ce qu'elles soient dans une plage cohérente (3, 5 ou 8 points)
2. Supposons que l'histoire inclut toute refactorisation nécessaire

Au fil du temps, cela vous donnera une référence pour la vitesse. Chaque histoire de 5 points ne prendra pas le même temps que les autres, mais la vitesse moyenne par sprint (combien de points d'histoire l'équipe peut compléter) sera cohérente.

S'inquiéter du temps que prendra une histoire spécifique est contre-productif. Les estimations ne font que la moyenne sur des histoires de taille cohérente en volume (IE un pointeur 5 peut prendre un peu plus de temps en raison de la refactorisation, mais vous tirez le bénéfice de cet effort sur un autre).

Il devrait y avoir une coupure relative entre la quantité contenue dans l'élément de travail d'origine et la quantité autre chose. Les histoires d'utilisateurs sont des points de départ pour les discussions et il peut donc y avoir toutes sortes d'éléments de portée à clouer pendant un sprint tout en travaillant sur une histoire.

Il peut y avoir des moments où dans une planification de sprint une histoire peut être ajoutée à des critères supplémentaires afin d'éviter un "fluage de portée" qui peut se produire lorsqu'un utilisateur souhaite un nouveau formulaire, puis 101 modifications de ce formulaire, ce qui n'est pas réaliste. se faire dans un sprint de 2 semaines parfois.

Un revers à garder à l'esprit est la valeur ajoutée de ce travail supplémentaire. Il peut y avoir des tonnes de refactorisations possibles qui pourraient être faites, mais quel avantage y a-t-il pour quiconque pour tout ce travail? C'est là qu'il doit y avoir des lignes directrices pour aider à bien travailler l'équipe mais ne pas se perdre en essayant de rendre le code parfait.