Demandes de fonctionnalités par rapport aux rapports de bogues : connaître la différence

Dans les logiciels scientifiques et d’ingénierie, la plupart des frustrations ne proviennent pas de problèmes difficiles – cela provient d’énoncés de problèmes peu clairs. Un ticket qui « semble mal » peut en fait décrire une capacité manquante. Une demande de « petite amélioration » peut masquer un défaut qui corrompt les résultats. Lorsque les équipes classent mal les billets, elles perdent du temps : les développeurs enquêtent sur les bogues fantômes, les chercheurs attendent des fonctionnalités qui n’ont jamais été définies et les priorités dérivent.

Ce guide vous aide à décider rapidement si quelque chose est un rapport de bogue ou une demande de fonctionnalité, et montre comment écrire chacun afin que l’équipe puisse agir en conséquence. L’objectif est simple : moins de commentaires de va-et-vient, un triage plus rapide et moins de surprises dans les versions.

Pourquoi la distinction est importante

Les rapports de bogues et les demandes de fonctionnalités sont traités différemment dans la plupart des flux de travail (Trac, Jira, GitHub, problèmes Redmine, etc.). Ils ont une urgence différente, des critères d’acceptation différents et différentes façons de tester et de boucler la boucle.

• Un rapport de bogue a généralement une attente d’exactitude : le logiciel viole son propre contrat, sa documentation ou son comportement établi.
• Une demande de fonctionnalité demande un nouveau comportement : quelque chose que le logiciel ne promet pas actuellement, même s’il serait utile.

Lorsque vous étiquetez correctement le ticket, le triage devient plus facile : les responsables de la maintenance peuvent reproduire, hiérarchiser et affecter le travail sans deviner ce qui doit se produire.

Les définitions de base

Qu’est-ce qu’un rapport de bogue ?

Un bogue se produit lorsque le système se comporte de manière incorrecte par rapport à un point de référence convenu. Ce point de référence peut être :

• Documentation ou interface publiée (contrat API)
• Comportement stable précédent (une régression)
• Exactitude scientifique (p. ex. lois de conservation, invariants attendus, cohérence des unités)
• Exigences clairement énoncées (y compris les tests ou les spécifications)

En bref : un rapport de bogue décrit une erreur qui doit être corrigée pour restaurer l’exactitude.

Qu’est-ce qu’une demande de fonctionnalité ?

Une demande de fonctionnalité propose une capacité ou une amélioration qui rendrait le système plus utile, flexible ou efficace, mais qui n’est pas requis pour l’exactitude du comportement actuel. Les exemples incluent :

• Prise en charge d’un nouveau type de condition aux limites
• Ajout d’un exportateur pour un nouveau format de fichier
• Améliorer les performances au-delà des objectifs actuels
• Ajout d’options UI/CLI qui n’existent pas encore

En bref : une demande de fonctionnalité décrit quelque chose de nouveau que le système devrait faire.

Liste de vérification des décisions rapides

Si vous ne vous souvenez qu’une seule règle, utilisez ceci :

• Si le logiciel rompt une promesse, c’est un bogue.
• Si vous voulez une nouvelle promesse, c’est une fonctionnalité.

Posez-vous ces questions :

1. Cela a-t-il déjà fonctionné dans le même scénario ? Si oui, probablement un bogue (éventuellement une régression).
2. Existe-t-il une documentation indiquant que le comportement devrait fonctionner ? Si oui, bug.
3. Le comportement est-il ambigu et vous proposez ce qu’il devrait être ? Probablement une fonctionnalité (ou une clarification des spécifications en premier).
4. Le problème est-il que vous ne pouvez pas faire quelque chose du tout, mais que rien n’est « mal » avec les sorties existantes ? probablement une fonctionnalité.
5. Produit-il des résultats incorrects, un crash, des données de corruption ou des contraintes physiques ? Bogue.

Comparaison côte à côte

Exemples de calcul scientifique

Exemple 1 : résultats erronés dus à une non-concordance d’unités

Vous exécutez une simulation et remarquez qu’un paramètre documenté comme « mètres » est traité comme des « millimètres », en décalant les résultats de 1 000 ×. Si la documentation et le code ne sont pas d’accord et que les sorties sont incorrectes pour une utilisation documentée, il s’agit d’un rapport de bogue. Votre ticket doit inclure le paramètre, où il est documenté, un cas minimal et des preuves de non-concordance.

