Raisons pour ne pas construire votre propre système de suivi des bogues [fermé]

https://stackoverflow.com/questions/62153

bug-tracking

09-06-2019
|

Question

Plusieurs fois maintenant, une équipe qui souhaitait mettre en place son propre système de suivi des bogues m'avait projetée - non pas en tant que produit, mais en tant qu'outil interne.

Les arguments que j'ai entendus dans favous vont généralement dans le sens de:

Vouloir "manger notre propre nourriture pour chiens" en termes de framework web construit en interne
Besoin d'un rapport hautement spécialisé ou de la possibilité de modifier certaines fonctionnalités d'une manière prétendument unique
Estimant qu'il n'est pas difficile de construire un système de suivi des bogues

Quels arguments pourriez-vous utiliser pour vous aider à acheter un système de suivi de bogues existant? En particulier, quelles fonctionnalités semblent simples mais difficiles à mettre en œuvre ou sont difficiles et importantes mais souvent négligées?

La solution

Tout d'abord, examinez ces statistiques Ohloh :

    Trac:  44 KLoC, 10 Person Years,   $577,003
Bugzilla:  54 KLoC, 13 Person Years,   $714,437
 Redmine: 171 KLoC, 44 Person Years, $2,400,723
  Mantis: 182 KLoC, 47 Person Years, $2,562,978

Qu'apprenons-nous de ces chiffres? Nous apprenons que la construction de Yet Another Bug Tracker est un excellent moyen de gaspiller des ressources!

Voici donc mes raisons de créer votre propre système de suivi des bogues interne:

Vous devez neutraliser tous les bozocodeurs pendant une décennie ou deux.
Vous devez utiliser de l'argent pour éviter une réduction de budget l'année prochaine.

Sinon, ne le faites pas.

Autres conseils

Je voudrais inverser la question. POURQUOI sur terre voudriez-vous construire le vôtre?
Si vous avez besoin de champs supplémentaires, choisissez un package existant pouvant être modifié.
Rapport spécial? Puisez dans la base de données et créez-la.

Croire que ce n'est pas difficile? Essayez alors. Spécifiez-le et consultez la liste des fonctionnalités et des heures. Une fois la liste terminée, essayez de trouver un package existant pouvant être modifié avant de mettre en œuvre le vôtre.

En bref, ne réinventez pas la roue quand un autre a juste besoin d’être peaufiné.

Les programmeurs aiment construire leur propre système de ticket car, après en avoir vu et utilisé des dizaines, ils en savent tout. De cette façon, ils peuvent rester dans la zone de confort.

C’est comme regarder un nouveau restaurant: c’est certes gratifiant, mais cela comporte un risque. Mieux vaut commander à nouveau une pizza.

Il y a aussi un fait décisif dans la prise de décision: il y a toujours deux raisons de faire quelque chose: une bonne et une bonne. Nous prenons une décision ("Construisons notre propre"), puis nous la justifions ("nous avons besoin d'un contrôle total"). La plupart des gens ne sont même pas conscients de leur vraie motivation.

Pour changer d'avis, vous devez vous attaquer à la vraie raison, pas à la justification.

Syndrome non inventé ici!

Construisez votre propre traqueur de bogues? Pourquoi ne pas créer votre propre client de messagerie, outil de gestion de projet, etc.

As Omer van Kloeten dit ailleurs, payez maintenant ou payez plus tard.

Il existe une troisième option, ni acheter ni construire. Il y a des tas de bons gratuits là-bas. Par exemple:

Utiliser votre propre système de suivi des bogues pour un usage autre que l’apprentissage n’est pas une bonne utilisation du temps.

Autres liens:

Je dirais simplement que c'est une question d'argent: acheter un produit fini, vous savez que c'est bon pour vous (et parfois même ne pas acheter s'il est gratuit), c'est mieux que de devoir en développer un vous-même. C’est un jeu simple consistant à payer maintenant et à payer plus tard .

Tout d'abord, contre les arguments en faveur de la construction du vôtre:

Vouloir "manger notre propre nourriture pour chiens" en termes de framework web construit en interne

Cela pose bien sûr la question de savoir pourquoi créer votre propre framework Web. Tout comme il existe de nombreux trackers de bogues gratuits et dignes, il existe également de nombreux frameworks valables. Je me demande si vos développeurs ont bien défini leurs priorités? Qui fait le travail qui rapporte de l'argent à votre entreprise?

