Mein Team besteht aus Softwareentwicklern und UX-Designern. Ihr Workflow ist anders – UX hat andere Schritte als eine reine Entwicklungsaufgabe. Was ist der beste Weg, dies auf einem Kanban-Board zu verwalten?
Bonus: Was ist der beste Weg, dies in Kanban von Jira zu verwalten?
Bei unserem Projekt führen UX-Leute Stakeholder-Interviews durch, erstellen Wireframes und holen Genehmigungen ein. Ihre Schritte sind in etwa so:
Wir haben auch Entwickler mit ihrem eigenen Ablauf, wie zum Beispiel:
Einige der Stories, an denen die Designer arbeiten, fließen direkt in die Stories der Entwickler ein, daher wäre es sinnvoll, ein Board zu haben, das die Schritte aller Teammitglieder kombiniert. Manchmal gibt es jedoch Designarbeiten, die nicht direkt zu einer Entwicklungsgeschichte führen – im Grunde überspringen Designgeschichten Schritte im Ablauf.
Vielen Dank für Ihre Hilfe! 🙇♂️
Kanban ist ein Pull-Queue-System , das Prozesstore und Arbeitszustandsübergänge visualisiert. Das bedeutet, dass jede Arbeitsaufgabe von den Aufgabenausführern aus einer vorherigen Warteschlange gezogen wird, wenn ihre WIP-Grenzen dies zulassen. Jedes Board sollte eine logische Ansicht eines einzelnen einheitlichen Prozesses darstellen. Sie können mehrere Boards haben, um die Arbeit zwischen unabhängigen oder sequenziellen Prozessen in die Warteschlange zu stellen, sowie zusätzliche Boards, um eine bessere Sichtbarkeit der Zustandsänderungen in jeder Spalte zu bieten.
Kanban ist kein Ticketing-System, und die Einbeziehung unterschiedlicher oder hochvariabler Workflows arbeitet gegen den Rahmen. Die Aufnahme von Arbeitszuständen ohne Ablauf und Warteschlangen innerhalb eines einzelnen Boards erzeugt Rauschen, da viele der Warteschlangen nicht auf ein beträchtliches Volumen der zu visualisierenden Arbeitsaufgaben anwendbar sind. Tu das nicht!
Ein Teil des Problems, das Sie auszudrücken versuchen, besteht darin, dass die UX- und Software-Leute eigentlich nicht im selben Team sind. Mehrere Teams sollten jeweils von einer separaten Warteschlange aus arbeiten, anstatt zu versuchen, den Workflow jedes Teams in eine konsolidierte Ansicht zu stopfen.
Während ein einzelnes Produkt-Backlog auf höherer Ebene normalerweise das Richtige ist, benötigt jedes Team im Allgemeinen sein eigenes Kanban-Board und seinen eigenen visualisierten Prozess zur Verfolgung von Zustandsübergängen. In skalierten Scrum-Implementierungen erfolgt dies, indem für jedes Team zwischen dem Product Backlog und dem Sprint Backlog unterschieden wird. Kanban ist weniger präskriptiv, aber das gleiche Modell sollte gelten.
JIRA ist im Kern ein Ticketsystem. Obwohl es sicherlich verwendet werden kann, um Kanban-Funktionalität bereitzustellen, ist es wichtig, Ihren Prozess nicht zu verzerren, um ihn an JIRA anzupassen. Stattdessen sollten Sie Ihren Prozess definieren und dann die Funktionen von JIRA nutzen, um Ihren Workflow so genau wie möglich abzubilden.
Wenn Sie Arbeitselemente klein halten, ist es in einem agilen Kontext durchaus akzeptabel, Spalten als grobkörnige Warteschlangen zu behandeln. Konkret könnten Sie ein einheitliches Board haben, das einfach sagt:
und überlassen Sie es dann jedem Team, beliebige Warteschlangen und Prozesse zu implementieren, die sie intern in einem separaten JIRA-Board verfolgen möchten.
Eine andere Alternative besteht darin, sich nicht mehr von den Beschränkungen von JIRA als Ticketsystem einschränken zu lassen. Behalten Sie ein konsolidiertes Board bei, aber verwenden Sie Team- oder Rollenkonten als Einzelverantwortliche für Tickets und E-Mail-Verteilerlisten, um sicherzustellen, dass alle in den relevanten Teams weiterhin E-Mail-Benachrichtigungen und dergleichen erhalten können.
Der Team/Rollen-Ansatz hat den Nebennutzen, dass alle über Zustandsänderungen auf dem Laufenden gehalten werden. Wenn Sie feststellen, dass das Signal-Rausch-Verhältnis, um alle über jeden Zustandsübergang zu informieren, zu niedrig ist, müssen Sie fragen:
Wenn das Rauschen, alles konsolidiert zu halten, zu hoch ist, dann macht es einfach mehr Sinn, Ihre Boards zu entkoppeln oder zu sequenzieren. Wenn Sie nicht integrierte Teams haben, sollte Ihre Visualisierung dies genau modellieren. Ein eng gekoppeltes Kanban-Board impliziert ein Maß an Workflow-Kohärenz, das in Ihrem Unternehmen möglicherweise nicht vorhanden ist und das für alle Beteiligten vollständig sichtbar sein muss.
Separate vs. integrierte Workflows stellen eine Reihe von geschäftlichen und betrieblichen Kompromissen dar. Erwägen Sie, das X in diesem X/Y-Szenario neu zu bewerten, und stellen Sie sicher, dass Sie nicht zulassen, dass die Einschränkungen von JIRA Ihre Prozesse bestimmen.
Derzeit scheinen Sie entkoppelte Teams mit separaten Prozessen und einigen Abhängigkeiten zwischen den Prozessen zu haben. Das sollte die Grundlage sein, auf der Sie Ihre Kanban-Boards modellieren, anstatt ein Ersatz-Management-Dashboard mit begrenztem Wert für die Prozessbeteiligten zu erstellen. Natürlich möchte das Management einen Überblick sehen, aber ein visuelles Modell, das die bestehenden Prozesse nicht genau abbildet, ist für niemanden von äußerst begrenztem Wert.
Erwägen Sie bei Bedarf die Entwicklung eines separaten Dashboards oder Berichts, der Daten aus jedem relevanten Workflow abruft. Verschmutzen Sie damit jedoch nicht den Workstream. Echte Kanban-Boards sollen einen Prozess transparent machen, nicht andere Formen der Analyse und Berichterstattung ersetzen.
JIRA-Boards sind effektiv Ansichten zu Projekten. Das bedeutet, dass viele verschiedene Boards dieselben Daten (oder eine Teilmenge derselben Daten) enthalten können.
Beispielsweise könnten Sie ein Entwicklerboard, ein UX-Board und ein kombiniertes Board haben, die alle auf dasselbe Projekt verweisen. Alles, was JIRA braucht, ist eine Möglichkeit herauszufinden, welche Aufgaben auf welchen Boards angezeigt werden sollen. Sie könnten beispielsweise ein benutzerdefiniertes Feld oder eine Bezeichnung verwenden und diese in JQL in einem Filter verwenden, um die Boards zu definieren.
Es lohnt sich, das Team zusammenzubringen, um darüber nachzudenken, für welche Zwecke Sie die Boards verwenden möchten, da dies die Spalten auf jedem Board und den JQL für die Filter bestimmt.
Aus Erfahrung würde ich vorschlagen, dass Sie dies wahrscheinlich nicht gleich beim ersten Mal richtig machen werden. Ich würde empfehlen, mehrere Boards zu erstellen und die Ergebnisse nach einigen Wochen zu überprüfen, um festzustellen, welche Boards gut funktionieren und welche modifiziert werden müssen.
Einige der Geschichten, an denen die Designer arbeiten, fließen direkt in die Geschichten der Entwickler ein
Hier ist Ihr Problem.
Sehen Sie sich die INVEST-Mnemonik an .
I - Unabhängig - Die PBI sollte in sich abgeschlossen sein, so dass keine inhärente Abhängigkeit von einer anderen PBI besteht.
Sie nehmen eine einzelne Geschichte ("Machen Sie den Alpha-Widjet unscharf") und teilen sie in zwei nicht unabhängige Geschichten auf ("Machen Sie den Alpha-Widjet unscharf aussehen" und "Lassen Sie den Alpha-Widjet unscharf wirken").
Was Sie stattdessen tun sollten, ist eine einzelne Story, die Unteraufgaben enthält.
Manchmal gibt es jedoch Designarbeiten, die nicht direkt zu einer Entwicklungsgeschichte führen – im Grunde überspringen Designgeschichten Schritte im Ablauf.
Das ist in Ordnung? Lassen Sie einfach zu, dass die Issues so übergehen, wie der Benutzer es wünscht.
Das obige wird funktionieren , hat aber etwas Klobigkeit.
Eine Verbesserung, die ich vorschlagen würde, wäre das Hinzufügen verschiedener Arten von Unteraufgaben. Dann kannst du:
John Gordon