> Kontinuierliche Prozessverbesserung > Softwareentwicklungslebenszyklus > Jira Software > Daten Template

Ihr Daten-Template für den Softwareentwicklungszyklus

Jira Software

← Zurück zum Leitfaden zur Prozessverbesserung

Attribute des Softwareentwicklungszyklus (21) Aktivitäten im Softwareentwicklungszyklus (14) Anleitungen zum Extrahieren von Daten (4)

Ihr Daten-Template für den Softwareentwicklungszyklus

Dieses Template bietet einen klaren Leitfaden zur Erfassung der wesentlichen Daten für die Analyse Ihres Softwareentwicklungszyklus. Es beschreibt die wichtigsten zu erfassenden Datenfelder und Prozessschritte und gibt praktische Hinweise zum Extrahieren der Informationen aus Jira Software. Bereiten Sie mit diesem Leitfaden Ihr Event Log für ein aussagekräftiges Process Mining vor.

Empfohlene zu erfassende Attribute
Wichtige zu verfolgende Aktivitäten
Hinweise zum Extrahieren von Daten aus Jira Software

Neu bei Event Logs? Erfahren Sie, wie Sie ein Event Log für Process Mining erstellen.

Template herunterladen

Attribute des Softwareentwicklungszyklus

Diese empfohlenen Datenfelder sollten Sie in Ihr Event Log aufnehmen, um den Softwareentwicklungszyklus umfassend zu analysieren.

5 Erforderlich 6 Empfohlen 10 Optional

	Name	Beschreibung
	Aktivität Activity	Der Name eines bestimmten Ereignisses oder einer Statusänderung im Entwicklungslebenszyklus eines Vorgangs.
Beschreibung Dieses Attribut bezeichnet einen einzelnen Schritt oder Meilenstein im Softwareentwicklungsprozess. Die Aktivitäten werden aus Änderungen des Statusfelds eines Jira-Vorgangs oder aus anderen wichtigen Ereignissen wie Code-Commits oder Reviews abgeleitet. Beim Process Mining bildet die Abfolge dieser Aktivitäten die Prozesslandkarte. Ihre Analyse macht den Prozessablauf sichtbar, zeigt die Dauer einzelner Phasen und deckt Abweichungen vom Standard-Workflow auf, etwa Nacharbeitsschleifen oder übersprungene Qualitätsprüfungen. Warum das wichtig ist Aktivitäten bilden die Prozessschritte ab. Ihre Reihenfolge ist entscheidend, um den Prozessablauf darzustellen, Engpässe zu erkennen und Prozessabweichungen zu analysieren. Woher beziehen Wird üblicherweise aus den Übergängen des Felds „status“ im Verlauf oder Änderungsprotokoll des Jira-Vorgangs abgeleitet. Daten aus angebundenen Entwicklungstools können die Informationen ergänzen. Beispiele Entwicklung gestartetCode-Review durchgeführtQA-Test abgeschlossenIn der Produktionsumgebung bereitgestellt
	Entwicklungsvorgang DevelopmentItem	Der eindeutige Bezeichner für eine einzelne Arbeitseinheit in Jira Software, etwa eine Story, einen Fehler oder eine Aufgabe.
Beschreibung Der Entwicklungsvorgang dient als primäre Case-ID und steht für eine klar abgegrenzte Arbeitseinheit, etwa eine Funktion, eine Fehlerbehebung oder eine Aufgabe. Er verknüpft alle Aktivitäten für diesen Vorgang, von der ersten Idee und Planung über Entwicklung und Tests bis zur Bereitstellung. In Jira entspricht dies üblicherweise dem Vorgangsschlüssel, zum Beispiel „PROJ-123“. Mit diesem Attribut lässt sich der gesamte Lebenszyklus jedes Arbeitselements nachvollziehen. Es bildet die Grundlage für Prozesslandkarten, die Berechnung von Zykluszeiten und die Ermittlung von Unterschieden im Ablauf verschiedener Vorgänge. Warum das wichtig ist Dieser zentrale Schlüssel verknüpft alle zugehörigen Entwicklungsaktivitäten. So lässt sich der Weg eines einzelnen Arbeitselements vom Anfang bis zum Abschluss nachvollziehen. Woher beziehen Dies ist das Standardfeld „key“ für einen Vorgang im Jira-Software-Issue-API-Objekt. Beispiele PROJ-101CORE-5432API-789
	Ereigniszeitpunkt EventTime	Das genaue Datum und die Uhrzeit, zu denen eine bestimmte Entwicklungsaktivität oder ein Ereignis stattgefunden hat.
Beschreibung Der Ereigniszeitpunkt ist der Timestamp, der festhält, wann eine Aktivität stattgefunden hat. Er bildet die zeitliche Grundlage für alle Process-Mining-Analysen und legt die chronologische Reihenfolge der Ereignisse für jeden Case fest. Dieses Attribut ist entscheidend für die Berechnung aller zeitbezogenen Kennzahlen, darunter Zykluszeiten, Verarbeitungszeiten und Wartezeiten zwischen Aktivitäten. Es ermöglicht die Analyse der Prozessleistung im Zeitverlauf und hilft dabei, Verzögerungen im Entwicklungslebenszyklus zeitlich und örtlich einzugrenzen. Warum das wichtig ist Dieser Timestamp ist entscheidend, um Ereignisse korrekt anzuordnen und alle dauerbezogenen Kennzahlen zu berechnen. Diese Kennzahlen helfen dabei, die Prozesseffizienz zu verstehen und Verzögerungen aufzudecken. Woher beziehen Entspricht dem Timestamp „created“ für jeden Eintrag im Änderungsprotokoll oder Verlauf eines Vorgangs. Beispiele 2023-10-26T10:00:00Z2023-11-15T14:35:10Z2024-01-05T09:00:00Z
	Letzte Datenaktualisierung LastDataUpdate	Der Timestamp, der angibt, wann die Daten für diesen Prozess zuletzt aus dem Quellsystem aktualisiert wurden.
Beschreibung Dieses Attribut erfasst Datum und Uhrzeit der letzten Datenextraktion aus Jira Software. So lässt sich einordnen, wie aktuell die analysierten Daten sind. Der Zeitpunkt der letzten Aktualisierung ist wichtig, um die Aktualität der Prozesserkenntnisse beurteilen zu können. Analysten und Fachanwender können damit prüfen, ob sie aktuelle Daten sehen und bis zu welchem Zeitpunkt Ereignisse in die Analyse eingeflossen sind. Warum das wichtig ist Zeigt, wie aktuell die Daten sind. Das ist wichtig, damit Analysen und Dashboards den neuesten Prozessstand abbilden. Woher beziehen Dieser Timestamp wird am Ende des Datenextraktions-, Transformations- und Ladeprozesses (ETL) erzeugt und erfasst. Beispiele 2024-03-15T02:00:00Z2024-03-16T02:00:00Z
	Quellsystem SourceSystem	Das System, aus dem die Daten zum Entwicklungslebenszyklus extrahiert wurden.
Beschreibung Dieses Attribut gibt die Herkunft der Daten an. Für diesen Prozess lautet der Wert immer „Jira Software“. Es hilft jedoch, Daten zu unterscheiden, wenn eine umfassendere Analyse mehrere Quellsysteme zusammenführt. In einer größeren IT-Landschaft sorgt die Angabe des Quellsystems für eine nachvollziehbare Datenherkunft und unterstützt das Datenqualitätsmanagement sowie die Integration verschiedener Plattformen. Warum das wichtig ist Macht die Herkunft der Daten nachvollziehbar. Das ist besonders wichtig, wenn Daten aus mehreren Systemen zusammengeführt werden oder Anforderungen an Data Governance und Audits bestehen. Woher beziehen Dies ist ein statischer Wert, der bei der Datenextraktion und -transformation hinzugefügt werden sollte. Beispiele Jira Software
	Priorität des Vorgangs ItemPriority	Die dem Entwicklungsvorgang zugewiesene Prioritätsstufe, die seine Dringlichkeit angibt.
Beschreibung Die Priorität eines Vorgangs gibt seine relative Bedeutung oder Dringlichkeit an. Jira stellt dafür das Standardfeld „priority“ mit konfigurierbaren Stufen wie „Höchste“, „Hoch“, „Mittel“ und „Niedrig“ bereit. Die Priorität zu analysieren ist wichtig, um die Konformität zu prüfen und Engpässe bei kritischen Vorgängen zu erkennen. Das Dashboard „Konformitätsprüfung für priorisierte Vorgänge“ verwendet dieses Attribut beispielsweise, um zu prüfen, ob Vorgänge mit hoher Priorität wie erwartet schneller bearbeitet werden oder in denselben Warteschlangen wie Vorgänge mit niedriger Priorität liegen bleiben. Warum das wichtig ist Zeigt, ob Vorgänge mit hoher Priorität schneller bearbeitet werden als solche mit niedriger Priorität und ob sie einen direkteren Ablauf durchlaufen. So lässt sich prüfen, ob SLAs eingehalten werden. Woher beziehen Dies ist das Feld „priority“ im Objekt „fields“ der Jira-Issue-API-Antwort. Beispiele HöchsteHochMittelNiedrig
	Projektname ProjectName	Der Name des Jira-Projekts, zu dem der Entwicklungsvorgang gehört.
Beschreibung In Jira sind alle Arbeitselemente Projekten zugeordnet. Der Projektname liefert einen übergeordneten Kontext und steht häufig für ein bestimmtes Produkt, Team oder eine Initiative. Dieses Attribut eignet sich besonders gut zum Filtern und Vergleichen. Damit können Sie den SDLC-Prozess über verschiedene Projekte oder Produkte hinweg analysieren und vergleichen. So wird sichtbar, welche Projekte effizienter sind, wo mehr Nacharbeit anfällt und ob Teams unterschiedliche Prozessvarianten verwenden. Warum das wichtig ist Ermöglicht die Analyse nach Projekt, Produkt oder Team. So können Sie die Leistung vergleichen und bewährte Vorgehensweisen ermitteln. Woher beziehen Dies ist das Feld „project“ im Objekt „fields“ der Jira-Issue-API-Antwort. Beispiele Entwicklung mobiler AppsKernplattformDatenwissenschaft
	Status des Vorgangs ItemStatus	Der aktuelle Status des Entwicklungsvorgangs innerhalb seines Workflows.
Beschreibung Dieses Attribut gibt die jeweilige Phase des Entwicklungsvorgangs zu einem bestimmten Zeitpunkt an, zum Beispiel „In Bearbeitung“, „In Prüfung“ oder „Erledigt“. Aus der Abfolge der Statusänderungen entstehen die Aktivitäten für das Process Mining. Das Attribut „Aktivität“ bezeichnet das Änderungsereignis, während „ItemStatus“ den Zustand des Vorgangs angibt. Als Dimension eignet es sich zum Filtern und Analysieren. So können Sie sehen, wie viele Vorgänge sich aktuell in einem bestimmten Status befinden oder welche Merkmale Vorgänge aufweisen, die lange in einem Status verbleiben. Warum das wichtig ist Zeigt den aktuellen Stand eines Vorgangs in seinem Lebenszyklus. Das ist wichtig für statusbezogene Analysen und um den aktuellen Stand der laufenden Arbeit zu verstehen. Woher beziehen Dies ist das Feld „status“ im Objekt „fields“ der Jira-Issue-API-Antwort. Beispiele Zu erledigenIn BearbeitungIn PrüfungErledigt
	Teamname TeamName	Das Entwicklungsteam, das für den Vorgang zuständig ist.