Exemple 2 : Besoin d’un nouveau terme PDE ou d’un couplage

Vous souhaitez ajouter un terme d’électromigration à un modèle de transport existant. Le code actuel fonctionne comme prévu ; Cela n’inclut tout simplement pas cette physique. C’est une demande de fonctionnalité. Votre ticket doit expliquer l’équation gouvernante, les entrées attendues et comment vous le valideriez (benchmarks ou limites analytiques).

Exemple 3 : « C’est trop lent »

Les performances peuvent être soit. Si le code fonctionnait en 5 minutes et prend désormais 50 minutes sur la même configuration, c’est un bogue (une régression des performances). Si le code a toujours pris 50 minutes et que vous souhaitez qu’il en soit 5, c’est une demande de fonctionnalité (travail d’optimisation), à moins que la lenteur ne provienne d’un comportement inattendu (comme un solveur bloqué en raison d’un problème de convergence).

Exemple 4 : message d’erreur déroutant

Un message d’erreur déroutant est généralement une demande de fonctionnalité (amélioration UX), à moins que le message soit factuellement incorrect ou masque l’erreur réelle d’une manière qui empêche le diagnostic. Dans de nombreuses équipes, « Améliorer le message d’erreur » est suivi comme une amélioration, pas comme un bogue.

Les erreurs de classification courantes et comment les corriger

Mauvaise classification : « ça plante » (mais uniquement avec une entrée non valide)

Si le logiciel se bloque lorsqu’il a une entrée non valide, il peut s’agir d’un bogue si le programme échoue avec élégance (erreur d’effacement, pas de fichiers corrompus). Si un plantage est attendu parce que l’entrée est en dehors des contraintes prises en charge et que l’outil documente déjà cela, il pourrait s’agir d’une demande d’amélioration pour améliorer la validation et la messagerie.

Mauvaise classification : « le résultat semble faux » (mais les attentes ne sont pas claires)

Si le ticket ne définit pas ce que signifie « droit », les mainteneurs ne peuvent pas décider de bogue par rapport à la fonctionnalité. Dans ce cas, inscrivez le ticket sous forme de question plus une attente proposée, et joignez des éléments de preuve. Souvent, la meilleure première étape est la suivante : « clarifier le comportement attendu » – puis refiler en tant que bogue ou fonctionnalité une fois confirmé.

Mauvaise classification : « Veuillez ajouter l’option X » (mais le code la prend déjà en charge)

Il ne s’agit ni d’une fonctionnalité ni d’un bogue dans le comportement de base – il peut s’agir d’un écart de documentation. Si la capacité existe mais est difficile à découvrir, créez un ticket DOC (ou une amélioration axée sur la convivialité).

Comment rédiger un rapport de bogue de haute qualité

Un bon rapport de bogue facilite la reproduction, le diagnostic et la vérification du correctif.

Modèle de rapport de bogue

• Résumé : Une phrase décrivant le comportement incorrect
• Environnement : OS, version Python/C++, version/commit de package, versions MPI/solveur, le cas échéant
• Étapes à reproduire : étapes minimales, fichiers d’entrée minimaux, extrait de code minimal
• Résultat attendu : que devrait-il se passer et pourquoi (Docs/Tests/Comportement précédent)
• Résultat réel : que se passe-t-il à la place (logs, trace de pile, captures d’écran, diff de sortie)
• Impact : gravité (crash, mauvaise science, interface utilisateur mineure), fréquence, solution de contournement, le cas échéant

Exemple de rapport de bogue (court)

Résumé : L’exemple de diffusion échoue avec Dirichlet BC sur la grille 3D.

• Attendu : la simulation s’exécute et produit des valeurs de champ stables comme en 2D.
• Réel : le solveur diverge après n étapes ; Les valeurs deviennent Nan.
• Preuve : Fournissez un script, des valeurs de paramètres et une sortie de journal minimales.

Comment rédiger une demande de fonctionnalité forte

Une demande de fonctionnalités fortes se lit comme une mini-note de conception : elle explique pourquoi la capacité est importante, ce à quoi ressemble le « fait » et comment vous la vérifierez.

Modèle de demande de fonctionnalité