OK, s’ils doivent créer un cadre, laissez-le évoluer de manière organique à partir du processus de création du logiciel que votre entreprise utilise pour gagner de l’argent.

Besoin d'un rapport hautement spécialisé ou de la possibilité de modifier certaines fonctionnalités d'une manière prétendument unique

Comme d'autres l'ont déjà dit, prenez l'un des nombreux trackers open source et modifiez-le.

Estimant qu'il n'est pas difficile de construire un système de suivi des bogues

Eh bien, j’ai écrit la première version de mon BugTracker.NET en seulement quelques semaines, en commençant par aucune connaissance préalable de C #. Mais maintenant, six ans et quelques milliers d’heures plus tard, il reste encore une longue liste de demandes de fonctionnalités annulées. Tout dépend donc de ce que vous souhaitez qu'un système de suivi des bogues fasse. Intégration du courrier électronique, intégration du contrôle de source, autorisations, flux de travail, suivi du temps, estimation de la planification, etc. Un suivi de bogues peut être une application majeure.

Quels arguments pouvez-vous utiliser pour prendre en charge l'achat d'un système de suivi de bogues existant?

Inutile d'acheter. Trop de bons logiciels libres: Trac , < a href = "http://en.wikipedia.org/wiki/Mantis_Bug_Tracker" rel = "nofollow noreferrer"> Mantis_Bug_Tracker , mon propre BugTracker.NET, pour en nommer quelques-uns.

En particulier, quelles fonctionnalités semblent simples mais difficiles à mettre en œuvre ou sont difficiles et importantes mais souvent négligées?

Si vous ne le créez que pour vous-même, vous pouvez utiliser de nombreux raccourcis, car vous pouvez effectuer des câblages fixes. Si vous le construisez pour un grand nombre d'utilisateurs différents, dans de nombreux scénarios différents, le support de la configurabilité est difficile. Flux de travail configurable, champs personnalisés et autorisations.

Je pense que deux caractéristiques qu'un bon traqueur de bogues doit avoir, sont que FogBugz et BugTracker.NET ont, entre autres, 1) une intégration des e-mails entrants et sortants, de sorte que la conversation entière sur un bogue survit avec le bogue et non dans un fil de messagerie séparé, et 2) un utilitaire permettant de transformer un courrier électronique. capture d'écran dans un post de bogue en quelques clics.

L'argument le plus fondamental pour moi serait la perte de temps. Je doute qu'il puisse être achevé en moins d'un mois ou deux. Pourquoi passer du temps quand il y a tellement de bons systèmes de suivi des bogues disponibles? Donnez-moi un exemple de fonctionnalité que vous devez modifier et qui n'est pas facilement disponible.

Je pense qu'un bon système de suivi des bogues doit refléter votre processus de développement. Un processus de développement très personnalisé est intrinsèquement mauvais pour une entreprise / équipe. La plupart des pratiques agiles favorisent Scrum ou ce genre de choses, et la plupart des systèmes de suivi des bogues sont en ligne avec ces suggestions et méthodes. Ne soyez pas trop bureaucratique à ce sujet.

Un système de suivi des bogues peut être un excellent projet pour démarrer des développeurs juniors. C'est un système assez simple que vous pouvez utiliser pour les former à vos conventions de codage, etc. Amener les développeurs juniors à construire un tel système est relativement peu coûteux et ils peuvent commettre des erreurs sur quelque chose qu'un client ne verra pas.

Si c’est du courrier indésirable, vous pouvez le jeter, mais vous pouvez leur donner l’impression que le travail est déjà important pour l’entreprise, s’il est utilisé. Vous ne pouvez pas imputer un coût à un développeur débutant capable de faire l'expérience du cycle de vie complet et de toutes les opportunités de transfert de connaissances qu'un tel projet apportera.

Nous l'avons fait ici. Nous avons écrit notre premier il y a plus de 10 ans. Nous l'avons ensuite mise à niveau pour utiliser les services Web, davantage comme moyen d'apprendre la technologie. La raison principale pour laquelle nous avons fait cela à l'origine était que nous voulions un système de suivi des bogues qui produise également des rapports sur l'historique des versions et quelques autres fonctionnalités que nous ne pouvions pas trouver dans les produits commerciaux.

