Welche Rolle spielt der traditionelle Issue Tracker bei der Verwendung von Scrum / Kanban-Boards?

Aus meiner Sicht gibt es im Allgemeinen zwei Arten von Projektmanagement-Tools:

1. Traditionelle Issue Tracker wie Fogbugz, JIRA, BugZilla, Trac, Redmine etc.
2. Virtuelle Karten / agile Projektmanagement-Tools wie Pivotal Tracker, GreenHopper, AgileZen, Trello usw.

Sicher, sie überlappen sich auf die eine oder andere Weise, z. B. können Pivotal Tracker-Aufgaben in JIRA importiert werden, GreenHopper selbst wird auf der JIRA-Issue-Basis usw. implementiert, aber ich denke, man kann immer noch den Unterschied in der Ausrichtung zwischen diesen beiden Arten von Tools erkennen.

Der traditionelle Issue Tracker scheint auch in Unternehmen eingesetzt zu werden, die sonst ein agiles Projektmanagement betreiben. Meine Frage ist, warum machen sie das? Ich bin auch der Meinung, dass wir in meinem Unternehmen einen Issue Tracker verwenden sollten, aber wenn ich darüber nachdenke, bin ich mir nicht sicher, warum wir ihn brauchen sollten.

Zum Beispiel scheint die Trello-Entwicklung mithilfe von Trello selbst (siehe diese virtuelle Pinnwand ) verwaltet zu werden, obwohl sie Zugriff auf Fogbugz haben, einen der besten Issue-Tracker auf dem Markt. Vielleicht brauchen wir also keinen herkömmlichen Issue Tracker, wenn wir 100% unserer Arbeit mit einem der agilen PM-Tools auf agile Weise erledigen wollen?

Es gibt (mindestens) drei verschiedene Arten, wie ein Team arbeiten könnte. Wählen Sie diejenige, die für Ihr Team funktioniert.

1. Detail im Vergleich zur übergeordneten Übersicht

Verwenden Sie den Issue Tracker, um die einzelnen Aufgaben zu verfolgen. Verwenden Sie die Pappe, um einen Überblick über die wichtigsten Funktionen zu erhalten und eine Zusammenfassung der Aufgaben im Issue Tracker zu erhalten.

2. Bugs vs. Features

Verwenden Sie den Issue-Tracker, um einzelne Fehler und Kundendienstanfragen zu verfolgen. Verwenden Sie die Karte, um die neuen Funktionen zu verfolgen, die derzeit entwickelt werden.

3. Meilenstein der Softwarebereitstellung im Vergleich zur kontinuierlichen Softwarebereitstellung

Verwenden Sie einen Issue-Tracker, wenn Sie unregelmäßig große Mengen neuer Funktionen bereitstellen (z. B. wenn Sie das Windows-Team sind und alle paar Jahre eine neue Version verfügbar ist). Es ist ideal für einen Entwicklungsprozess, bei dem große, abgeschlossene Projekte gleichzeitig an Kunden geliefert werden (einschließlich Spiele, eingebetteter Software und traditioneller Software, die auf jährlichen oder halbjährlichen Releases basiert).

Verwenden Sie eine Pappe, wenn Sie Kunden kontinuierlich neue Funktionen bereitstellen, wie sie beispielsweise in einem Web-Team entwickelt wurden, das Kunden kontinuierlich oder sehr häufig einen Mehrwert bietet. In diesem Szenario ist Ihr Softwareentwicklungsprozess fast wie ein Fließband und weniger wie ein Projekt mit einem Anfang und einem Ende.

Ich denke, die einfache Antwort ist, dass Sie mit der herkömmlichen Fehlerverfolgungssoftware den Rückstand verwalten können, während Sie mit dem Scrum Board den aktuellen Sprint und die aktuelle Version verfolgen können.

Natürlich ist es möglich, beide Arten von Werkzeugen zu verwenden, aber am Ende müssen Sie einige Kompromisse eingehen.

Vollständige Offenlegung: Ich bin ein wenig voreingenommen, weil ich der GreenHopper-Produktmanager bei Atlassian bin, aber ich bin auch lange Zeit mit der Agile-Entwicklung außerhalb von Atlassian befasst

Nur ein agiles Planungstool oder einen Issue-Tracker zu haben, ist auf jeden Fall sinnvoll. Das Problem ist, dass es suboptimal ist. Meiner Erfahrung nach ist es suboptimal, weil:

• Die Produktplanung erfolgt normalerweise auf der Ebene von Epic und Story in einem Backlog. Agile Planungstools sind hier großartig
• Doch wie das alte Sprichwort sagt, überlebt kein Plan den ersten Kontakt mit dem Feind. In diesem Fall sind Sie nach Ihren ersten Veröffentlichungen dazu verpflichtet , Fehler (und andere Rückmeldungen) zu erhalten, die von der Qualitätssicherung, den Kunden, dem Support usw. protokolliert werden

