Comment dois-je mettre en œuvre Histoires de l'utilisateur dans Bugzilla? [fermé]

Question

Quelques individus à mon travail se sont réunis pour former un groupe dont le but est d'analyser les avantages de la mise en œuvre des principes de gestion du développement logiciel Agile / projet.

En tant que développeur, je vois un grand avantage dans les histoires de l'utilisateur. Nous cherchons à mettre en place un radiateur d'information qui peut être utilisé pour les étapes de suivi de la version actuelle et la planification de futures versions. Je voudrais utiliser des histoires d'utilisateurs pour ce processus.

En ce moment, nous utilisons Bugzilla pour le suivi des problèmes. La plupart planification de la libération est effectuée à l'aide des bugs de ce système. L'utilisation de Bugzilla ne changera probablement pas. Il fournit la plupart de ce que nous avons besoin au bon prix (0 $).

L'une des préoccupations est la mise en correspondance des histoires d'utilisateurs à des bugs. La gestion des versions est actuellement effectuée à l'aide des numéros de bogues. Le problème est que l'on Story utilisateur pourrait inclure trois bugs ou vice-versa.

Dans le scénario d'avoir plusieurs bogues signalé pour une seule histoire de l'utilisateur, une idée est d'avoir une histoire d'utilisateur Bug qui définit les dépendances d'histoire et la série sur les bogues des enfants qui composent cette histoire. Je suis inquiet cela peut finir par être trop complexe et créer une confusion entre les parties prenantes, le développement et l'assurance qualité. En outre, il encombre Bugzilla un peu.

Quelqu'un at-il déjà été dans cette voie? Si oui, ce que vous avez fait? Dois-je pousser à abandonner l'idée d'histoires d'utilisateur dans Bugzilla? Y at-il une solution plus simple?

Toutes les pensées seraient appréciés.

Answer 1

Je l'ai fait des choses semblables avant dans Bugzilla, et la solution que j'ai trouvé de ne pas mettre en œuvre « bugs histoire » hiérarchiques ou similaires; nous avons décidé et que cela causerait la confusion et était tout simplement trop compliqué pour ce que nous voulions. La solution que je l'ai utilisé avant était tout simplement de mettre le numéro de l'histoire de l'utilisateur dans la description du bogue; vous pouvez jeter un lien là-dedans aussi, pour le rendre plus facile à déréférencer. Il est un peu patchworkish, mais cela fonctionne assez bien.

Answer 2

Je dirais, que si vos histoires d'utilisateurs ont besoin de plus d'un cas de bug - ils sont trop gros. Avec une bonne abstraction de la fonctionnalité requise, vous pouvez partager vos histoires d'utilisateur à un plus petits, qui nécessitent un seul cas par histoire, puis de planifier et de procéder de cette façon.

Nous avons essayé d'utiliser la @McWafflestix décrit, avec des liens des cas au fonctionnaire de document (wiki) de l'histoire de l'utilisateur, mais après un certain temps nous avons trouvé que la création d'histoires d'utilisateurs plus petits est mieux - elle conduit aussi à une meilleure conception de l'application, car chaque utilisateur histoire est mis en œuvre abstraite que possible, offrant une meilleure testabilité et la maintenabilité du code.

Answer 3

Si oui ou non l'utilisation de liens de dépendance dans Bugzilla sont utilisés pour le suivi de l'histoire, je recommande fortement l'utilisation d'un mot-clé sur vos histoires. Nous utilisons « l'histoire ». L'utilisation d'un mot-clé permet la flexibilité de suivre facilement des histoires contre les insectes dans les arbres de produits. Je recommande également l'utilisation du temps de suivi dans l'installation Bugzilla; même si le temps n'est suivi sur les histoires.