Issue Tracking System

Um im Team zu arbeiten bevorzuge ich zwei Werkzeuge: ein Wiki und ein Issue Tracking System, auch Ticketsystem genannt.
Issues, auch Tickets genannt, definieren einzelne Aufgaben, die in einem gesamten Projekt eingebettet sind. So können Issues bestimmten Bearbeitern zugeordnet und die Reihenfolge festgelegt werden. Issues können in Themenbereiche gegliedert oder an Meilensteine angehängt werden.
Ein Issue Tracking System kann man aber nicht nur für IT Projekten nutzen. Aufgaben in einer Gruppe zu strukturieren kann auch am Bau, bei Veranstaltungen oder in der Immobilienwirtschaft sinnvoll sein. Also überall da, wo Aufgaben anfallen, die eine strukturierte und nachvollziehbare Erledigung erfordern.

Und das wichtigste: Issues können und sollen ständig verändert werden. Es kommen neuen Informationen hinzu, werden umpriorisiert oder zusammengefasst. Issues werden von unterschiedlichen Personen gesichtet, geplant, bearbeitet und geprüft. Ein Issue ist ein ständig aktuelles Dokument, das ist der große Vorteil gegenüber e-Mail-Ping-Pong oder chat-chaos.

Thread vs Wiki

In jedem Issue Tracking System gibt es für jedes Issue eine Überschrift, eine Beschreibung, Kommentare und Verknüpfungen (wie Bearbeiter, Labels, Meilensteine, Datum). Die Kommunikation an einem Issue läuft dann häufig wie einem Konversationsthread oder E-Mail-Ping-Pong: Ein erster Beitrag (example.org funktioniert nicht) und viele folgende Kommentare. Gefüllt mit Debug-Ansätzen, mehr Informationen, Korrekturen, Verbesserungen und irgendwo verstreut zwischen drin: die eigentliche Grundursache und die rettende Lösung.
Ich finde es besser die Beschreibung wird als eine Art Wiki genutzt. Und mit Wiki meine ich: Ändern und aktuell halten, als ständiges "State of the Issue". Google SRE nennt so was ein Live Incident State Document.
In den Kommentaren sollte man nur Protokollieren, Aktivitäten mit schreiben oder Personen direkt ansprechen. So take clear notes of what ideas you had, which tests you ran, and the results you saw, aber der Kern des ganzen muss in der Beschreibung stehen.

Struktur

Eine Beschreibung muss klar und eindeutig sein. Die Zielgruppe ist nicht nur der Bugreporter oder der Featurerequester selbst, oder die Person mit der das schon mal vorab besprochen wurde. Jedes andere Teammitglied muss diese Beschreibung verstehen können. Daher ist Fachsprache ok, aber es müssen alle relevanten Information vorhanden sein. Ein klarer Prosatext besser ist als eine frei interpretierbare Stichwortliste. Dieser Prosatext darf sich gern mit links auf die Doku beziehen.

In einem Bugreport muss mehr stehen, als es geht nicht oder ein stummer link auf die Fehlfunktion. Bugreports sind am besten mit der kopierten Fehlermeldung. Bitte macht keine Screenshots von Schrift. Fehlermeldungen sollte man in einem <code>-tag formatieren. Bei langen Fehlermeldungen sollte man die nur relevante Textstelle kopieren, die für den Fehler verantwortlich ist. Zusätzlich kann man die gesamte Fehlermeldung zu Dokumentationszwecken in die Kommentare dumpen. Fehler auf der Benutzeroberfläche stellt man am besten mit Screenshots oder, im Reallive, mit Bildern dar. Es gilt: Errmsg/Pics or It Didn't Happen!
Und man sollte genau benennen wo der Fehler aufgetreten ist. Welche Entwicklungsumgebung, welcher Service, welche Anwendung, welche URL, das genutzte Gerät, die Browserversion, das Bauteil, Adresse, Raumnummer, Stockwerk, Koordinate etc.
Und was sind die Auswirkungen, welche Personenkreise sind betroffen. Liegt eine Serviceunterbrechung vor?

