Gründe, kein eigenes Bug-Tracking-System aufzubauen [geschlossen]

https://stackoverflow.com/questions/62153

bug-tracking

09-06-2019
|

Frage

Ich wurde nun schon mehrfach mit Plänen eines Teams konfrontiert, das ein eigenes Bug-Tracking-System aufbauen möchte – nicht als Produkt, sondern als internes Tool.

Die Argumente, die ich dafür gehört habe, lauten normalerweise wie folgt:

Wir möchten im Sinne eines intern erstellten Web-Frameworks „unser eigenes Hundefutter essen“.
Sie benötigen einen hochspezialisierten Bericht oder die Möglichkeit, eine Funktion auf vermeintlich einzigartige Weise zu optimieren
Ich glaube, dass es nicht schwierig ist, ein Bug-Tracking-System aufzubauen

Mit welchen Argumenten könnten Sie den Kauf eines bestehenden Bug-Tracking-Systems unterstützen?Welche Funktionen klingen insbesondere einfach, erweisen sich aber als schwierig umzusetzen oder sind schwierig und wichtig, werden aber oft übersehen?

Lösung

Zuerst schauen Sie sich diese Ohloo Metriken:

    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

Was wir aus diesen Zahlen lernen? Wir erfahren, dass noch eine weitere Bug Tracker bauen eine gute Möglichkeit ist es, Ressourcen zu verschwenden!

Hier sind also meine Gründe, Ihr eigenes internen Bug-Tracking-System zu erstellen:

Sie müssen sich für ein oder zwei Jahrzehnten alle bozocoders neutralisieren.
Sie brauchen etwas Geld zu spülen Budgets Reduktion im nächsten Jahr zu vermeiden.

Ansonsten nicht.

Andere Tipps

Ich möchte die Frage umdrehen. Warum in aller Welt würden Sie wollen Ihr eigenes bauen?
Wenn Sie zusätzliche Felder benötigen, gehen Sie mit einem bestehenden Paket, das geändert werden kann.
Sonderbericht? Tippen Sie in die Datenbank und machen es.

Im Glauben, dass es nicht schwierig ist? Versuchen Sie dann. Spec es auf, und sehen Sie die Liste der Funktionen und Stunden wachsen. Dann, nachdem die Liste vollständig ist, versuchen, ein vorhandenes Paket zu finden, die geändert werden können, bevor Sie Ihre eigenen implementieren.

Kurz gesagt, nicht das Rad neu erfinden, wenn ein anderer braucht nur einige Optimierungen zu passen.

Programmierer wie ihr eigenes Ticket-System zu bauen, weil, und verwendet Dutzende von ihnen gesehen zu haben, sie wissen alles über sie. Auf diese Weise können sie in der Komfortzone bleiben.

Es ist wie ein neues Restaurant Check-out: es lohnend sein könnte, aber es birgt das Risiko. Bessere Pizza bestellen wieder.

Es gibt auch eine große Tatsache der Entscheidungsfindung in dort begraben: Es gibt immer zwei Gründe, etwas zu tun: ein guten und die richtigen. Wir machen eine Entscheidung ( „unser eigenes Build“), ist es dann rechtfertigen ( „wir brauchen die volle Kontrolle“). Die meisten Menschen sind nicht einmal bewusst ihre wahre Motivation.

ihre Meinung zu ändern, haben Sie die real Grund angreifen, nicht die Begründung.

Not Here-Syndrom erfunden!

Erstellen Sie Ihre eigenen Bug-Tracker? Warum Sie Ihren eigenen Mail-Client nicht bauen, Projektmanagement-Tool, etc.

Wie Omer van Kloeten sagt anderswo, zahlen jetzt oder später zahlen.

Es gibt eine dritte Option, weder kaufen noch bauen. Es gibt Berge von guten freien da draußen. Zum Beispiel:

Ihre eigenen Bug-Tracker Rollen für jede andere Verwendung als das Lernen ist kein guter Umgang mit der Zeit.

Weitere Links:

Vergleich Issue-Tracking-Systeme