Nous examinons à nouveau les systèmes de suivi des bogues et envisageons sérieusement de migrer vers Mantis et d’utiliser Mantis Connect pour ajouter nos propres fonctionnalités personnalisées. Le déploiement de notre propre système est tout simplement trop difficile.

Je suppose que nous devrions également regarder FogBugz: -)

Plus important encore, où allez-vous soumettre les bogues pour votre suivi de bogues avant qu'il ne soit terminé?

Mais sérieusement. Les outils existent déjà, pas besoin de réinventer la roue. Modifier les outils de suivi pour ajouter certaines fonctionnalités spécifiques est une chose ( Trac auparavant). .. la réécriture est juste idiot.

La chose la plus importante que vous puissiez souligner est que si tout ce qu’ils veulent, c’est d’ajouter quelques rapports spécialisés, il n’exige aucune solution de base. Et en outre, le DERNIER endroit "Votre solution homebrew" questions est pour les outils internes. Qui se soucie de ce que vous utilisez en interne si le travail est fait comme vous en avez besoin?

En tant que programmeur travaillant sur une tâche déjà critique (ou moins importante), ne vous laissez pas distraire en essayant de développer quelque chose qui est déjà disponible sur le marché (open source ou commercial).

Vous allez maintenant essayer de créer un système de suivi des bogues pour garder une trace du système de suivi des bogues que vous utilisez pour suivre les bogues dans votre développement principal.

d'abord: 1. Choisissez la plate-forme sur laquelle votre système de bogue fonctionnerait (Java, PHP, Windows, Linux, etc.) 2. Essayez de trouver des outils open source disponibles (par open source, j'entends des outils commerciaux et gratuits) sur la plate-forme que vous avez choisie. 3. Passez un minimum de temps à essayer de personnaliser votre système Si possible, ne perdez pas de temps en personnalisation

Pour une équipe de développement d'entreprise, nous avons commencé à utiliser JIRA . Nous voulions des rapports supplémentaires, un login SSO, etc. JIRA en était capable, et nous pouvions l'étendre en utilisant le plugin déjà disponible. Étant donné que le code faisait partie du support payant, nous avons passé très peu de temps à écrire le plug-in personnalisé pour la connexion.

Construire sur ce que d’autres ont dit, plutôt que de télécharger un logiciel libre / open source. Que diriez-vous de le télécharger, puis de le modifier entièrement pour vos propres besoins? Je sais que je devais le faire par le passé. J'ai installé Bugzilla puis je l'ai modifié pour prendre en charge les tests de régression et les rapports de test (il y a de nombreuses années).

Ne réinventez pas la roue si vous n’êtes pas convaincu de pouvoir construire une roue plus ronde.

Je dirais que l’un des plus gros obstacles est l’agonie sur le modèle de données / le flux de travail. Je prédis que cela prendra longtemps et impliquera de nombreux arguments sur ce qui devrait arriver à un bogue dans certaines circonstances, sur ce qui constitue réellement un bogue, etc. Plutôt que de passer des mois à se disputer, si vous deviez simplement déployer un système prédéfini, la plupart des gens apprendront à l'utiliser et à en tirer le meilleur parti, quelles que soient les décisions prises. Choisissez quelque chose d'open-source, et vous pourrez toujours le modifier plus tard si besoin est - ce sera beaucoup plus rapide que de lancer le vôtre à partir de zéro.

À ce stade, sans une nouvelle direction importante en matière de suivi des bogues / billetterie, il s'agirait simplement de réinventer la roue. Ce qui semble être ce que tout le monde pense, en général.

Vos discussions commenceront par ce qui constitue un bogue, évolueront en un flux de travail à appliquer et aboutiront à un débat massif sur la façon de gérer des projets de génie logiciel. Veux-tu vraiment ça? :-) Nah, ne pensais pas - va en acheter un!

La plupart des développeurs pensent avoir des pouvoirs uniques que personne d'autre n'a et par conséquent, ils peuvent créer un système unique.

99% d'entre eux ont tort.

Quelles sont les chances pour que votre entreprise ait des employés dans le 1%?

