Mein Entwicklungsteam ist nur um 100% gewachsen (von 1 Entwickler auf 2). Meine neue Kohorte möchte in Bug-Tracking-Software investieren. Gibt es Vorteile einer solchen Software für ein so kleines Team?

Ich denke, dass alle "Ja" -Antworten einen großen Beitrag zur Unterstützung der Idee leisten. Aber ich werde die Idee verwerfen, dass die Entscheidung auf ein paar Fragen basiert:

• Wie möchten Sie als Team kommunizieren? Mit 2 Entwicklern sind Sie jetzt ein Team. Wie möchten Sie kommunizieren? Viele agile Teams leben mit persönlichen Diskussionen und Whiteboard-Skizzen. Sie können aber auch so weit gehen, Dinge aufzuschreiben, insbesondere wenn es sich um einen Fehler handelt, der eine Weile nicht mehr ganz oben auf der Prioritätenliste steht.
• Wie möchten Sie mit Ihren Kunden kommunizieren? Ich kenne die Antwort darauf nicht, aber wenn Sie einen Grund haben, Fehler zu veröffentlichen (oder behobene Fehler in einem Versions-Release-Dokument), werden Sie sie irgendwann aufschreiben. Könnte auch ein stressfreies Bug-Management-System auswählen und damit fertig sein.
• Hat es einen Wert, die Geschichte zu bewahren? Die Antwort lautet möglicherweise "derzeit nicht", aber wenn Sie der Meinung sind, dass Sie in Zukunft die Tendenz von Fehlern sehen möchten, damit Sie Orte sehen können, an denen Benutzer die meisten Probleme haben, oder Orte, an denen Sie einige Zeit mit der Überprüfung verbringen könnten und Überprüfung vor einer Hauptversion - dann erhalten Sie ein Bug-Tracking-System. Die Sache mit der Geschichte ist, dass der Tag, an dem Sie die Aufzeichnung wünschen, nicht der Tag ist, an dem Sie beginnen sollten, Aufzeichnungen zu führen.

IMO, die Antworten auf diese Fragen beziehen sich mehr darauf, wo Sie das Produkt sehen und wie Sie Ihr Team erweitern möchten, und weniger darauf, ob "2 Personen = Grund für das Fehlerverfolgungssystem". Die größere Frage ist wahrscheinlich: "Lohnt sich die Konfiguration und Verwaltung eines Fehlerverfolgungssystems und die Anschaffungskosten?"

1, aber nur wenn es schmerzlos ist. GitHub hat zum Beispiel einen sehr einfachen und benutzerfreundlichen Issue-Tracker mit mehr als genug Funktionen für ein kleines Team. Bugzilla, Trac oder andere sind gut, aber alle erfordern Hardware, Installation und Konfiguration, bevor sie verwendet werden, und die Wartung ist definitiv ein Aufwand, der nicht bei Null liegt.

Wir hatten ein winziges Team, als ich zum ersten Mal Bug-Tracking-Software einsetzte, und ich war erstaunt darüber, wie viele Dinge wir gedacht hatten, wir müssten sie irgendwie reparieren, damit sie nicht behoben wurden. Es lohnt sich auf jeden Fall, egal wie groß Ihr Team ist.

Ja. Tausendmal ja.

Denken Sie nicht einmal an Bug-Tracking, sondern an Ticket-Tracking.

Alle Ihre Aufgaben in Tickets sehen zu können, hat einen enormen Vorteil. Sie können den Verlauf einer Aufgabe an einem Ort aufbewahren. Sie wissen, wer wann daran gearbeitet hat. Sie können genau sagen, was an welchem ​​Tag für eine Aufgabe erledigt wurde.

Bei der Fehlerverfolgung können Sie alle Ihre Fehler an einer Stelle platzieren und verfolgen, welche abgeschlossen wurden und welche noch in Bearbeitung sind.

Es hilft Ihnen nur, die Dinge so viel besser zu verwalten.