würde ich nur sagen, es ist eine Frage des Geldes ist - ein fertiges Produkt für Sie wissen, ist gut zu kaufen (und manchmal nicht einmal zu kaufen, wenn es kostenlos ist) ist besser, als wenn man auf eigene Faust zu gehen und zu entwickeln. Es ist ein einfaches Spiel von zahlen jetzt gegen zahlen später .

Zuerst gegen die Argumente, die für den Aufbau Ihrer eigenen:

Zu wollen, ‚isst unser eigenes Hundefutter‘ in Bezug auf einig intern eingebauten Web-Framework

Das wirft natürlich die Frage, warum Sie Ihren eigenen Web-Framework aufbauen. Genau wie es dort viele würdigen kostenlos Bug-Tracker sind, gibt es zu viele würdigen Rahmen. Ich frage mich, ob Ihre Entwickler ihre Prioritäten gerade haben? Wer macht die Arbeit, die Ihr Unternehmen tatsächlich Geld macht?

OK, wenn sie einen Rahmen bauen müssen, lassen Sie es für den Bau der eigentlichen Software Ihr Unternehmen nutzt organisch aus dem Prozess entwickeln, Geld zu machen.

Needing einigen hochspezialisierte Bericht, oder die Fähigkeit, einige Features in einige angeblich einzigartigen Art und Weise zu optimieren

Wie andere gesagt haben, eine der vielen feinen Open-Source-Tracker greifen und es zwicken.

Im Glauben, dass es nicht schwierig ist, ein Bug-Tracking-System zu bauen

Nun, schrieb ich die erste Version meiner BugTracker.NET in nur ein paar Wochen, Start ohne vorheriges # Wissen C. Aber jetzt, 6 Jahre und ein paar tausend Stunden später, gibt es noch eine große Liste von rückgängig gemacht Feature-Anfragen, so dass es hängt alles davon ab, was Sie ein Bug-Tracking-System tun wollen. Wie viel E-Mail-Integration, Integration der Quellcodeverwaltung, Berechtigungen, Workflow, Zeiterfassung, Zeitplanschätzung, etc. Ein Bug-Tracker kann eine große, wichtige Anwendung sein.

Welche Argumente könnten Sie ein vorhandenes Bug-Tracking-System zu unterstützen, verwenden zu kaufen?

Sie brauchen nicht viele gute Open-Source-diejenigen buy.Too: Trac , < a href = "http://en.wikipedia.org/wiki/Mantis_Bug_Tracker" rel = "nofollow noreferrer"> Mantis_Bug_Tracker , meine eigene BugTracker.NET, um nur einige zu nennen.

Insbesondere was leicht kennzeichnet klingen, aber entpuppt schwer zu implementieren, oder sind schwierig und wichtig, aber oft übersehen?

Wenn Sie es nur für sich selbst erstellen, dann können Sie eine Menge Abkürzungen nehmen, weil Sie hart Draht Dinge. Wenn Sie es für viele verschiedene Benutzer erstellen, in vielen verschiedenen Szenarien, dann ist es die Unterstützung für Konfigurierbarkeit, die hart ist. Konfigurierbaren Workflow, benutzerdefinierte Felder und Berechtigungen.

Ich denke, zwei Eigenschaften, die ein gut Bug-Tracker muss haben, dass beide FogBugz und BugTracker.NET haben, sind: 1) Integration von ein- und ausgehender E-Mail, so dass das gesamte Gespräch über einen Fehler mit dem Bug lebt und nicht in einem separaten E-Mail-Thread, und 2) ein Dienstprogramm für eine Dreh Screenshot in einen Bug Post mit einem nur ein paar Klicks.

Das Hauptargument für mich wäre der Zeitverlust sein. Ich bezweifle es in weniger als einem Monat oder zwei abgeschlossen werden konnte. Warum die Zeit verbringen, wenn es soooo viele gute Bug-Tracking-Systeme sind verfügbar? Geben Sie mir ein Beispiel für eine Funktion, die Sie zwicken haben und sind nicht ohne weiteres verfügbar.

