Comment recommanderiez-vous de ne pas utiliser une feuille de calcul partagée pour suivre les bugs / problèmes?

Dans notre entreprise, les développeurs souhaitent utiliser un outil de suivi des bogues approprié pour gérer les problèmes dans notre application. La direction insiste cependant sur l'utilisation d'une feuille de calcul partagée (autrement dit un fichier Excel partagé, désormais une feuille de calcul sur une solution de base Web permettant un accès simultané).

Leur argument est que la feuille de calcul leur permet d'avoir une vue plus élevée de l'état du projet car ils peuvent voir combien de bogues sont ouverts en un coup d'œil. Cela leur permet également de voir qui travaille sur chaque bogue et d'obtenir une estimation du temps nécessaire pour les fermer tous (car les développeurs sont tenus de remplir l'estimation du temps du bogue sur lequel ils travaillent).

Comme vous pouvez le comprendre, ce n'est pas vraiment pratique à utiliser pour les développeurs (le logiciel de suivi des bogues a été inventé pour une raison). Alors, comment puis-je préconiser un logiciel de suivi des bogues pour faciliter le travail du développeur?

En prime, quel logiciel recommanderiez-vous qui permettrait à la direction d'obtenir ses retours (nombre de bogues ouverts, qui y travaille, estimation du temps) avec une vue de haut niveau?

Alors, comment puis-je préconiser un logiciel de suivi des bogues pour faciliter le travail du développeur?

Compte tenu de cette déclaration:

la feuille de calcul leur permet d'avoir une vue plus élevée de l'état du projet car ils peuvent voir combien de bogues sont ouverts en un coup d'œil.

vous devez vous pencher sur des systèmes dotés d'outils de reporting qui permettent efficacement la création de feuilles de calcul en "temps réel" (ou aussi près que possible). Lorsque vous en trouvez un, expliquez que le fait que les développeurs utilisent un système «approprié» signifie que les données qui les intéressent seront (espérons-le) plus précises et à jour (par exemple).

Quelle version de la feuille de calcul est à jour? Qui a cette feuille de calcul?

Tout bugtracker décent fera ce qu'une feuille de calcul peut, seulement:

• enverra un e-mail aux parties concernées en cas de changement
• fournit une source canonique unique d'informations à jour
• permet des rapports de synthèse, pour donner des vues de haut niveau de l'état du projet

Pour mes projets personnels, j'utilise Mantis (juste parce que c'est très facile à configurer). Le travail utilise Trac avec l'intégration Mercurial.

Mantis fournit des choses comme le nombre de bogues ouverts / fermés / attribués hors de la boîte, et j'imagine que la plupart des dépisteurs de bogues le feraient. Je ne connais pas l'estimation du temps, car je n'ai pas pris la peine de regarder. Trac (ou l'installation ici au travail) a une estimation du temps, et il est facile d'écrire un rapport personnalisé qui, par exemple, additionnera les estimations par étape.

Les réponses de tous les autres sont bonnes. Un autre aspect me vient à l'esprit.

Qu'en est-il de la sécurité autour de la feuille de calcul. La direction ne devrait-elle pas craindre qu'un développeur aléatoire puisse frapper accidentellement les boutons CTRL + A, SUPPRIMER et vraiment gâcher les choses? Un bon système de suivi des bogues ne permettrait pas ce type de corruption de données. Et cela ne tient même pas compte de la malveillance. Et si un développeur particulier voulait plus de crédit et commençait à réaffecter tous les correctifs de défauts à lui-même. Un vrai système aurait une piste de vérification où ce genre de chose serait perceptible. Une feuille de calcul ne le ferait pas.

Vous devez montrer à la direction que ses exigences seront satisfaites.