Bei Featurerequest bitte eine saubere User Story und nicht nur ein "Zöglfrex anschalten". Geht es um die Features in der Benutzeroberfläche, gern mit Mockups. Die kann man gern mit dem zittrigen Mauszeiger in Paint machen, aber sie sollten genau das hervorheben was wichtig ist. (z.B. Position des Features, Ausrichtung an welchen Kanten, etc.)

Der Rest der Beschreibung kann gern in Absätze strukturiert sein. Das kann z.B. sein:

Status
liegt eine Issue lange unbearbeitet rum, sollte in einem Abschnitt Status die aktuellen Situation stehen (z. B. Warte, dass Alice ein Foobar kauft). Das hilft Anderen die auf dieses Issue warten und manchmal einem selbst, wenn man nach langer Zeit mit dem Issue wieder weiter macht. (Ich hab das für GitLab als geflaggten comment vorgeschlagen.)
Debug-Trail
Bei Bugs ist die meiste Arbeit den Fehler erst mal zu finden. Wenn das restliche Team weiß, was bereits mit welchem Ergebnis untersucht worden ist, kommt Hilfe schneller an oder die Übergabe klappt viel schneller, als wenn jeder die gleichen Fehlerquellen wieder abklappert.
mögliche Lösungswege
meistens gibt es mehrere mögliche Lösungen für ein Feature oder ein Problem. Welche davon die richtige Lösungen ist, stellt sich erst heraus wenn man beginnt alle möglichen Lösungen zu diskutieren oder, noch besser, auszuprobieren. In einem schriftlichen Brainstorming findet man durch Ausschluss der anderen Lösungen die richtige. Das kann man in Kommentaren machen, aber auch in einem JourFix oder zwischen einzelnen Teammitgliedern besprochen werden.
implementierte Lösung
Nachdem sich auf die bestmöglichen Lösungen geeinigt hat, sollte man anhand seiner Definition of Done, festhalten wie diese am Ende in die Praxis umgesetzt wurde.
ToDo
einzeln Aufgaben die im Rahmen des issues erledigt werden müssen.


Wann

Soll man für jede Aufgabe ein Issue eröffnen? Im Zweifel? Ja!
Lange Antwort: Man sollte immer ein Issue auf machen, wenn man an Dingen arbeitet, die potentiell wachsen könnten:

  • mehr als 30 Minuten für eine Aufgabe (so sieht man selbst und das Team woran man gerade arbeitet)
  • mindestens eine weitere Person beteiligt ist. So hat jeder alle relevanten Informationen.
  • alles was in Produktion geht oder Kundeneigentum betrifft.
  • große und wachsende Aufgaben muss man in neue Issues aufteilen. So kann jeder mögliche Lösungswege oder größere Debug-Ansatz in einem eigenen Issue behandelt werden.
    Dabei ist es gar nicht so einfach zu entscheiden wann man ein neues issue aufmacht. Das ist sicherlich Geschmacksache. Man sollte sich bei jedem Kommentar kurz überlegen ob das noch mit der Beschreibung zusammenhängt. Denn ist verwirrend wenn issues gekapert werden und die Diskussion sich Kommentar für Kommentar vom eigentlichen Thema entfernt.

Selbst wenn sich herausstellt, dass ein neues Issue keine große Sache ist, es ist einfacher, ein No-Deal-Issue zu schließen, als alle nützlichen Informationen postnatal nach stundenlanger Arbeit zu sammeln, an der mehrere Personen beteiligt waren und keiner genau weiß was wirklich bereits getan wurde.

Workload-Management