Ich denke, ein gutes Bug-Tracking-System Ihres Entwicklungsprozess zu reflektieren hat. Ein sehr individueller Entwicklungsprozess ist von Natur aus schlecht für ein Unternehmen / Team. Die meisten agile Praktiken begünstigen Scrum oder diese Art von Dingen, und die meisten Bug-Tracking-Systeme im Einklang mit solchen Vorschlägen und Methoden. Seien Sie nicht zu bürokratisch bekommen darüber.

Ein Bug-Tracking-System kann ein großes Projekt auf Junior-Entwickler zu starten. Es ist ein ziemlich einfaches System, das Sie sie in Ihrem Coding Conventions zu trainieren und so weiter verwenden können. Erste Junior-Entwickler, ein solches System zu bauen, ist relativ billig, und sie können ihre Fehler auf etwas ein Kunde nicht sehen lassen.

Wenn es Junk ist können Sie werfen es einfach weg, aber man kann ihnen ein Gefühl von dort Arbeit gibt schon wichtig für das Unternehmen zu sein, wenn es verwendet wird. Sie können keine Kosten für ein Junior-Entwickler in der Lage, setzen den gesamten Lebenszyklus und alle Möglichkeiten für den Wissenstransfer zu erfahren, dass ein solches Projekt bringen wird.

Wir haben das hier getan. Wir schrieben unsere erste vor über 10 Jahren. Wir bekamen ein Upgrade es dann Web-Dienste zu nutzen, mehr als eine Möglichkeit, die Technologie zu lernen. Der Hauptgrund, warum wir dies ursprünglich tat, war, dass wir ein Bug-Tracking-System, das auch produziert Versionshistorie Berichte und einige andere Funktionen, die wir nicht finden konnten in kommerziellen Produkten.

gesucht

Wir betrachten jetzt Tracking-Bug Systeme wieder und überlegen sich ernsthaft zu Mantis migrieren und mit Mantis Connect zusätzliche benutzerdefinierte Funktionen unserer eigenen hinzuzufügen. Der Aufwand im eigenen System Roll ist einfach zu groß.

Ich denke, wir sollten auch auf FogBugz suchen: -)

Am wichtigsten ist, wo Sie die Fehler für Ihre Bug-Tracker einreichen, bevor es fertig ist?

Aber im Ernst. Die Werkzeuge bereits vorhanden ist, gibt es keine Notwendigkeit, das Rad neu zu erfinden. Ändern Tracking-Tools bestimmte Funktionen hinzuzufügen ist eine Sache (ich habe Trac vor). .. Umschreiben eines ist einfach albern.

Das Wichtigste, was Sie können darauf hinweisen, dass, wenn alles, was sie tun wollen, ein paar spezielle Berichte ist hinzuzufügen, es keinen Grund auf Lösung erfordert. Und außerdem ist der letzte Ort „Ihre Homebrew-Lösung“ Angelegenheiten ist für die internen Tools. Wen kümmert es, was Sie verwenden intern, wenn es die Arbeit erledigt wird immer wie Sie es brauchen?

Als Programmierer auf eine bereits kritische Arbeit (oder am wenigsten wichtig) Aufgabe, sollten Sie sich von nicht zuläßt abweichen versuchen, etwas zu entwickeln, die bereits auf dem Markt (Open Source oder kommerziell) zur Verfügung.

Sie werden nun versuchen, ein Bug-Tracking-System zu erstellen Spur des Bug-Tracking-Systems zu halten, dass Sie Fehler in Ihrer Kernentwicklung nutzen zu verfolgen.

Erstens: 1. Wählen Sie die Plattform, um Ihre Bug System liefe auf (Java, PHP, Windows, Linux etc.) 2. Versuchen Sie Open-Source-Tools zu finden, die zur Verfügung stehen (von Open Source, meine ich sowohl kommerzielle als auch kostenlose Tools) auf der Plattform haben Sie sich 3. Verbringen Sie minimale Zeit, um zu versuchen, um Ihren Bedarf anpassen. Wenn möglich, verschwendet keine Zeit überhaupt im Customizing

