Quelle est la différence entre un bug et une demande de changement dans MSF pour CMMI ?

Question

J'évalue actuellement le MSF for CMMI modèle de processus sous TFS pour une utilisation dans mon équipe de développement, et j'ai du mal à comprendre la nécessité de types d'éléments de travail distincts pour les bogues et les demandes de modification.

Je comprends qu'il est avantageux de pouvoir faire la différence entre les bogues (erreurs) et les demandes de changement (exigences changeantes) lors de la génération de rapports.

Dans notre système actuel, cependant, nous n'avons qu'un seul type de demande de modification et utilisons simplement un champ pour indiquer s'il s'agit d'un bug, d'un changement d'exigence, etc. (ce champ peut être utilisé pour créer des requêtes de rapport).

Quels sont les avantages d’avoir un flux de travail séparé pour les bogues ?

Je suis également confus par le fait que les développeurs peuvent soumettre des travaux contre un bug ou une demande de modification, je pensais que le flux de travail prévu était de permettre aux bogues de générer des demandes de modification auxquelles le développeur fait référence lorsqu'il apporte des modifications.

Answer 1

@Luc

Je ne suis pas en désaccord avec vous, mais cette différence est généralement l'explication donnée pour expliquer pourquoi il existe deux processus différents disponibles pour traiter les deux types de problèmes.

Je dirais que si la couleur de la page d'accueil a été conçue à l'origine pour être rouge et que, pour une raison quelconque, elle est bleue, c'est facilement une solution rapide et ne nécessite pas d'impliquer beaucoup de personnes ou d'heures de travail pour effectuer le changement.Extrayez simplement le fichier, changez la couleur, réarchivez-le et mettez à jour le bogue.

Cependant, si la couleur de la page d'accueil a été conçue pour être rouge et qu'elle est rouge, mais que quelqu'un pense qu'elle doit être bleue, c'est, pour moi en tout cas, un type de changement différent.Par exemple, quelqu'un a-t-il pensé à l'impact que cela pourrait avoir sur d'autres parties de la page, comme les images et les logos superposés sur le fond bleu ?Pourrait-il y avoir des limites aux choses qui semblent mauvaises ?Le lien souligné est en bleu, est-ce que cela apparaîtra ?

A titre d'exemple, je suis daltonien rouge/vert, changer la couleur de quelque chose n'est, pour moi, pas quelque chose que je prends à la légère.Il y a suffisamment de pages Web sur le Web qui me posent problème.Juste pour souligner que même le changement le plus insignifiant peut être non trivial si l’on considère tout.

Le changement réel de mise en œuvre finale est probablement à peu près le même, mais pour moi, une demande de changement est une bête différente, précisément parce qu'il faut y réfléchir davantage pour s'assurer qu'elle fonctionnera comme prévu.

Un bug, cependant, c'est que quelqu'un a dit c'est comme ça que nous allons procéder et puis quelqu'un l'a fait différemment.

Une demande de changement ressemble plus à mais nous devons également considérer cette autre chose...Hmm....

Il y a bien sûr des exceptions, mais permettez-moi de démonter vos exemples.

Si le serveur était conçu pour gérer plus de 300 000 000 000 de pages vues, alors oui, c'est un bug que ce ne soit pas le cas.Mais concevoir un serveur capable de gérer autant de pages vues ne se résume pas à dire notre serveur devrait gérer 300 000 000 000 de pages vues, il doit contenir un très spécification détaillée sur la manière dont il peut y parvenir, jusqu'aux garanties de temps de traitement et aux temps moyens d'accès au disque.Si le code est ensuite implémenté exactement comme prévu et incapable de fonctionner comme prévu, alors la question devient : l'avons-nous mal conçu ou l'avons-nous mal mis en œuvre ?.

Je conviens que dans ce cas, que cela doive être considéré comme un défaut de conception ou un défaut de mise en œuvre dépend de la raison réelle pour laquelle il ne répond pas aux attentes.Par exemple, si quelqu'un supposait que les disques étaient 100 fois plus rapides qu'ils ne le sont réellement, et que cela est considéré comme la raison pour laquelle le serveur ne fonctionne pas comme prévu, je dirais qu'il s'agit d'un bug de conception et que quelqu'un doit repenser la conception. .Si l'exigence initiale d'autant de pages vues doit toujours être respectée, une refonte majeure avec davantage de données en mémoire et similaires pourrait devoir être entreprise.

