Suivi des problèmes simple pour 1-2 développeurs [fermé]

Je travaille actuellement principalement seul sur un projet (en Java). Je suis la plupart du temps seul car j'ai un conseiller qui me donne des instructions de haut niveau sur ce qu'il faut faire et apporte rarement une contribution au code. Elle codera cependant quelques tests d'acceptation de temps en temps.

Je n'avais jamais utilisé de traqueur de problème auparavant, et je pensais commencer à en utiliser un maintenant, car j'aimerais avoir un endroit où je peux enregistrer les éventuels bugs que je trouve et les suivre de manière centralisée. Serait-il possible d'intégrer le suivi des problèmes avec Eclipse, mieux encore.

Alors voici les contraintes:

1. Ce n'est pas un projet open-source. Notre code ne doit être partagé avec personne!
2. nous utilisons et utiliserons Subversion;
3. nous avons notre propre serveur Subversion et nous continuerons à utiliser ce même serveur Subversion;
4. ça doit être gratuit;
5. il doit permettre au moins 2 utilisateurs.

Quel est votre conseil sur quoi choisir? Je cherche la solution la plus simple disponible.

Pour les petits projets, je suis devenu un grand fan de Trello . Il y a une telle barrière à l'entrée et une telle facilité d'utilisation que je l'utiliserais pour des projets de moindre envergure.

Si vous voulez quelque chose d'un peu plus compliqué et complet de fonctionnalités, j'appuierais les suggestions de FogBugz ou de Bugzilla.

Modifier pour fournir plus "explication et contexte":

Le problème le plus courant que j'ai remarqué parmi les petites équipes sans chefs de projet dédiés est que tant de choses ne sont tout simplement pas entrées dans le système . Soit les développeurs ne prennent pas le temps d'entrer tout ce qui doit être fait, soit les problèmes ne sont mis à jour que sporadiquement au fur et à mesure de l'avancement des travaux.

Trello encourage les utilisateurs à tenir le système à jour avec de bonnes données en facilitant la création de nouveaux problèmes et en mettant à jour le statut des problèmes existants.

Plus particulièrement, son système de "listes" à l'intérieur des tableaux peut être facilement et rapidement modifié pour représenter presque tous les systèmes de jalons et de types de problèmes qu'un petit projet souhaiterait utiliser.

Il prend également en charge des outils de suivi des problèmes plus courants tels que les commentaires sur les problèmes, le vote sur les problèmes, la réorganisation, le balisage et l'attribution - mais ils sont tous cachés hors de votre chemin (mais à peu près exactement où vous le souhaitez quand vous en avez besoin).

Bugzilla est un outil de suivi des problèmes complet et complet, mais force est de constater que créer et éditer des bogues coûte cher . FogBugz atténue en grande partie la douleur subconsciente liée au suivi de tout dans votre projet, mais a toujours suffisamment de modifications et d'écrans pour donner l'impression de faire plus de travail que de simplement tirer une carte de "faire" à "terminé" dans Trello.

tl; dr - la meilleure façon de garder un outil de suivi des problèmes pertinent et à jour est de le rendre aussi facile à utiliser que possible , et c'est ce que Trello a été conçu pour accomplir.

"la solution la plus simple disponible" est bien sûr un jugement.

Je trouve FogBugz très facile à utiliser et je peux le recommander pour le cas d'utilisation que vous décrivez. Il est gratuit pour les équipes de deux personnes et très abordable pour les plus grandes, dispose d'un plugin Eclipse et s'intègre à Subversion .

Dans l’intérêt d’une divulgation complète: Mon expérience avec FogBugz s’applique à la version sur site avec le plug-in Visual Studio et l’intégration Perforce et non à la configuration exacte que vous recherchez.

SVN + Trac + Eclipse avec le plugin SVN Team Provider (et Mylyn si vous le souhaitez)

Cela fonctionnera pour les projets personnels et d’équipe simultanés.

À partir d’Eclipse (avec les plugins ci-dessus et le plugin Trac XML-RPC ), vous et votre équipe pourrez:

1. accéder et utiliser le référentiel SVN depuis Eclipse et sans restriction
2. suivre les tickets d'émission via Trac
3. définir des tâches personnelles et d'équipe via Mylyn
4. suivre le temps passé par les membres du projet sur chaque tâche
5. voir tout ce qui précède dans un seul espace de travail dynamique

Vous pouvez utiliser Mantis: http://www.mantisbt.org/index.php

C'est assez simple, et il peut être configuré pour intégrer SVN et Eclipse: http://www.unitz.com/u-notez/2009/10/subversion-svn-integration-mantisbt/ http://stackoverflow.com/ questions / 2939794 / mantis-bug-tracker-api-integration

Cela dit, s’en tenir aux fonctionnalités de base de Trac peut également être très facile à utiliser: http://trac.edgewall.org/