Was passiert nach dem eröffnen eines Issues? Alle neuen Issues tauchen in einem gemeinsamen Backlog, einer Übersicht über alle neuen Aufgaben, auf. Das hat für den Anfragenden den Vorteil er muss nicht wissen er zuständig ist, sondern eröffnet das issue oder schreibt an support@example.org. Der große Vorteil an einem Issue Tracking System ist das die Zuständigkeit nicht bei der Eröffnung eines Anliegens fest stehen muss, oft ist es der größte Teil der Arbeit überhaupt rauszufinden was getan werden muss und dann kann man erst zur Lösung jemanden zuordnen. So kann die Zuständigkeit angepasst werden und sich auch während der Bearbeitungsphase ändern.
Ein Team kann nun die Aufgaben, je nach Dringlichkeit, verteilen. Entweder zusammen im Team JourFix. Oder jedes Teammitglied schaut über neue Aufgaben und schnappt sich die für die persönliche Qualifikation, aktuelle Arbeitslast und auch Motivation passensten. Dann muss natürlich jemand drauf achten das keine Aufgaben übrig bleiben, bei guten Teams machen das die Seniorigen, kann aber auch der Chef sein.

Eine erste Aufgabe ist das neue Issue erst mal zu qualifizieren ob die relevantesten Infos da sind. Im Verlauf der Bearbeitung kann das Ticket oder das Issue jeweils den zuständigen Bearbeiter oder die Dringlichkeit wechseln, wobei jede Nachfrage und jede Tätigkeit in den Kommentaren und Änderungen in der Beschreibung dokumentiert werden müssen. Bis es vom Ersteller nach erfolgreicher Definition of Done geschlossen werden kann.

Jedes Ticket soll unterschiedliche Status haben die den Arbeitsfortschritt abilden:

  • Alle neuen Issues tauchen im Backlog, Unassigend oder altdeutsch Arbeitsvorrat auf.
  • Wenn jemand anfängt zu arbeiten, muss ersichtlich sein das daran geabeitet wird und vor allem wer.
  • Alles wo man auf ein anderes Ticket oder noch auf Team externe Tätigkeiten, warten muss. Hier es immer ganz praktisch einen Statusvermerk zu haben, um zu wissen auf wen oder was man wartet.
  • Nach getaner Arbeit landen dies Issues dann zum testen und schliessen in der Spalte Testing.

Ich mag dazu ein Kanban-Board mit diesen vier Status als Spalten. In so einem Kanbanboard sieht man 2-dimensional wo die Arbeitslast des Teams liegt. Wenn es auf das Board passt. Klappt bei einem Softwareentwicklungsteam das sein Sprint so organsiert.
Bei einem 1-Level-Support der Tickets im 3-Minuten-Takt abarbeitet macht das kein Sinn. Da helfen auch machen ganz normale getrennte Listen.

Natürlich kann man jeden Zwischenschritt, wie qualifizierte Anforderung, noch zu Schätzen, fachliche oder technische Tests, etc, auch noch abbilden. Aber das verüberkompliziert das ganz oft. Backlog, Doing, Waiting, Review langt mir meist.

Prioritäten, Termine oder Reihenfolge

Issues im Backlog können keine Prioritäten oder due dates haben, sie können nur eine Reihenfolge haben.
Den welches von 20 Issues mit Priorität 1 soll jemand zuerst umsetzen? Menschen können immer nur eine Sache auf einmal erledigen. Daher kann man immer nur die Reihenfolge festlegen, was zuerst bearbeitet wird.
Auch mit due dates klappt das nicht. Ein due date definiert einen festen Termin, das ist sinnvoll wen man eine Aufgaben genau dann machen muss, weil es sonst zu spät oder zu früh wäre. Haben aber zuviele Aufgaben ein due date, muss man diese nahtlos aneinander ketten. Klassisches Projektmanagement nennt das den kritischen Pfad. Oft ist der zeitliche Aufwand einer Aufgabe schwer zu einzuschätzen. Eine Kette von due dates setzt vorraus dass man vorher genau weiß wie lange etwas dauert. So muss man bei Planänderungen immer den ganzen kritischen Pfad aus due dates anpassen.

Manchmal kann man es nicht vermeiden, eine dringende Aufgabe rein gedrückt zu bekommen (kritischer Fehler, dringende Funktion). Dann sollte man aber ehrlich und die aktuellen Issues, die dann eben nicht getan werden, zurück ins backlog zu legen.

