Wie kann ich JIRA-Ticketzuweisungen nutzen, um Gruppenbesitz, Pairing und Schwärmen zu fördern, ohne andere Kernfunktionen zu umgehen?

Hintergrund & Ziele

Atlassian JIRA ist im Kern wirklich nur ein Ticketing-System. Während dem System eine Reihe agiler Workflows und Plugins zur Verfügung stehen, besteht das grundlegende Design des Tools darin, die Zuweisung von Tickets an Einzelpersonen und nicht an Gruppen zu erzwingen.

Aus einer agilen Perspektive (und speziell aus einer SAFe 4.5-Perspektive) würde ich eher sehen, dass Probleme Affinitätsgruppen zugewiesen werden als Einzelpersonen. Eigentlich würde ich sie eher Produktwarteschlangen als Teams zuweisen sehen, aber das könnte für das Tool einen Schritt zu weit gehen.

Atlassian bietet verschiedene Tricks an, um dieses Problem zu umgehen, aber sie fühlen sich alle ein bisschen ... na ja, suboptimal an. Sogar die „Nicht zugewiesen“-Warteschlange oder die benutzerdefinierte Gruppenauswahloption scheinen das Umgehen einer großen Anzahl integrierter Berichts- und Verfolgungsfunktionen von JIRA zu erfordern, und ich möchte keine Problemumgehung empfehlen, die zu einem geringeren Wert gegenüber anderen Standardfunktionen von führt das Werkzeug.

Die Frage

Wie kann ich JIRA am effektivsten nutzen, um die Werte der kollektiven Teamverantwortung, der Paarung und des Schwärmens innerhalb von JIRA zu kommunizieren, ohne es unmöglich zu machen, die Standard-Dashboards und -Berichte zu verwenden?

Vorbehalte

  1. Die Werkzeugauswahl war eine Geschäftsentscheidung, die über meiner Gehaltsstufe lag. Ich kann CodeGnome's Law oder First Corollary nicht durchsetzen und muss mein Bestes tun, um innerhalb der Einschränkungen des Tools zu arbeiten.
  2. Ich suche wirklich nach einer Prozessantwort, aber Workflows, Praktiken, JIRA-Plug-ins oder benutzerdefinierte Berichte liegen sicherlich im Bereich.
  3. Ich möchte klarstellen, dass ich nach einer Framework-zentrierten Lösung suche, die die Einschränkungen des Tools berücksichtigt, anstatt nach Softwareempfehlungen zu suchen.
