Ticketsysteme wie beispielsweise Redmine werden in der Softwareentwicklung vor allem als Bug-Tracking System eingesetzt, oder um Kundenanfrage zu bearbeiten. Dabei kann ein Ticketsystem mehr als Fehlermeldungen oder Störungen erfassen und einem Bearbeiter zuordnen. Vor allem in der Entwicklung von Projekten dient es dazu für einen reibungsloseren Ablauf der Aufgabenabwicklung zu sorgen. Sowie den Teammitgliedern und Stakeholdern eine bessere Übersicht, mehr Transparenz und Struktur zum Projektfortschritt zu verschaffen.
Wer für ein Entwicklungsprojekt eine Funktionsbeschreibung besitzt, sollte generell dazu übergehen die Funktionalität nicht nur in der Anwendungsbeschreibung zu definieren. Sondern den Entwicklern mit Hilfe von aussagekräftigen Tickets geeignete Arbeitspakete zu schnüren, die dann entsprechen abgearbeitet werden können. Nur so stellt man die erste Weiche für eine spätere Akzeptanz der erledigten Arbeiten beim Auftraggeber.
Daten eines aussagekräftigen Tickets
Damit der Ticketbearbeiter ohne weitere Nachfrage (und unnötigen zeitlichen Aufwand) mit dem ihm zugeordneten Ticket etwas anfangen kann, ist es notwendig als Ticketersteller einige Dinge zu beachten. Ein aussagekräftiges Ticket enthält stets folgende Daten:
- eine Ticketnummer (erstellt Redmine beim sichern automatisch)
- Datum der Ticketerstellung (erstellt Redmine beim sichern automatisch)
- Infos zum Ticketersteller (erstellt Redmine beim sichern automatisch)
- Vorgangstyp des Tickets (z. B. Bug, Change Request, Feature, normale Task, Story etc.)
- eine aussagekräftige Bezeichnung
- eine ausführliche Beschreibung zum Vorgang, den der Ticketbearbeiter zu erledigen hat. Evtl. mit Verlinkung auf weiterführende Dokumentation / Wikiseiten etc., oder mit angedachtem Lösungsvorschlag.
- Passende Auswahl zum Bearbeitungsstatus (offen, in Arbeit, zur Abnahme, gelöst etc. - abhängig von der verwendeten Projektmanagementmethode)
- Sinnvolle Prioritätsstufe festlegen
- Ticketbearbeiter zuordnen
- Bevorzugtes Abgabedatum (nur falls absolut notwendig)
- Dateianhänge zum besseren Verständnis (falls notwendig)
- Zuordnung von Beobachtern (falls notwendig)
Der Ticketbearbeiter wiederum ist dann dafür verantwortlich das ihm zugeordnete Ticket entsprechend zu bearbeiten. Dazu gehört:
- den Status zu ändern
- eine Aufwandsschätzung zu betreiben
- den Projektfortschritt zu aktualisieren
- entsprechende Unklarheiten mit dem Ticketersteller zu klären
Tipps zur Ticketbeschreibung
Die Ticketbeschreibung sollte so kurz und prägnant wie möglich sein, damit sie die eigentliche Arbeit nicht lange aufhält, dennoch ausführlich genug, damit der Bearbeiter möglichst wenig nachfragen muss. Wichtige Punkte, die die Beschreibung abdeckt sind etwa:
- was ist zu tun
- was für ein Ergebnis wird erwartet
- wo findet man evtl. weiterführende Informationen um das Ticketziel zu erreichen
Beispiel
So nicht:
Lieber Karsten, bitte schau ab und zu mal auf den Server und mach Updates, falls nötig.
Grund:
- persönliche Ansprache (keine offene Formulierung)
- keine konkreten Infos (Welcher Server? Welches Update?)
- nicht abschließbar (Wann soll es erledigt werden?)
- nicht schätzbar (Keine konkreten Infos, was gemacht werden soll, deshalb schwer schätzbar)
Ziele eines Ticketsystems
Egal zu welchem Zweck ein Ticketsystem eingesetzt wird. Generell erhält man dadurch die Möglichkeit
- eine Übersicht der geleisteten Arbeiten zu erhalten
- den Entwicklungsprozess transparenter zu gestalten
- die Qualität der gelieferten Tätigkeiten zu verbessern
- die Historie des Vorgangs zu sichern
- die Effizienz zu erhöhen
- Ablaufvorgänge zu verbessern
- ein zentrales Kommunkationsmedium für alle Projektbeteiligten zu verwenden
- die Arbeitsleistung des Teams oder einzelner Mitarbeiter besser zu bewerten
Zusammenfassung
Zusammengefasst kann man sagen, dass ein Ticket folgende Eigenschaften erfüllen sollte (vor allem wenn man es als User Story in der agilen Softwareentwicklung verwendet):
- offen formuliert
- so klein gehalten wie möglich aber so ausführlich wie nötig
- schätzbar
- testbar
- abschließbar