• Déclaration du problème : ce que vous ne pouvez pas faire aujourd’hui
• Cas d’utilisation : qui en a besoin et pourquoi (flux de travail de recherche, module d’enseignement, pipeline de production)
• Solution proposée : comportement de haut niveau, modifications de l’interface utilisateur/API, des valeurs par défaut
• Critères d’acceptation : ce qui doit être vrai pour le considérer comme terminé
• Validation : Comment tester (benchmarks, tests unitaires, solutions analytiques, suite de régression)
• Alternatives prises en compte : solutions de contournement ou autres approches

Exemple de demande de fonctionnalité (court)

Demande : Ajoutez une option pour exporter l’état de simulation vers un format de visualisation standardisé à des intervalles configurables.

• Cas d’utilisation : exécutions importantes sur HPC où une visualisation intermédiaire est nécessaire pour la surveillance.
• Acceptation : exporter les travaux pour les grilles 2D/3D ; Inclut les métadonnées (pas de temps, unités) ; Pas de ralentissement majeur.
• Validation : comparez les champs exportés avec les tableaux en mémoire ; Assurez-vous que le rechargement reproduit l’état dans la tolérance.

Quand un billet devrait devenir deux

De nombreux problèmes du monde réel mélangent des bogues et des fonctionnalités. Leur division accélère souvent les progrès.

• S’il y a un crash (bug) et aussi un désir d’un message plus agréable (fonctionnalité), classez deux tickets.
• S’il y a un problème d’exactitude (bug) ainsi qu’une demande d’appui à un nouveau régime, séparez le « comportement actuel » de « la capacité d’extension ».
• Si la demande est « accélérée » mais que vous soupçonnez une régression, enregistrez un bogue pour la régression et une fonctionnalité pour une optimisation ultérieure.

Le fractionnement des tickets permet aux équipes de fermer rapidement le bogue et de planifier l’amélioration de manière raisonnable.

Conseils de triage pour les mainteneurs et les prospects

Utiliser des étiquettes et un court commentaire de décision

Lorsqu’un ticket arrive ambigu, ajoutez un court commentaire qui verrouille la classification :

• « Classification de bug parce que le comportement contredit la section de documentation X. »
• « Classification de la demande de fonctionnalité, car cela ajoute une nouvelle fonctionnalité de solveur qui n’est actuellement pas prise en charge. »

Exiger un minimum de critères d’acceptation pour les fonctionnalités

Les demandes de fonctionnalités échouent lorsque « Terminé » n’est pas clair. Demandez tôt les critères d’acceptation : quelle sortie, quelle interface, quels tests, quel exemple. Une fonctionnalité sans critères d’acceptation est en fait un élément de la liste de souhaits.

Transformez les questions récurrentes en tâches de documentation

Si plusieurs « demandes de fonctionnalités » sont en fait des demandes de conseils (« Comment puis-je… ? »), capturez-les sous forme d’améliorations Docs. Ceci est particulièrement courant dans les bibliothèques scientifiques où les capacités existent mais ne sont pas évidentes.

Modèles pratiques que vous pouvez copier dans les tickets

Classificateur à une ligne

Utilisez-le comme première ligne de la description de votre billet :

• Bug : « Le comportement observé contredit le comportement attendu défini par [docs/test/previous version]. »
• Fonctionnalité : « Nouvelle fonctionnalité nécessaire pour prendre en charge [use case], non disponible actuellement. »

Critères d’acceptation Démarrage défini pour les fonctionnalités

• API : nouvelle option/paramètre documenté avec les valeurs par défaut
• Exemple : exemple de travail minimal inclus dans les documents/exemples
• Tests : au moins un test automatisé couvre le comportement principal
• Compatibilité ascendante : les scripts existants continuent de s’exécuter sans modification (ou étapes de migration documentées)

Conclusion

Bug reports restore trust; Les demandes de fonctionnalités développent la fonctionnalité. Les deux sont essentiels dans les logiciels scientifiques, mais ils ne réussissent que lorsqu’ils sont écrits avec la bonne intention et les preuves. Si vous associez des bogues à un point de référence et associez des fonctionnalités à un cas d’utilisation clair avec des critères d’acceptation, vous réduirez les frictions de triage, accélérez le développement et rendez les versions plus prévisibles, ce qui améliore finalement la vitesse de recherche et la fiabilité des résultats.