Beschreibung Bezeichnet das agile Team oder Feature-Team, das dem Entwicklungsvorgang zugewiesen ist. In Jira wird dieses Attribut häufig als benutzerdefiniertes Feld umgesetzt oder aus anderen Angaben wie dem Projekt oder einer bestimmten Komponente abgeleitet. Dieses Attribut ist wichtig für die Leistungsanalyse auf Teamebene. Dashboards lassen sich damit nach Kennzahlen wie Zykluszeit, Nacharbeitsquote und Durchsatz einzelner Teams filtern. Es ist entscheidend für die Dashboards „Effizienz von Übergaben zwischen Phasen“ und „Arbeitslast der Entwickler und Fortschritt der Vorgänge“. Warum das wichtig ist Ermöglicht die Leistungsmessung und den Vergleich verschiedener Entwicklungsteams. So lassen sich leistungsstarke Teams ermitteln und bewährte Vorgehensweisen weitergeben. Woher beziehen In Jira ist dies häufig ein benutzerdefiniertes Feld. Fragen Sie Ihren Jira-Administrator nach dem konkreten Feldnamen, der beispielsweise „Team“ oder „Squad“ lauten kann. Beispiele Team PhoenixKerndiensteUI/UX Avengers
	Vorgangstyp ItemType	Die Klassifizierung des Entwicklungsvorgangs, zum Beispiel Fehler, Story, Aufgabe oder Epic.
Beschreibung Der Vorgangstyp kategorisiert die Art der ausgeführten Arbeit. Jira verwendet das Standardfeld „issuetype“, um verschiedene Arten von Arbeitselementen zu unterscheiden, für die oft unterschiedliche Workflows gelten. Dieses Attribut ist für vergleichende Analysen wichtig. Damit können Sie den Prozess nach bestimmten Arbeitstypen filtern und beispielsweise den Lebenszyklus eines Fehlers mit dem einer Story vergleichen. So lässt sich feststellen, ob bestimmte Arbeitstypen häufiger zu Verzögerungen, Nacharbeit oder Abweichungen vom Standardprozess führen. Warum das wichtig ist Ermöglicht den Vergleich verschiedener Arbeitstypen, etwa Fehlerbehebungen und neuer Funktionen, und zeigt, wie sie bearbeitet werden und wo sich ihre Abläufe unterscheiden. Woher beziehen Dies ist das Feld „issuetype“ im Objekt „fields“ der Jira-Issue-API-Antwort. Beispiele StoryFehlerAufgabeEpic
	Zugewiesen an Assignee	Der Benutzer, der aktuell für die Bearbeitung des Entwicklungsvorgangs zuständig ist.
Beschreibung Der Zugewiesene ist die Person, die in der aktuellen Phase für das Arbeitselement verantwortlich ist. In Jira ist dies ein Standardfeld, dessen Wert sich ändert, wenn der Vorgang zwischen Personen oder Teams wechselt. Die Analyse der zuständigen Personen hilft dabei, Ressourcenzuweisung, Arbeitslastverteilung und Übergaben zu verstehen. Sie zeigt, welche Entwickler oder Teams an bestimmten Phasen beteiligt sind, wo Engpässe entstehen und wie die Arbeit innerhalb der Organisation verteilt ist. Warum das wichtig ist Gibt den für eine Aktivität zuständigen Benutzer oder die zuständige Ressource an. Das ermöglicht die Analyse der Arbeitslast und des Ressourceneinsatzes sowie die Untersuchung von Übergaben zwischen Personen. Woher beziehen Dies ist das Feld „assignee“ im Objekt „fields“ der Jira-Issue-API-Antwort. Beispiele Alice SmithBob JohnsonNicht zugewiesen
	Endzeitpunkt des Ereignisses EventEndTime	Der Timestamp, zu dem eine Aktivität oder ein Status abgeschlossen wurde.
Beschreibung Dieses Attribut gibt den Abschlusszeitpunkt einer Aktivität an. Es entspricht dem Timestamp der nächsten Aktivität in der Abfolge eines Cases. Während „EventTime“ (StartTime) den Beginn einer Aktivität markiert, gibt „EventEndTime“ ihr Ende an. Die Differenz zwischen diesen beiden Timestamps ist die Verarbeitungszeit der Aktivität. Sie ist entscheidend für die Berechnung der KPI „Durchschnittliche Verarbeitungszeit je Phase“ und für Dashboards zur Analyse der Aktivitätsdauer. Warum das wichtig ist Legt den Endzeitpunkt einer Aktivität fest. Damit lässt sich die Dauer jedes Prozessschritts berechnen, was für die Engpassanalyse entscheidend ist. Woher beziehen Dies ist ein abgeleitetes Attribut. Bei einem bestimmten Ereignis entspricht die Endzeit der Startzeit des nachfolgenden Ereignisses desselben Cases. Beispiele 2023-10-26T12:30:00Z2023-11-15T18:00:15Z2024-01-05T11:45:00Z
	Fix Version FixVersion	Die Softwareversion, in der der Entwicklungsvorgang tatsächlich abgeschlossen und veröffentlicht wurde.
Beschreibung „Fix Version“ gibt in Jira die Veröffentlichung an, die die abgeschlossene Arbeit an einem Vorgang enthält. Das Feld dokumentiert das konkrete Ergebnis der Entwicklungsarbeit. Dieses Attribut liefert den tatsächlichen Veröffentlichungskontext. Ein Vergleich mit „PlannedReleaseVersion“ zeigt, wie die Lieferung im Verhältnis zur Planung abschneidet. Außerdem lassen sich damit alle Vorgänge einer bestimmten Veröffentlichung gruppieren und die Ergebnisse zusammenfassen. Warum das wichtig ist Bestätigt, in welcher Veröffentlichung die Arbeit enthalten war. Damit liefert das Attribut eine verlässliche Grundlage für die Veröffentlichungsanalyse und die Nachverfolgung ausgelieferter Funktionen. Woher beziehen Entspricht dem Feld „fixVersions“ in der Jira-Issue-API-Antwort. Beispiele v2.1.1-Hotfixv3.0.0-Hauptveröffentlichungv2.2.0
	Geplante Veröffentlichung PlannedReleaseVersion	Die Zielversion oder Veröffentlichung, für die die Bereitstellung des Vorgangs geplant ist.
Beschreibung Dieses Attribut, in Jira häufig das Feld „Affects Version/s“, gibt die geplante Veröffentlichung einer Funktion oder Fehlerbehebung an. Es dient als Termin oder Ziel für den Abschluss der Arbeit. Dieses Attribut ist entscheidend für die KPI „Pünktliche Veröffentlichungsrate“. Vergleichen Sie das tatsächliche Bereitstellungsdatum mit dem geplanten Veröffentlichungsdatum dieser Version, um die Termineinhaltung und die Planbarkeit Ihres Veröffentlichungsprozesses zu messen. Warum das wichtig ist Legt den geplanten Liefertermin oder die Zielveröffentlichung fest. Damit lassen sich die pünktliche Lieferung und die Einhaltung des Zeitplans analysieren. Woher beziehen Entspricht den Feldern „versions“ oder „fixVersions“ in der Jira-Issue-API. Welches Feld für die Planung verwendet wird, kann variieren. Beispiele Version 2.1Veröffentlichung Q1 2024Einführung von Project Phoenix
	Gesamte Zykluszeit CycleTime	Die gesamte Durchlaufzeit eines Entwicklungselements von Anfang bis Ende.
Beschreibung Die Zykluszeit misst die gesamte verstrichene Zeit von der Erstellung eines Entwicklungselements bis zu dessen abschließendem Ergebnis, etwa der Bereitstellung in der Produktion. Sie wird auf Case-Ebene berechnet, indem der Timestamp des ersten Ereignisses vom Timestamp des letzten Ereignisses abgezogen wird. Diese zentrale KPI misst die Geschwindigkeit und Effizienz des Gesamtprozesses. Die KPI „Durchschnittliche Zykluszeit von Anfang bis Ende“ und das Dashboard „Analyse der gesamten SDLC-Zykluszeit“ basieren direkt auf dieser Berechnung. Die Verkürzung der Zykluszeit ist häufig ein wichtiges Ziel von Prozessverbesserungsinitiativen. Warum das wichtig ist Misst die Geschwindigkeit des Entwicklungsprozesses von Anfang bis Ende und liefert eine zentrale Kennzahl für Effizienz und Auslieferungsgeschwindigkeit. Woher beziehen Dies ist ein berechnetes Attribut auf Case-Ebene. Für ein bestimmtes „DevelopmentItem“ wird der Timestamp des ersten Ereignisses vom Timestamp des letzten Ereignisses abgezogen. Beispiele 12096002592000604800
	Ist Nacharbeit IsRework	Kennzeichnet, ob eine Aktivität Teil einer Nacharbeitsschleife ist.
Beschreibung Dieses boolesche Attribut ist wahr, wenn eine Aktivität einen Rückschritt im Prozess darstellt, etwa wenn nach einem nicht bestandenen QA-Test erneut „Entwicklung gestartet“ folgt. Der Wert wird durch die Analyse der Aktivitätsfolge eines Cases ermittelt. Nacharbeit zu erkennen, ist entscheidend, um Prozesseffizienz und Qualität zu verbessern. Dieses Attribut unterstützt direkt die KPI „Anteil der Nacharbeitsaktivitäten“ und das Dashboard „Häufigkeit und Pfade von Nacharbeitsschleifen“. Damit lässt sich der Aufwand für unnötige Arbeit quantifizieren und die Ursache von Qualitätsproblemen ermitteln, die zu Nacharbeit führen. Warum das wichtig ist Kennzeichnet ausdrücklich Aktivitäten in ineffizienten Nacharbeitsschleifen. So lassen sich Prozessverluste und Qualitätsprobleme präzise messen und analysieren. Woher beziehen Dies ist ein berechnetes Attribut. Dafür müssen Sie den erwarteten Prozessablauf definieren und anschließend alle Aktivitäten kennzeichnen, die durch einen Wechsel zu einer früheren Phase davon abweichen. Beispiele truefalse
	Komponente Component	Ein Teilbereich oder Funktionsbereich eines Projekts, zu dem der Vorgang gehört.
Beschreibung Mit Komponenten lassen sich Vorgänge in Jira innerhalb eines Projekts in kleinere, überschaubare Bereiche gliedern. Das kann einen Funktionsbereich wie „Benutzerauthentifizierung“, eine technische Ebene wie „Backend-API“ oder ein Modul wie „Berichte“ bezeichnen. Die Analyse nach Komponenten bietet einen detaillierteren Einblick in den Entwicklungsprozess. Sie kann zeigen, ob bestimmte Teile der Anwendung mehr Fehler verursachen, längere Entwicklungszyklen haben oder häufiger Nacharbeit erfordern. Das kann auf technische Schulden oder hohe Komplexität hinweisen. Warum das wichtig ist Ermöglicht die Analyse nach funktionalen oder technischen Produktbereichen. So lässt sich feststellen, welche Komponenten Verzögerungen oder Qualitätsprobleme verursachen. Woher beziehen Dies ist das Standardfeld „components“ im Objekt „fields“ der Jira-Issue-API-Antwort. Beispiele BenutzeroberflächeDatenbankAPI-GatewayAuthentifizierung
	Melder Reporter	Der Benutzer, der den Entwicklungsvorgang ursprünglich erstellt oder gemeldet hat.