Es lohnt sich mit einem Team von einem oder mehreren.

Seien Sie ehrlich, ob Sie eine formelle Softwarelösung kaufen oder nicht, Sie werden ein System zur Fehler- / Funktionsverfolgung haben. Es kann sich in einem Notizblock befinden, es kann sich um Haftnotizen handeln, es kann sich um einen Kommentarblock am oberen Rand Ihres Codes handeln. Wenn Sie sich jedoch nicht zufällig weiterentwickeln, werden Sie Ihre Aufgabenlisten irgendwo aufschreiben. Verwenden Sie ein besser organisiertes System, das mit Ihrem Team mitwachsen kann.

Ebenfalls eine Überlegung wert: Viele der Bug-Tracker können von sehr kleinen Teams kostenlos verwendet werden (1-2). Es ist also nicht so, als würden Sie große Kosten für diesen Vorteil aufwenden.

Sie benötigen keine Fehlerverfolgungssoftware, solange Sie nicht alle Mitglieder des Teams sind

• Hat ein perfektes fotografisches Gedächtnis und
• Kann ihre Gedanken mit jedem anderen Teammitglied synchronisieren.

Die kurze Antwort lautet ja.

Einige Gründe warum:

1. Protokollierung von Fehlern, die bei bestimmten Versionen festgestellt wurden.
2. Fähigkeit zu wissen, welche (bekannten) Fehler noch nicht behoben wurden.
3. Verfolgen Sie, wer einen Fehler behoben hat, der seitdem wieder gefunden wurde.
4. Entwicklerfluktuation - ermöglicht Wissenstransfer, auch wenn Sie vom sprichwörtlichen Bus getroffen werden.

Sie werden sich wahrscheinlich etwas ansehen wollen, dessen Einrichtung / Verwaltung nicht viel Zeit in Anspruch nimmt. Ich würde auch vorschlagen, nach etwas zu suchen, das diese Fähigkeit enthält, es mit Ihrer Quellcodeverwaltung zu integrieren.

Diese Antwort fügt der JA- Seite des Arguments Gewicht hinzu .

Ich bin meistens ein Team von einem. Ich benutze ausgiebig Issue Tracking (Redmine) zusammen mit der SVN-Integration.

Es ist wirklich großartig und ich würde ohne es verrückt werden; Meine Qualität würde sinken, weil ich Dinge vergessen und den Überblick darüber verlieren würde, woran ich arbeiten muss.

Produktivitätswerkzeuge:

• Anständige IDE
• Fehlersuche
• Quellcodeverwaltung

Fehlersuche; Verlasse das Haus nicht ohne es

Wenn Sie weniger als 3 haben, kommen Sie wahrscheinlich mit einer Google Docs-Tabelle zurecht, denke ich. Aber tatsächlich sind die Kosten für die Installation von Bugzilla oder Ähnlichem so gering wie die Kosten für einen Programmierer, dass Sie besser dran sind, es einfach zu tun. (Plus, wenn Sie auf 7 wachsen, wird es schon da sein)

Selbst ein Team kann von einer Art Bug-Tracker profitieren, sei es eine Textdatei mit Notizen oder eine vollständige Software. Für 2 Entwickler würde ich nur empfehlen, Zeit in die Einrichtung eines Bug-Tracking-Systems zu investieren, nicht in Geld. Je nach Projekt kommen Sie gut damit zurecht, Fehler auf Papier zu schreiben, eine Liste über ein freigegebenes Online-Dokument zu führen oder kostenlose Fehlerverfolgungssoftware wie Trac oder Bugzilla zu verwenden. Fogbugz ist auch als kostenlose Testversion für 45 Tage erhältlich.

Ja.

Sie müssen sie einigermaßen nachverfolgen!

Das Problem ist, wie viele Fehler Sie haben, anstatt wie viele Entwickler. Sie können mit einem Excel-Arbeitsblatt umgehen, wenn Sie mit ein paar Fehlern zu tun haben, aber selbst dann ist es nicht das Beste.