Definition of Done

Wann gilt was als fertig? Das ist wie beim Kochen. Ist man da fertig wenn das Essen fertig ist, angerichtet auf dem Teller liegt oder wenn die Küche wieder sauber ist? Das ist eine Frage der gemeinsame Definition. In der Küche und bei Issues.
Man kann ein Issue nicht einfach zu machen, wenn man denkt es ist fertig. Was fertig ist muss definiert sein. Die Definition of Done legt dazu gemeinsame Bedingungen fest. Das kann beispielsweise sein:

  • Alle vorgenommenen Änderungen müssen dokumentiert werden. In der Softwareentwicklung sind das git commits, aber können auch Verweisen auf andere Systeme sein (z.B. Buchhaltungssoftware, CRM) oder im "echten Leben" mit Bildern.
  • Benutzerdokumentation, am besten im Wiki;)
  • Testergebnisse wie Testprotokolle von Unittest, links auf das fertige Ergebnis oder die schriftliche Bestätigung eines Kunden.
  • Die Person, die das Ticket geöffnet hat, sollte auch diejenige sein, die es schließt. Nur diese Person kann das Endergebnis überprüfen und sicher sein, dass die Arbeit erledigt ist. Hat man ein Issue fertig gestellt, dass man selber eröffnet hat, sollte ein Teamkollege als viertes Auge das Issue prüfen und schließen.

Jedes Team sollte das für sich selber definieren, aber es sollte definiert sein, sonst werden unausgesprochene Erwartungen enttäuscht.

Zugriff

Jedes Informationssystem muss fest legen in welchem Umfang einzelne Benutzer Zugriff auf seine Daten hat. Auch bei Issue Tracking Systemen kommt es auf die Art der Issues an. Grundsätzlich sollten Issue Tracking Systemen möglichst offen sein. Ein Open Source Projekt kann seine Tickets weltöffentlich lassen. Eine Firma kann Auftragsdaten allen Mitarbeiter zugänglich lassen. Aber schützenwerte Daten, vor allem personenbezogene Daten, müssen auf den notwendigen Personenkreis beschränkt werden. Eine Personalabteilung, eine Schule, eine Arztpraxis, kann schon auch mit Tickets arbeiten, aber eingeschränkter. Dann müssen Zugriff auf die Betroffenen (Mitarbeiter, Schülerinnen oder Patientinnen) und dedizierte Bearbeitergruppen eingeschränkt sein.

Beispiel

Ein Beispiel anhand eines Bugs auf einer Website die "nicht geht".

Website funktioniert nicht

Dieser initialen Meldung fügt man weitere qualifizierte Informationen zu.

http://example.org/thispage antwortet "no such service [503]"

Bei einem Fehler sucht man nun nach der Ursache. Das sollte man schriftlich festhalten.

http://example.org/thispage antwortet "no such service [503]"

## debuggen

  • check db: ok:
  • Webserver überprüfen: ok:
  • Überprüfung des Nginx-Proxys! fehlgeschlagen

Wenn man weiß was los ist, sammelt man mögliche Lösungen.

http://example.org/thispage antwortet "no such service [503]"

## debuggen

  • check db: ok:
  • Apache-Webserver überprüfen: ok:
  • Überprüfung des Nginx-Proxys! fehlgeschlagen
  • check config: ok:
  • prüfe Version: 2 Jahre alt!

## mögliche Lösungswege

  • Nginx aktualisieren
  • deaktiviere nginx und apache direkt einbinden

Welche von den möglichen Lösungen umgesetzt werden sollte, bespricht man mit seinem Team, den Kunden oder Vorgesetzten. Was man dann wirklich getan hat, schreibt man mit, so können alle die Lösung nachvollziehen.

http://example.org/thispage antwortet "no such service [503]"

## debuggen

  • check db: ok:
  • Apache-Webserver überprüfen: ok:
  • Überprüfung des Nginx-Proxys! fehlgeschlagen
  • check config: ok:
  • prüfe Version: 2 Jahre alt!