Für ein Unternehmen Entwicklungs-Team, wir begannen mit JIRA . Wir wollten einige zusätzliche Berichte, SSO Login usw. JIRA der Lage war, und wir konnten erweitern es mit dem bereits vorhandenen Plugin. Da der Code Teil der bezahlten Unterstützung gegeben wurde, wir nur eine minimale Zeit auf das Schreiben der benutzerdefinierten Plugin für die Anmeldung ausgegeben.

Basierend auf, was andere Leute gesagt haben, anstatt einfach herunterladen eine freie / Open-Source ein. Wie wäre es herunterladen, es dann ganz für Ihre eigenen Bedürfnisse anpassen? Ich weiß, ich habe gezeigt, dass in der Vergangenheit zu tun erforderlich. Ich habe eine Installation von Bugzilla und modifiziert es dann Regressionstests und Test Reporting zu unterstützen (das war vor vielen Jahren).

Setzen Sie das Rad nicht neu erfinden, wenn Sie überzeugt sind Sie eine rundere Rad bauen können.

Ich würde sagen, einer der größten Stolpersteine wäre die Auseinandersetzung mit dem Datenmodell/Workflow.Ich gehe davon aus, dass dies eine Weile dauern wird lang Zeit und beinhalten viele Diskussionen darüber, was unter bestimmten Umständen mit einem Fehler passieren sollte, was wirklich einen Fehler ausmacht usw.Anstatt monatelang hin und her zu streiten, würden die meisten Menschen lernen, wie man es nutzt und das Beste daraus macht, wenn man einfach ein vorgefertigtes System einführt, unabhängig davon, welche Entscheidungen bereits festgelegt sind.Wählen Sie etwas Open Source, und Sie können es später bei Bedarf jederzeit optimieren – das wird es sein viel schneller, als es von Grund auf selbst zu rollen.

An diesem Punkt ohne eine große neue Richtung in der Bug-Tracking / Ticketing, wäre es einfach neu zu erfinden werden, um das Rad. Welche scheint zu sein, was alle anderen denkt, in der Regel.

Ihre Diskussionen werden mit beginnen, was einem Fehler ausmacht, und entwickeln sich in dem, was Workflow anzuwenden und mit einem massiven Argumente am Ende darüber, wie Software-Engineering-Projekte zu verwalten. Wollen Sie das wirklich? :-) Nee, dachte nicht - gehen und kaufen ein

Die meisten Entwickler denken, dass sie einige einzigartige Kräfte haben, die sonst niemand hat und daher können sie ein System schaffen, das in gewisser Weise einzigartig ist.

99% von ihnen sind falsch.

Wie stehen die Chancen, dass Ihre Mitarbeiter des Unternehmens in der 1%?

Ich war auf beiden Seiten dieser Debatte so lassen Sie mich ein wenig zwei hier konfrontiert sein.

Als ich jünger war, schob ich unser eigenes Bug-Tracking-System zu bauen. Ich hervorgehoben nur all die Dinge, die die aus dem Regal Zeug nicht tun konnte, und ich bekam Management für ihn zu gehen. Wer hat sie holen das Team zu führen? Mich! Es würde meine erste Chance sein, ein Team zu führen zu sein und eine Stimme in der alles von Design-Tool für das Personal hat. Ich war begeistert. So würde meine Empfehlung an die Motivationen der Menschen dieses Projekt drängen zu überprüfen sein.

Jetzt, wo ich älter bin und mit der gleichen Frage konfrontiert wieder, ich habe gerade beschlossen, mit FogBugz zu gehen. Es tut 99% von dem, was wir brauchen, und die Kosten sind im Grunde 0. Plus Joel werden Sie persönliche E-Mails senden Sie spezielle fühlen. Und am Ende, ist das nicht das Problem, Ihre Entwickler denken, das wird sie besonders machen?

Jeder Software-Entwickler will ihr eigenes Bug-Tracking-System bauen. Es ist, weil wir können offensichtlich auf verbessern, was bereits da draußen, da wir Domain-Experten sind.

Es ist mit ziemlicher Sicherheit nicht wert, die Kosten (in Bezug auf die Entwickler Stunden). Kaufen Sie einfach JIRA .