Beschreibung Der Melder ist die Person, die den Vorgang in Jira erstellt hat. Das kann ein Entwickler, ein Tester der Qualitätssicherung, ein Produktmanager oder über eine Service-Desk-Integration auch ein Kunde sein. Die Analyse der Melder gibt Aufschluss darüber, woher die Arbeit kommt. So können Sie beispielsweise prüfen, ob von der Qualitätssicherung gemeldete Fehler einen anderen Lebenszyklus haben als von Kunden gemeldete. Außerdem lassen sich Kommunikationsmuster und der Informationsfluss zu Prozessbeginn untersuchen. Warum das wichtig ist Zeigt, woher ein Arbeitselement stammt. So lassen sich Muster danach untersuchen, wer Aufgaben erstellt oder Fehler meldet. Woher beziehen Dies ist das Feld „reporter“ im Objekt „fields“ der Jira-Issue-API-Antwort. Beispiele Charles DarwinMarie CurieIsaac Newton
	Resolution des Vorgangs ItemResolution	Das endgültige Ergebnis oder der Grund für den Abschluss eines Entwicklungsvorgangs.
Beschreibung Die Resolution erklärt, warum ein Vorgang geschlossen wurde. Der Status kann beispielsweise „Geschlossen“ lauten, während die Resolution „Erledigt“, „Wird nicht umgesetzt“, „Duplikat“ oder „Nicht reproduzierbar“ angibt. Sie liefert damit wichtigen Kontext zum Arbeitsergebnis. Die Analyse der Resolution unterscheidet erfolgreich abgeschlossene Arbeit von abgebrochenen oder abgelehnten Vorgängen. Das ist wichtig für die Qualitätsanalyse und um den tatsächlichen Durchsatz wertvoller Arbeit dem Aufwand für letztlich verworfene Vorgänge gegenüberzustellen. Warum das wichtig ist Unterscheidet erfolgreich abgeschlossene Vorgänge von solchen, die aus anderen Gründen geschlossen wurden. Das ist wichtig für eine genaue Produktivitäts- und Qualitätsanalyse. Woher beziehen Dies ist das Feld „resolution“ im Objekt „fields“ der Jira-Issue-API-Antwort. Es wird üblicherweise nur ausgefüllt, wenn ein Vorgang geschlossen wird. Beispiele ErledigtWird nicht umgesetztDuplikatNicht reproduzierbar
	Sprintname SprintName	Der Name des agilen Sprints, dem der Entwicklungsvorgang zugewiesen ist.
Beschreibung Für Teams, die Scrum verwenden, ist ein Sprint ein festgelegter Zeitraum, in dem eine bestimmte Menge Arbeit abgeschlossen wird. Dieses Attribut erfasst den Namen oder Bezeichner des Sprints, zu dem ein Vorgang gehört. Die Analyse nach Sprints ist eine wichtige Grundlage für agiles Process Mining. Sie hilft dabei, die Leistung einzelner Sprints zu bewerten, übernommene Arbeit zu verstehen und den Fortschritt im Hinblick auf Sprintziele nachzuverfolgen. Der Sprint liefert einen konkreteren zeitlichen Bezug als allgemeine Datumsbereiche. Warum das wichtig ist Liefert agilen Teams einen wichtigen Kontext und ermöglicht die Analyse von Prozesseffizienz und Durchsatz für jeden einzelnen Sprint. Woher beziehen Diese Information ist üblicherweise in einem benutzerdefinierten Feld „Sprint“ gespeichert, das von Jira Software (Agile) verwaltet wird. Die Daten sind über die Issue-API verfügbar. Beispiele PROJ Sprint 1Q4-2023 Sprint 3November PI Sprint 2
	Wartezeit bei Übergaben HandoffWaitTime	Die Leerlaufzeit zwischen zwei aufeinanderfolgenden Aktivitäten.
Beschreibung Diese Kennzahl erfasst die Warte- oder Liegezeit zwischen dem Abschluss einer Aktivität und dem Beginn der nächsten. Sie zeigt, wie lange Arbeit unerledigt bleibt, bis sie jemand übernimmt. Diese Kennzahl ist zentral für die KPI „Durchschnittliche Wartezeit bei Übergaben“ und das Dashboard „Effizienz von Übergaben zwischen Phasen“. Lange Übergabezeiten deuten häufig auf Abstimmungsprobleme, knappe Ressourcen oder ineffiziente Kommunikation zwischen Teams hin, etwa zwischen Entwicklung und QA. Weniger Leerlauf verkürzt die gesamte Zykluszeit. Warum das wichtig ist Macht Leerlauf- und Wartezeiten im Prozess sichtbar. So werden ineffiziente Übergaben zwischen Teams oder Personen sowie Abstimmungsprobleme erkennbar. Woher beziehen Dies ist eine berechnete Kennzahl. Sie ergibt sich aus der Startzeit einer Aktivität abzüglich der Endzeit der vorherigen Aktivität im selben Case. Beispiele 017280043200

Erforderlich Empfohlen Optional

Aktivitäten im Softwareentwicklungszyklus

Diese wichtigen Prozessschritte und Meilensteine sollten Sie in Ihrem Event Log erfassen, damit der Softwareentwicklungszyklus präzise erkannt werden kann.

6 Empfohlen 8 Optional

	Aktivität	Beschreibung
	Abnahmetest freigegeben	Markiert den erfolgreichen Abschluss des User Acceptance Testing und zeigt an, dass die Beteiligten die Veröffentlichung freigegeben haben. Dieser Zeitpunkt wird aus einer Statusänderung von 'In UAT' zu einem Status wie 'Ready for Release' oder 'Done' abgeleitet.
Warum das wichtig ist Dieser Meilenstein bestätigt die fachliche Abnahme und gibt den Vorgang für die Bereitstellung in der Produktionsumgebung frei. Er ist ein entscheidender Kontrollpunkt, um sicherzustellen, dass das Ergebnis den Erwartungen der Benutzer entspricht. Woher beziehen Wird aus dem Änderungsprotokoll des Jira-Vorgangs abgeleitet. Der Timestamp gibt den Statuswechsel von „In UAT“ zum nächsten Workflow-Status wieder und kennzeichnet die Freigabe. Erfassung Timestamp des Statuswechsels von „In UAT“ zu „Bereit für die Veröffentlichung“. Ereignistyp inferred
	Entwicklung gestartet	Markiert den Zeitpunkt, an dem ein Entwickler aktiv mit der Arbeit am Entwicklungselement beginnt. Dieser Zeitpunkt wird in Jira fast immer aus einer Statusänderung im Workflow abgeleitet, beispielsweise wenn der Vorgangsstatus zu 'In Progress' wechselt.
Warum das wichtig ist Dieser wichtige Meilenstein dient dazu, die aktive Entwicklungszeit zu messen. Er hilft, Wartezeit von wertschöpfender Arbeit zu unterscheiden und ist damit eine wichtige Kennzahl zur Erkennung von Engpässen. Woher beziehen Wird aus dem Änderungsverlauf des Jira-Vorgangs abgeleitet. Erfasst wird der Timestamp, an dem das Feld 'status' erstmals zu 'In Progress', 'In Development' oder einem ähnlichen aktiven Status wechselt. Erfassung Timestamp der Statusänderung zu 'In Progress'. Ereignistyp inferred
	Entwicklungselement angelegt	Damit beginnt der Lebenszyklus: Ein neues Entwicklungselement, etwa eine Story, ein Fehler oder eine Task, wird in Jira erfasst. Das System speichert dieses Ereignis für jeden Vorgang mit einem Erstellungs-Timestamp.
Warum das wichtig ist Diese Aktivität markiert den eindeutigen Prozessbeginn. Sie ist wichtig, um die Zykluszeit von Anfang bis Ende zu berechnen und das gesamte Volumen neu eingehender Arbeit zu verfolgen. Woher beziehen Dieses grundlegende Ereignis gibt es für jeden Jira-Vorgang. Der Erstellungs-Timestamp wird im Feld 'created' des Vorgangsdatensatzes gespeichert und ist über die Jira-API verfügbar. Erfassung Das Timestamp-Feld 'created' des Jira-Vorgangsobjekts. Ereignistyp explicit
	In der Produktionsumgebung bereitgestellt	Dieses Ereignis kennzeichnet den Zeitpunkt, zu dem die Codeänderungen des Entwicklungsvorgangs in der Produktionsumgebung verfügbar sind. Dies lässt sich aus einem abschließenden Statuswechsel zu „Erledigt“ oder „Veröffentlicht“ ableiten oder über ein explizites Ereignis eines integrierten CI/CD-Tools erfassen.
Warum das wichtig ist Dies ist der zentrale Endpunkt für den Prozesserfolg. Er ist entscheidend, um die gesamte Durchlaufzeit von Anfang bis Ende zu berechnen und Veröffentlichungshäufigkeit sowie Durchsatz zu messen. Woher beziehen Lässt sich aus dem Änderungsprotokoll des Jira-Vorgangs ableiten, wenn der Status zu „Veröffentlicht“ oder „Erledigt“ wechselt. Genauere Daten liefern Bereitstellungsereignisse, die CI/CD-Tools wie Jenkins oder Bamboo übermitteln, oder die Funktion „Deployments“ in Jira. Erfassung Timestamp des Statuswechsels zu „Erledigt“ oder „Veröffentlicht“. Ereignistyp inferred
	QA-Test abgeschlossen	Zeigt an, dass das Entwicklungselement alle Qualitätssicherungsprüfungen bestanden hat und für die nächste Phase bereit ist, etwa den Abnahmetest oder die Veröffentlichung. Dieser Zeitpunkt wird aus einer Statusänderung heraus aus dem primären Teststatus abgeleitet.
Warum das wichtig ist Damit ist eine wichtige Qualitätsprüfung abgeschlossen. Die Analyse der Dauer der QA-Phase hilft, Testprozesse und Ressourcenzuteilung zu optimieren. Woher beziehen Wird aus dem Änderungsverlauf des Jira-Vorgangs abgeleitet. Erfasst wird der Timestamp, an dem das Feld 'status' von 'In QA' zu einem nachfolgenden Status wie 'Ready for UAT' oder 'Ready for Release' wechselt. Erfassung Timestamp der Statusänderung von 'In QA' zu 'Ready for UAT'. Ereignistyp inferred
	QA-Test gestartet	Dieses Ereignis markiert den Beginn der formellen Qualitätssicherungsphase für das Entwicklungselement. Es wird aus einer Jira-Statusänderung abgeleitet, wenn der Vorgang beispielsweise zu 'In QA', 'In Testing' oder 'Ready for Testing' wechselt.
Warum das wichtig ist Dieser wichtige Meilenstein markiert den Beginn der Qualitätsprüfung. Die Zeit zwischen „Entwicklung abgeschlossen“ und diesem Zeitpunkt zeigt Verzögerungen bei der Übergabe zwischen Entwicklungs- und QA-Teams. Woher beziehen Wird aus dem Änderungsverlauf des Jira-Vorgangs abgeleitet. Erfasst wird der Timestamp, an dem das Feld 'status' zu einem festgelegten QA-Teststatus wie 'In QA' wechselt. Erfassung Timestamp der Statusänderung zu 'In QA' oder 'In Testing'. Ereignistyp inferred
	Abnahmetest gestartet	Markiert den Beginn des User Acceptance Testing, bei dem fachliche Beteiligte oder Endbenutzer die neue Funktionalität prüfen. Dieser Zeitpunkt wird aus einer Jira-Statusänderung zu einem Status wie 'In UAT' oder 'User Acceptance Testing' abgeleitet.