J'ai été des deux côtés de ce débat, alors laissez-moi être un peu deux face ici.

Quand j'étais plus jeune, j'ai poussé à construire notre propre système de suivi des bogues. Je viens de souligner toutes les choses que les produits du commerce ne pouvaient pas faire, et j'ai demandé à la direction de le faire. Qui ont-ils choisi pour diriger l'équipe? Moi! Cela allait être ma première chance d’être un chef d’équipe et d’avoir une voix dans tout, de la conception aux outils en passant par le personnel. J'étais ravi. Ma recommandation serait donc de vérifier les motivations des personnes qui font avancer ce projet.

Maintenant que je suis plus vieux et que je suis de nouveau confronté à la même question, je viens de décider d’utiliser FogBugz. Cela représente 99% de ce dont nous avons besoin et les coûts sont essentiellement nuls. De plus, Joel vous enverra des courriels personnels qui vous feront vous sentir spécial. Et au final, n’est-ce pas le problème, vos développeurs pensent que cela les rendra spéciaux?

Chaque développeur de logiciel souhaite créer son propre système de suivi des bogues. C’est parce que nous pouvons évidemment améliorer ce qui existe déjà puisque nous sommes des experts de domaine.

Cela ne vaut certainement pas le coût (en termes d’heures de développement). Il suffit d'acheter JIRA .

Si vous avez besoin de rapports supplémentaires pour votre système de suivi des bogues, vous pouvez les ajouter, même si vous devez le faire en accédant directement à la base de données sous-jacente.

La question est la suivante: pour quoi votre entreprise vous paie-t-elle? Est-ce pour écrire un logiciel que vous seul utiliserez? Évidemment pas. Donc, la seule façon de justifier le temps et l’argent nécessaires pour mettre en place un système de suivi des bogues est si son coût est inférieur aux coûts associés à l’utilisation même d’un système de suivi des bogues gratuit.

Dans certains cas, cela peut avoir un sens. Avez-vous besoin d'intégrer un système existant? (Suivi du temps, estimation, exigences, assurance qualité, tests automatisés)? Votre organisation a-t-elle des exigences uniques en matière de conformité SOX qui nécessitent des éléments de données spécifiques difficiles à capturer?

Êtes-vous dans un environnement extrêmement beauracratique qui entraîne des "temps d'arrêt" significatifs entre projets?

Si la réponse à ces types de questions est affirmative, il est clair que l'option " buy " vs construire argument dirait construire.

Si "vous avez besoin d'un rapport hautement spécialisé ou de la possibilité d'ajuster certaines fonctionnalités d'une manière prétendument unique", le meilleur et le plus économique moyen de le faire est de parler aux développeurs des systèmes de suivi des bogues existants. Payez-les pour intégrer cette fonctionnalité à leur application et la rendre accessible au monde entier. Au lieu de réinventer la roue, il suffit de payer les fabricants de roues pour installer des rayons en forme de ressorts.

Sinon, si vous essayez de présenter un framework, c'est tout bon. Assurez-vous simplement de mettre en place les clauses de non-responsabilité appropriées.

Pour les personnes qui pensent que le système de suivi des bogues n'est pas difficile à construire, suivez strictement les instructions SDLC en cascade. Obtenez toutes les exigences à l'avance. Cela les aidera sûrement à comprendre la complexité. Ce sont généralement les mêmes qui disent qu’un moteur de recherche n’est pas si difficile à construire. Juste une zone de texte, une "recherche" bouton et un "je me sens chanceux" bouton "et je me sens chanceux" bouton peut être fait en phase 2.

Utilisez certains logiciels Open Source tels quels . Bien sûr, il y a des bugs, et vous aurez besoin de ce qui n'y est pas encore ou en attente d'un correctif. Cela arrive tout le temps. :)

Si vous étendez / personnalisez une version open source, vous devez la maintenir. Désormais, l’application censée vous aider à tester les applications permettant de gagner de l’argent deviendra un fardeau à supporter.

