Einblicke aus Ihren JIRA-Daten zur Verbesserung Ihres Teams

Viele Teams verwenden JIRA von Atlassian als Issue Tracker, der dann zu einer wertvollen Informationsquelle für ihre tägliche Arbeit wird. Als Teamleiter, der JIRA verwendet, haben Sie wahrscheinlich schon JIRA-Dashboards eingesetzt, um den Status der Arbeit zu überwachen, in der Regel im Zusammenhang mit einer (Release-)Planung. Diese Dashboards helfen Ihnen jedoch oft kaum, strukturelle Ineffizienzen in Ihrer Organisation zu erkennen.

Deshalb haben wir drei verschiedene Ansichten auf JIRA-Daten ausgewählt, die sich in verschiedenen Unternehmen bewährt haben. Sie bieten Ihnen Einblicke, damit Sie besser informierte Entscheidungen treffen können, um die Erfahrung Ihrer Entwickler und die Produktivität Ihres Teams kontinuierlich zu verbessern.

Bitte denken Sie daran, dass Daten zwar aussagekräftig, aber kontextabhängig sind und nur einen Teil der Wahrheit zeigen.

 

Änderungen des Bergbaustatus verarbeiten

Durch die Analyse des Verlaufs von Jira-Problemen können wir den tatsächlichen Fluss von Aufgaben und Problemen aufzeigen. Daraus geht hervor, welche Status am häufigsten verwendet werden und wie viel Zeit in jedem Status verbracht wird. Diese Darstellung ähnelt manchmal einer automatisierten Wertstromkarte.Wir neigen dazu, dieses Diagramm pro Fragetyp zu betrachten - da Epics, Stories und Bugs in der Regel einen anderen Fluss oder eine andere Lebensdauer haben. Um dieses Diagramm lesbar zu machen, lassen wir außerdem die am wenigsten genutzten Statusübergänge weg.

 

Beispiel: Zeigt die Status, die Übergänge zwischen ihnen und die durchschnittliche Zeit zwischen ihnen. Die Farben stehen für die Statuskategorie.

Zu den Erkenntnissen, die wir daraus ziehen, gehören:

• Kollaboration: Jira-Status werden oft für die Weitergabe von Arbeit verwendet. Viele Status führen oft zu Verzögerungen und isolierter Arbeit, statt zu Zusammenarbeit.
• Verspätungen : Durch die Quantifizierung der Zeitintervalle zwischen den Status können wir Bereiche mit Optimierungsbedarf identifizieren. Einige Beispiele:
  • Es ist nicht ungewöhnlich, dass wir beobachten, dass ein 'Test'-Status länger dauert als die eigentliche Implementierung. Oft hängt dies mit Übergaben, schlechter Testbarkeit oder einer ineffizienten Teststrategie zusammen.
  • Der Verfeinerungsstatus könnte zu kurz sein oder ganz übersprungen werden. Wenn wir später feststellen, dass viele abgeschlossene Elemente überarbeitet werden müssen, können wir untersuchen, ob das Team überhaupt keine Zeit für die Verfeinerung hat oder ob die Interessengruppen des Unternehmens nicht in der Lage sind, Informationen zu liefern.
• Nacharbeit : Es ist wichtig, auf Pfeile zu achten, die auf frühere Status zurückgehen. Wenn die Häufigkeit solcher Vorkommnisse hoch ist, deutet dies auf Verbesserungsmöglichkeiten hin.
  • Eine sich wiederholende Schleife von 'Testen' zu 'in Entwicklung' deutet zum Beispiel oft auf Fehler in einem späten Stadium hin, die auf eine unzureichende Testautomatisierung oder unklare Anforderungen zurückzuführen sind.
• Realitätschecks : Oft wird ein Prozess mit vielen Status entworfen. Ein wichtiger Einblick, den wir erhalten, ist, ob dieser Entwurf auch wirklich befolgt wird. Zum Beispiel:
  • Ungenutzte oder selten genutzte Status bringen möglicherweise keinen Mehrwert und können daher entfernt werden.
  • Manchmal überspringen Teams einen Status ganz (durchschnittliche Vorlaufzeit von 0 Minuten). In diesem Fall stimmt der geplante Prozess nicht mit der Realität überein.
  • Einige Ideen können über einen längeren Zeitraum im Backlog verbleiben, bevor sie bereinigt werden (d.h. "nicht zu beheben"). Ziehen Sie in Erwägung, diese aktiv zu reduzieren.
• Historische Vergleiche : Der Vergleich einer Version dieses Diagramms im Laufe der Jahre (jetzt vs. vor 3 Jahren vs. vor 5 Jahren) kann wichtige Informationen darüber liefern, ob es in den letzten Jahren Verbesserungen gegeben hat oder nicht.

Erstellung von Ausgaben im Laufe der Zeit nach aktueller Statuskategorie

Ein Histogramm, das die Anzahl der im Laufe der Zeit erstellten Fragen nach ihren aktuellen Statuskategorien anzeigt, hat sich als aufschlussreiches Diagramm erwiesen. Auch hier betrachten wir dieses Diagramm in der Regel pro Problemtyp. In JIRA werden häufig benutzerdefinierte Status verwendet, die jedoch alle zu einer "Statuskategorie" gehören.

Diese Tabelle befasst sich mit Fragen wie: Kann das Team mit der eingehenden Arbeit Schritt halten?

Beispiel: Ein Histogramm der erstellten Bugs, gefärbt nach der Statuskategorie.

