Vorlage für ein Flussdiagramm zur Bug-Triage

Die Bug-Triage funktioniert am besten als Entscheidungsbaum statt als Swimlane, denn die eigentliche Schwierigkeit liegt in der Reihenfolge der Fragen, nicht darin, wer gerade das Ticket hat. Wir empfehlen folgendes Vorgehen:

1. Listen Sie alle Ergebnisse auf, bei denen eine Meldung enden kann: geschlossen, Duplikat, Informationen erforderlich und jede Prioritätsstufe.
2. Notieren Sie die Fragen, die diese Ergebnisse voneinander trennen, und stellen Sie die günstigste an den Anfang.
3. Machen Sie aus jeder Frage einen Entscheidungsknoten mit beiden Ausgängen, damit keine Meldung ohne Entscheidung endet.
4. Prüfen Sie, ob jeder Pfad ein Ende hat. Ein Baum mit einem offenen Zweig ist der Ort, an dem Bugs verschwinden.
5. Zeichnen Sie das Diagramm in dem Tool, das Ihr Publikum ohnehin nutzt. Eine kostenlose Vorlage nimmt Ihnen den Großteil der Layoutarbeit ab.

Der Schweregrad beschreibt, wie gravierend sich der Bug auswirkt. Die Priorität legt fest, wie bald Sie ihn beheben. Beides wird von unterschiedlichen Personen aus unterschiedlichen Gründen festgelegt, und die Verwechslung der beiden ist der häufigste Fehler in der Triage.

Ein Absturz in einer Funktion, die drei Kunden nutzen, hat einen hohen Schweregrad und niedrige Priorität. Eine kosmetische Verschiebung auf der Checkout-Seite hat einen niedrigen Schweregrad und hohe Priorität. Diese Vorlage stellt beide Fragen getrennt: zuerst nach kritischem Schweregrad, dann nach hoher Auswirkung. Denn ein einzelnes Feld „Wie dringend ist es?“ fasst zwei Entscheidungen zu einer zusammen und erzeugt Diskussionen statt Antworten.

Es sind Prioritätsstufen, und in dieser Vorlage steht jede für eine konkrete Zusage statt für ein Gefühl:

• P1: sofort beheben, außerhalb der Planung. Ein Hotfix, der die laufende Arbeit unterbricht.
• P2: im aktuellen Sprint beheben. Eingeplant, aber ohne Unterbrechung.
• P3: Backlog. Zur Kenntnis genommen, eingeordnet und nicht terminiert.

Der Wert liegt darin, dass jede Stufe benennt, was als Nächstes tatsächlich passiert. Ein Prioritätsschema, in dem P1 und P2 beide „bald“ bedeuten, ist kein Prioritätsschema.

Weil die Bewertung des Schweregrads aufwendig ist und die Prüfung der Reproduzierbarkeit nicht. Wer eine Entwicklerin oder einen Entwickler die Auswirkung eines Fehlers bewerten lässt, den noch niemand reproduziert hat, verschwendet die teuerste Zeit im Prozess auf die unzuverlässigsten Informationen.

Außerdem werden so Duplikate erkannt, bevor sie eingestuft werden. Wenn zwei Personen denselben zugrunde liegenden Fehler unabhängig voneinander bewerten, landet ein Bug schnell gleichzeitig bei P1 und P3.

Sie führen zu Informationen anfordern oder Duplikat verknüpfen, statt geschlossen oder eingestuft zu werden. Das ist ein bewusster Zwischenzustand: Die Meldung wird nicht abgelehnt, sie kommt aber erst in die Prioritätsdiskussion, wenn jemand sie reproduzieren kann.

Die meisten Triage-Prozesse zeichnen diesen Zweig gar nicht ein, und deshalb werden nicht reproduzierbare Meldungen entweder ungerechtfertigt geschlossen oder liegen für immer im Backlog. Wer ihn einzeichnet, muss klären, wer sich bei der meldenden Person zurückmeldet.

Die Bug-Triage entscheidet, was wann behoben wird. Die Incident-Triage stellt den Service sofort wieder her. In der Praxis macht das einen Unterschied:

• Ein Bug kann warten, ein Incident nicht.
• Die Bug-Triage endet in einer Prioritätsstufe, die Incident-Triage in einer Lösung.
• Aus einem Incident entsteht oft hinterher ein Bug, aber nicht umgekehrt.

Es sind getrennte Prozesse, und sie verdienen getrennte Diagramme. IT- und Lizenzadministratoren halten die Incident-Triage meist in einem eigenen Diagramm fest.

Jeder Prüfpunkt im Diagramm sollte eine benannte verantwortliche Stelle haben, und das ist nicht immer dieselbe Person:

• Support oder QA: Gültigkeit und Reproduzierbarkeit, bevor Entwicklungszeit investiert wird.
• Entwicklung: der Schweregrad, weil er eine technische Einschätzung ist.
• Produktmanagement: die Auswirkung, weil sie eine geschäftliche Einschätzung ist.
• Wer die Triage leitet: die Schwellenwerte selbst und die Überprüfung, wie oft P1 vergeben wird.

PowerPoint kann das mit SmartArt und der Shapes gallery, aber die Arbeit ist manuell: Sie platzieren jede Raute selbst, beschriften beide Ausgänge und verbinden die Verbinder neu, sobald sich etwas verschiebt. Bei einem Baum mit vier Prüfpunkten und fünf Endpunkten ist genau das der Grund, warum das Diagramm irgendwann nicht mehr aktualisiert wird.

Schneller geht es mit dem Lucen Flowchart tab: Er rastet Verbinder an den Ankerpunkten der Formen ein und ordnet das Diagramm mit Auto Layout neu an, wenn Sie eine Verzweigung ergänzen. In beiden Fällen bleibt das Ergebnis eine Gruppe nativer PowerPoint-Objekte auf Ihrer Folie.

Der Download ist eine kostenlose .pptx-Datei aus nativen PowerPoint-Formen. Jede Person kann sie öffnen, lesen und bearbeiten, und Sie können sie wie jede andere Präsentation teilen; Empfänger müssen nichts installieren.

Die intelligenten Verbinder, Auto Layout und Lucen AI stammen aus dem Lucen Flowchart Add-in. Es ergänzt das Menüband um einen Lucen Flowchart tab und läuft unter Windows mit PowerPoint 2016 oder neuer sowie mit PowerPoint für Microsoft 365. PowerPoint für das Web, Mac und mobile Geräte werden nicht unterstützt. Anleitungen zur Einrichtung und Fehlerbehebung finden Sie im Lucen Support.