Wenn Sie zusätzliche Berichte für Ihr Bug-Tracking-System benötigen, können Sie diese hinzufügen, auch wenn Sie es zu tun haben, durch die zugrunde liegende Datenbank direkt zugreifen.

Die quesion ist, was ist Ihr Unternehmen zahlen Sie zu tun? Ist es, Software zu schreiben, die nur Sie verwenden? Offensichtlich nicht. So ist die einzige Möglichkeit, die Zeit zu rechtfertigen und Kosten ein Bug-Tracking-System zu bauen, wenn es kostet weniger als die Kosten im Zusammenhang mit der Verwendung von sogar ein kostenloses Bug-Tracking-System.

Es kann auch Fälle geben, wo dies sinnvoll ist. Sie benötigen mit einem bestehenden System zu integrieren? (Zeiterfassung, die Einschätzung, Anforderungen, QA, automatisierte Tests)? Haben Sie einige einzigartigen Anforderungen in Ihrem Unternehmen haben im Zusammenhang SOX-Compliance zu sagen, dass bestimmte Datenelemente benötigt, die schwer zu erfassen?

Sind Sie in einer extrem beauracratic Umgebung, die zu erheblicher „Ausfallzeit“ zwischen den Projekten führt?

Wenn die Antwort ja auf diese Art von Fragen - dann mit allen Mitteln der „buy“ vs Build arguement würde Build sagen.

Wenn „einige hochspezialisierte Bericht Needing, oder die Fähigkeit, einige Feature in einigen angeblich einzigartige Art und Weise zu optimieren“, die beste und billigste Weg, dies zu tun ist, um den Entwicklern von bestehenden Bug-Tracking-Systeme zu sprechen. Zahlen sie diese Funktion in ihrer Anwendung zu bringen, machen es auf der Welt zur Verfügung. Anstatt das Rad neu zu erfinden, zahlen nur die Rad-Hersteller in Speichen wie Federn geformt zu setzen.

Ansonsten, wenn versucht, einen Rahmen zu präsentieren, es ist alles gut. So stellen Sie sicher, dass in den entsprechenden Haftungsausschlüssen setzen.

Um die Menschen, die Bug-Tracking-System glauben, sind nicht schwer zu bauen, folgen Sie den Wasserfall streng SDLC. Holen Sie sich alle Anforderungen nach unten vorne. Das wird sie sicherlich dazu beitragen, die Komplexität zu verstehen. Diese sind in der Regel die gleichen Leute, die sagen, dass eine Suchmaschine nicht so schwierig zu bauen. Nur ein Textfeld, eine Schaltfläche „Suche“ und „Auf gut Glück!“ Taste und die „Auf gut Glück!“ Taste kann in der Phase 2 durchgeführt werden.

einige Open-Source-Software verwenden wie . Sicherlich gibt es Fehler, und Sie müssen, was noch nicht da ist oder ein Bug-Fix ansteht. Es passiert die ganze Zeit. :)

Wenn Sie erweitern / anpassen eine Open-Source-Version, dann müssen Sie es beibehalten. Nun ist die Anwendung, die mit Ihnen helfen Testen Geld Anwendungen werden zu einer Belastung zu unterstützen.

ist wohl

Ich denke, der Grund, warum die Menschen ihre eigenen Bug-Tracking-Systeme schreiben (in meiner Erfahrung) sind,

Sie wollen nicht für ein System, sie sehen zahlen als relativ leicht zu bauen.
Programmer Ego
Allgemeine Unzufriedenheit mit der Erfahrung und Lösung von bestehenden Systemen ausgeliefert.
Sie verkaufen es als Produkt:)

Für mich ist der wichtigste Grund, warum Tracker die meisten Fehler gescheitert war, dass sie keine optimale User Experience liefern hat und es kann sehr schmerzhaft sein, die Arbeit mit einem System, das Ihnen eine Menge zu verwenden, wenn es nicht für die Benutzerfreundlichkeit optimiert ist.

Ich denke, der andere Grund ist die gleiche wie, warum fast jeder von uns (Programmierer) ihren eigenen CMS oder CMS-Framework aufgebaut hat irgendwann (schuldig im Sinne der Anklage). Nur weil Sie können!