Ma recommandation:

Un fichier nommé bugs.txtdans la racine du référentiel.

Avantages:

• C'est un .txt. Signifie que vous n'êtes pas lié à un système / logiciel particulier

• C'est simple comme bonjour.

• Vous décidez ce qui fonctionne pour vous avec cette méthode - voici un exemple:

filename.ext.class/method: refactor when I get the chance, that regex is really screwed up.

filename2.ext.class/method: got a lovely UI bug with that, doesn't work in Mac Chrome. Screenshot: imgur.com/foobar

• Cross plate-forme. Dès que vous faites un svn checkout <url>bogue, vous avez votre bugtracker - vous pouvez aussi utiliser $ IDE-of-choice -, c'est juste un autre fichier texte.

Désavantages:

• devient difficile après plus de 2-3 développeurs.

• Pas moyen de l'attribuer vraiment à une personne.

• Aucun moyen d'intégrer des images de bugs d'interface utilisateur et autres.

Mon vote est pour Redmine . Il est totalement gratuit et s’intègre bien à Subversion.

application web de gestion de projet. Écrit en utilisant le framework Ruby on Rails, il est multi-plateforme et multi-base de données.

Redmine est une application open source publiée sous les termes de la licence GNU General Public License (GPL) ...

Les principales caractéristiques de Redmine sont:

• Prise en charge de plusieurs projets
• Contrôle d'accès flexible basé sur les rôles
• Système de suivi flexible des problèmes
• Diagramme de Gantt et calendrier
• News, documents et gestion de fichiers
• Flux et notifications par courrier électronique
• Wiki par projet
• Forums par projet
• Suivi du temps
• Champs personnalisés pour les problèmes, les entrées de temps, les projets et les utilisateurs
• Intégration SCM (SVN, CVS, Git, Mercurial, Bazaar et Darcs)
• Création de problème par email
• Prise en charge de plusieurs authentifications LDAP
• Prise en charge de l'auto-inscription de l'utilisateur
• Support multilingue
• Plusieurs bases de données supportées ...

Ce n'est peut-être pas "simple", mais je le considère comme l'un des meilleurs détecteurs de problèmes du secteur: Jira d' Atlassian . Il est livré avec une licence de démarrage de 10 utilisateurs pour 10 dollars australiens ... Je l'utilise en tant que développeur solo. (Veuillez noter que le site semble préférer afficher des licences / prix "à la demande" et vous aurez peut-être besoin de la tarification "de téléchargement").

Un autre avantage considérable de ce tarif préférentiel: les recettes intégrales sont reversées à l' association caritative Room to Read . Vous pouvez donc bénéficier d'un bugtracker complet et vous en sentir bien aussi :-)

Vous pouvez également jeter un coup d'œil à BugZilla . Voir aussi cette comparaison de différents suiveurs de bogues sur les programmeurs SE. Trac est également une bonne alternative à utiliser comme traqueur.

Une autre option est Sourceforge . À ma connaissance, il est gratuit quel que soit le nombre d'utilisateurs. Il comprend un référentiel SVN (que vous n'utiliserez probablement pas) et un suivi. Pour obtenir un exemple de ce suivi, voir cet exemple du projet Audacity (logiciel d’enregistrement open source).

Découvrez ditz .

C'est un outil de suivi des problèmes très simple, piloté par ligne de commande, dont vous pouvez stocker la base de données dans votre référentiel de code.

Il n'y a pas d'interface utilisateur sophistiquée, seulement un simple outil de ligne de commande. Cet esprit est similaire à la suggestion de @ jrg et à l'outil TODO.txt.

Regardez Asana . C'est un outil simple et gratuit de suivi de projet basé sur le Web. Je l'utilise pour des projets et des tâches à la maison. Vous pouvez créer plusieurs projets et leur attribuer des tâches. Pour toute tâche donnée, vous pouvez définir:

• Personne assignée à
• Date d'échéance
• N'importe quel nombre de balises de texte
• Fichiers joints
• Changements
• Notes (un champ de note par tâche)
• Commentaires (n'importe quel nombre par tâche, classés chronologiquement)

Vous pouvez hiérarchiser les éléments avec quelque chose appelé "en-têtes de priorité". Vous pouvez également planifier des éléments comme "aujourd'hui", "à venir" ou "plus tard" pour avoir une idée de base de ce sur quoi il faut travailler au plus tôt.

C'est toujours un travail en cours, mais son interface est très simple et facile à utiliser.

Le système de suivi des bogues le plus simple qui existe consiste en une pile de fiches 3x5 (ou 4x6 si vous avez une grande écriture), une boîte de punaises et votre mur cubique, IMO. Si vous n'avez pas d'équipe distribuée (vous ne le faites pas puisque vous travaillez seul), c'est très bien. Gardez à l'esprit que vous voulez avoir la plus faible impédance possible avec un traqueur de bogues - s'il est difficile d'écrire un bogue ou de noter une idée d'amélioration, vous ne le ferez pas. Quand quelque chose est fait, il sort du mur et va dans une pile faite.

Si cela est accepté, l'intégration avec le point Eclipse échoue, mais pour un développeur solo, en avez-vous vraiment besoin? Si votre conseiller ne corrige pas les bogues, il n'a pas besoin d'accéder aux cartes (ou peut s'arrêter et jeter un coup d'œil). S'ils écrivent des tests d'acceptation, vous pouvez noter l'essentiel de ces tests sur la carte à laquelle elle s'applique.

Je serais intéressé de comprendre ce qui vous pousse à regarder un outil. Avez-vous besoin d'une sorte de métrique de bogue (temps moyen ouvert, total ouvert vs fermé, etc.)? Pourquoi l'intégration dans Eclipse est-elle importante?

Pour un suivi très simple des problèmes, vous pouvez toujours utiliser une feuille de calcul comme Excel ou une base de données MS Access . Ce sont essentiellement des jouets par rapport aux véritables outils de suivi des problèmes, mais ils présentent les avantages d’une courbe d’apprentissage faible et d’une barrière à l’entrée réduite: créez simplement un tableur et ajoutez des colonnes à votre guise!

Excel est pratique pour cela, car vous pouvez trier et filtrer par colonne et générer facilement des graphiques et des graphiques pour suivre les progrès. Voir cet article pour plus d'informations: http://chandoo.org/wp/2009/09/08/issue-trackers/

Un bon modèle de suivi des problèmes MS Access est disponible ici: http://office.microsoft.com/en-us/templates/issue-tracking-database-TC001225348.aspx

YouTrack de JetBrains (la société derrière IntelliJ IDEA et ReSharper) semble très prometteur, bien que mon expérience personnelle en soit encore limitée.

• Il est hébergé dans le cloud et la configuration de votre propre instance est très rapide (peut-être 5 minutes).
• Gratuit pour <= 9 utilisateurs . (En outre, même les plus gros forfaits couvrant 2 000 utilisateurs sont gratuits jusqu'au 29 février 2012)
• Prise en charge de la connexion Open ID (par exemple, à partir de Google)
• A de bons raccourcis clavier

D'après ce que j'ai utilisé jusqu'à présent, YouTrack, au moins, je le préfère de loin à JIRA.

Pour ma petite équipe (surtout moi seul), j'ai utilisé CodeTrack . Cela fonctionne vraiment bien pour moi, car il ne nécessite que PHP sur le serveur, pas même une base de données.

Vous pouvez simplement le télécharger, l'extraire sur votre serveur Web et cela fonctionne presque instantanément. De plus, le code est très simple, vous pouvez donc le personnaliser en fonction de vos besoins.

Si vous n'exposez pas d'informations sensibles dans les rapports de bogues et les commentaires, je vous recommande Google Code. Dans le passé, nous avions utilisé sa fonction Issues pour l'un de nos projets avec une équipe de 8 développeurs. C'est vraiment simple, facile et assez bon pour une petite équipe.

Notez que bien que vous ayez besoin de démarrer un projet open source mais que vous n’ayez pas besoin de télécharger votre code sur Google, utilisez la fonction Problèmes. Et bien sûr, n'importe qui peut voir vos bugs s'ils ont accidentellement trouvé votre projet ou si vous partagez le lien de projet avec eux.

Trackie est extrêmement simple mais flexible.

Il s'adresse aux petites équipes techniques ou semi-techniques / semi-créatives ayant besoin de suivre les problèmes de manière simple et unique. Il prend en charge les statuts personnalisés (avec couleurs personnalisées) des problèmes, ainsi que les priorités et les destinataires.

Alors que l'interface utilisateur est déjà très simple et propre, une interface utilisateur simplifiée supplémentaire est présentée aux utilisateurs qui sont ajoutés à un projet en tant que client.

Enfin, il accepte les problèmes par courrier électronique. Non seulement directement, mais également si vous transmettez le problème d'un client à Trackie, toute correspondance avec votre client sera ensuite traitée dans Trackie sans que votre client le sache. Garder tout dans un seul endroit.

C'est gratuit tant qu'il est en beta privée. Au moment de la rédaction de cet article, on ne sait pas si cela restera gratuit.

Disclaimer: Je suis le développeur de ce traqueur de problème. Mais je pense que cette réponse est néanmoins pertinente pour le PO.

basecamp.com - un projet est gratuit, l'interface est très simple et vous pouvez être opérationnel en environ deux minutes sans rien installer

Maintenant remets-toi au travail ;-)