Was meinst du mit dem Begriff "zuordnen"? Die Aufgabe wird schließlich einer Einzelperson zugewiesen und JIRA erlaubt keine Gruppenzuweisung oder Gruppenarbeit (man kann jedoch die Arbeit für die einem anderen zugewiesene Aufgabe protokollieren). Geht Jira Scrum Board nicht auf Ihre Bedürfnisse ein?
@AlexeyR. JIRA erlaubt einige kludgey Alternativen zur individuellen Zuweisung, die ich in der Frage verlinkt habe. Aber wenn Sie das Confluence-Dokument lesen, gibt es eine Menge Fallstricke. Individuelle Zuordnung ist jedoch grundsätzlich ein nicht agiler Geruch.
Warum ist es ein „nicht agiler Geruch“, eine einzelne Person für den Fortgang der Arbeit verantwortlich zu machen? Ich stimme zu, dass Pairing oder Mobbing gut ist, und wenn Sie diese verwenden, sollte dies in Ihren Iterationsplanungsaktivitäten herauskommen (der Arbeitsaufwand, den Sie mit starkem Pairing oder Mobbing übernehmen, ist geringer als bei Einzelpersonen, die arbeiten und dann zur Überprüfung und Paarung einreichen wie nötig). Aber ich habe festgestellt, dass es weniger wahrscheinlich ist, dass sie erledigt wird, wenn eine Person nicht als verantwortlich für die Arbeit identifiziert oder dafür verantwortlich gemacht wird, dass Fortschritte erzielt werden. Sie können bei Bedarf benutzerdefinierte Felder hinzufügen, um Personen in Paaren oder Mobs zu identifizieren.
@ThomasOwens Weil das gesamte Team verantwortlich ist. Auch wenn das Team einen nicht fließenden Ansatz zum Thema Story Ownership hat, führt der gesamte Begriff der individuellen „Zuweisungen“ (insbesondere Push vs. Pull) als Informationsstrahler oft dazu, dass weniger erfahrene Teams und Organisationsleitungen eine Struktur um die individuelle Nutzung und individuelle Zuweisung herum erstellen anstatt sich zu paaren und zu schwärmen. Nach meiner beruflichen Erfahrung treibt die zugrunde liegende Metapher des Werkzeugs den Prozess trotz bester Absichten oft auf unzählige subtile (und nicht so subtile) Arten voran.
Ich bin nicht der Meinung, dass das gesamte Team verantwortlich sein kann. Das gesamte Team kann für die Ausführung der Arbeiten verantwortlich sein. Aber am Ende des Tages bin ich der festen Überzeugung, dass eine Person dafür verantwortlich sein muss, dass die Arbeit richtig und richtig gemacht wird. Diese eine Person ist der Bevollmächtigte der Arbeit im Tool. Es liegt in der Verantwortung der Person in der Coaching-Rolle (Scrum Master in Scrum, Teamleiter in DAD, Scrum Master/RTE/STE in SAFe), die Organisation zum richtigen Verhalten und zur Verwendung der Tools und der darin enthaltenen Informationen zu führen der beste Weg für die Organisation.
@ThomasOwens One person accountableist teamzerstörerisch.

Antworten (4)

Ich würde die Ticketzuweisung für diesen Zweck vermeiden. Normalerweise habe ich gesehen, dass der Zugewiesene nicht zugewiesen ist, bis ein Mitglied des Entwicklungsteams die Story/Aufgabe im Sprint aufnimmt. Dies kann sich auf Feature-/Epic-Ebene unterscheiden, da das Produktmanagementteam das Backlog verfeinert.

Es ist sehr üblich, das Feld Labels zu verwenden und einen Teamnamen hinzuzufügen, wenn das Feature/Epic/die Story einem Team zugewiesen wird. Es ist dann ganz einfach, teamorientierte Boards zu erstellen, die nach dem Teamnamen filtern. Dieser Filter wird auf die Registerkarten „Backlog“ und „Reporting“ übertragen, sodass Sie nach Team planen oder analysieren können.

Hoffe das hilft!

Sie könnten JIRA-Benutzer erstellen, die Gruppen repräsentieren.

Die wichtigste Information in einem JIRA-Benutzer ist die E-Mail-Adresse, Sie brauchen also nur E-Mail-Aliase, die Mailinglisten für jede Gruppe darstellen.

Dies würde bedeuten, dass ein Problem seinen Lebenszyklus durchlaufen und niemals einer Person zugeordnet werden könnte. Die Benachrichtigung würde weiterhin funktionieren, da alle Mitglieder einer zugewiesenen Gruppe (oder Produktwarteschlange) E-Mail-Updates erhalten würden.

Der Nachteil bei diesem Ansatz ist, dass Sie sicherstellen müssten, dass Sie die Mitgliedschaft in den verschiedenen Mailinglisten auf dem neuesten Stand halten.