Es gibt definitiv Vorteile - ich benutze Bug-Tracking-Software auch für persönliche Projekte. Es ist nicht nur zum Verfolgen von Fehlern nützlich, sondern auch zum Verfolgen von Aufgaben und Funktionsanforderungen.

Ich habe überall Bugs benutzt, wenn ich alleine gearbeitet habe. Es funktioniert mit Ihrem DVCS, indem es Fehlerinformationen zusammen mit Ihrer Quelle speichert. Sehr geringer Overhead, da kein zentraler Server erforderlich ist. Der Nachteil ist, dass Sie vorsichtig sein müssen, in welche Zweige Sie neue Fehler eintragen, um sicherzustellen, dass sie sich rechtzeitig verbreiten. Es ist jedoch möglicherweise nicht so wichtig, ob Sie hauptsächlich Ihre eigenen Fehler verfolgen möchten und was in Ihrer letzten Aktion behoben wurde als den Status eines Teams als Ganzes zu verfolgen.

Beginnen Sie einfach mit einem

Wenn Sie gerade erst damit anfangen, werden Sie feststellen, wie praktisch die Versionskontrollsoftware oder die verteilte Versionskontrolle ist.

Entwicklungsreife

Es spielt keine Rolle, ob Sie ein Team von 100 oder 1 haben. Ich habe angefangen, Bug-Tracking und verteilte Versionskontrolle (was aufgrund lokaler Commits sehr sinnvoll ist) nur für mich und mich selbst zu verwenden, und ich habe mich bereits auf einer anderen Ebene gefühlt, aber nicht nur das, ich könnte meine Arbeit auf einer anderen Ebene verwalten ... auf einer Ebene, die sich skalieren lässt, ohne dass ich mehr Mühe investiere.

Wenn Sie einen Tracker verwenden, können Sie Probleme antizipieren und die Arbeit priorisieren. Bug- / Issue-Tracker sind nicht nur für Bugs / Issues gedacht, sondern eher für die Projektverwaltung, und jedes Projekt sollte dies haben .

Für mich geht es nicht nur um die Software, sondern auch um den Prozess, der damit umgeht. In meiner täglichen Arbeit als Test Manager lebe ich im Grunde genommen in einer und es bietet die folgenden Vorteile:

Ich finde, das funktioniert sehr gut mit 2+ Testern und 3+ Entwicklern.

Management der Bemühungen zur Fehlerbehebung für Entwickler

Wir verwalten aktiv eine Entwickler- "Fehlerwarteschlange", um zu steuern, wie viel Arbeit sie ihnen zugewiesen haben, und um sicherzustellen, dass wir eine Level-Zuordnung der Fehlerbehebungsarbeit im gesamten Team haben.

Entscheiden, was repariert und was nicht

Das Durchsuchen neuer Fehler in einem täglichen Prozess ist eine großartige Möglichkeit, sich auf das zu konzentrieren, was Sie tun und was nicht, und wann Sie es beheben. Schon früh in einem Projekt möchten Sie alles reparieren. Am Ende möchten Sie nur Show-Stopper reparieren, und das Bug-Tracking-Tool ist dafür großartig

Wenn Sie Metriken benötigen

Das Wichtigste für mich ist die Metrik, dh wenn Sie in der Lage sein möchten, Fehler zu suchen und zu beheben, wo sich die fehlerhaften Codebereiche befinden oder wie schnell Tester Fehler finden und erneut testen. Es ist Zeit für ein Bug-Tracking-System.

Ich stimme der allgemeinen Meinung zu, dass ein Teammitglied ausreicht, um einen Bug-Tracker zu benötigen. Ich würde es als obligatorisch kennzeichnen, nachdem Sie einen oder zwei echte Benutzer haben, aber es ist wichtig, lange vor Ihrer ersten Veröffentlichung.