Je pense que la raison pour laquelle les gens écrivent leur propre système de suivi des bogues (d'après mon expérience) est,

Ils ne veulent pas payer pour un système qu’ils considèrent comme relativement facile à mettre en place.
Moi égreneur
Insatisfaction générale à l'égard de l'expérience et de la solution apportées par les systèmes existants.
Ils le vendent en tant que produit:

Pour moi, la plupart des raisons pour lesquelles la plupart des suiveurs de bogues ont échoué est qu’ils ne fournissaient pas une expérience utilisateur optimale et qu’il pouvait être très pénible de travailler avec un système utilisant beaucoup de LOT, alors que sa convivialité n’est pas optimisée.

Je pense que l’autre raison est identique à la raison pour laquelle presque chacun d’entre nous (programmeurs) a parfois construit son propre CMS personnalisé ou son propre framework CMS (coupable selon les accusations). Juste parce que vous le pouvez!

Je suis d’accord avec toutes les raisons pour ne PAS. Nous avons essayé pendant un certain temps d’utiliser ce qui se trouvait sur le marché et nous avons fini par écrire le nôtre. Pourquoi? Principalement parce que la plupart d’entre eux sont trop lourds pour engager des personnes autres que les techniciens. Nous avons même essayé le camp de base (qui, bien sûr, n’est pas conçu pour cela et a échoué à cet égard).

Nous avons également mis au point des fonctionnalités uniques qui ont parfaitement fonctionné avec nos clients: un "rapporter un bogue". bouton que nous avons scripté dans le code avec une ligne de javascript. Il permet à nos clients d’ouvrir une petite fenêtre, de saisir rapidement des informations et de les soumettre à la base de données.

Mais, cela a certainement pris plusieurs heures à coder; est devenu un grand projet d'animal de compagnie; beaucoup de temps de week-end.

Si vous souhaitez y accéder: http://www.archerfishonline.com

J'aimerais avoir des commentaires.

Nous avons fait cela ... quelques fois. La seule raison pour laquelle nous avons construit le nôtre, c'est parce que c'était il y a cinq ans et qu'il n'y avait pas beaucoup de bonnes alternatives. mais maintenant, il y a des tonnes d'alternatives. La principale chose que nous ayons apprise en construisant notre propre outil est que vous passerez beaucoup de temps à le travailler. Et il est temps que vous facturiez votre temps. En tant que petite entreprise, il est beaucoup plus logique de payer les frais mensuels que vous pouvez facilement récupérer avec une ou deux heures facturables, plutôt que de passer tout votre temps à rouler vous-même. Bien sûr, vous devrez faire des concessions, mais vous serez beaucoup mieux à long terme.

Pour nous, nous avons décidé de rendre notre application disponible pour les autres développeurs. Consultez-la à l'adresse http://www.myintervals.com

Parce que Trac existe.

Et parce que vous devrez former du nouveau personnel sur votre logiciel sur mesure alors qu'il aura probablement de l'expérience dans d'autres systèmes sur lesquels vous pourrez vous appuyer plutôt que de le jeter.

Parce que ce n'est pas du temps facturable ni même très utile, à moins que vous ne le vendiez.

Il existe d'excellents systèmes de suivi des bogues disponibles, par exemple, FogBugz .

J'ai travaillé dans une start-up pendant plusieurs années, où nous avons démarré avec GNATS , une source ouverte. outil, et essentiellement construit notre propre système élaboré de suivi des bogues sur le dessus. L'argument était que nous éviterions de dépenser beaucoup d'argent sur un système commercial et que nous aurions un système de suivi des bogues parfaitement adapté à nos besoins.

Bien sûr, cela s’est avéré beaucoup plus difficile que prévu et a été une source de distraction majeure pour les développeurs, qui ont également dû maintenir le système de suivi des bogues en plus de notre code. C’est l’un des facteurs qui ont contribué à la disparition de notre entreprise.

N'écrivez pas votre propre logiciel uniquement pour pouvoir "manger votre propre nourriture pour chien". Vous ne faites que créer plus de travail, alors que vous pourriez probablement acheter un logiciel qui fait la même chose (et mieux) avec moins de temps et moins d’argent.

Dites-leur, c'est excellent, la société pourrait économiser de l'argent pendant un certain temps et sera heureuse de contribuer aux outils de développement pendant que vous travaillerez sur ce congé sabbatique non rémunéré. Toute personne souhaitant prendre son congé annuel au lieu de travailler sur le projet est libre de le faire.

Licencié sous: CC-BY-SA avec attribution

Non affilié à StackOverflow