Leur argument est que la feuille de calcul leur permet d'avoir une vue plus élevée de l'état du projet car ils peuvent voir combien de bogues sont ouverts en un coup d'œil. Cela leur permet également de voir qui travaille sur chaque bogue et d'obtenir une estimation du temps nécessaire pour les fermer tous (car les développeurs sont tenus de remplir l'estimation du temps du bogue sur lequel ils travaillent).

Alors, configurez un système factice et montrez-leur avec des démos qu'ils peuvent obtenir ces informations aussi bien et peut-être même mieux que d'utiliser une feuille de calcul.

Jusqu'à présent, tout le monde a trouvé des réponses similaires et appropriées. Il y a un aspect important qui n'a pas encore été abordé. Afin de suivre les bogues et de vous assurer que rien ne passe à travers les mailles du filet, vous avez besoin de deux choses:

• De bons rapports, à la fois résumés et détaillés - cela peut être recherché plus tard
• Tout le monde a besoin de savoir où se trouve la copie la plus récente.

Dans presque tous les environnements qui préconisent l'utilisation d'une feuille de calcul Excel, il existe différentes copies de cette feuille de calcul sur la machine de chacun - et aucune d'entre elles n'est la même. Cela rend le processus d'examen des progrès extrêmement difficile et contre-productif.

Un serveur centralisé tel que Trac, RedMine, JIRA, Mantis ou tout ce que vous voulez résout ces deux problèmes. À ce stade, il s'agit de savoir ce qui correspond le mieux aux besoins de votre entreprise. Selon votre environnement, ces outils peuvent s'intégrer à votre IDE tout comme votre système de contrôle de version (Eclipse a cette fonctionnalité). Cela facilite considérablement le traitement des bogues attribués.

Je ne connais pas votre environnement, mais pour les utilisateurs de Visual Studio, je suggère fortement TFS. Il intègre à la fois le contrôle des sources et le suivi des problèmes, avec des capacités de rapport complètes. Il offre également des couches d'autorité, un suivi complet de l'historique (c'est-à-dire qui a mis à jour le bogue quand et si configuré, pourquoi), vous permet de faire la différence entre un "bogue" et un "problème" et une "amélioration" et tout ce que vous voulez. comme, et s'intègre complètement avec l'IDE Visual Studio. Il lie un bogue avec le code qui a été archivé, qui peut être lié à des builds spécifiques. Et bien plus encore.

J'ai utilisé beaucoup de systèmes de contrôle de source différents (VSS, SVN, TFS ...) et beaucoup de systèmes de suivi des bogues (systèmes propriétaires personnalisés, Tracker, SharePoint, et oui, même Excel), mais pour mon argent (et c'est un bon morceau de changement), TFS vaut l'investissement en temps et en argent.

Et oui, vous pouvez exporter vers (et importer depuis) ​​Excel.

Pour aider à vendre la transition vers un outil de suivi des problèmes approprié, vous devriez essayer de découvrir quels problèmes la gestion a avec votre système actuel (il y aura forcément un `` ce serait bien si ... '') et voir si vous ne pouviez pas gratter cette démangeaison pour eux.

Lire les arguments de la direction

Leur argument est que la feuille de calcul leur permet d'avoir une vue plus élevée de l'état du projet car ils peuvent voir combien de bogues sont ouverts en un coup d'œil. Cela leur permet également de voir qui travaille sur chaque bogue et d'obtenir une estimation du temps nécessaire pour les fermer tous (car les développeurs sont tenus de remplir l'estimation du temps du bogue sur lequel ils travaillent).

Je suis d'accord avec chacun d'eux et chacun est rencontré par JIRA (je mentionne JIRA uniquement parce que c'est ce que j'utilise, je suis sûr qu'il y a d'autres candidats valables)

Vous devez souligner qu'avec un outil comme JIRA, non seulement ils conserveront tous les avantages de votre configuration actuelle, mais ils bénéficieront également de nombreux nouveaux avantages.

L'heure du conte.

Il y a quelques mois, je suis rentré d'une semaine de vacances pour trouver toute mon entreprise sur le dos. Un projet sur lequel une autre section du département de développement avait travaillé pendant des mois était soudainement devenu une priorité urgente, et toute l'équipe a été retirée de ce sur quoi elle travaillait pour mettre fin à la chose. Lors de la réunion de ce jour-là, le propriétaire de l'entreprise nous a demandé de supprimer quelques pièces ce jour-là et le reste le lendemain et nous serions en bonne forme.

Six semaines plus tard, nous avons finalement livré cette chose, après à peu près des cycles de travail / sommeil sans arrêt.

Notre métrique pour «terminé» était que le client n'avait plus de commentaires. Des choses nouvelles et passionnantes se présenteraient sur chaque version de leurs commentaires (qui nous ont été livrés par e-mail) qui ne s'était jamais présentée auparavant, et chaque mot qu'ils ont dit faisait instantanément partie de la spécification (justifié par la phrase "faisons-le ").

Tard dans la nuit, je venais de paniquer totalement avec la gestion des rapports de bogues par e-mail et des impressions avec des coches. J'ai installé Mantis sur notre serveur de test et y ai chargé le document de commentaires que je venais de recevoir pour ma section. J'ai configuré mon manager en tant qu'utilisateur et je l'ai laissé commencer à en recevoir des e-mails lorsque j'ai fermé les problèmes.

En environ 6 heures, j'ai eu toute l'équipe dessus. Le PM filtrait les e-mails des clients dans Mantis, les développeurs réclamaient et travaillaient des listes de problèmes. Encore mieux, ils ont pu demander des éclaircissements et des communications à l'intérieur du système, ce qui a entraîné une trace papier sans papier des détails sur chaque élément.

Le lendemain, ils m'ont demandé de diriger Tech le reste du projet. C'était un peu comme se faire remettre une grenade en direct, mais je l'ai prise et j'ai couru avec. Deux semaines plus tard, nous avons finalement épuisé la capacité de notre client à tirer notre anneau nasal et à mettre le site en production. Mantis est maintenant la façon dont nous gérons les bogues et pourrait devenir la façon dont nous traitons les demandes de fonctionnalités depuis le début d'un projet.

TL; DR: installez-le vous-même et commencez à l'utiliser pour vos propres trucs. Laissez-le prouver sa valeur par lui-même.

BTW, c'est la même politique que je suis à propos du contrôle de version. Nous utilisons Subversion sous une stratégie de verrouillage requis, car mon gestionnaire ne fait pas confiance à la fusion de fichiers. C'est bien, mais après avoir vérifié un projet SVN, j'en fais immédiatement un dépôt git local pour ma propre utilisation dans le développement.

Nous utilisons Atlassian Jira .

Il a de nombreux rapports disponibles comme celui-ci:

Vous devez créer une feuille de calcul qui, lorsque le gestionnaire l'ouvre, toutes les données de rapport nécessaires sont mises à jour à partir de l'application de votre choix. Si vous le faites fonctionner, il n'y a aucun argument.

choses qui peuvent mal tourner avec une feuille de calcul de suivi des bogues sur un partage réseau:

• personne d'autre ne peut le modifier lorsque quelqu'un le laisse ouvert, puis verrouille le poste de travail et va déjeuner.
  • la solution de contournement "évidente" consiste à enregistrer une nouvelle version pour l'écriture. Cela crée une branche - et Excel ne réussit pas à fusionner. Le travail de quelqu'un sera perdu.
• le document peut être enregistré avec des lignes cachées, un problème est ignoré pendant des semaines.
• tout peut être supprimé et le suivi de l'historique est marginal. "qu'est-il arrivé à l'analyse détaillée des problèmes que j'ai saisie la semaine dernière?"
• il est facile d'ajouter des valeurs aux champs «restreints». "Comment la gravité de ce bogue a-t-elle été marquée" Epic Fail "?"
• couper et coller écrase les formules. Un calcul peut facilement devenir une constante.

J'ai vécu tout ça. Et nous avons quand même réussi à livrer ... Ce n'était que trois mois de retard et a coûté des milliers d'heures supplémentaires imprévues.

"C'est gratuit!" est généralement un très bon argument. Pivotal Tracker est gratuit, ne nécessite aucune installation et pourrait très facilement donner à vos gestionnaires une meilleure vue d'ensemble des choses que ce qui est possible avec une feuille de calcul modeste.

Éditer:

À mon grand désagrément, il vient d'être annoncé que Pivotal Tracker ne sera pas gratuit plus longtemps. :(