Nur ein agiles Planungstool zu haben ist großartig, aber wenn Ihr Produkt ausgereift ist und Sie mehr externe Inputs erhalten, wird es immer schwieriger, diese Inputs effektiv zu verwalten. Einige dieser externen Mitwirkenden können einfach nicht in einer Art "verwaltetem Agile-Rückstand" beitragen, sondern möchten lediglich ihr Problem einreichen und weitermachen. Mit einem Issue-Tracker können Sie diese Mitarbeiter einbeziehen und das laufende Geschäft zur Aufrechterhaltung der Produktentwicklung erfolgreich verwalten.

Ich würde sagen, dass Sie beide Werkzeuge benötigen. Sie müssen auch wirklich integriert werden, sonst verbringen Sie die ganze Zeit damit, die beiden synchron zu halten.

Einige Produkte sind für Storys und Aufgaben im Vergleich zu Fehlern etwas optimierter, aber es gibt wirklich keinen großen Unterschied. Jedes gute agile PM-Tool, das hinsichtlich der erzwungenen Struktur oder der erforderlichen Felder nicht zu viel Aufwand verursacht, kann problemlos für die Fehlerverfolgung verwendet werden. Mein aktuelles Projekt verwendet ein einziges Tool für Aufgaben und Fehler und es funktioniert einwandfrei, abgesehen davon, dass das Produkt ein POS ist :)

Wir führen einen Issue-Tracker namens DoneDone ein, der zu Joels Antwort Nr. 3 passt - die traditionellere Rolle eines Bug-Trackers. In der Tat haben wir es entwickelt, weil unsere Beratung in der Vergangenheit in unregelmäßigen Abständen viele Codes (in Form von Websites) liefert.

Wir haben jedoch vor einem Monat einen kleinen Kontakt zu unserer DoneDone-Anwenderbasis aufgenommen, und etliche von ihnen haben ein Front-End angefordert, das Trello und Sprint.ly ähnelt, um ihre kontinuierlicheren Code- / Release-Zyklen zu verbessern. Eine weitere nützliche Erkenntnis war, dass viele dieser Mitarbeiter DoneDone verwenden, bevor ihre Qualitätssicherung beginnt, sodass sie all diese Daten an einem Ort haben möchten, wenn sich ihre Projekte (oder Funktionen) zwischen den Zyklen bewegen.

Meine zwei Cent sind alles Daten mit ein bisschen Workflow. Der Unterschied liegt in der Benutzeroberfläche und in der Art und Weise, in der sich das Team befindet, sowie in der jeweiligen Methodik und / oder Projektphase.

Die Nachverfolgung von Problemen ist kein Projektmanagement, obwohl viele der Tools so konzipiert sind, dass Sie beides tun können, sodass ein System das andere nicht wirklich ersetzt.

Ein Kanban-Board gibt Ihnen einen schönen Überblick über Ihre aktuelle und herausragende Arbeit und lässt Sie auf einen Blick wissen, welche Prioritäten Sie setzen. Ein Issue-Tracker hingegen ermöglicht es Ihnen, Ihre Probleme mit Ihrem Versionskontrollsystem zu verknüpfen und funktioniert besser Als Mittel, um alles zu protokollieren, was sich in Ihrem Kanban-Backlog befinden sollte, aber mit zusätzlichen Details, die Ihr Kanban-Board ansonsten zu einem echten Durcheinander machen würden.

Die Sache ist, dass die beiden Konzepte gut zusammenarbeiten und sich gut unterstützen. Wenn Sie ein System haben, das Ihnen das Beste aus beiden Welten in einer sauberen Anwendung bietet, können die Linien natürlich ein wenig verwischt werden, die Konzepte bleiben jedoch einigermaßen getrennt.

Ich weiß nicht, ob es eine klare Antwort gibt, also berichte ich nur über meine Erfahrungen ...

Seit Jahren war ich auf einer wahren Bug - Tracking - Systeme vollständig verkauft, wie FogBugz, Jira, Trac, etc. Jedoch Vor kurzem nahm ich einen Job , wo wir Agile sind (wirklich agil, nicht nur tun Agile). Wir haben keine langen, historischen Listen mit Fehlern oder nützlichen Gegenständen.

Es gibt einfach keinen Sinn für ein solches Werkzeug. Alles, was wichtig ist, machen wir ziemlich schnell. Irgendetwas, was nicht so wichtig ist?

Es ist ziemlich befreiend, keinen großen Rückstand an Dingen zu haben, von denen wir wissen, dass wir keine Zeit haben, dies zu tun, und gleichzeitig zu wissen, dass wir jeden Tag den besten Wert liefern.