Review unseres Ticket-Workflows

[Rüdiger Kupper]

Wir benutzen unser Trac nun seit etwa einem Jahr mit einem stabilen Ticket-Workflow. Zeit, einmal zu überdenken, ob das Design für uns angemessen ist.

Tickettypen

Ich stelle beispielsweise fest, dass die überwiegende Mehrheit der Tickets vom Typ "Defekt" sind. "Verbesserung", "Aufgabe", und "Wunsch" kommen dagegen nur selten vor. Also sollten wir überdenken

• ob wir die Typen "Verbesserung", "Aufgabe", und "Wunsch" so wirklich brauchen
• ob wir den Typ "Defekt" vielleicht noch in Untertypen spezifizieren können

Schweregrade

Reichen "blocker", "kritisch", "normal", "unkritisch"?

Prioritäten

Reichen "höchste", "hoch", "normal", "gering", "geringste"?

Komponenten

• Brauchen wir zusätzliche Komponenten?
• War es sinnvoll, die Fachschaften als Komponenten einzuführen?

Lösungen

• Manchmal würde ich mir neben "erledigt", "ungültig", "bleibt so", "Doppel", "bei mir geht's" noch so etwas wie "teilweise gelöst" wünschen.

[Rüdiger Kupper]

Bei den Lösungen könnte auch "veraltet" bzw. "nicht mehr aktuell" sinnvoll sein. Allerdings kann man dafür auch "ungültig" verwenden.

[Rüdiger Kupper]

Hallo Hannes,

Du hattest mal erwähnt, Du hättest Ideen zur Restrukturierung der Ticket-Klassen unseres Trac. Als ​dritthäufigster Benutzer würde ich Dich gerne in die Überarbeitung einbeziehen.

Zur Debatte stehen:

1. die Tickettypen
2. Schweregrade
3. Prioritäten
4. Komponenten
5. Lösungen

(siehe Beschreibung dieses Tickets).

[jas]

na, einige Änderungen sind ja vorgenommen worden. Ich würde sagen, wir schließen das Ticket nach 12 Monaten Ruhe und fügen vielleicht noch die Lösung: "Veraltet" hinzu.

[Rüdiger Kupper]

Ist mehr etwas, was wir nebenbei im Auge behalten sollen.
Du hast ja gestern gesehen, dass wir z.B. stark nach Wichtigkeitsklassen priorisieren:

• Es gibt zur Zeit nur drei Tickets mit Priorität "höchste", weil die eben schneller erledigt werden.
• vom Schweregrad "blocker" haben wir gar keine offen, weil die immer sofort bearbeitet werden,
• vom Schweregrad "kritisch" sind drei offen (wobei mir #883 da nicht ganz richtig eingeordnet scheint)

Das heißt: Die Nützlichkeit eines Systems wie Trac steht und fällt damit, dass man möglichst passende Kategorien für Schweregrade und Prioritäten hat. Ich habe z.B. den Eindruck, dass für viele Kollegen eine weitere Schwerekategorie zwischen "normal" und "kritsch" nützlich wäre.

Derzeit interpretiere ich unsere Schweregrade so:

• blocker: macht normalen Schulbetrieb unmöglich (z.B. Ausfall des Hauptservers)
• kritisch: beeinträchtigt den Unterricht vieler Kollegen (z.B: Ausfall eines Klassenraumservers in einem U)
• normal: beeinträchtigt den Unterricht eines oder weniger Kollegen
• unkritisch: ohne Einfluss auf den Schulbetrieb

Die Steckdosen in der BK (#883) sind in obigem Sinne vielleicht nicht normal, aber auch nicht wirklich kritisch.

Andererseits darf man bei einem solchen System auch nicht den Fehler machen, zu viele Zwischenstufen einzuführen, weil sie sonst nicht mehr aussagekräftig sind und damit ihre Funktion verlieren, wirkungsvoll zu priorisieren.

Also: Augen offen halten, ob sich an unseren Katgorien etwas verbesser lässt -- in dem Sinne, dass wir dadurch unsere Aufgaben besser/schneller/gezielter erledigen können.

[Rüdiger Kupper]

Hintergrundinfo: Das doppelte Kategorisierungsverfahren stammt übrigens aus der Notfallmedizin und ist dort hochgradig erprobt und wissenschaftlich validiert. Es wurde später auf technische "Notfälle" übertragen.

​WikipediaDe:Emergency_Severity_Index (müsste Dir als Sanitäter ja bekannt sein :-) ).

Zitat:

Im Gegensatz zu anderen Triage-Systemen benutzt der Emergency Severity Index ein zweistufiges Herangehen an die Festlegung der Gruppenzuordnung bei neu eintreffenden Notfallpatienten. Dabei werden zunächst Patienten mit hoher Behandlungsdringlichkeit identifiziert, für die anderen wird nachfolgend eine Gruppenzuordnung (nicht Behandlungsreihenfolge!) aufgrund des voraussichtlichen Ressourcenbedarfes festgelegt.
[...]
Bei genauer Betrachtung muss der Emergency Severity Index als eine Kombination aus einem dreistufigen Dringlichkeitssystem (0 Min, 10 Min, keine Zeitgrenze) mit einem dreistufigen Aufwandeinschätzungssystem betrachtet werden.

Die benutzen z.B. jeweils drei Stufen, nicht mehr.

[jas]

So, hoffe der Beitrag passt in dieses Ticket...
Habe mir gerade überlegt, ob wir Tickets auch eine Zwischenzeitliche Lösung geben könnten. Sowas unter dem Motto "Problem ist bekannt, kann zur Zeit nicht gelöst werden, weshalb das Ticket in näherer Zukunft nicht bearbeitet werden kann". der Lösungsvorschlag wäre dann sowas wie "freezed" oder "stilgelegt"... was meint ihr?
Das würde evtl. etwas mehr Übersicht schaffen. Von Zeit zur Zeit könnte man sich diese Tickets anschauen und bei Langeweile bearbeiten- oder sie irgendwann ganz schließen.

[Rüdiger Kupper]

Milestone unbestimmter Termin deleted

[lehm]

ping