## mögliche Lösungswege

  • Nginx aktualisieren
  • deaktiviere nginx und apache direkt einbinden

## implementierte Lösung

service nginx stop
apt update nginx
service nginx start
curl -I http://example.org
HTTP/1.1 200 OK

Das gleiche gilt ähnlich für features, nur das man anstatt des debuggings eine ausführliche User-Story voranstellt:

Ein Kunde benötigt Aktualisierungen zum Liefertermin seiner Bestellung. Während des Abschlusses der Checkouts geben wir einen Liefertermin an (meistens 3 Tage), aber wenn es zu einer Verzögerung kommt, müssen wir auch den Kunden informieren.

## mögliche Lösungswege

  • Mailalert
  • Benachrichtigung im Shop
  • Kunden anrufen

## implementierte Lösung

Immer die Benachrichtigungen im Shop überprüfen zu müssen ist umständlich. Und Anrufe sind zu teuer. Daher haben wir ein Mailalert implementiert, dies kann man auf http://example.org/alert sehen.

Kultur

Natürlich ersetzt ein Issue-Tracking-System keinen Chat, keinen Anruf und vor allem kein Kaffee mit seinem Team. Issues betreffen nur die Sachebene, aber ein Team ist mehr als eine große Menge von Aufgaben. Wer nur mit Tickets arbeitet, verliert wichtige Gespräche und persönlichen Beziehungen.

Man muss sofort zum Telefon greifen oder ein Termin ausmachen, sobald man den Verdacht hat, dass ein Teammitglied ein Problem oder eine Interpretation missverstanden hat. Dann ist Reden 1000mal besser als 1000mal hin und her schreiben. Aber es es hilft jedem Gespräch, wenn die Fakten vorab schriftlich bekannt sind. Und man sollte neuen Erkenntnisse aus dem Gespräch aufschreiben. Am besten im betreffenden Issue.☻

Werkzeug

Ich habe bisher mit Mantis, flyspray, Redmine und Jira gearbeitet. Mantis, flyspray und Redmine sind recht alt.
Jira gilt als der Marktführer unter den issue-tracking-tools, aber "es hat die Tendenz, die Entwicklungsarbeit zu bürokratisieren und zu verkomplizieren" 1, das führt zu: ifuckinghatejira.
Mein aktueller Favorit ist GitLab Issues. Nicht nur, weil es sehr gut in GitLab Repository und GitLab Wiki integriert ist. GitLab hat alle Funktionen nach dem Stand der Technik: Ein praktikables Kanban-Board, Labels (in Farbe), Abhängigkeiten, ToDo-Listen, Epics, Milestones, Timetracking und sogar fancy Drilldown-Charts für das Managementkaraoke. Aber GitLab ist vor allem schnell und einfach:

Für eingeschränkte Daten habe ich bisher OTRS und Zammad genutzt.

Wunschzettel

Ich habe einige Featurewünsche, die ich gerne in meinem Issue Tracker haben würde:

SimpleMDE
SimpleMDE ist ein Markdown-Editor der die Markdown-Struktur und das Ergebnis anzeigt.
Etherpad
Etherpad ist ein Online-Editor in Echtzeit ermöglichte gleichzeitige Bearbeitungen, wenn viele Leute schnell Infos einpflegen wollen. Denn ein Live Incident State Document can live in a wiki, but should ideally be editable by several people concurrently.
Git basiert
Jedes Issue stellt eine Datei dar, mit Assigne, Tags und Meilenstein in Front Matter, und ein Kanban-Boards aus yaml-Listen. Natürlich alles, was von einem Webfrontend mit drag&drop gesteuert werden kann, aber auch mit einem lokalen Git-Klon. So kann man bequem lokal arbeiten, aber auch Änderungen in der Beschreibung mit Git-Bordmittel nachvollziehen.


  1. Sujeevan Vijayakumaran: DevOps ISBN 978-3-8362-9099-9 S. 67 ↩