LINK zu dieser Intranet-Seite merken: https://kurzelinks.de/wlo-intranet
2 Wichtige Regeln...
Bitte für WLO keine Issues ohne Epic anlegen - immer Epic-Owner = Assignee fragen.
Bitte keine WLO-Epics ohne Projektleitung anlegen.
Umständlich? Warum?
Epics sind Verträge zwischen Projektmanagement und Teamleitung.
Issues sind Verträge zwischen Teamleitung und Teammitglied
Sub-Tasks unter Issues könnt ihr frei anlegen um Eure Aufgabe zu organisieren, solange sie im Budget der Issues und Epics liegen.
Unten findet Ihr Hilfe und Erste Schritte...
Verträge zwischen Projektmanagement und Teamleitungen. Die Nummerierung ist synchron zu den Teams & Gebieten >>>>
NEW : Der Auftraggeber (Jira: Autor/Reporter) hat die Aufgabe quasi in einer eigenen Merkliste erstellt. Die Aufgabe ist noch nicht vom Bearbeiter angenommen.
OPEN: Der Auftraggeber hat die Aufgabe dem Bearbeiter (Assignee) zugewiesen. Der könnte ablehnen, indem er die Aufgabe auf "Neu" zurückschiebt und einen Kommentar schreibt.
TODO NOW: Auftraggeber oder Bearbeiter möchten, dass diese Aufgabe ist AKTUELL HEISS getan wird - im Gegensatz meint "OPEN" "bei nächster Gelegenheit entsprechend der Priorität".
IN PROGRESS: gibt Auftraggebern das Zeichen, dass sehr zeitnah ein Ergebnis kommt. Wie die im Daily kommunizierte Liste meint es "Mache ich heute". Es können aktuelle Dinge des Tages, der Woche oder im aktuellen Sprint sein.
DONE: Ist das Signal für den Auftraggeber "Die Bearbeitung ist fertig, schau mal ob noch Nacharbeiten / Änderungen nötig sind". Ihr habt Pech, wenn das Ticket wieder in Open geschoben wird und Glück, wenn es in
CLOSED verschoben wird.
REFUSED: Ist wie eine finale Ablehnung die Aufgabe zu bearbeiten, z.B. weil sie nicht mehr sinnvoll ist. Euer Auftraggeber sollte es gelegentlich in CLOSED schieben und diese Entscheidung damit bejahen.
INACTIVE: ist wie die nichtfinale Ablehnung, diese Aufgabe zu erfüllen. Ihr signalisiert Bereitschaft, es wieder weiterzuführen, wenn Euch jemand einen triftigen Grund dafür gibt.
WARTET AUF SUPPORT-TEAM : Ist wie OPEN - es ist eine vom "Kunden" gestellte Aufgabe. Bastis Support ist daran.
WARTET AUF KUNDEN: Das Support-Team stellte eine Rückfrage an den Kunden oder vermutete eine Wissenslücke / Bedienfehler und informierte den Kunden. Wir warten auf dessen Antwort. Aktuell ist nichts zu tun. Nach angemessener Zeit fragt das Supportteam nach oder resolved das Ticket.
WARTET AUF WLO-TEAM: Ist OPEN im internen Projekt-Ablauf, jemand aus dem WLO-Team muss etwas tun.
IN PROGRESS: gibt dem Support-Team das Zeichen, dass sehr zeitnah ein Ergebnis kommt.
RESOLVED: Ist das "DONE" mit einer Lösung, die den Kunden zufriedenstellen sollte. Falls es nicht zufriedenstellend lösbar ist, bleibt noch...
CLOSED heißt erledigt, auf nimmer wiedersehen - i.d.R. erfolgreich manchmal nicht.
LÄNGERFRISTIGE WARTELISTE: Das heißt wahrscheinlich ist das Problem nicht in absehbarer Zeit dran oder nicht lösbar. Das Support-Team sollte ab und zu diese Liste nochmals durchgehen und Issues wieder öffnen, die doch unsere Aufmerksamkeit brauchen.
CANCELED: wir geben auf oder legen es auf. Wenn kein größerer Ärger mit dem Kunden folgt, wird das Ticket vom Support-Team "Closed" gesetzt.
Epics / Activities : Aufträge von der Projektleitung an ein Team. Es gibt nur 2 Aufgabenebenen Issue und Sub-Task. Eine 3. Ebene macht das Epic auf, wobei dies eher eine Art Sammlung und keine klare Hierarchie ist. Denn ein Issue kann auch in mehreren Epics verlinkt werden. Epics dienen dem systematischen Management einer Zuständigkeit.
Task: Aufgaben diverser Art
Sub-task: Eine Unteraufgabe unter allen anderen Issue-Arten.
Improvement: Eine Verbesserung an etwas VORHANDENEM, auch als Change-Request nutzbar.
New Feature: Etwas Neues soll hinzugefügt werden. Das bedarf Investment-Entscheidungen. Es muss nicht nur der Betroffene / Fachexperte, sondern ggf. die Produktkonferenz mit entscheiden.
Bug: Ein Fehler
Blocker: alles bleibt liegen, sofort das (Missbrauch kostet einen Kasten)
Üblich ist "Major", Dringend / hoch priorisiert ist "Critical"
Die Teams definieren Zuständigkeitsgebiete ihrer Teammitglieder. Diese sollten für andere Teams verständlich und klar sein. Denn einem Ticket soll jeder im Team eine Komponente / Zuständigkeit zuweisen können. Diese Zuständigkeiten sind im WLO-Projekt-Board als Filter implementiert, so dass Ihr sehen könnt, wo es in Eurer Zuständigkeit brennt.