Persönlich mag ich Fossilien sowohl für die Quellcodeverwaltung als auch für die Fehlersuche. Es handelt sich um ein vollständig Low Ceremony-verteiltes SCM, das gut in einen Bug-Tracker und ein Wiki integriert ist. Und es ist eine einfach ausführbare Installation, die weitgehend portabel ist und eine interne Webanwendung als GUI verwendet. Seine Homepage wird eigentlich fast ausschließlich von einer Kopie von Fossilien bedient.

Mit dem eng in die Revisionskontrolle integrierten Tracker können Sie Änderungen problemlos mit Tickets verknüpfen und Ticketaktualisierungen in der gleichen Zeitleistenansicht wie Revisionen (und Wiki-Seitenänderungen) anzeigen.

Ja Ja ja ja! Die Nachverfolgung, Priorisierung und Verwaltung Ihrer Probleme ist der Schlüssel zu einer erfolgreichen Softwareentwicklung. Mit einer Person können Sie (fast) mit einer Tabelle davonkommen und alte Quellbäume zippen. Das Hinzufügen von nur einem Entwickler zu einem Projekt ändert die Dinge dramatisch - plötzlich sind Fehlerverfolgung und Quellcodeverwaltung erforderlich, oder Sie lassen Probleme fallen, überschreiben Funktionen und haben im Allgemeinen eine miserable Zeit davon.

Ich bin überrascht, dass bisher noch niemand FogCreek, die Muttergesellschaft von StackExchange, erwähnt hat - ihre FogBugz-Software ist die beste App zur Problemverfolgung, die ich je verwendet habe. Hohe Geschwindigkeit, geringer Luftwiderstand und erschwinglich, besonders wenn Sie die gehostete Lösung verwenden. Früher hatten sie eine kostenlose, gehostete Testversion, bei der, glaube ich, zwei Benutzerlizenzen frei waren - das ist vielleicht nicht mehr der Fall, aber ich würde empfehlen, sie auszuprobieren.

Hier sind meine 2 Cent.

Für die Fehlersuche verwende ich einfach eine Google-Doc-Tabelle. Ich kann jeden einladen, den ich bearbeiten oder anzeigen möchte. Es ist kostenlos, also keine große Investition. Ich verfolge alle Aufgaben dort, um nur Bugs zu finden.

Ich führe auch SVN auf meinem Webhost aus, was keine zusätzlichen Kosten für das Webhosting verursacht.

Einige Kunden haben die Verwendung von unfuddle oder einer anderen solchen Projektmanagement- / Bug-Tracking-Software verlangt, aber ich würde die oben erwähnten kostenlosen Lösungen vorziehen.

Wenn Sie einen minimalistischen Bug-Tracker haben, würde ich sagen, dass er sogar für ein Team von einem nützlich ist. Auf einer der Projektwebsites meines Freundes, QuokForge , stellen sie im Grunde genommen für jedes Projekt eine Red Mine-Instanz bereit. Red Mine hat meiner Meinung nach einen guten Bug-Tracker (auch wenn er manchmal etwas seltsam ist). Das liegt nämlich daran, dass Sie einen Fehler melden können, indem Sie nur Text in EIN Feld eingeben. Ich habe auch schon einmal FogBugz benutzt . Es ist kostenlos für 2 oder weniger Personen. Und es erlaubt die gleiche Einfachheit, einen Fehler zu melden, indem nur ein Textfeld ausgefüllt wird. (Es bietet auch Grafiken und andere Dinge, die wahnsinnig nützlich sind)

Grundsätzlich sollten Sie das Einreichen von Fehlern nicht zu einem strengen und formalen Prozess machen, bei dem Sie 30 Minuten Zeit benötigen, um einen Fehlerbericht auszufüllen (BugZilla, ich sehe Sie an). Das bedeutet nur, dass die Leute es nicht benutzen werden.

