Pratiques agiles: révision du code - échouer la révision ou soulever un problème?
À la fin d'un sprint de 2 semaines et une tâche a une révision de code, dans la revue, nous découvrons une fonction qui fonctionne, est lisible, mais elle est assez longue et a quelques odeurs de code. Travail de refactorisation facile.
Sinon, la tâche correspond à la définition de terminé.
Nous avons deux choix.
- Échec de la révision du code, afin que le ticket ne se ferme pas dans ce sprint, et nous prenons un peu le moral, car nous ne pouvons pas faire passer le ticket.
- Le refactor est un petit morceau de travail, et se ferait dans le prochain sprint (ou même avant qu'il ne commence) comme une petite histoire en demi-point.
Ma question est: y a-t-il des problèmes ou des considérations inhérents à l'augmentation d'un ticket au dos d'une critique, au lieu de l'échouer?
Les ressources que je peux trouver et lire les revues de code détaillées sont à 100% ou rien, généralement, mais je trouve que ce n'est généralement pas réaliste.
existe-t-il des problèmes ou des considérations inhérents à l'augmentation d'un ticket au dos d'une critique, au lieu de l'échouer?
Pas intrinsèquement. Par exemple, la mise en œuvre du changement actuel peut avoir mis au jour un problème qui était déjà là, mais qui n'était pas connu/apparent jusqu'à présent. Échouer le ticket serait injuste car vous échoueriez pour quelque chose sans rapport avec la tâche réellement décrite.
dans la revue, nous découvrons une fonction
Cependant, je présume que la fonction ici est quelque chose qui a été ajouté par le changement actuel. Dans ce cas, le ticket doit échouer car le code n'a pas réussi le test d'odeur.
Où traceriez-vous la ligne, sinon où vous l'avez déjà tracée? Vous ne pensez clairement pas que ce code est suffisamment propre pour rester dans la base de code sous sa forme actuelle; alors pourquoi envisager de donner un laissez-passer au billet?
Échec de la révision du code, afin que le ticket ne se ferme pas dans ce sprint, et nous prenons un peu le moral, car nous ne pouvons pas faire passer le ticket.
Il me semble que vous soutenez indirectement que vous essayez de donner un laissez-passer à ce ticket pour le moral de l'équipe, plutôt que pour la qualité de la base de code.
Si tel est le cas, vos priorités sont mitigées. Le standard du code propre ne doit pas être modifié simplement parce qu'il rend l'équipe plus heureuse. La justesse et la propreté du code ne dépendent pas de l'humeur de l'équipe.
Le refactor est un petit morceau de travail, et se ferait au prochain sprint (ou même avant qu'il ne commence) comme une petite histoire en demi-point.
Si la mise en œuvre du ticket d'origine a provoqué l'odeur du code, il doit être traité dans le ticket d'origine. Vous ne devez créer un nouveau ticket que si l'odeur du code ne peut pas être directement attribuée au ticket d'origine (par exemple, un scénario "paille qui a brisé le dos du chameau").
Les ressources que je peux trouver et lire les revues de code détaillées sont à 100% ou rien, généralement, mais je trouve que ce n'est généralement pas réaliste.
Réussite/échec est intrinsèquement un état binaire, qui est intrinsèquement tout ou rien.
Je pense que ce à quoi vous faites référence ici, c'est plus que vous interprétez les revues de code comme nécessitant du code parfait ou autrement échouant, et ce n'est pas le Cas.
Le code ne doit pas être impeccable, il doit simplement respecter la norme raisonnable de propreté que votre équipe/entreprise utilise. L'adhésion à cette norme est un choix binaire: elle adhère (passe) ou non (échoue).
Sur la base de votre description du problème, il est clair que vous ne pensez pas que cela adhère à la norme de code attendue et qu'il ne devrait donc pas être adopté pour des raisons ultérieures telles que le moral de l'équipe.
Sinon, la tâche correspond à la définition de terminé.
Si "il fait le travail" était la meilleure référence pour la qualité du code, alors nous n'aurions pas eu à inventer le principe du code propre et les bonnes pratiques - le compilateur et les tests unitaires seraient déjà notre processus d'examen automatisé et vous n'auriez pas besoin de révisions de code ou d'arguments de style.
À la fin d'un sprint de 2 semaines et une tâche a une révision de code [...] Travail de refactorisation facile.
Pourquoi cela apparaît-il à la fin du sprint? Un examen du code devrait avoir lieu dès que vous pensez que le code est terminé (ou même avant). Vous devriez vérifier votre définition de terminé avec chaque histoire que vous avez terminée.
Si vous vous retrouvez à terminer des histoires si peu de temps avant votre examen de démo/sprint que vous ne pouvez pas lui faire une "petite" tâche, alors vous devez vous améliorer pour estimer votre travail. Oui, cette histoire n'est pas terminée. Pas à cause d'une révision de code, mais parce que vous n'aviez pas prévu d'incorporer les modifications de la révision de code. Cela revient à estimer que les "tests" ne prennent aucun temps, car "si vous les avez programmés correctement, cela fonctionnera, non?". Ce n'est pas ainsi que cela fonctionne. Les tests trouveront des erreurs et l'examen du code trouvera des choses à changer. Sinon, ce serait une grande perte de temps.
Donc, pour résumer: oui, le DoD est binaire. Réussir ou échouer. Une révision de code n'est pas binaire, elle devrait plutôt ressembler à une tâche en cours. Vous ne pouvez pas échouer. C'est un processus et finalement c'est fait. Mais si vous ne planifiez pas correctement, vous n'atteindrez pas cette étape "terminée" dans le temps et êtes coincé dans le territoire "non terminé" à la fin du sprint. Ce n'est pas bon pour le moral, mais vous devez en tenir compte dans la planification.
Simple: vous passez en revue le changement. Sinon, vous ne passez pas en revue l'état du programme. Si je corrige un bogue dans une fonction de 3000 lignes, alors vous vérifiez que mes modifications corrigent le bogue, et c'est tout. Et si ma modification corrige le bogue, vous acceptez la modification.
Si vous pensez que la fonction est trop longue, vous introduisez une demande de modification pour raccourcir la fonction, ou la divisez, après ma modification a été acceptée, et cette demande de changement peut ensuite être hiérarchisée en fonction de son importance. Si la décision est prise que l'équipe a des choses plus importantes à faire, elle est traitée plus tard.
Ce serait ridicule si vous pouviez décider des priorités de développement lors d'une révision de code, et rejeter ma modification pour cette raison serait une tentative de décider des priorités de développement.
En résumé, il est tout à fait acceptable d'accepter un changement de code et de lever immédiatement un ticket en fonction de ce que vous avez vu lors de l'examen du changement. Dans certains cas, vous le ferez même si le changement lui-même a causé les problèmes: S'il est plus important d'avoir les changements maintenant que de résoudre les problèmes. Par exemple, si d'autres ont été bloqués, en attendant la modification, vous souhaitez les débloquer pendant que le code peut être amélioré.
Échec de la révision du code, afin que le ticket ne se ferme pas dans ce sprint, et nous prenons un peu le moral, car nous ne pouvons pas faire passer le ticket.
Cela semble être le problème.
En théorie, vous savez ce que vous devez faire, mais c'est proche de la date limite, vous ne voulez donc pas faire ce que vous savez que vous devez faire.
La réponse est simple: faites tout ce que vous feriez si vous obteniez le même code pour la révision du code le premier jour du sprint. Si cela était acceptable, il devrait l'être maintenant. Sinon, ce ne serait pas le cas maintenant.
Une grande partie du processus consiste à décider ce que a fait et à s'en tenir à vos armes. Cela signifie également de ne pas trop s'engager et de faire vos examens par les pairs à temps pour permettre aux tests de s'assurer que le travail est également fonctionnel.
En ce qui concerne les problèmes de révision de code, il existe plusieurs façons de le gérer, et le bon choix dépend de quelques facteurs.
- Vous pouvez simplement nettoyer le code vous-même et faire savoir à la personne ce que vous avez fait. Fournit des opportunités de mentorat, mais cela devrait être assez simple et réalisable en quelques minutes.
- Vous pouvez relancer avec des commentaires sur ce qui ne va pas. Si la gestion des erreurs est mal effectuée ou si le développeur continue de répéter les mêmes erreurs, cela peut être garanti.
- Vous pouvez créer un ticket et contracter une dette technique. Le ticket est là pour vous assurer de le rembourser plus tard. Il se peut que vous soyez sur une période de crise et que vous soyez en train d'examiner les changements, vous voyez un problème plus important qui n'est pas directement lié au changement.
L'essentiel, c'est que lorsque vous avez terminé le travail, vous devez en avoir terminé. S'il y a des problèmes plus importants que ceux sur lesquels le développeur a travaillé, relevez le drapeau et continuez. Mais vous ne devriez pas être dans une position où il y a des heures avant la fin du sprint et vous êtes en train de passer en revue par les pairs. Cela sent le sur-engagement de vos ressources ou la procrastination sur les évaluations par les pairs. (une odeur de processus).
Il n'y a pas de problèmes inhérents à la priorisation des problèmes de révision de code, mais il semble que les principaux problèmes sur lesquels vous devez vous mettre d'accord, en équipe, sont:
- Quel est le but de votre révision de code?
- Comment les résultats de l'examen du code sont-ils liés à la définition de Terminé pour un élément de travail?
- Si la révision du code s'applique comme test de déclenchement, quels problèmes sont considérés comme des "bloqueurs"?
Tout cela se résume à ce que l'équipe a accepté comme définition de Terminé. Si la réussite de la révision de code avec Zero Issues est la définition de terminé pour un élément de travail, vous ne pouvez pas fermer un élément qui ne remplit pas cette condition.
C'est la même chose que si lors d'un test unitaire un test unitaire a échoué. Vous corrigeriez le bogue, sans ignorer le test unitaire, si la réussite des tests unitaires était une condition pour être terminé.
Si l'équipe n'a pas accepté que les révisions de code soient une définition de Terminé, vos révisions de code ne sont pas un test d'acceptation de déclenchement de l'élément de travail. Il s'agit d'une activité d'équipe qui fait partie de votre processus de backlog pour rechercher du travail supplémentaire qui pourrait être nécessaire. Dans ce cas, tous les problèmes que vous découvrez ne sont pas liés aux exigences de l'élément de travail d'origine et sont de nouveaux éléments de travail que l'équipe doit hiérarchiser.
Par exemple, il pourrait être tout à fait acceptable pour une équipe de déprioriser la correction des fautes de frappe dans certains noms de variable car cela n'affecte pas la fonctionnalité métier qui a été fournie, même si l'équipe déteste vraiment voir le nom de variable "myObkect".
Les réponses les plus votées ici sont très bonnes; celui-ci traite de l'angle de refactorisation.
Dans la plupart des cas, la majorité du travail de refactorisation consiste à comprendre le code existant; le changer ensuite est généralement la plus petite partie du travail pour l'une des deux raisons:
Si simplement rendre le code plus clair et/ou concis, les changements nécessaires sont évidents. Souvent, vous avez acquis votre compréhension du code en essayant des changements qui semblaient plus propres et en voyant s'ils fonctionnaient réellement ou s'ils manquaient une certaine subtilité dans le code plus complexe.
Vous avez déjà en tête une conception ou une structure particulière dont vous avez besoin pour faciliter la construction d'une nouvelle fonctionnalité. Dans ce cas, le travail pour développer ce design faisait partie de l'histoire qui en a généré le besoin; il est indépendant que vous ayez besoin de refactoriser pour arriver à cette conception.
Apprendre et comprendre le code existant représente une quantité considérable de travail pour un avantage non permanent (dans un mois, quelqu'un aura probablement oublié beaucoup de code s'il ne continue pas à le lire ou à travailler avec lui pendant cette période), et donc il cela n'a aucun sens, sauf sur les zones de code qui vous causent des problèmes ou que vous prévoyez de changer dans un avenir proche. À son tour, puisque c'est le travail principal de refactoring, vous ne devriez pas faire de refactoring sur le code, sauf si cela vous cause actuellement des problèmes ou si vous prévoyez de le changer dans un proche avenir.
Mais il y a une exception à cela: si quelqu'un a actuellement une bonne compréhension du code qui s'échappera au fil du temps, utiliser cette compréhension pour rendre le code plus clair et plus rapidement compris plus tard peut être un bon investissement. C'est la situation dans laquelle se trouve quelqu'un qui vient de terminer le développement d'une histoire.
Le refactor est un petit morceau de travail, et se ferait au prochain sprint (ou même avant qu'il ne commence) comme une petite histoire en demi-point.
Dans ce cas, vous envisagez de créer une histoire distincte pour la refactorisation est un signe d'avertissement sur plusieurs fronts:
Vous ne pensez pas à la refactorisation dans le cadre du codage, mais comme une opération distincte, ce qui, à son tour, risque de tomber sous pression.
Vous développez du code qui sera plus difficile à comprendre la prochaine fois que quelqu'un devra travailler avec lui, ce qui rend les histoires plus longues.
Vous perdez peut-être du temps et de l'énergie en refactorisant des choses dont vous n'obtenez pas beaucoup d'avantages. (Si un changement se produit beaucoup plus tard, quelqu'un devra encore comprendre le code, de toute façon; c'est plus efficacement combiné avec le travail de refactoring. Si un changement ne se produit pas plus tard, le refactoring n'a servi aucun objectif, sauf peut-être esthétique.)
Donc, la réponse ici est d'échouer l'élément pour indiquer clairement que quelque chose dans votre processus a échoué (dans ce cas, c'est le développeur ou l'équipe qui n'alloue pas de temps pour la révision et la mise en œuvre des modifications qui sortent de la révision) et demander au développeur de continuer immédiatement le travail sur l'article.
Lorsque vous allez estimer pour la prochaine itération, réestimez l'histoire existante comme la quantité de travail qui semble être laissée pour la faire passer en revue et l'ajouter à votre prochaine itération, mais en préservant l'estimation de l'itération précédente. Lorsque l'histoire est terminée à la fin de la prochaine itération, définissez la quantité totale de travail historique sur la somme des première et deuxième estimations afin de savoir combien de travail estimé y a vraiment été consacré. Cela vous aidera à produire des estimations plus précises d'histoires similaires à l'avenir à l'état actuel de votre processus. (C'est-à-dire, ne supposez pas que votre sous-estimation apparente ne se reproduira plus; supposez que cela se reproduira jusqu'à ce que vous ayez terminé avec succès des histoires similaires tout en mettant moins de travail.)
Je suis surpris par le manque de réponse dans les réponses et les commentaires à la notion d '"échouer" une révision de code, car ce n'est pas un concept que je connais personnellement. Je ne serais pas non plus à l'aise avec ce concept ni avec aucun membre de mon équipe utilisant cette terminologie.
Votre question fait explicitement appel à des "pratiques agiles", revenons donc sur le manifeste agile (c'est moi qui souligne):
Nous découvrons de meilleures façons de développer des logiciels en le faisant et en aidant les autres à le faire. Grâce à ce travail, nous avons pris de la valeur:
- Individus et interactions sur les processus et les outils
- Logiciel fonctionnel sur une documentation complète
- Collaboration client sur la négociation du contrat
- Répondre au changement suite à un plan
Autrement dit, bien qu'il y ait de la valeur dans les éléments de droite, nous valorisons davantage les éléments de gauche.
Parlez à votre équipe. Discutez du code en question. Évaluez les coûts et les avantages et décidez - en tant que groupe cohérent d'experts - de refactoriser ce code maintenant, plus tard ou jamais.
Commencez à collaborer. Arrêtez d'échouer les révisions de code.
Il y a deux façons de voir ce problème à mon avis:
- La voie académique
- Le vrai monde
D'un point de vue académique, la plupart des processus de révision de code échouent au déploiement d'un PBI (élément de backlog de produit) lorsque la norme de qualité du code n'est pas respectée.
Cependant, personne dans le monde réel ne suit agile au T, car pour une raison (pour de nombreuses raisons), les différentes industries ont des exigences différentes. Ainsi, la correction du code maintenant ou la prise en charge dette technique (vous créeriez probablement un nouveau PBI) devrait être décidée au cas par cas. Si cela va compromettre le sprint ou une version ou introduire un niveau de risque déraisonnable, les parties prenantes commerciales doivent être impliquées dans la décision.
dans la revue, nous découvrons une fonction qui fonctionne, est lisible, mais elle est assez longue et a quelques odeurs de code ...
Existe-t-il des problèmes ou des considérations inhérents à l'élévation d'un ticket au dos d'une critique, au lieu de l'échouer?
Pas de problème du tout (de l'avis de mes équipes). Je suppose que le code répond aux critères d'acceptation énoncés dans le billet (c'est-à-dire qu'il fonctionne). Créez un élément de backlog pour traiter la longueur et les odeurs de code, et hiérarchisez-le comme n'importe quel autre ticket. S'il est vraiment petit, alors donnez-lui une priorité élevée pour le prochain sprint.
L'une des paroles que nous avons est "Choisissez l'amélioration progressive plutôt que la perfection différée".
Nous avons un processus très fluide et construisons un assez bon nombre de fonctionnalités de `` preuve de concept '' (1 ou 2 par sprint) qui passent par le développement et le test mais ne dépassent jamais l'examen interne des parties prenantes (hmm, pouvons-nous le faire à la place ?), alpha ou bêta ... certains survivent, d'autres non.
Sur le projet actuel, j'ai perdu de vue le nombre de fois où nous avons construit une certaine fonctionnalité, l'avons mise entre les mains des parties prenantes et un sprint ou deux plus tard, je l'ai totalement supprimée car la direction du produit a changé ou les exigences ont causé une refonte complète de la façon dont la fonctionnalité doit être implémentée. Toutes les tâches de `` raffinement '' restantes pour une fonctionnalité supprimée, ou qui ne correspondent pas aux nouvelles exigences, sont supprimées ainsi qu'une partie du nettoyage du backlog.