Zu den Erkenntnissen, die wir daraus ziehen, gehören.

• Trend zur Erstellung von Ausgaben: Der Trend bei der Erstellung von Ausgaben selbst kann viel aussagen. Vielleicht geht die Zahl der erstellten Stories zurück, weil ein Projekt zu Ende geht. Vielleicht nimmt die Zahl der eingehenden Fehler zu und wir müssen Maßnahmen ergreifen, um sie zu bewältigen.
• Ausgabe Alter: Indem wir den aktuellen Status der Probleme hinzufügen, können wir uns ein Bild davon machen, wie alt die Probleme sind, an denen gearbeitet wird. Wenn das Team nur an alten Problemen arbeitet, könnte es Schwierigkeiten haben, mit den aktuellen Anforderungen des Marktes Schritt zu halten.
• Ausgabe Balance: Das Gleichgewicht zwischen abgeschlossenen und unvollständigen Aufgaben ist ein zuverlässiger Indikator für den Zustand des Projekts. Wenn die Anzahl der eingehenden Probleme zunimmt, während sich das Team ausschließlich auf ältere Probleme konzentriert, wird es wahrscheinlich noch schwieriger, wieder in Schwung zu kommen.

Entwicklung der laufenden Arbeiten

Allzu oft sehen wir Teams, die ohne gemeinsame Ziele und einen Fokus auf deren Erreichung arbeiten. Stattdessen arbeiten sie an verschiedenen Dingen und erledigen mehrere Aufgaben, und die tatsächliche Leistung ist suboptimal. Wir empfehlen oft, die Anzahl der laufenden Arbeiten zu begrenzen, aber selbst dann kann die Analyse der Trends suboptimale Abläufe und Schwerpunkte aufdecken.

Konkret bedeutet unsere Definition von 'in Arbeit' nicht nur die Arbeit in der Statuskategorie 'in Arbeit'. Stattdessen zählen wir auch Arbeiten, die von 'erledigt' oder 'in Arbeit' auf 'zu erledigen' zurückgegangen sind. Wir berücksichtigen also Arbeit, die aktiv in Arbeit ist, aber auch Arbeit, die begonnen, aber nicht beendet wurde.

Beispiel: Die in Arbeit befindlichen Geschichten wachsen mit der Zeit

Zu den Erkenntnissen, die wir daraus ziehen, gehören

• Langfristige Trends der laufenden Arbeiten : Wenn die unfertigen Arbeiten ständig zunehmen, ist es wahrscheinlich, dass das Team davon profitieren würde, wenn es sich mehr auf die Fertigstellung von Dingen konzentrieren würde, und wir würden empfehlen, herauszufinden, was die Probleme in Arbeit hält.
• Trends in der laufenden Arbeit während eines Sprints : Bei manchen Gelegenheiten sehen wir vielleicht ein anderes Muster in der Reihe, bei dem die in Arbeit befindliche Arbeit sehr stark um jedes Sprint-Ende herum einbricht. Obwohl es im Allgemeinen gut ist, Dinge in einem Sprint abzuschließen, ist es auch wichtig, über mögliche Gründe nachzudenken. Vielleicht wird die Qualität zugunsten der Einhaltung der Frist eingeschränkt, oder die Arbeitslast kann besser über den Sprint verteilt werden, oder vielleicht wird die Verwaltung der Arbeit erst am Ende des Sprints aktualisiert.

Fazit

Wie wir Ihnen hoffentlich gezeigt haben, erfordert die Navigation durch die Fülle der in Ihrem JIRA Issue Tracking System verfügbaren Daten Präzision und strategisches Vorgehen. Die vorhandenen JIRA-Dashboards können zwar eine Momentaufnahme der aktuellen Vorgänge liefern, aber wenn Sie tiefer in die Daten eindringen, können Sie eine historische Perspektive auf Ihre Leistung erhalten.

Die Untersuchung von Problemflüssen und historischen Mustern in Ihrem Softwareentwicklungsprozess kann Ihnen wertvolle Einblicke in die Effizienz Ihres Unternehmens und in potenzielle Engpässe in Ihrem Prozess geben:

• Wissen wir, ob unser Testverfahren effizient genug ist?
• Können wir rechtzeitig auf die Anforderungen des Marktes reagieren und die benötigten Funktionen schnell in Produktion bringen?
• Ist unser Backlog-Management effizient genug?

Ganz gleich, ob Sie diese analytische Reise gerade erst beginnen oder bereits tief in datengesteuerte Strategien einsteigen, es gibt immer eine Geschichte, die darauf wartet, in den Zahlen entdeckt zu werden.

Wir würden uns freuen, wenn Sie sich mit uns in Verbindung setzen, wenn dieser Artikel Ihnen in irgendeiner Weise geholfen hat, wenn Sie mehr wissen möchten oder wenn Sie einfach nur ein gutes Gespräch bei einer Tasse Kaffee führen möchten.

 

Update 04-04-2024

Wir haben einen Teil der JIRA-Analyse als Teil von DevLake veröffentlicht. Siehe unseren Blog-Beitrag: DevLake Playground Wie Sie Ihre Daten untersuchen können

Dieser Blog ist Teil unserer Serie " Ganzheitliche Horizonte ". Lesen Sie den vorherigen Eintrag - " Überwindung der Kluft zwischen Geschäftsinteressenten und Entwicklungsteams " von Dmitry Litosh.