Cependant, si quelqu'un n'a tout simplement pas pris en compte le fonctionnement des disques RAID et la manière de bénéficier correctement des médias répartis, il s'agit d'un bug et il n'est peut-être pas nécessaire de procéder à un changement aussi important pour le corriger.

Là encore, il y aura bien sûr des exceptions.

Quoi qu’il en soit, la différence initiale que j’ai énoncée est celle que j’ai trouvée vraie dans la plupart des cas.

Answer 2

Gardez à l’esprit qu’une partie de la définition d’un type d’élément de travail pour TFS est la définition de son « workflow », c’est-à-dire les états dans lesquels l’élément de travail peut être et les transitions entre les états.Cela peut être sécurisé par un rôle de sécurité.

Ainsi, de manière générale, une « demande de changement » serait initiée et approuvée par une personne relativement haut placée dans une organisation (une personne disposant de droits de « parrainage » liés à la dépense de ressources pour apporter une modification (éventuellement très importante) au système.En fin de compte, c’est cette personne qui approuverait que le changement ait été effectué avec succès.

Cependant, pour un "Bug", TOUT utilisateur de l'application devrait pouvoir lancer un Bug.

Dans une organisation dans laquelle j'ai implémenté TFS, seuls les chefs de service peuvent être à l'origine d'une "demande de changement" - mais les "bogues" ont été créés à partir de tickets "Help Desk" (non automatisés, uniquement via un processus...)

Answer 3

En général, même si je ne peux pas parler au nom de CMM, les demandes de modification et les bogues sont traités et considérés différemment car ils font généralement référence à différents éléments du cycle de vie de votre application.

Un bug est un défaut dans la mise en œuvre de votre programme.Par exemple, si vous concevez votre programme pour pouvoir additionner deux nombres et donner la somme à l'utilisateur, un défaut serait qu'il ne gère pas correctement les nombres négatifs, et donc un bug.

Une demande de modification, c'est lorsque vous avez un défaut de conception.Par exemple, vous avez peut-être spécifiquement indiqué que votre programme ne devait pas gérer de nombres négatifs.Une demande de modification est alors déposée afin de repenser et ainsi réimplémenter cette partie.Le défaut de conception n'est peut-être pas intentionnel, mais pourrait facilement être dû au fait que vous n'avez tout simplement pas pris en compte cette partie lors de la conception initiale de votre programme, ou que de nouveaux cas qui n'existaient pas au moment où la conception originale a été créée ont été inventés ou découverts. depuis.

En d’autres termes, un programme peut fonctionner exactement comme prévu, mais doit être modifié.Il s'agit d'une demande de changement.

---

En règle générale, corriger un bug est considéré comme une action beaucoup moins coûteuse que d'exécuter une demande de modification, car le bug n'a jamais été destiné à faire partie de votre programme.La conception, cependant, l'était.

Un flux de travail différent peut donc être nécessaire pour gérer les deux scénarios différents.Par exemple, vous pourriez avoir une manière différente de confirmer et de classer les bogues que pour les demandes de modification, ce qui pourrait nécessiter plus de travail pour exposer les conséquences du changement.

Answer 4

Un bug est quelque chose qui ne fonctionne pas dans une exigence dont la mise en œuvre a déjà été approuvée.

Une demande de changement doit passer par un cycle au cours duquel l'impact et les efforts doivent être estimés pour ce changement, puis sa mise en œuvre doit être approuvée avant que les travaux puissent commencer.

Les deux sont fondamentalement différents sous CMM.

Answer 5

Mon hypothèse est-elle alors incorrecte selon laquelle les demandes de modification devraient être générées à partir de bogues ?Je suis confus car je ne pense pas que tous les bogues devraient être automatiquement approuvés pour la mise en œuvre - ils peuvent être triviaux et au moins dans notre cas, ils passeront par le même processus d'examen qu'une demande de modification avant d'être attribués à un développeur.