Der Sinn von Issue Tracking Systemen
Wie handhaben Sie es eigentlich wenn ein (Bestands) Kunde sich mit einem Anliegen mailtet? Email, Telefon, vielleicht noch ein Word Dokument und dann alles sauber strukturiert auf dem Fileserver ablegen? Finden Sie diese Informationen nach 3 Wochen wieder? Weiß ihr Kollege davon wenn der Kunde nach einem halben Jahr sich darauf beruft? Wir der Kunde über die Ergebnisse informiert? Wie reagieren Sie wenn der Kunde verzweifelt anmerkt „das habe ich doch schon vor 2 Jahren mit Herrn Schmidt geklärt„? Vergessen Sie auch manchmal ein Kundenanliegen zu bearbeiten weil es in Ihren Spam Mails untergeht?
Issue Tracking Systeme
Natürlich sind Sie nicht der Erste der dieses Problem hat. Für diese alltägliche Anforderung gibt es Issue Tracking Systeme.
Den Definitionsspielraum von Bug oder Fehler (Sprachweise des Kunden, gelegentlich auch Fehler, Finding, Defects etc.) bis hin zu Feature oder neuer Anforderung (Sichtweise des Entwicklers) möchten wir an dieser Stelle keine weitere Beachtung schenken, reden wir politisch korrekt einfach von Issues.
Issue Tracking wird von einer unüberschaubaren Anzahl an kommerziellen und OSS Tools angeboten, gelegentlich in speziellen Ausbaustufen auch als Trouble Ticket System bezeichnet und sogar mit einem eigenen RFC beachtet.
Auf Seiten der OSS Produkte nimmt Bugzilla eine Sonderstellung ein, sehr viele große Projekte bauen darauf. Wir bei doubleSlash haben uns vor vielen Jahren nach einem längerem Auswahlprozess für die kommerzielle Lösung Atlassian Jira entschieden.
Nutzen von Tracking Systeme
Issue Tracking Tools im Allgemeinen und Jira im speziellen erlauben es uns und vor allem auch unseren Kunden:
» Issues zu melden
» Issues zu kommentieren und andere Kommentare einzusehen und sich auf diese zu beziehen
» Issues zu recherchieren (auch fremde)
» für Issues zu voten (Stimmabgabe um die Klärung eines Issues zu gewichten)
» Prioritäten zu verwalten
» Due Dates einzustellen und zu verfolgen
» (Datei) Anhänge einzustellen und zu verwalten
» eine beliebige Anzahl von Projekten zu verwalten
» beliebige Projektreleases und Kategorien zu verwalten
» individuelle Prozesse und Statusworkflows je Projekt zu definieren
» individuelle Berechtigungsstruktur je Projekt zu definieren
» beliebige Filter und Auswertungen zu definieren (z.B. Projektübersichten, Eigene Issues etc.)
» Änderungen in unserem Source Code Repository nachzuvollziehen
» eine Vielzahl an (oftmals freien oder kostenlosen) Zusatzmodulen und Plugins zu nutzen
» offene Datenbankstrukturen zur Anbindung eigener Auswerteprozesse und Metriken
» eine technologisch fortschrittliche (Web) Oberfläche mit Web 2.0 Elementen zu nutzen
» eine individuelle Startseite zu definieren und ei Oberfläche anzupassen
» verschiedene Schnittstellen und Exportformate zu nutzen (XML, XLS, DOC, CSV, RSS, SMTP etc.)
» Benachrichtigungen zu definieren und zu erhalten
Track+ hatten wir vor einigen Jahren in der Tat im Einsatz, allerdings gab es dann auf Seiten des Herstellers offenbar Unklarheiten bzgl. der Lizenz und wir haben uns letztendlich für Jira entschieden. Angeschaut haben wir damals so ziemlich alles und Jira ist in unseren Augen nicht die schlechteste Wahl. Aber eben kostenpflichtig (für den kommerziellen Einsatz), genauso wie Track+ (zumindest damals).
Track+ kennen wir bestens und haben es dann vor ein paar Jahren durch JIRA substituiert. Das Tool hat sich mächtig verbessert und kostet ab 5 User ebenso Bares.
Würden deine Erfahrungen interessieren…
Mein Kommentar hat sich wohl erübrigt: Ich wollte nämlich nach einem empfehlenswerten, aber kostenlosen Tool fragen. Jira ist zweifellos ein sehr gutes Produkt, aber halt auch nicht ganz billig.
Jetzt schaue ich mir mal Track+ näher an….
Herr Schubert schwärmt für JIRA, ich für TRACK+ zu beziehen unter http://www.trackplus.com