Le code de refactorisation aléatoire est-il autorisé dans Scrum

Contexte

• Mon équipe utilise Scrum
• Je n'ai actuellement aucune tâche assignée
• Il n'y a plus de tâche en attente dans le backlog
• Aujourd'hui, c'est la fête du Travail pour mon client.

N'ayant pas beaucoup de choses à faire aujourd'hui, je voulais commencer à refactoriser du code que je continue de voir dans le projet sur lequel je travaille, mais actuellement je ne suis assigné à aucune tâche de sprint pour effectuer une refactorisation à grande échelle.

Est-ce correct dans Scrum si je commence à refactoriser au hasard le code que j'ai et que je n'ai pas écrit qui me dérange toujours mais que je n'ai pas le temps d'autres jours pour le réparer à cause des affectations d'autres jours?

Et les autres jours où j'ai du temps libre entre les sprints.

En fait, je le fais et je crois au refactoring continu. Je le fais toujours sur les morceaux de code que je travaille quand on m'assigne une histoire, mais qu'en est-il d'un autre code que je vois qui n'est pas actuellement lié à ce sur quoi je travaille à ce moment?

Je ne veux vraiment pas attaquer d'autres réponses, mais personne d'autre n'écrit des tests automatisés ici? Voici une lecture amusante de Martin Fowler pour quiconque pratique Scrum sans bonnes pratiques en génie logiciel. Robert C. Martin dit aussi beaucoup sur ce ici .

Donc, à ma réponse ... Bref, ça se passe comme ceci:

Oui, le code de refactorisation "aléatoire" est autorisé dans Scrum , tant que l'équipe décide que cela doit être fait. (Après tout, c'est auto-organisé)

Et maintenant pour la longue réponse:

Il est évident que laisser de plus en plus de dettes techniques après chaque Sprint est une recette pour un désastre. Bientôt, tout le monde ralentira à mesure que le code deviendra plus compliqué; chaque changement sera plus difficile à effectuer car le code est tellement emmêlé et désordonné qu'il faut plus de temps pour trouver les points à changer que pour effectuer le changement réel. Cela devient encore pire si vous devez faire un changement dans un module gros et désordonné dont vous ne savez rien, il devient impossible de gagner / conserver la productivité lors de l'ajout / du changement de personnes dans le projet, etc.

Si une équipe veut maintenir sa vitesse constante, elle doit être capable de garder la base de code propre afin d'incrémenter continuellement le logiciel. Le refactoring est une pratique obligatoire si vous voulez garder votre vitesse tout au long du cycle de vie du projet, et si vous voulez atténuer le risque d'ajouter / de changer de personnes sur le projet, et si vous voulez être en mesure d'apporter des modifications dans les modules, vous ne savez rien à propos, et ainsi de suite.

Cependant, le refactoring est une activité très dangereuse. Je le répète - c'est une activité très dangereuse . Autrement dit, à moins que vous n'ayez suffisamment de couverture de test pour pouvoir modifier librement et en toute sécurité la base de code. Si vous pouvez simplement appuyer sur un bouton pour vérifier si rien ne s'est cassé, le refactoring devient une activité très sûre; si sûr, en fait, qu'il fait partie du cycle de TDD , qui est la pratique qui vous permet de créer une telle suite de tests en premier lieu.

Mais, comme les équipes de Scrum sont auto-organisées, votre équipe doit finalement décider de la bonne chose à faire. J'espère vous avoir donné quelques arguments au cas où vous devriez convaincre qui que ce soit. (Accordez une attention particulière aux liens du premier paragraphe et à tous les autres articles vers lesquels ils pointent)

Scrum ne dit rien sur la refactorisation.

Ce que Scrum dit, c'est que si vous n'avez aucune tâche dans le sprint à travailler, vous devez aider le reste de votre équipe à atteindre l'objectif du sprint. Même si cela signifie aller leur chercher du café.
Si votre équipe convient que la refactorisation du code est la meilleure façon de les prendre en charge (et cela inclut la mise en place de l'infrastructure pour garantir que la refactorisation n'introduit pas trop de nouveaux bogues), alors allez-y par tous les moyens.

Je dirais que non. Ceci quel que soit le type de travail (refactoring, etc.).

