Notre flux de travail de suivi des anomalies est-il si unique?

Question

Nous utilisons actuellement Mantis comme bugtracker, et nous en sommes plutôt fatigués. Les développeurs veulent plus d'intégration SVN, les clients veulent un système plus facile à utiliser. En tant que tel, nous sommes à la recherche d'un nouveau bugtracker et pour le moment nous regardons Redmine. Cependant, dans sa configuration par défaut, il ne correspond pas au flux de travail souhaité, ou du moins pas mieux que Mantis.

Nous avons le flux de travail suivant, et aimerions qu'un correcteur de bug le corresponde.

• Un bug est signalé (souvent par le client), et est considéré comme «nouveau». Ces bugs sont régulièrement revus et reconnus (c'est un bug) ou marqués comme une caractéristique (le client a souvent besoin de payer) et retardés jusqu'à ce que la partie financière ait été élaborée.
• Les bogues sont ensuite attribués et gérés par un développeur
• lorsque vous avez terminé, il est marqué comme « prêt-à-review » (par un autre développeur)
• quand révisaient est marqué comme « revue »
• une fois marqué en tant que «révisé», le développeur d'origine place le nouveau code dans l'environnement de transfert et marque le bogue comme «prêt à être testé» (par le rapporteur de bogues)
• bug-reporter marque le bogue comme «résolu»
• lorsqu'il est placé en production, bug-reporter ferme le bug

Bien sûr, la rétroaction est souvent nécessaire, surtout au cours des premières étapes. Nous cherchons un moyen de distinguer entre qui est requis de passer à l'étape suivante, et à qui le bug est assigné (développeur). Nous voulons aussi que le client le fasse en utilisant un simple gui - en lui demandant de changer le cessionnaire de son propre compte pour le développeur, ou encore plus difficile: une tierce partie (think: agence de design) a trop à demander en utilisant gui. Le GIU devrait leur montrer quoi faire et quelles options il y a - pas les chercher.

Quelqu'un at-il une expérience avec un bugtracker qui fonctionne de cette façon? Notre flux de travail est-il vraiment bête? Comment vous assurez-vous que tout le monde comprend où se trouve le bogue, et qui doit prendre quelle étape?

Answer 1

L'année dernière, nous avons eu le même problème, et nous avons compris que la meilleure solution pour nous était Jira. En ce qui concerne notre flux de travail est plus robuste et plus compliqué que le vôtre.

Answer 2

Nous avons à peu près le même type de flux de travail que nous gérons en utilisant Redmine avec l'intégration de courrier électronique. Le client enregistre directement les bogues dans Redmine. La notification arrive au chef de projet qui décide quel développeur peut travailler sur le bogue. Le développeur ouvre le bogue et le place dans l'état Enquêteur. S'il s'agit d'une fonctionnalité, il y répond en indiquant les raisons et le place dans l'état Répliqué qui est ensuite revu plus tard. Si c'est un bug, alors le développeur commence le développement. Avant cela, il met le bug dans l'état de codage. Une fois le codage terminé, il modifie l'état du bug en tant que Review et les peer reviews se produisent. En cas de réusinage, le développeur passe à l'état Rework. Une fois que tout est en ordre, le développeur passe l'état à Delivered. Le contrôle qualité vérifie le bug et le ferme définitivement en changeant l'état en Closed.

Nous avons défini tout ce flux de travail dans Redmine et nous l'utilisons très efficacement sans aucun problème. L'intégration du courrier électronique facilite le suivi du gestionnaire de projet chaque fois qu'un bogue change d'état. Vous pouvez également créer et enregistrer des rapports personnalisés, ce qui est également une fonctionnalité intéressante.

Answer 3

J'ai utilisé Trac pour un petit projet personnel, et au travail, nous avons utilisé Bugzilla pour cela.

Le flux de travail que vous avez décrit ressemble également à la façon dont Red Hat utilise Bugzilla.

Answer 4

Comme d'autres l'ont dit, Jira est très bon. J'aime particulièrement sa capacité à créer un numéro personnalisé workflow