question agile et fonctionnalité logiciel Tracker [fermé]

Question

Je cherche la « meilleure » fonctionnalité et un logiciel de suivi des défauts agile convivial. À l'heure actuelle, nous utilisons FogBugz, mais ce n'est pas très utile pour les équipes suite à une méthodologie agile pour autant que je peux dire. Il y a de meilleurs outils pour cela, comme Greenhopper pour JIRA. Je l'ai utilisé JIRA, mais je me demande s'il y a d'autres outils mieux.

Answer 1

Je rapporterez mon expérience, en espérant qu'il sera utile.

Nous avons commencé à piloter Scrum en utilisant des cartes sur un mur. Nous avons décidé de passer à un outil, une fois que nous avons commencé de le faire pour de vrai. Nous avons créé notre tracker défaut ( Redmine ) avec l'histoire de l'utilisateur et les tâches, et un moyen de créer un burndown dans chaque projet. Ce que nous avons trouvé, cependant, est que vous ne vraiment pas obtenir la transparence d'un radiateur d'information physique. Les gens marchent par le mur de la carte et peut voir les progrès de l'équipe. Très peu consultez le site Web aussi souvent qu'ils inspectent le mur de la carte. Donc, actuellement, nous faisons le mur de la carte pour le sprint courant et suivre la Sprint Redmine, qui nous donne des informations historiques.

Comme nous l'avons mis à l'échelle jusqu'à plus d'équipes que nous avons l'espace de mur, nous avons réalisé que nous allons avoir besoin d'un outil qui peut fonctionner comme un mur de carte et être un « réel » agile suivi. Nous avons donc examiné plusieurs outils, et notre courte liste Version un , Rallye et Mingle . Chacune de ces produits pourrait être le mieux pour vous, mais en fin de compte, nous avons choisi Mingle pour diverses raisons.

Le souci I d'une chose au sujet de la perte des murs de la carte. Il est difficile d'expliquer la valeur de transformation que ces radiateurs d'information publique ont eu. Les équipes obtiennent beaucoup de visibilité auprès des propriétaires des produits ainsi que la gestion et d'autres parties prenantes. Je crains que la visibilité sera perdue si nous passons à l'aide de l'outil uniquement. Je dois construire des tableaux de bord qui montent sur les écrans montés à parois, agissant comme une version high-tech des murs de la carte. Une chose que nous avons fait était des tableaux blancs PROCURE écran tactile qui permettent aux équipes de standups pour déplacer les cartes virtuelles de manière familière, par glisser-déposer interface murale de la carte de l'outil. J'espère que cela nous permettra de conserver les avantages de la communication et l'interaction équipe que nous avons vu quand réunis autour d'une paroi de la carte.

Quoi qu'il en soit, bonne chance dans votre quête!

Answer 2

Nous utilisons PivotalTracker (http://pivotaltracker.com) dans nos projets. Il est léger et facile à utiliser l'outil. Il travaille dans le nuage, créant ainsi un compte et la mise en place d'un projet est une question de minutes. histoire d'utilisateur et bug entrée est assez facile. L'outil prend en charge un workflow standard des tâches consistant de pas démarré, Démarré, fini, Livré, acceptés et rejetés états.

Je n'ai pas essayé encore FogBugz mais j'utilisé JIRA, Greenhopper et VersionOne avant PivotalTracker. L'inconvénient de tous ces outils contre PivotalTracker est que leur utilisation vous apporte trop de frais généraux. Vous devez installer et les entretenir. Vous devez les configurer. Et parce qu'ils sont plus difficiles à utiliser, ils ont besoin de plus de temps pour un usage quotidien. Je l'ai vu que les développeurs hésitent à utiliser ces outils, car ils créent trop de frictions. OMI PivotalTracker est le meilleur outil à cet égard.

L'inconvénient de PivotalTracker est qu'il ne donne que quelques options de configuration. Il ne vous permet pas de personnaliser les flux de travail. Il ne dispose pas d'options d'autorisation beaucoup d'utilisateurs. Mais dans notre cas, il convient très bien à nos besoins.

Answer 3

Cela pourrait être une non-réponse dans une certaine mesure, mais je l'espère sera toujours instructif et ajouter de la valeur.

Je suis sur plusieurs équipes à l'aide de divers outils, y compris des conseils physiques et Greenhopper. D'autres équipes agiles de mon ministère ont utilisé et évalué diverses autres options. Si vous parlez de trouver la façon la plus efficace de gérer l'équipe dans un sprint (par opposition à la planification de la libération, le toilettage du carnet de commandes, etc.) Je suis venu à la conclusion suivante: Rien ne va être un grand ajustement à moins que vous avez écrit vous-même l'outil ou utilisez un speadsheet. Oui, une feuille de calcul. Il est la solution la plus souple que je suis venu à travers. Nous utilisons une fantaisie avec des graphiques burndown et tels, mais il fonctionne très bien.

Tout outil vous trouvez maintenant qui peut être un ajustement parfait finira finalement par ne pas faire quelque chose que vous voulez. Voici un exemple de ma propre expérience récente:

Nous travaillions pour faire baisser la durée du temps qu'il faut pour faire rapport au cours de l'état des réunions quotidiennes Scrum. Le défi est que les développeurs ont tendance à entrer dans une explication détaillée des problèmes qu'ils ont rencontrés tout en travaillant sur une tâche. Nous essayons de reporter ces discussions qu'après la réunion du point de presse. Il était difficile de le faire jusqu'à ce que nous avons commencé tout simplement mettre en évidence tous les éléments dans la feuille de calcul, nous devons en discuter davantage. Ce laissez-nous passer à la réunion, mais pas le suivi lose des questions qui doivent être discutées. Il était très facile d'introduire cela dans notre processus précisément parce que nous utilisions un outil flexible comme une feuille de calcul. L'outil ne se distingue pas de la manière d'améliorer notre processus.

Comme pour défaut virement de bord, la plupart des équipes dans mon utilisation du département JIRA.