Au minimum, les tâches doivent être créées et insérées dans votre sprint actuel. Le but du suivi du temps est de capturer votre vitesse afin d'être en mesure de tracer efficacement de futurs sprints. Si vous travaillez sur des choses sans les suivre, vous aurez un impact sur la vitesse et elle ne s'améliorera pas avec le temps comme prévu avec un suivi approprié (vous n'aurez probablement pas assez de travail régulièrement parce que votre vitesse projetée est inférieure à votre vitesse réelle ).

En ce qui concerne le refactoring du travail en soi, je peux faire une tirade à ce sujet, mais je ne le ferai pas car je ne pense pas que ce soit la question centrale à laquelle vous essayez d'avoir une réponse.

Je vais également dire non. La refactorisation conduit souvent à des bogues involontaires si elle n'est pas gérée correctement.

En tant que directeur général, je mettais périodiquement tout le monde sur un autre projet et passais une semaine à réviser / refactoriser / renommer le code et à appliquer les conventions sur un projet. Ces sprints de refactorisation seraient presque toujours de nature cosmétique. Toute refonte fonctionnelle serait planifiée à l'avance et impliquerait le développeur d'origine.

La refacturation fonctionnelle doit toujours être planifiée et coordonnée dans le cadre du processus de mêlée afin que le temps puisse être suivi et que tous les membres de l'équipe nécessaires soient disponibles pour valider le processus. Un développeur ne devrait pas changer le code écrit par un autre hors piste, car il est probable que cela gâche le sprint actuel pour tout le monde. Surtout quand il s'agit de temps de fusion de code.

S'il s'agit d'un projet dont vous êtes le seul responsable et qu'il s'agit de votre propre temps libre, il peut être différent en supposant que vous preniez des mesures pour vous assurer de ne pas causer de retards inutiles dans votre sprint actuel.

En cas de doute, demandez à votre responsable.

EDIT: Je veux également mentionner qu'un morceau de code donné que vous n'aimez pas peut avoir un certain objectif de performance qui lui est associé. Vous ne l'aimez peut-être pas, mais il peut être plus rapide que tout ce que vous pourriez construire qui convient à la façon dont vous souhaitez l'utiliser. Une autre raison pour laquelle la refacturation fonctionnelle devrait toujours être un processus géré.

Scrum ne dit rien sur le refactoring (voir une conférence de Robert C. Martin, "La terre que Scrum a oubliée").

Dans Scrum, les tâches visent les fonctionnalités de votre logiciel spécifiées par le client, et non les dettes techniques à rembourser par refactoring. Ce sont des niveaux d'abstraction totalement différents. Le client n'est généralement pas en mesure d'évaluer la nécessité.

Scrum est la gestion statistique de projets. Pour obtenir des mesures significatives de "combien de temps cela prend-il", vous devez connaître les performances (sortie par sprint). Vous comparez l'estimation et la durée réelle d'une fonctionnalité pour au moins plus d'un sprint pour entrer dans la statistique. Je recommande 5 sprints. Mais cela dépend de votre équipe.

L'essentiel est de conserver des mesures significatives et comparables pour rendre toute prévision possible. Ce ne sera pas le cas si la performance diminue en raison de dettes techniques.

Si vous pensez toujours à refactoriser des tâches, vous avez deux problèmes: 1. Un client, qui ne comprend pas, pourquoi il doit accepter une tâche qui ne produira pas de nouvelle fonctionnalité 2. Vous déformez totalement vos statistiques et donc votre capacité à prévoir lorsque vous changez soudainement une variable différente qui n'était pas prise en compte dans les sprints précédents

Dans les deux cas, vous compromettez l'idée de la mêlée lorsque vous voulez parler des fonctionnalités avec le client ET faire des prévisions fiables pour "Combien de temps cela prend-il?" de manière statistique. Pour être sûr, vous devez conserver votre base de code dans une qualité constante (peut-être élevée).

Le refactoring est la plupart du temps une tâche souterraine. Les «grands» refactorings signifient que les «petits» refactorings n'ont pas été traités dans le passé.

Une dernière remarque: si vous effectuez des refactorisations, assurez-vous que le composant est en cours de test. Ohh, tu n'as pas de tests? Faites une tâche pour écrire des tests. Votre client sera heureux de savoir que le logiciel qu'il utilise actuellement n'a pas une couverture de test suffisante ...

Gardez les éléments techniques à l'écart du client et faites votre travail en tant que développeur professionnel.

Voici une approche: faites les deux!

La refactorisation est souvent sujette aux erreurs ou prend plus de temps que celle initialement estimée comme le souligne @misterbiscuit.

Considérez donc une tentative de faire un brouillon ou un pic. Vous n'avez pas besoin de demander l'approbation ou de faire de la publicité à ce stade.

Ensuite, cherchez à l'inclure via l'un des deux canaux:

• un ticket existant qui touche le même code / fonctionnalité où vous pouvez raisonnablement envelopper cela. Raisonnablement comme convenu avec les autres membres de l'équipe.
• un billet entier pour révision lors du prochain toilettage (ou réunion hebdomadaire, etc. en cas de chute d'eau). À ce moment-là, vous pouvez le faire.

Une fois que vous obtenez le buy-in réel, vous pouvez chercher à appliquer ou refaire votre pic et à fusionner le code réel dans la branche principale (maître, etc.).

Cela aura plusieurs avantages:

• Tous vos codes de code passent par le même processus, sont testés, QA, dans le pipeline de versions, etc.
• Vous obtenez un accord formel, y compris de la part du chef de produit, que le refactoring fait partie de l'artisanat et non quelque chose qui doit être `` introduit '' en vacances. Demandez-vous pourquoi vous n'êtes pas en train de vous faufiler, une fonctionnalité réelle peut aider à la perspective.
• Vous pouvez demander l'appariement, la révision du code, le qa, les devops et tout autre support qui peut être nécessaire pour le changement de code d'affacturage. Tout sera officiel, selon la politique et la procédure et ci-dessus.
• Si vous êtes une entreprise cotée en bourse avec la conformité SOX, vous voulez / devez probablement faire ce genre de processus formel (c.-à-d. Le documenter puis le suivre).
• Vous obtenez une meilleure réputation à la fois avec le chef de produit (le changement a été fait rapidement) et l'équipe de développement (la base de code a été améliorée).
• L'organisation cherche à se soucier de la qualité du code, ce qui est bon pour la productivité, le moral, la rétention des employés et bien d'autres raisons.
• L'effet sur la vitesse du projet peut être plus facilement suivi lorsque tout le travail est inclus. Il peut être correct de ne nommer aucun point car la présence elle-même peut être utilisée pour affecter la vitesse.
• Les développeurs sont susceptibles de découvrir des outils qui encouragent les révisions de code plus faciles tels que Fisheye, Github, etc.
• Les développeurs sont plus susceptibles de découvrir certaines normes de base (parfois documentées, parfois non) qui facilitent le partage de code et donc la refactorisation. Parfois, une grande partie de la refactorisation consiste à choisir un style, puis à l'appliquer largement (en remplaçant un mélange d'approches par un).

Un dernier commentaire: évitez que le chef de produit n'entende le mot «aléatoire». Ils peuvent répondre plus favorablement avec une mise à niveau du code «ciblée, stratégique et améliorant les performances». Ou le service pack d'application. Ou quelle que soit la langue qui vous couvre.

La refactorisation aléatoire n'a aucun sens. Ce qui est logique, c'est la refactorisation d'un code qui introduira la plupart des avantages. Cela signifie :

• correction d'un problème de conception ou d'architecture
• améliorer la mise en œuvre

Est-ce correct dans Scrum si je commence à refactoriser au hasard le code que j'ai et que je n'ai pas écrit qui me dérange toujours mais que je n'ai pas le temps d'autres jours pour le réparer à cause des affectations d'autres jours?

De cette réponse :

Garder le code maintenable doit être un élément de votre liste déroulante (si vous utilisez un Scrum). C'est tout aussi important qu'un nouveau développement. Bien que cela ne semble pas être quelque chose de "visible pour l'utilisateur", l'ignorer augmente votre dette technique. Plus tard, lorsque la dette technique s'accumulera suffisamment pour que le manque de maintenabilité de votre code ralentisse le développement, les retards dans le développement de nouvelles fonctionnalités seront visibles pour les clients.

Dans mon travail précédent, nous avions une sorte de mêlée, avec des sprints plus grands (2-3 mois). Comme nous avons eu quelques retards entre les sprints (1 mois), nous avons utilisé ce temps pour analyser le logiciel et refactoriser le code.