Ich habe diese Option in der Liste der "offiziellen" Kludges gesehen. Verursacht dies neben dem Aufwand für die Pflege von Mailinglisten weitere größere Probleme bei der Berichterstellung, Statusübergängen oder anderen Kernfunktionen? Es scheint sicherlich die am wenigsten schlechteste der veröffentlichten Optionen zu sein.
Meine größte Sorge bei diesem Ansatz ist, dass es schwierig ist, zu bestimmen, mit wem man über ein bestimmtes Problem sprechen soll, wenn man mit dem Projekt und der Zusammensetzung des Teams nicht vertraut ist. Mir gefällt die Idee, Metadaten für den Benutzer „Gruppe“ zu verwenden, die angeben, wer in der Gruppe ist, und sie dann in Problemen als benutzerdefiniertes Feld anzuzeigen. Ich habe jedoch nie versucht, das zum Laufen zu bringen, daher bin ich mir nicht sicher, ob es möglich ist. Das Melden sollte kein Problem darstellen, es sei denn, Sie müssen auf individueller Ebene berichten.
Ich versuche tatsächlich, die Organisation davon abzubringen, auf individueller Ebene zu berichten. Während ich den kontinuierlichen Dialog zwischen dem Team und Stakeholdern/Endbenutzern rund um die In-Sprint-Arbeit (weil „Zusammenarbeit“) voll und ganz unterstütze, ist die individuelle Zuordnung von Arbeit kein Informationsstrahler über die Arbeit , sondern über die Nutzung oder ein Proxy für die individuelle Leistung. Das ist das Anti-Pattern, das ich versuche zu vermeiden. Deine Punkte sind aber gut getroffen!

Welcher Wert der „Standard-Dashboards und -Berichte“ wird beeinträchtigt? Ist oder warum es keine Option, das Objekt einer Person zuzuweisen? (Was ist das eigentliche Problem/Anliegen/Motivator?)

Wenn es vorgeschrieben ist, Tools zu verwenden, oder sogar wenn ausgewählte Tools verwendet werden, wird die Förderung der Teammentalität leicht unterstützt, indem einfach die Anforderung entfernt wird, dass dieses Feld ausgefüllt werden muss. (Ich habe Jira eine Weile nicht verwendet, also ist es vielleicht nicht möglich; es ist zum Beispiel in VSTS möglich.)

Der Confluence-Beitrag in meinem OP listet einige Problemumgehungen auf, darunter keine erforderliche Zuweisung, aber die Einstellung Allow unassigned issuesist global und würde mehr als nur die agilen Projekte in JIRA betreffen. Dieser Ansatz würde auch die Verantwortlichkeit des Teams nicht fördern; Es würde einfach alle Arbeiten als Warteschlange behandeln, was in Kanban nützlich sein könnte, aber weniger für Scrum oder SAFe.
Wie funktioniert das Nicht-Zuordnen eines Artikels zu einer Person nicht promote team accountability? Vielleicht wäre eine Klärung dessen, was team accountabilityfür Sie bedeutet, hilfreich, um das Problem/die Sorge/den Motivator aufzudecken. Wenn mehrere Teams an demselben Produkt arbeiten und dies das Problem ist, könnte dies in der Frage geklärt werden. Das Product Backlog an ordered listist eine modifizierbare Warteschlange und das Sprint Backlog gehört zum sich selbst organisierenden Entwicklungsteam; keine probleme da. Das Teilen einer Jira-Instanz mit anderen scheint aufgrund der Bedenken hinsichtlich der globalen Einstellung ebenfalls ein Problem zu sein.

Ich glaube, das Problem ist (wie Alex feststellt), dass das Tool selbst nicht speziell für SAFe entwickelt wurde. Eingebaute und hinzugefügte Problemumgehungen versuchen, dies auszugleichen.
Haben Sie darüber nachgedacht, andere Tools in JIRA zu integrieren, um Ihnen das zu bieten, was Sie brauchen? Ich will damit nicht JIRA ersetzen, sondern einen Mehrwert schaffen. Tools wie SwiftEASe von Digite bieten ein Tool, das als eigenständiges SAFe-Implementierungstool verwendet oder vollständig in JIRA integriert werden kann und viele der von Ihnen festgestellten Probleme löst.

Das Problem, das Sie in einer Nussschale haben - Lippenstift auf einem Schwein.

Wie kann ich JIRA-Ticketzuweisungen nutzen, um Gruppenbesitz, Pairing und Schwärmen zu fördern, ohne andere Kernfunktionen zu umgehen?
AntwortenHierDatenschutz-Bestimmungen1y, 0v