Warum das wichtig ist Diese Aktivität markiert den Beginn der abschließenden Prüfphase vor der Veröffentlichung. Ihre Dauer ist wichtig, um Verzögerungen durch die Verfügbarkeit der Beteiligten oder Feedbackschleifen zu verstehen und zu verringern. Woher beziehen Wird aus dem Änderungsverlauf des Jira-Vorgangs abgeleitet. Erfasst wird der Timestamp, an dem das Feld 'status' auf 'In UAT' oder einen ähnlichen festgelegten Status gesetzt wird. Erfassung Timestamp der Statusänderung zu 'In UAT'. Ereignistyp inferred
	Code-Review durchgeführt	Zeigt an, dass ein Kollege oder Teamleiter den Code auf Qualität, Standards und Funktionalität geprüft hat. Dies lässt sich aus einer Statusänderung ableiten, etwa von 'In Review' zu 'Ready for QA', oder explizit aus integrierten Entwicklungstools erfassen.
Warum das wichtig ist Diese Aktivität ist eine wichtige Qualitätsprüfung. Werden ihre Dauer und Ergebnisse, etwa erforderliche Nacharbeit, analysiert, lässt sich die Codequalität verbessern und die Zahl später entdeckter Fehler verringern. Woher beziehen Wird häufig aus dem Änderungsverlauf des Jira-Vorgangs abgeleitet, wenn der Status den Status 'Code Review' verlässt. Bei integrierten Tools für Code-Repositories wie Bitbucket oder GitHub kann das Ereignis auch explizit erfasst werden. Erfassung Timestamp der Statusänderung von 'In Review' zum nächsten Status. Ereignistyp inferred
	Entwicklung abgeschlossen	Diese Aktivität zeigt an, dass der Entwickler die Programmierung abgeschlossen hat und das Element für die nächste Phase bereit ist, etwa für ein Code-Review oder Tests. Sie wird aus einer Statusänderung in Jira abgeleitet, beispielsweise von 'In Progress' zu 'In Review' oder 'Ready for QA'.
Warum das wichtig ist Damit endet die zentrale Entwicklungsphase. So lassen sich die Dauer der Programmierung und die Effizienz der Übergabe an die Qualitätssicherung analysieren. Woher beziehen Wird aus dem Änderungsverlauf des Jira-Vorgangs abgeleitet. Erfasst wird der Timestamp, an dem das Feld 'status' von einem aktiven Entwicklungsstatus zu einem nachfolgenden Status wie 'In Review' oder 'Ready for QA' wechselt. Erfassung Timestamp der Statusänderung von 'In Progress' zu 'In Review' oder 'Ready for QA'. Ereignistyp inferred
	Entwicklungselement bereit für die Entwicklung	Zeigt an, dass ein Entwicklungselement vollständig spezifiziert, geprüft und priorisiert wurde und ein Entwickler mit der Arbeit beginnen kann. Dieser Zeitpunkt wird üblicherweise aus einer Statusänderung im Workflow abgeleitet, etwa von 'Backlog' zu 'To Do' oder 'Ready for Dev'.
Warum das wichtig ist Damit lässt sich messen, wie gut der Backlog vorbereitet ist und wie lange Elemente vor Entwicklungsbeginn warten. So können Planungs- und Verfeinerungszeit von der aktiven Entwicklungszeit getrennt betrachtet werden. Woher beziehen Wird aus dem Änderungsverlauf des Jira-Vorgangs abgeleitet. Suchen Sie nach dem Timestamp, an dem das Feld 'status' zu einem Wert wie 'Ready for Dev', 'To Do' oder 'Selected for Development' wechselt. Erfassung Timestamp der Statusänderung in einen Status, der die Entwicklungsbereitschaft anzeigt. Ereignistyp inferred
	Entwicklungsvorgang abgebrochen	Kennzeichnet das Ende eines Entwicklungsvorgangs vor dessen Abschluss. Dies lässt sich aus einem Statuswechsel zu einem Endstatus wie „Abgebrochen“, „Abgelehnt“ oder „Wird nicht umgesetzt“ ableiten und wird häufig durch eine entsprechende Resolution ergänzt.
Warum das wichtig ist Diese Aktivität erfasst nicht erfolgreiche Prozessergebnisse. Eine Analyse der Abbruchgründe kann Probleme bei der Planung, Priorisierung oder Anforderungsdefinition aufdecken. Woher beziehen Wird aus dem Änderungsprotokoll des Jira-Vorgangs abgeleitet. Der Timestamp gibt den Zeitpunkt an, zu dem der „status“ des Vorgangs zu „Abgebrochen“ oder „Wird nicht umgesetzt“ wechselt und eine entsprechende Resolution festgelegt wird. Erfassung Timestamp des Statuswechsels zu „Abgebrochen“, „Abgelehnt“ oder „Wird nicht umgesetzt“. Ereignistyp inferred
	Entwicklungsvorgang geschlossen	Dies ist der abschließende administrative Schritt und bestätigt, dass keine weitere Arbeit an dem Vorgang erwartet wird. Er lässt sich häufig aus einem Statuswechsel zu „Geschlossen“ und dem Ausfüllen des Felds „Resolution“ ableiten.
Warum das wichtig ist Kennzeichnet das endgültige Ende des Lebenszyklus eines Vorgangs. Ein Vergleich mit „In der Produktionsumgebung bereitgestellt“ kann administrative Verzögerungen oder Überwachungszeiträume nach der Bereitstellung sichtbar machen. Woher beziehen Wird aus dem Änderungsprotokoll des Jira-Vorgangs abgeleitet. Der Timestamp gibt den Zeitpunkt an, zu dem das Feld „status“ zu „Geschlossen“ wechselt und eine Resolution festgelegt wird. Erfassung Timestamp des Statuswechsels zu „Geschlossen“. Ereignistyp inferred
	Für die Veröffentlichung vorbereitet	Zeigt an, dass der Entwicklungsvorgang alle Prüfungen bestanden und einer bestimmten Softwareversion zugeordnet wurde. Er wartet nun auf die Bereitstellung. Dies lässt sich häufig daran erkennen, dass der Status eines Vorgangs zu „Bereit für die Veröffentlichung“ wechselt oder das Feld „Fix Version“ ausgefüllt wird.
Warum das wichtig ist Diese Aktivität hilft dabei, die Veröffentlichungsbereitschaft nachzuverfolgen und zu messen, wie lange Vorgänge nach Abschluss der Entwicklungs- und Testarbeiten auf ein Bereitstellungsfenster warten. Woher beziehen Wird üblicherweise aus dem Änderungsprotokoll des Jira-Vorgangs als Statuswechsel zu „Bereit für die Veröffentlichung“ abgeleitet. Alternativ lässt sich der Timestamp erfassen, zu dem das Feld „Fix Version/s“ ausgefüllt wird. Erfassung Timestamp des Statuswechsels zu „Bereit für die Veröffentlichung“ oder des Ausfüllens von „Fix Version“. Ereignistyp inferred
	QA-Test nicht bestanden	Zeigt an, dass das QA-Team einen Fehler gefunden hat und das Entwicklungselement zur Nacharbeit an die Entwickler zurückgeht. Dies wird aus einem rückwärts gerichteten Statuswechsel abgeleitet, beispielsweise von 'In QA' zurück zu 'In Progress' oder 'To Do'.
Warum das wichtig ist Diese Aktivität ist wichtig, um Schleifen durch Nacharbeit zu erkennen. Ihre Häufigkeit zeigt die Kosten mangelhafter Qualität und macht Verbesserungsmöglichkeiten bei der Entwicklung oder den Anforderungen sichtbar. Woher beziehen Wird aus dem Änderungsverlauf des Jira-Vorgangs abgeleitet. Erfasst wird der Wechsel des Felds 'status' von einem Teststatus, beispielsweise 'In QA', zu einem früheren Entwicklungsstatus wie 'In Progress'. Erfassung Timestamp der Statusänderung von einem Teststatus zu einem Entwicklungsstatus. Ereignistyp inferred

Anleitungen zum Extrahieren von Daten

So exportieren Sie Ihre Daten aus Jira Software

Schritte

Melden Sie sich bei Ihrer Jira-Software-Instanz an.
Wählen Sie in der Hauptnavigation Vorgänge und klicken Sie anschließend auf Nach Vorgängen suchen. Dadurch wird der Vorgangsnavigator geöffnet.
Wechseln Sie auf der Suchseite von der standardmäßig ausgewählten Einfachen Suche zur Erweiterten Suche, um Jira Query Language (JQL) verwenden zu können.
Geben Sie die bereitgestellte JQL-Abfrage in die Abfrageleiste ein. Ersetzen Sie die Platzhalter für den Projektschlüssel und den Zeitraum durch die für Sie passenden Werte.
Führen Sie die Abfrage aus, indem Sie auf das Suchsymbol klicken oder die Eingabetaste drücken. Daraufhin wird eine Liste aller Entwicklungselemente angezeigt, die Ihren Kriterien entsprechen.
Klicken Sie oben rechts auf der Suchergebnisseite auf das Symbol Exportieren (es kann wie ein Teilen-Symbol aussehen oder ausdrücklich so beschriftet sein) und wählen Sie XML. Verwenden Sie nicht CSV, da das XML-Format den vollständigen, strukturierten Änderungsverlauf enthält, der für die Erstellung des Event Logs erforderlich ist.
Speichern Sie die heruntergeladene XML-Datei auf Ihrem Rechner. Sie enthält einen Datensatz pro Jira-Vorgang, einschließlich aller darin verschachtelten historischen Änderungen.
Wichtiger Transformationsschritt: Die exportierte XML-Datei ist kein flaches Event Log. Sie müssen die Datei mit einem externen Skript oder einem ETL-Tool analysieren. Das Skript muss jedes Tag <item> (das einen Jira-Vorgang darstellt) in der XML-Datei durchlaufen.
Erzeugen Sie für jeden Vorgang zunächst eine Zeile für die Aktivität Entwicklungselement erstellt, und verwenden Sie dafür den Timestamp des Felds created.
Analysieren Sie anschließend die Daten <changelog> jedes Vorgangs. Erstellen Sie für jedes <changeitem>, das einen Statuswechsel darstellt, eine neue Zeile in der Ausgabedatei. Ordnen Sie den Jira-Statuswechsel (z. B. von „In Bearbeitung“ zu „In Prüfung“) der entsprechenden Geschäftsaktivität (z. B. „Entwicklung abgeschlossen“) zu und verwenden Sie den Timestamp des Übergangs als EventTime.
Füllen Sie für jede Zeile alle erforderlichen und empfohlenen Attribute aus. Extrahieren Sie dazu beispielsweise Vorgangsschlüssel, Vorgangstyp, zuständige Person und Projekt aus der XML-Struktur.
Speichern Sie die transformierten Daten nach der Verarbeitung aller Vorgänge und ihrer Verläufe als CSV-Datei. Verwenden Sie Spaltenüberschriften, die den angegebenen Attributen entsprechen. Die Datei kann anschließend in das Process-Mining-Tool hochgeladen werden.

Konfiguration