Schließlich ist eine Fehlerliste (auch wenn jeder Fehler ungefähr 50 Zeichen Text enthält) äußerst wertvoll. "Hmm, bevor wir 1.0 veröffentlichen. Ich denke, ich habe den letzten Fehler behoben." Und es ist auch großartig für Manager zu sehen, dass Sie tatsächlich etwas tun :). In einem Team ist es wertvoller, weil Sie nicht beide versuchen, eine Reihe von mentalen Aufgabenlisten im Kopf zu behalten. Und es behebt die "Hast du diesen [wirklich schlechten Sicherheitsfehler] behoben? Ähm, ja, ich denke schon. Ok, dann lass uns 1.0 veröffentlichen."

Ich liebe es auch, Features im Auge zu behalten. Dies ist ein bisschen optionaler, aber ich finde immer noch einen Vorteil, wenn ich die mentale Aufgabe, eine Aufgabenliste im Kopf zu haben, nicht mehr erledigen kann.

Sehen Sie auch, was Joel dazu zu sagen hat

Sie haben gerade diese Zahl erreicht ... 2 ! Ich kann zwar die Vorteile der Verwendung von Bug-Tracking-Software erkennen, auch wenn Sie der einzige Entwickler sind. Sie können jedoch ohne diese Software auskommen, wenn die Gesamtzahl der Entwickler 1 beträgt.

Sobald Sie jedoch zwei oder mehr Entwickler haben, gibt es keinen einzigen Grund, keine Fehlerverfolgungssoftware zu haben, nicht einen.

Ja. Und eine Empfehlung ist bitbucket http://www.bitbucket.org. Sie bieten kostenloses Bug-Tracking sowie kostenlose private Repositories in mercurial.

Ein. In diesem Fall handelt es sich eher um eine Aufgabenliste.

Ich nehme an, indem Sie meine Zeit investieren. Es gibt viele kostenlose Bug-Tracking-Systeme, die für ein Zwei-Personen-Team in Ordnung sein sollten. Ich würde nicht in kommerzielle Angebote suchen, bis ich ein größeres Team hatte.

Ich denke, Ihre Frage hat Ihr Missverständnis deutlich gemacht. Es ist nicht das Team, das Bug-Tracking benötigt, sondern das / die Produkt (e).

Muss Bug Tracking in der Software durchgeführt werden? Nun, das würde helfen, meinst du nicht auch?

Es könnte sich nicht lohnen, wenn die folgenden zwei Bedingungen vorliegen:

1. Probleme haben eine kurze Lebensdauer. In diesem Fall reicht es möglicherweise aus, ein einfaches Taskboard zu verwenden (da es aus vielen anderen Gründen sinnvoll ist, den Workflow zu visualisieren). Wenn Sie Probleme jedoch nicht schnell beheben können, z. Wenn Sie Fehler schnell beheben, finden Sie es hilfreich, das Problem zu verfolgen.
2. Codeänderungen werden mit automatisierten Tests als lebende Dokumentation dokumentiert. Das heißt, Bugs und Fixes werden mit fehlgeschlagenen Tests dokumentiert, wenn sie angezeigt werden. Bestehende Tests werden nach dem Fix zu Regressionstests. - Und Funktionsänderungen werden mit automatisierten Abnahmetests dokumentiert (z. B. mit einem BDD-Tool wie FitNesse oder Cucumber). Eine solche Dokumentation sollte auf einem CI-Server wie Jenkins leicht verfügbar sein.

Wenn 1 oder 2 nicht vorhanden ist, profitieren Sie von der Problemverfolgung.

Nein

Verfolge keine Fehler, behebe sie .

Es kommt nicht auf die Größe des Teams an, sondern darauf, wie lange Sie bereit sind, Fehler in einer Liste zu untersuchen, bevor Sie sie beheben.

Wenn Sie Agile / TDD verwenden, ist Ihre Fehlerliste kurz und Fehler bleiben nicht lange auf der Liste. In diesem Fall ist jedes Trackingsystem ausreichend.