Requests: was an ein Projekt herangetragen wird

Wer in einem Projekt arbeitet, bekommt ständig Dinge zugerufen: „Die Bank lehnt unsere SEPA-Datei ab“, „Könnten wir nicht …?“. Das sind keine Storys. Wer so etwas meldet, kennt die Zerlegung des Projekts nicht und soll sie auch nicht kennen müssen. Es ist eine Eingabe, über die noch zu entscheiden ist, und genau dafür gibt es seit diesem Stand die Requests.

Dieselbe Stellung wie die Sonderaufgabe, die andere Richtung

Ein Request hängt direkt am Projekt und hat keine Kinder, genau wie die Sonderaufgabe vom Vortag. Der Unterschied ist die Richtung: Eine Sonderaufgabe ist Arbeit, die neben der Planung läuft. Ein Request ist etwas, das von außen kommt und aus dem vielleicht erst Arbeit wird. Was daraus entsteht, entsteht als eigener Vorgang in der Hierarchie. Ich hätte die Storys auch unter den Request hängen können, aber dann gäbe es neben dem Epic eine zweite, konkurrierende Zerlegung, und die Frage „Wo steht diese Story?“ hätte zwei Antworten.

Jeder Request trägt eine von zwei Unterkategorien: Problem oder Idee. Beide kommen von außen, verlangen aber verschiedene Antworten. Ein Fehler will behoben werden, ein Vorschlag will entschieden werden. Die Unterkategorie steuert deshalb, was die Karte zeigt:

• Problem: Kommentare, Priorität, Zuweisung, Zieltermin und Zeiterfassung. Ein Request wird angesehen, nachgestellt und bewertet, bevor irgendeine Story entsteht, und diese Zeit hätte sonst keinen Vorgang, an dem sie hängen könnte.
• Idee: nur Kommentare. Priorität und Zieltermin setzen voraus, dass etwas getan wird, und wer eine Idee umsetzt, steht erst nach ihrer Annahme fest.

Das Requestboard

Für die Probleme gibt es ein eigenes Board unter dem Menüpunkt „Requests“, mit Kanban und Liste, Filtern, gespeicherten Ansichten und Verschieben per Maus oder Tastatur.

Dasselbe Board wie bei den Aufgaben, nur mit einem anderen Katalogeintrag dahinter. Eine Karte ist unkenntlich gemacht.

Ich habe dafür keine Kopie des Aufgabenboards gebaut. Beide Boards unterscheiden sich in genau drei Angaben: Schlüssel, Titel, Reiter. Alles andere ist gleich, und als Kopie wären das ein paar hundert Zeilen, von denen die zweite Hälfte beim nächsten neuen Filter zurückbliebe. Stattdessen steht an einer einzigen Stelle, was ein Board zeigt, und der Browser schickt nur noch „Requestboard“. Welche Vorgangsarten und Unterkategorien das bedeutet, entscheidet der Server. Als Parameter in der Anfrage wäre der Filter auf „Problem“ nur eine Bitte, keine Bedingung.

Die Spalten sind immer der Systemstatus. Requests haben keine eigenen Statuswerte je Prozess: Eine Meldung ist neu, in Arbeit, erledigt oder verworfen, und genau diese Abstufung leistet der feste Systemstatus bereits.

Der Menüpunkt hieß vorher „Tickets“ und war ausgegraut. Ich habe ihn umbenannt, statt einen zweiten danebenzustellen, denn ein Ticket und ein Request sind dieselbe Sache unter zwei Namen. Mit dem Namen hat auch das Symbol gewechselt: Statt einer Abrissmarke zeigt es jetzt eine Sprechblase mit einem Pfeil hinein. Etwas kommt an und wartet auf Antwort.

Melden, ohne den Baum zu kennen

Oben rechts steht „Neuer Request“: Projekt, Titel, Priorität, Zuweisung, fertig. Das Aufgabenboard bekommt diesen Knopf bewusst nicht. Eine Story gehört unter ein Feature, und welches, beantwortet keine Übersicht über alle Projekte. Ein Request dagegen ist eine Wurzel, da gibt es nichts zu wählen.

Die Unterkategorie hat kein Feld: Was hier entsteht, ist immer ein Problem.

Bei der Zuweisung kann man ein ganzes Team wählen. Gespeichert werden dann dessen Mitglieder einzeln, denn ein Vorgang trägt keine Teams. Man kann danach also auch einzelne wieder entfernen. Und weil ein frisch angelegter Request niemandem zugeordnet ist, steht er in der Vorgabeansicht „Eigene Aufgaben“ gar nicht. Statt einer Erfolgsmeldung ohne sichtbare Wirkung sagt die Seite das deshalb ausdrücklich und bietet die Kennung als Verweis an.

Ideen sind kein Board

Ideen haben eine eigene Seite, und zwar als Blog. Ein Board beantwortet „Wer arbeitet woran?“, und das trifft auf eine Idee nicht zu. Was zählt, ist ihr Text, und den zeigt keine Kartenspalte. Jeder hat je Projekt 20 Punkte, die er auf Ideen verteilt.

Eine Idee zeigt Text, Verfasser und Punkte, keine Spalten.

Über eine Idee zu entscheiden ist ein eigenes Recht, getrennt von „Requests ändern“. Wer Ideen einbringt, ist ein anderer Kreis als der, der sie freigibt. Und gesehen werden Ideen nur von den Mitgliedern des Projekts. Das Recht, alle Projekte zu lesen, öffnet sie nicht, denn ein ausformulierter Vorschlag ist etwas anderes als der Stand einer Vorgangsliste.

Was aus einer Idee wird, wenn sie angenommen ist, kam ein paar Tage später: Aus ihr lässt sich direkt eine Aufgabe erstellen, und beide bleiben verbunden.