JQL-Abfragefilter: Die JQL-Abfrage ist das wichtigste Werkzeug zur Auswahl der Daten. Zu den zentralen Filtern gehören project für bestimmte Entwicklungsprojekte, issuetype für relevante Elemente wie Story, Bug oder Task und created zur Festlegung des Analysezeitraums.
Zeitraum: Für eine erste Analyse empfiehlt es sich, Daten aus einem Zeitraum von 3 bis 6 Monaten zu extrahieren. So erhalten Sie ausreichend Daten, um aussagekräftige Muster zu erkennen, während die Exportdatei überschaubar bleibt. Geben Sie den Zeitraum in JQL mit created >= 'YYYY-MM-DD' und created <= 'YYYY-MM-DD' an.
Vorgangstypen: Legen Sie die Werte für issuetype genau fest. Häufig sollten Sie Story, Bug, Task und Spike einschließen und übergeordnete Vorgänge wie Epic oder detaillierte Vorgänge wie Sub-task ausschließen, sofern diese nicht den primären Case darstellen.
Exportformat: Wählen Sie als Exportformat unbedingt XML. Der standardmäßige CSV-Export enthält die strukturierten Änderungsverläufe, die zur Rekonstruktion der Aktivitätsfolge benötigt werden, nicht zuverlässig.
Benutzerberechtigungen: Der Benutzer, der den Export ausführt, benötigt für die in der JQL-Abfrage angegebenen Jira-Projekte die Berechtigung „Projekte durchsuchen“.

a Beispielabfrage config

project = "[Your Project Key]" AND issuetype in (Story, Bug, Task) AND created >= "[Start Date in YYYY-MM-DD format]" AND created <= "[End Date in YYYY-MM-DD format]" ORDER BY created DESC

Schritte

Datenbankverbindung einrichten: Stellen Sie sicher, dass Sie über schreibgeschützte Zugangsdaten und eine Netzwerkverbindung zur SQL-Datenbank im Backend Ihrer Jira-Instanz verfügen. Diese Methode ist nur für selbst gehostete Jira-Installationen geeignet.
Mit einem SQL-Client verbinden: Stellen Sie mit einem Datenbank-Client wie DBeaver, SQL Server Management Studio oder pgAdmin und den bereitgestellten Zugangsdaten eine Verbindung zur Jira-Datenbank her.
Workflow-Status ermitteln: Öffnen Sie vor der Abfrage die Workflow-Einstellungen Ihres Jira-Projekts (Projekteinstellungen > Workflows). Notieren Sie genau die Statusnamen, die den zu verfolgenden Aktivitäten entsprechen, zum Beispiel „Backlog“, „In Bearbeitung“, „In Prüfung“ und „Erledigt“.
SQL-Abfrage anpassen: Kopieren Sie die bereitgestellte SQL-Abfrage in Ihren Client. Ersetzen Sie die Platzhalterwerte. Achten Sie besonders auf die Statusnamen in den WHERE-Klauseln der einzelnen UNION ALL-Blöcke. Sie müssen genau mit dem Workflow Ihres Projekts übereinstimmen.
Abfrageparameter festlegen: Passen Sie den Datumsfilter (WHERE ji.created >= '2023-01-01') an den gewünschten Analysezeitraum an. Außerdem empfiehlt es sich dringend, die Abfrage auf bestimmte Projekte zu beschränken. Heben Sie dazu den Kommentar des Projektfilter-Schlüssels auf und legen Sie ihn fest (--AND p.pkey IN ('PROJ1', 'PROJ2')).
Benutzerdefinierte Felder konfigurieren: Ermitteln Sie die ID des benutzerdefinierten Felds „Team Name“ in Ihrer Jira-Instanz. Sie finden sie in der Administrationsseite für benutzerdefinierte Felder. Ersetzen Sie in der Abfrage den Platzhalter 'customfield_10100' durch die tatsächliche ID.
Abfrage ausführen: Führen Sie die angepasste SQL-Abfrage für die Jira-Datenbank aus.
Ausgabe prüfen: Prüfen Sie kurz, ob die zurückgegebenen Daten Zeilen für verschiedene Aktivitäten enthalten und die Spalten wie erwartet ausgefüllt sind.
Event Log exportieren: Exportieren Sie das vollständige Ergebnis aus Ihrem SQL-Client in eine CSV-Datei. Achten Sie darauf, dass die Datei UTF-8-kodiert ist.
Upload vorbereiten: Prüfen Sie, ob die Spaltenüberschriften in der exportierten CSV-Datei den erforderlichen Attributnamen entsprechen: DevelopmentItem, Aktivität, EventTime, SourceSystem, LastDataUpdate, Assignee, ItemType, ItemPriority, ItemStatus, ProjectName und TeamName.

Konfiguration

Datenbankzugangsdaten: Erforderlich ist ein schreibgeschütztes Benutzerkonto für die Jira-Datenbank, damit Daten nicht versehentlich geändert werden.
Workflow-Statusnamen: Die Abfrage filtert nach Statusnamen wie „In Bearbeitung“ oder „Erledigt“. Diese unterscheiden sich je nach Jira-Workflow und Projekt. Ersetzen Sie die Platzhalter in der Abfrage durch die genauen Namen Ihrer Konfiguration.
Zeitraum: Die Abfrage enthält eine WHERE ji.created >= '[YYYY-MM-DD]'-Klausel, um die verarbeitete Datenmenge zu begrenzen. Für eine erste Analyse empfiehlt sich ein Zeitraum von 3 bis 6 Monaten. So bleibt das Datenvolumen überschaubar und die Abfrage wird schneller ausgeführt.
Projektfilter: Beschränken Sie die Analyse nachdrücklich auf bestimmte Projektschlüssel, indem Sie die Bedingung p.pkey IN ('[YourProjectKey]') verwenden. Eine Abfrage aller Projekte in einer großen Jira-Instanz kann sehr lange dauern.
Benutzerdefiniertes Teamfeld: „Team Name“ wird als benutzerdefiniertes Feld vorausgesetzt. Die bereitgestellte Abfrage verwendet die Platzhalter-ID customfield_10100. Ersetzen Sie diese durch die passende ID aus der Konfiguration Ihrer Jira-Instanz.
Leistung: Direkte Datenbankabfragen können viele Ressourcen beanspruchen. Führen Sie den Export außerhalb der Spitzenzeiten aus oder, vorzugsweise, auf einer Lesereplik der Produktionsdatenbank, damit die Leistung von Jira für Benutzer nicht beeinträchtigt wird.

a Beispielabfrage sql

WITH EventLogBase AS (
    SELECT
        p.pkey || '-' || ji.issuenum AS DevelopmentItem,
        au.display_name AS Assignee,
        it.pname AS ItemType,
        pr.pname AS ItemPriority,
        p.pname AS ProjectName,
        (SELECT cfv.stringvalue FROM customfieldvalue cfv JOIN customfield cf ON cfv.customfield = cf.id WHERE cf.cfname = 'Team' AND cfv.issue = ji.id LIMIT 1) AS TeamName,
        ji.created AS created_timestamp,
        cg.created AS change_timestamp,
        ci.fieldtype,
        ci.field,
        ci.oldstring,
        ci.newstring,
        s.pname as CurrentItemStatus
    FROM jiraissue ji
    LEFT JOIN project p ON ji.project = p.id
    LEFT JOIN issuetype it ON ji.issuetype = it.id
    LEFT JOIN priority pr ON ji.priority = pr.id
    LEFT JOIN issuestatus s ON ji.issuestatus = s.id
    LEFT JOIN app_user au ON ji.assignee = au.user_key
    LEFT JOIN changegroup cg ON cg.issueid = ji.id
    LEFT JOIN changeitem ci ON ci.groupid = cg.id
    WHERE ji.created >= '2023-01-01' --<<< Set your desired start date here
    --AND p.pkey IN ('PROJ1', 'PROJ2') --<<< Uncomment and set your project keys here
)
-- 1. Development Item Created
SELECT
    b.DevelopmentItem,
    'Development Item Created' AS Activity,
    b.created_timestamp AS EventTime,
    'Jira SQL' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    b.Assignee,
    b.ItemType,
    b.ItemPriority,
    b.CurrentItemStatus AS ItemStatus,
    b.ProjectName,
    b.TeamName
FROM (
    SELECT DISTINCT DevelopmentItem, created_timestamp, Assignee, ItemType, ItemPriority, CurrentItemStatus, ProjectName, TeamName
    FROM EventLogBase
) b

UNION ALL

-- 2. Item Ready for Development
SELECT DISTINCT
    b.DevelopmentItem,
    'Item Ready for Development' AS Activity,
    b.change_timestamp AS EventTime,
    'Jira SQL' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    b.Assignee,
    b.ItemType,
    b.ItemPriority,
    b.newstring AS ItemStatus,
    b.ProjectName,
    b.TeamName
FROM EventLogBase b
WHERE b.field = 'status' AND b.oldstring = 'Backlog' AND b.newstring = 'To Do' --<<< Adjust status names

UNION ALL

-- 3. Development Started
SELECT DISTINCT
    b.DevelopmentItem,
    'Development Started' AS Activity,
    b.change_timestamp AS EventTime,
    'Jira SQL' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    b.Assignee,
    b.ItemType,
    b.ItemPriority,
    b.newstring AS ItemStatus,
    b.ProjectName,
    b.TeamName
FROM EventLogBase b
WHERE b.field = 'status' AND b.newstring = 'In Progress' --<<< Adjust status names

UNION ALL

-- 4. Development Completed
SELECT DISTINCT
    b.DevelopmentItem,
    'Development Completed' AS Activity,
    b.change_timestamp AS EventTime,
    'Jira SQL' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    b.Assignee,
    b.ItemType,
    b.ItemPriority,
    b.newstring AS ItemStatus,
    b.ProjectName,
    b.TeamName
FROM EventLogBase b
WHERE b.field = 'status' AND b.oldstring = 'In Progress' AND b.newstring = 'In Review' --<<< Adjust status names

UNION ALL

-- 5. Code Review Performed
SELECT DISTINCT
    b.DevelopmentItem,
    'Code Review Performed' AS Activity,
    b.change_timestamp AS EventTime,
    'Jira SQL' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    b.Assignee,
    b.ItemType,
    b.ItemPriority,
    b.newstring AS ItemStatus,
    b.ProjectName,
    b.TeamName
FROM EventLogBase b
WHERE b.field = 'status' AND b.oldstring = 'In Review' AND b.newstring = 'Ready for QA' --<<< Adjust status names

UNION ALL

-- 6. QA Testing Started
SELECT DISTINCT
    b.DevelopmentItem,
    'QA Testing Started' AS Activity,
    b.change_timestamp AS EventTime,
    'Jira SQL' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    b.Assignee,
    b.ItemType,
    b.ItemPriority,
    b.newstring AS ItemStatus,
    b.ProjectName,
    b.TeamName
FROM EventLogBase b
WHERE b.field = 'status' AND b.newstring = 'In QA' --<<< Adjust status names

UNION ALL

-- 7. QA Testing Failed
SELECT DISTINCT
    b.DevelopmentItem,
    'QA Testing Failed' AS Activity,
    b.change_timestamp AS EventTime,
    'Jira SQL' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    b.Assignee,
    b.ItemType,
    b.ItemPriority,
    b.newstring AS ItemStatus,
    b.ProjectName,
    b.TeamName
FROM EventLogBase b
WHERE b.field = 'status' AND b.oldstring = 'In QA' AND b.newstring = 'In Progress' --<<< Adjust status names

UNION ALL