Ich stimme mit all den Gründen, nicht zu tun. Wir haben versucht, für einige Zeit zu verwenden, was da draußen, und Liquidation eigenen Schreiben sowieso. Warum? Vor allem, weil die meisten von ihnen zu umständlich sind zu engagieren, aber jeder die technischen Menschen. Wir haben sogar versucht, Basislager (das, natürlich, für diese und nicht bestand in dieser Hinsicht nicht ausgeführt).

Wir kamen auch mit einiger einzigartigen Funktionalität, die oben mit unseren Kunden großen gearbeitet: ein „Fehler melden“, um die wir mit einer Zeile Javascript in Code Skript. Es ermöglicht unsere Kunden ein kleines Fenster zu öffnen, notierten Informationen in schnell und legen auf die Datenbank.

Aber es dauerte sicherlich viele Stunden Code; wurde ein großes Haustier-Projekt; eine Menge Wochenende Zeit.

Wenn Sie wollen, check it out: http://www.archerfishonline.com

Würde ein Feedback lieben.

Wir haben das ... ein paar Mal getan. Der einzige Grund, warum wir unsere eigenen gebaut ist, weil es vor fünf Jahren war, und es gab nicht sehr viele gute Alternativen. aber jetzt gibt es jede Menge Alternativen. Die Hauptsache wir gelernt, unser eigenes Instrument beim Aufbau ist, dass Sie viel Zeit arbeiten daran verbringen. Und das ist Zeit, die Sie für Ihre Zeit Abrechnung werden könnten. Es macht viel mehr Sinn, als ein kleines Unternehmen, die monatliche Gebühr zu zahlen, die Sie leicht mit einer oder zwei verrechenbaren Stunden schöpfen können, als die ganze Zeit verbringen Sie Ihre eigenen Rollen. Sicher, Sie werden einige Zugeständnisse machen müssen, aber Sie werden viel besser auf lange Sicht sein.

Was uns betrifft, haben wir beschlossen, unsere Anwendung für andere Entwickler zu machen. Check it out unter http://www.myintervals.com

Da Trac existiert.

Und weil Sie haben neue Mitarbeiter auf Ihre maßgeschneiderte Software zu trainieren, wenn sie wahrscheinlich Erfahrung in anderen Systemen haben werden, die Sie lieber bauen können als wegzuwerfen.

Weil es nicht abrechenbare Zeit oder sogar sehr nützlich, wenn Sie es verkaufen werden.

Es gibt durchaus gute Bug-Tracking-Systeme zur Verfügung, zum Beispiel FogBugz .

arbeitete ich in einem Startup seit mehreren Jahren, wo wir angefangen mit GNATS , ein Open-Source Werkzeug und im wesentlichen unseres eigenes aufwendiges Bug-Tracking-System auf ihn gebaut. Das Argument war, dass wir eine Menge Geld für ein kommerzielles System vermeiden würden, und wir würden ein Bug-Tracking-System genau gepasst, um unsere Bedürfnisse zu bekommen.

Natürlich drehte es viel schwieriger zu sein als erwartet und war eine große Ablenkung für die Entwickler - die mußten auch das Bug-Tracking-System zusätzlich zu unserem Code halten. Dies war einer der Faktoren für den Untergang unseres Unternehmens.

Sie Ihre eigene Software nicht nur schreiben, so dass Sie „Ihr eigenes Hundefutter essen“ können. Sie sind nur mehr Arbeit zu schaffen, wenn Sie wahrscheinlich Software kaufen könnten, die die gleiche Sache tut (und besser) für weniger Zeit und Geld ausgegeben.

Sagen Sie ihnen, das ist toll, das Unternehmen mit dem Speichern etwas Geld für eine Weile tun könnte, und werden gerne die Entwicklungstools beitragen, während Sie auf dieser unbezahlten Sabbatical arbeiten. Wer seinen Jahresurlaub in Anspruch nehmen will, anstatt an dem Projekt zu arbeiten, ist frei, dies zu tun.

Lizenziert unter: CC-BY-SA mit Zuschreibung

Nicht verbunden mit StackOverflow