-- 8. QA Testing Completed
SELECT DISTINCT
    b.DevelopmentItem,
    'QA Testing Completed' AS Activity,
    b.change_timestamp AS EventTime,
    'Jira SQL' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    b.Assignee,
    b.ItemType,
    b.ItemPriority,
    b.newstring AS ItemStatus,
    b.ProjectName,
    b.TeamName
FROM EventLogBase b
WHERE b.field = 'status' AND b.oldstring = 'In QA' AND b.newstring = 'Ready for UAT' --<<< Adjust status names

UNION ALL

-- 9. UAT Started
SELECT DISTINCT
    b.DevelopmentItem,
    'UAT Started' AS Activity,
    b.change_timestamp AS EventTime,
    'Jira SQL' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    b.Assignee,
    b.ItemType,
    b.ItemPriority,
    b.newstring AS ItemStatus,
    b.ProjectName,
    b.TeamName
FROM EventLogBase b
WHERE b.field = 'status' AND b.newstring = 'In UAT' --<<< Adjust status names

UNION ALL

-- 10. UAT Approved
SELECT DISTINCT
    b.DevelopmentItem,
    'UAT Approved' AS Activity,
    b.change_timestamp AS EventTime,
    'Jira SQL' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    b.Assignee,
    b.ItemType,
    b.ItemPriority,
    b.newstring AS ItemStatus,
    b.ProjectName,
    b.TeamName
FROM EventLogBase b
WHERE b.field = 'status' AND b.oldstring = 'In UAT' AND b.newstring = 'Ready for Release' --<<< Adjust status names

UNION ALL

-- 11. Prepared For Release
SELECT DISTINCT
    b.DevelopmentItem,
    'Prepared For Release' AS Activity,
    b.change_timestamp AS EventTime,
    'Jira SQL' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    b.Assignee,
    b.ItemType,
    b.ItemPriority,
    b.newstring AS ItemStatus,
    b.ProjectName,
    b.TeamName
FROM EventLogBase b
WHERE b.field = 'status' AND b.newstring = 'Ready for Release' --<<< Adjust status names

UNION ALL

-- 12. Deployed To Production
SELECT DISTINCT
    b.DevelopmentItem,
    'Deployed To Production' AS Activity,
    b.change_timestamp AS EventTime,
    'Jira SQL' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    b.Assignee,
    b.ItemType,
    b.ItemPriority,
    b.newstring AS ItemStatus,
    b.ProjectName,
    b.TeamName
FROM EventLogBase b
WHERE b.field = 'status' AND b.newstring = 'Released' --<<< Adjust status names

UNION ALL

-- 13. Development Item Closed
SELECT DISTINCT
    b.DevelopmentItem,
    'Development Item Closed' AS Activity,
    b.change_timestamp AS EventTime,
    'Jira SQL' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    b.Assignee,
    b.ItemType,
    b.ItemPriority,
    b.newstring AS ItemStatus,
    b.ProjectName,
    b.TeamName
FROM EventLogBase b
WHERE b.field = 'status' AND b.newstring = 'Closed' --<<< Adjust status names

UNION ALL

-- 14. Development Item Canceled
SELECT DISTINCT
    b.DevelopmentItem,
    'Development Item Canceled' AS Activity,
    b.change_timestamp AS EventTime,
    'Jira SQL' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    b.Assignee,
    b.ItemType,
    b.ItemPriority,
    b.newstring AS ItemStatus,
    b.ProjectName,
    b.TeamName
FROM EventLogBase b
WHERE b.field = 'status' AND b.newstring IN ('Canceled', 'Won''t Do', 'Rejected'); --<<< Adjust status names

Schritte

Voraussetzungen: Stellen Sie sicher, dass Python 3 auf Ihrem System installiert ist. Installieren Sie die benötigten Bibliotheken requests für API-Aufrufe und pandas zur Datenverarbeitung mit folgendem Befehl: pip install requests pandas.
Jira-API-Token erstellen: Melden Sie sich bei Ihrer Jira-Instanz an. Öffnen Sie die Einstellungen Ihres Benutzerprofils, wechseln Sie zu „Sicherheit“ und wählen Sie „API-Token erstellen und verwalten“. Erstellen Sie ein Token und kopieren Sie es sicher. Das Skript verwendet dieses Token zur Authentifizierung anstelle eines Passworts.
Python-Skript konfigurieren: Kopieren Sie das bereitgestellte Python-Skript in eine Datei, zum Beispiel extract_jira_log.py. Öffnen Sie die Datei und tragen Sie im Konfigurationsabschnitt oben die URL Ihrer Jira-Site, Ihre E-Mail-Adresse und das soeben erstellte API-Token ein.
JQL-Abfrage festlegen: Passen Sie die Variable JQL_QUERY im Skript an. Diese Abfrage legt fest, welche Vorgänge extrahiert werden. Als Ausgangspunkt können Sie nach Projekt, Vorgangstyp und einem bestimmten Zeitraum filtern, zum Beispiel: project = "MyProject" AND issuetype in (Story, Bug, Task) AND updated >= -180d.
Statuszuordnung anpassen: Prüfen Sie das Wörterbuch STATUS_MAPPING im Skript. Diese Zuordnung überträgt die spezifischen Jira-Workflow-Status Ihrer Organisation in standardisierte Aktivitäten für Process Mining. Passen Sie die Schlüssel, also die Jira-Statusnamen, genau an Ihren Workflow an.
Skript ausführen: Starten Sie das Skript in Ihrem Terminal mit dem Befehl python extract_jira_log.py. Das Skript verbindet sich mit der Jira-API, ruft die Vorgangsdaten ab und verarbeitet die Änderungsverläufe.
API-Seitenaufteilung verarbeiten: Das Skript verarbeitet die Seitenaufteilung automatisch und ruft Vorgänge in Gruppen von 50 ab. Es sendet so lange weitere Anfragen, bis alle Vorgänge der JQL-Abfrage abgerufen wurden.
Änderungsverläufe der Vorgänge verarbeiten: Das Skript ruft für jeden Vorgang den vollständigen Verlauf ab. Es ermittelt das Erstellungsereignis und durchläuft anschließend alle Statusänderungen. Für jeden relevanten Übergang wird anhand Ihrer STATUS_MAPPING eine neue Zeile im Event Log erstellt.
Event-Log-Datei erstellen: Nach der Verarbeitung aller Vorgänge stellt das Skript die Ereignisse in einem pandas-DataFrame zusammen, ergänzt erforderliche Metadatenspalten wie SourceSystem und LastDataUpdate und speichert das fertige Event Log im selben Verzeichnis als CSV-Datei jira_event_log.csv.

Konfiguration

JIRA_URL: Die Basis-URL Ihrer Jira-Instanz, zum Beispiel https://your-company.atlassian.net.
JIRA_EMAIL: Die E-Mail-Adresse des Benutzerkontos, das zur Authentifizierung verwendet wird.
JIRA_API_TOKEN: Das in den Sicherheitseinstellungen des Jira-Benutzers erstellte API-Token zur Authentifizierung des Skripts.
JQL_QUERY: Die Jira Query Language-Abfrage, mit der die zu extrahierenden Vorgänge gefiltert werden. Begrenzen Sie das Datenvolumen, indem Sie nach einem Zeitraum filtern, etwa den letzten 6 bis 12 Monaten. Filtern Sie außerdem nach Projekt und den relevanten Vorgangstypen wie Story, Bug oder Task, damit Sie den richtigen Prozess analysieren.
STATUS_MAPPING: Ein Python-Wörterbuch, das Ihre Jira-Workflow-Statusnamen den erforderlichen generischen Aktivitätsnamen zuordnet. Diese Konfiguration ist entscheidend für die Genauigkeit des Prozessmodells. Passen Sie sie an den Workflow Ihres Projekts an.
Voraussetzungen: Das Skript benötigt ein Jira-Benutzerkonto mit Lesezugriff auf die zu extrahierenden Projekte und Vorgänge. Der Benutzer muss außerdem zur Verwendung der REST-API berechtigt sein.

a Beispielabfrage python

import requests
import pandas as pd
from requests.auth import HTTPBasicAuth
from datetime import datetime, timezone
import json

class=class="hl-string">"hl-comment"># --- CONFIGURATION SECTION ---
class=class="hl-string">"hl-comment"># Replace with your Jira instance details
JIRA_URL = class="hl-string">"https://[your-company].atlassian.net"
JIRA_EMAIL = class="hl-string">"[your-email@example.com]"
JIRA_API_TOKEN = class="hl-string">"[your-jira-api-token]"

class=class="hl-string">"hl-comment"># JQL query to select the issues for extraction
class=class="hl-string">"hl-comment"># Best practice: Filter by project, issue type, and a date range
JQL_QUERY = class="hl-string">'project = "PROJ" AND issuetype in (Story, Bug, Task) AND updated >= -180d'

class=class="hl-string">"hl-comment"># --- STATUS MAPPING ---
class=class="hl-string">"hl-comment"># CRITICAL: Customize this mapping to match your Jira workflow statuses.
class=class="hl-string">"hl-comment"># The key is the Jira status name (case-sensitive) and the value is the desired Activity name.
STATUS_MAPPING = {
    class=class="hl-string">"hl-comment"># Example Mappings - Adjust to your workflow
    class="hl-string">'To Do': class="hl-string">'Item Ready for Development',
    class="hl-string">'In Progress': class="hl-string">'Development Started',
    class="hl-string">'In Review': class="hl-string">'Development Completed',
    class="hl-string">'Code Review': class="hl-string">'Code Review Performed', class=class="hl-string">"hl-comment"># Often combined with class="hl-string">'In Review' -> class="hl-string">'In QA' transition
    class="hl-string">'In QA': class="hl-string">'QA Testing Started',
    class="hl-string">'QA In Progress': class="hl-string">'QA Testing Started',
    class="hl-string">'Done from QA to In Progress': class="hl-string">'QA Testing Failed', class=class="hl-string">"hl-comment"># Special case for backward transitions
    class="hl-string">'UAT': class="hl-string">'UAT Started',
    class="hl-string">'Ready for Release': class="hl-string">'Prepared For Release',
    class="hl-string">'Done': class="hl-string">'Deployed To Production', class=class="hl-string">"hl-comment"># Often corresponds to final class="hl-string">'Done' state
    class="hl-string">'Released': class="hl-string">'Deployed To Production',
    class="hl-string">'Closed': class="hl-string">'Development Item Closed',
    class="hl-string">'Canceled': class="hl-string">'Development Item Canceled',
    class="hl-string">'Won\'t Doclass="hl-string">': 'Development Item Canceled',
    class=class="hl-string">"hl-comment"># Transitions to specific activities
    class="hl-string">'transition_In Review_to_In QA': class="hl-string">'Code Review Performed',
    class="hl-string">'transition_In QA_to_Ready for Release': class="hl-string">'QA Testing Completed',
    class="hl-string">'transition_UAT_to_Ready for Release': class="hl-string">'UAT Approved',
}

def get_team_from_issue(issue_fields):
    class=class="hl-string">"hl-comment"># Placeholder function to extract Team Name.
    class=class="hl-string">"hl-comment"># Customize this based on how team information is stored in your Jira.
    class=class="hl-string">"hl-comment"># Common sources are Components, Labels, or a custom field.
    if class="hl-string">'components' in issue_fields and issue_fields[class="hl-string">'components']:
        return issue_fields[class="hl-string">'components'][0][class="hl-string">'name']
    return None

def extract_jira_event_log():
    class="hl-string">"""Extracts an event log from Jira based on a JQL query."""
    auth = HTTPBasicAuth(JIRA_EMAIL, JIRA_API_TOKEN)
    headers = {
        class="hl-string">"Accept": class="hl-string">"application/json"
    }
    search_url = fclass="hl-string">"{JIRA_URL}/rest/api/3/search"

    event_log = []
    start_at = 0
    max_results = 50
    total_issues = 1 class=class="hl-string">"hl-comment"># Initialize to enter loop

    while start_at < total_issues:
        params = {
            class="hl-string">'jql': JQL_QUERY,
            class="hl-string">'startAt': start_at,
            class="hl-string">'maxResults': max_results,
            class="hl-string">'expand': class="hl-string">'changelog'
        }
        response = requests.get(search_url, headers=headers, params=params, auth=auth)
        response.raise_for_status() class=class="hl-string">"hl-comment"># Exit if the request fails
        data = response.json()

        total_issues = data[class="hl-string">'total']
        issues = data[class="hl-string">'issues']

        last_data_update = datetime.now(timezone.utc).isoformat()

        for issue in issues:
            issue_key = issue[class="hl-string">'key']
            fields = issue[class="hl-string">'fields']
            
            class=class="hl-string">"hl-comment"># Common attributes for all events of this issue
            common_attrs = {
                class="hl-string">'DevelopmentItem': issue_key,
                class="hl-string">'ItemType': fields.get(class="hl-string">'issuetype', {}).get(class="hl-string">'name'),
                class="hl-string">'ProjectName': fields.get(class="hl-string">'project', {}).get(class="hl-string">'name'),
                class="hl-string">'SourceSystem': class="hl-string">'Jira Software'
            }

            class=class="hl-string">"hl-comment"># 1. Development Item Created event
            created_time = pd.to_datetime(fields[class="hl-string">'created']).isoformat()
            event_log.append({
                **common_attrs,
                class="hl-string">'Activity': class="hl-string">'Development Item Created',
                class="hl-string">'EventTime': created_time,
                class="hl-string">'Assignee': fields.get(class="hl-string">'creator', {}).get(class="hl-string">'displayName'),
                class="hl-string">'ItemPriority': fields.get(class="hl-string">'priority', {}).get(class="hl-string">'name'),
                class="hl-string">'ItemStatus': class="hl-string">'Created',
                class="hl-string">'TeamName': get_team_from_issue(fields),
                class="hl-string">'LastDataUpdate': last_data_update
            })

            class=class="hl-string">"hl-comment"># Process changelog for status transitions
            if class="hl-string">'changelog' in issue and issue[class="hl-string">'changelog'][class="hl-string">'histories']:
                for history in issue[class="hl-string">'changelog'][class="hl-string">'histories']:
                    event_time = pd.to_datetime(history[class="hl-string">'created']).isoformat()
                    author = history.get(class="hl-string">'author', {}).get(class="hl-string">'displayName')

                    for item in history[class="hl-string">'items']:
                        if item[class="hl-string">'field'] == class="hl-string">'status':
                            from_status = item[class="hl-string">'fromString']
                            to_status = item[class="hl-string">'toString']
                            activity = None

                            class=class="hl-string">"hl-comment"># Handle specific transitions first
                            transition_key = fclass="hl-string">"transition_{from_status.replace(' ', '')}_to_{to_status.replace(' ', '')}"
                            if transition_key in STATUS_MAPPING:
                                activity = STATUS_MAPPING[transition_key]
                            class=class="hl-string">"hl-comment"># Handle backward transitions (rework)
                            elif to_status == class="hl-string">'In Progress' and from_status in [class="hl-string">'In QA', class="hl-string">'QA In Progress', class="hl-string">'In Review']:
                                activity = class="hl-string">'QA Testing Failed'
                            class=class="hl-string">"hl-comment"># Handle general status changes
                            elif to_status in STATUS_MAPPING:
                                activity = STATUS_MAPPING[to_status]
                            
                            if activity:
                                event_log.append({
                                    **common_attrs,
                                    class="hl-string">'Activity': activity,
                                    class="hl-string">'EventTime': event_time,
                                    class="hl-string">'Assignee': author, class=class="hl-string">"hl-comment"># Person who made the change
                                    class="hl-string">'ItemPriority': fields.get(class="hl-string">'priority', {}).get(class="hl-string">'name'),
                                    class="hl-string">'ItemStatus': to_status,
                                    class="hl-string">'TeamName': get_team_from_issue(fields),
                                    class="hl-string">'LastDataUpdate': last_data_update
                                })
        
        start_at += len(issues)
        print(fclass="hl-string">"Processed {start_at} of {total_issues} issues...")

    if not event_log:
        print(class="hl-string">"No events were generated. Check your JQL query and STATUS_MAPPING.")
        return

    class=class="hl-string">"hl-comment"># Convert to DataFrame
    df = pd.DataFrame(event_log)

    class=class="hl-string">"hl-comment"># Ensure required columns are present
    required_cols = [class="hl-string">'DevelopmentItem', class="hl-string">'Activity', class="hl-string">'EventTime', class="hl-string">'SourceSystem', class="hl-string">'LastDataUpdate']
    recommended_cols = [class="hl-string">'Assignee', class="hl-string">'ItemType', class="hl-string">'ItemPriority', class="hl-string">'ItemStatus', class="hl-string">'ProjectName', class="hl-string">'TeamName']
    all_cols = required_cols + [col for col in recommended_cols if col in df.columns]
    df = df[all_cols]
    
    class=class="hl-string">"hl-comment"># Save to CSV
    df.to_csv(class="hl-string">'jira_event_log.csv', index=False)
    print(class="hl-string">"\nExtraction complete. Event log saved to jira_event_log.csv")

if __name__ == class="hl-string">"__main__":
    extract_jira_event_log()

Schritte

Prüfen Sie, ob Jira Automation, ausgehende Webhooks und ein HTTPS-Empfänger für das Jira-Projekt verfügbar sind. Der Empfänger muss POST-Anfragen annehmen und die vollständige JSON-Nutzlast einschließlich Ereignismetadaten und Vorgangsfeldern speichern.
Legen Sie vor dem Erstellen der Regeln das Ereignisschema fest. Verwenden Sie Development Item als Case-ID, Activity als Aktivitätsname, EventTime als Ereignis-Timestamp, SourceSystem als Jira Software und LastDataUpdate als Zeitstempel für Datenübernahme oder Aktualisierung. Konfigurieren Sie den Empfänger so, dass der Jira-Vorgangsschlüssel als DevelopmentItem erhalten bleibt.
Erstellen Sie Jira-Automatisierungsregeln mit Auslösern für Vorgangsereignisse. Richten Sie Regeln für die Erstellung von Vorgängen, Workflow-Statusübergänge, Änderungen der Lösung, Änderungen der Fix Version, sofern zutreffend, sowie verfügbare integrierte Bereitstellungs- oder Prüfereignisse ein. Jira bietet keinen einheitlichen Workflow für alle Projekte. Ordnen Sie daher die lokalen Statusnamen und Übergangsbedingungen den erforderlichen Aktivitäten zu.
Richten Sie jede Regel so ein, dass sie einen Webhook an [Your webhook endpoint] sendet. Verwenden Sie POST und JSON. Fügen Sie Vorgangsschlüssel, Vorgangstyp, zuständige Person, Priorität, Status, Projekt, Teamfeld (sofern verfügbar), Ereignis-Timestamp, Übergangsinformationen, Lösung, Fix-Version-Werte und Jira-Ereigniskennung hinzu. Verlassen Sie sich nicht darauf, dass ProcessMind Aktivitäten aus dem Statusverlauf ableitet.
Richten Sie im Webhook-Empfänger oder in der Datenübernahmeschicht explizite Aktivitätszuordnungen ein. Jeder relevante Webhook muss zu einer Zeile im Event Log werden. Ordnen Sie die Erstellung eines Vorgangs der Aktivität „Entwicklungselement erstellt“ zu, den Übergang zur Entwicklungsbereitschaft „Element bereit für Entwicklung“, den Übergang zu „In Bearbeitung“ „Entwicklung gestartet“, den Abschluss von Prüfung oder Entwicklung „Entwicklung abgeschlossen“, Prüfungsübergänge oder integrierte Prüfereignisse „Code-Review durchgeführt“, Testübergänge „QA-Test gestartet“, Rückschritte während der QA „QA-Test fehlgeschlagen“, erfolgreiche Tests „QA-Test abgeschlossen“, UAT-Übergänge „UAT gestartet“ und „UAT genehmigt“, die Release-Vorbereitung „Für Release vorbereitet“, die Bereitstellung in der Produktion oder den konfigurierten Release-Abschluss „In Produktion bereitgestellt“, den Abschluss „Entwicklungselement geschlossen“ und die Stornierung oder Ablehnung „Entwicklungselement abgebrochen“.
Verwenden Sie für die Zuordnung die vom Prozessverantwortlichen freigegebene Jira-Workflow- und Ereigniskonfiguration. Ordnen Sie lokale Status wie Backlog, To Do, Ready for Dev, In Progress, In Review, Ready for QA, In QA, In Testing, In UAT, Ready for Release, Done, Released, Closed, Canceled, Rejected oder Won't Do nur dann zu, wenn sie die vorgesehene fachliche Bedeutung haben. Erstellen Sie nicht mehrere Zeilen für denselben Webhook, es sei denn, die Nutzlast weist ausdrücklich mehrere relevante Ereignisse aus.
Überführen Sie jedes Ereignis in das erforderliche Schema. DevelopmentItem muss den Jira-Vorgangsschlüssel enthalten, Activity genau einen der 14 erforderlichen Aktivitätsnamen, EventTime den Timestamp des Ereignisses, SourceSystem den Wert Jira Software und LastDataUpdate den Timestamp der Datenübernahme. Ergänzen Sie empfohlene Attribute, sofern vorhanden, darunter Assignee, ItemType, ItemPriority, ItemStatus, ProjectName und TeamName.
Verhindern Sie doppelte Webhook-Zustellungen anhand der Jira-Ereigniskennung, des Vorgangsschlüssels, des Ereignis-Timestamps, der Übergangskennung und der Aktivitätszuordnung. Webhooks können erneut zugestellt werden. Der Empfänger muss solche Wiederholungen daher ohne doppelte Verarbeitung behandeln. Behalten Sie den ursprünglichen Ereignis-Timestamp bei und ersetzen Sie ihn nicht durch den Zeitpunkt der Datenübernahme.
Prüfen Sie das resultierende Event Log auf Schema, Timestamps, Case-IDs, Aktivitätsnamen, Duplikatbehandlung und Abdeckung des konfigurierten Zeitraums. Stellen Sie sicher, dass alle 14 Aktivitätswerte als Zeilen vorkommen können und ProcessMind keine Aktivitäten später ableiten muss.
Exportieren Sie das normalisierte Event Log als CSV oder in einem anderen von ProcessMind unterstützten Event-Log-Format. Fügen Sie für jedes explizite Ereignis eine Zeile mit den Spalten DevelopmentItem, Activity, EventTime, SourceSystem, LastDataUpdate, Assignee, ItemType, ItemPriority, ItemStatus, ProjectName und TeamName ein. Laden Sie die Datei hoch oder verbinden Sie die Ausgabe des Empfängers gemäß der ProcessMind-Konfiguration für die Datenübernahme.

Konfiguration

Methode und Abfragesprache: Konfigurieren Sie Jira-Automatisierungsregeln und einen HTTPS-Webhook-Empfänger. Der Abfragewert lautet config, da die Extraktion über Regelkonfiguration und Ereignisnormalisierung erfolgt und nicht über eine Jira-Datenbankabfrage.
Case-ID: Verwenden Sie den Jira-Vorgangsschlüssel als DevelopmentItem. Fassen Sie nicht mehrere Vorgänge zu einem Case zusammen.
Erforderliche Aktivitäten: Richten Sie explizite Zuordnungen für Entwicklungselement erstellt, Element bereit für Entwicklung, Entwicklung gestartet, Entwicklung abgeschlossen, Code-Review durchgeführt, QA-Test gestartet, QA-Test fehlgeschlagen, QA-Test abgeschlossen, UAT gestartet, UAT genehmigt, Für Release vorbereitet, In Produktion bereitgestellt, Entwicklungselement geschlossen und Entwicklungselement abgebrochen ein.
Ereignisauslöser: Aktivieren Sie Auslöser für die Erstellung von Vorgängen, Workflow-Übergänge, Lösungen, Fix-Versionen, integrierte Reviews und Bereitstellungen nur dann, wenn sie in der Jira-Konfiguration unterstützt werden und relevant sind.
Statuszuordnung: Pflegen Sie eine projektspezifische Zuordnungstabelle oder Konfiguration für lokale Jira-Status und Übergänge. Status wie In Progress, In QA, Done oder Closed müssen entsprechend der freigegebenen Workflow-Semantik interpretiert werden.
Zeitraum: Erfassen Sie für die erste Validierung Ereignisse aus einem Zeitraum von 3 bis 6 Monaten. Starten Sie bei kontinuierlichem Streaming den Empfänger vor dem gewünschten Beobachtungszeitraum und halten Sie eine Strategie zur erneuten Wiedergabe oder zum Nachladen von Ereignissen vor, die während eines Ausfalls entstanden sind.
Filter: Filtern Sie nach den vorgesehenen Jira-Projekten, Vorgangstypen, Workflows und dem Ereigniszeitraum. Company Code und Document Type sind keine standardmäßigen Jira-Software-Konzepte. Verwenden Sie stattdessen Projekte, Vorgangstypen und andere konfigurierte Jira-Felder.
Nutzlastfelder: Fügen Sie Vorgangsschlüssel, Vorgangstyp, zuständige Person, Priorität, Status, Projekt, Teamfeld (sofern verfügbar), Ereignis-Timestamp, Übergangsdetails, Lösung, Fix Version und Ereigniskennung hinzu.
Verarbeitung von Timestamps: Speichern Sie Timestamps nach Möglichkeit mit Zeitzoneninformationen. Verwenden Sie für EventTime den Timestamp des Quellereignisses und für LastDataUpdate den Aktualisierungszeitpunkt des Empfängers.
Zustellung und Sicherheit: Verwenden Sie HTTPS, eine vom Empfänger unterstützte Authentifizierung, Anfragevalidierung, Wiederholungsbehandlung und idempotente Verarbeitung. Speichern Sie Zugangsdaten nicht direkt in Zeilen des Event Logs.
Leistung: Verwenden Sie asynchrone Datenübernahme, gegebenenfalls Stapelverarbeitung nach dem Empfang, indizierte Schlüssel zur Duplikaterkennung und bei großen Datenmengen eine Partitionierung nach Ereignisdatum. Vermeiden Sie eine unbegrenzte Speicherung von Webhook-Nutzlasten im operativen Empfänger.
Voraussetzungen: Erforderlich sind Berechtigungen für Jira Automation, die Berechtigung zum Konfigurieren von Projektregeln, Zugriff auf die relevanten Vorgänge und Felder, ein erreichbarer HTTPS-Endpunkt sowie gegebenenfalls ein passender Jira-Tarif oder eine Integrationsfunktion für ausgehende Webhooks und Bereitstellungsereignisse.
Datenqualität: Legen Sie fest, wie mit gelöschten Vorgängen, umbenannten Status, fehlenden zuständigen Personen oder Teamfeldern, Zeitzonenumrechnungen, doppelten Zustellungen und verspätet eingehenden Ereignissen umzugehen ist.

a Beispielabfrage config

{
  "method": "Real-time Event Streaming via Automation Webhooks",
  "approach": "Jira Automation rules send issue event JSON payloads to a configured HTTPS endpoint. The receiver normalizes each qualifying payload into one explicit event-log row.",
  "queryLanguage": "config",
  "confidence": "verified",
  "caseIdentifier": "DevelopmentItem",
  "sourceSystem": "Jira Software",
  "endpoint": "[Your webhook endpoint]",
  "dateFrom": "[Start date and time]",
  "dateTo": "[End date and time]",
  "filters": {
    "projects": "[Configure based on your Jira projects]",
    "issueTypes": "[Configure based on your Jira issue types]"
  },
  "outputColumns": [
    "DevelopmentItem",
    "Activity",
    "EventTime",
    "SourceSystem",
    "LastDataUpdate",
    "Assignee",
    "ItemType",
    "ItemPriority",
    "ItemStatus",
    "ProjectName",
    "TeamName"
  ],
  "activityMappings": [
    {
      "activity": "Development Item Created",
      "trigger": "Issue created",
      "condition": "The Jira issue creation event is received within the configured scope"
    },
    {
      "activity": "Item Ready for Development",
      "trigger": "Workflow transition",
      "condition": "The issue transitions from a configured backlog or specification status to a configured ready-for-development status"
    },
    {
      "activity": "Development Started",
      "trigger": "Workflow transition",
      "condition": "The issue transitions to the configured active development status, commonly In Progress"
    },
    {
      "activity": "Development Completed",
      "trigger": "Workflow transition",
      "condition": "The issue transitions from active development to a configured development-complete, review, or QA-ready status"
    },
    {
      "activity": "Code Review Performed",
      "trigger": "Workflow transition or configured review integration event",
      "condition": "A qualifying code review completion event is received, such as a transition from review to QA-ready"
    },
    {
      "activity": "QA Testing Started",
      "trigger": "Workflow transition",
      "condition": "The issue transitions to a configured QA or testing status"
    },
    {
      "activity": "QA Testing Failed",
      "trigger": "Workflow transition",
      "condition": "The issue transitions backward from a configured QA or testing status to a development or rework status"
    },
    {
      "activity": "QA Testing Completed",
      "trigger": "Workflow transition",
      "condition": "The issue leaves the configured primary QA or testing status through a successful testing transition"
    },
    {
      "activity": "UAT Started",
      "trigger": "Workflow transition",
      "condition": "The issue transitions to a configured UAT or user acceptance testing status"
    },
    {
      "activity": "UAT Approved",
      "trigger": "Workflow transition",
      "condition": "The issue transitions from UAT to a configured approval, release-ready, or completed status"
    },
    {
      "activity": "Prepared For Release",
      "trigger": "Workflow transition or Fix Version field change",
      "condition": "The issue reaches a configured release-ready status or receives a qualifying Fix Version value"
    },
    {
      "activity": "Deployed To Production",
      "trigger": "Configured deployment event or workflow transition",
      "condition": "A production deployment event is received, or the configured final release transition represents production deployment"
    },
    {
      "activity": "Development Item Closed",
      "trigger": "Workflow transition or resolution change",
      "condition": "The issue reaches the configured Closed status and, where required, has a qualifying Resolution value"
    },
    {
      "activity": "Development Item Canceled",
      "trigger": "Workflow transition or resolution change",
      "condition": "The issue reaches a configured canceled, rejected, or won't-do terminal state and, where required, has a qualifying Resolution value"
    }
  ],
  "normalization": {
    "oneRowPerEvent": true,
    "developmentItem": "payload.issue.key",
    "eventTime": "payload.event.timestamp or the source timestamp supplied by the Jira event",
    "sourceSystem": "Jira Software",
    "lastDataUpdate": "receiver ingestion timestamp",
    "assignee": "payload.issue.fields.assignee.displayName or account identifier when available",
    "itemType": "payload.issue.fields.issuetype.name",
    "itemPriority": "payload.issue.fields.priority.name",
    "itemStatus": "payload.issue.fields.status.name",
    "projectName": "payload.issue.fields.project.name",
    "teamName": "payload.issue.fields.team or the configured team field when available"
  },
  "deduplication": {
    "key": "payload.event.id, payload.issue.key, payload.event.timestamp, payload.transition.id, mapped activity",
    "behavior": "Ignore repeated deliveries with the same deduplication key while retaining the first valid event row"
  },
  "requiredConfiguration": [
    "Configure one or more Jira Automation rules for each qualifying event type",
    "Configure the webhook receiver at [Your webhook endpoint]",
    "Configure local Jira status and transition mappings",
    "Configure project and issue-type filters at [Configure based on your Jira projects] and [Configure based on your Jira issue types]",
    "Configure authentication and request validation according to the receiver implementation"
  ]
}

Möchten Sie loslegen?

Bereiten Sie Ihre Daten mit diesem Template vor und beginnen Sie noch heute, Ihren Softwareentwicklungszyklus zu optimieren. Gewinnen Sie Erkenntnisse, um die Auslieferung zu beschleunigen und die Qualität zu steigern.

Zurück zum Leitfaden zur Prozessverbesserung Template herunterladen

Optimieren Sie Ihren SDLC in Jira Software. Starten Sie noch heute!

Ermitteln Sie Ineffizienzen und verkürzen Sie die Zykluszeit in Ihrem SDLC um 30 %.

Starten Sie Ihre kostenlose Testphase

Keine Kreditkarte erforderlich. Beginnen Sie in wenigen Minuten mit der Optimierung.

Ihr Daten-Template für den Softwareentwicklungszyklus

Ihr Daten-Template für den Softwareentwicklungszyklus

Attribute des Softwareentwicklungszyklus

Aktivitäten im Softwareentwicklungszyklus

Anleitungen zum Extrahieren von Daten

Jira-JQL-Abfrage mit integriertem CSV- oder XML-Export

Schritte

Konfiguration

a Beispielabfrage config

Direkte Jira-Datenbankabfrage mit SQL (Self-Hosted)

Schritte

Konfiguration

a Beispielabfrage sql

Python-Skript mit der offiziellen Jira-REST-API

Schritte

Konfiguration

a Beispielabfrage python

Echtzeit-Event-Streaming über Automatisierungs-Webhooks

Schritte

Konfiguration

a Beispielabfrage config

Möchten Sie loslegen?

Optimieren Sie Ihren SDLC in Jira Software. Starten Sie noch heute!

Ihr Daten-Template für den Softwareentwicklungszyklus

Ihr Daten-Template für den Softwareentwicklungszyklus

Attribute des Softwareentwicklungszyklus

Aktivitäten im Softwareentwicklungszyklus

Anleitungen zum Extrahieren von Daten

Jira-JQL-Abfrage mit integriertem CSV- oder XML-Export

Schritte

Konfiguration

a Beispielabfrage config

Direkte Jira-Datenbankabfrage mit SQL (Self-Hosted)

Schritte

Konfiguration

a Beispielabfrage sql

Python-Skript mit der offiziellen Jira-REST-API

Schritte

Konfiguration

a Beispielabfrage python

Echtzeit-Event-Streaming über Automatisierungs-Webhooks

Schritte

Konfiguration

a Beispielabfrage config

Möchten Sie loslegen?

Optimieren Sie Ihren SDLC in Jira Software. Starten Sie noch heute!

Der Schutz Ihrer Daten ist uns wichtig