Ihr Software Development Lifecycle Daten-Template

Azure DevOps
Ihr Software Development Lifecycle Daten-Template

Ihr Software Development Lifecycle Daten-Template

Diese Vorlage bietet eine klare Roadmap zur Vorbereitung Ihrer Software Development Lifecycle-Daten für das Process Mining. Sie umreißt die wesentlichen Datenattribute, die Sie sammeln müssen, die Schlüsselaktivitäten, die verfolgt werden sollen, und bietet praktische Anleitungen, wie diese Informationen speziell aus Azure DevOps extrahiert werden können. Nutzen Sie diese Ressource, um sicherzustellen, dass Ihre Daten perfekt für eine aussagekräftige Analyse und Prozessoptimierung strukturiert sind.
  • Empfohlene Attribute zur Erfassung
  • Schlüsselaktivitäten zur Verfolgung Ihres SDLC
  • Detaillierte Extraktionsanleitung für Azure DevOps
Neu bei Event-Logs? Erfahren Sie wie Sie ein Process-Mining-Event-Log erstellen.

Software Development Lifecycle Attribute

Dies sind die empfohlenen Datenfelder, die Sie in Ihren Event Log aufnehmen sollten, um eine umfassende Software Development Lifecycle Analyse und Optimierung zu ermöglichen.
5 Erforderlich 8 Empfohlen 6 Optional
Name Beschreibung
`Development Item`
DevelopmentItem
Der eindeutige Identifier für eine einzelne Arbeitseinheit, wie ein Feature, Bug oder eine User Story, der als Case Identifier für den Prozess dient.
Beschreibung

Das Development Item stellt eine eigenständige Arbeitseinheit dar, die in Azure DevOps verfolgt wird. Jedes Element, identifiziert durch seine einzigartige ID, ist das zentrale Objekt, um das sich alle Prozessaktivitäten drehen, von der Erstellung und Planung über die Entwicklung, das Testing bis zum Deployment.

In der Process Mining Analyse ist dieses Attribut grundlegend, um alle zugehörigen Events zu einer einzigen Case Journey zu korrelieren. Es ermöglicht die Rekonstruktion des End-to-End-Lifecycle für jedes Work Item und die Analyse von Cycle Times, Prozessabweichungen und Rework-Loops auf individueller Elementbasis.

Bedeutung

Dies ist der Kern-Identifier, der alle Prozessschritte zu einem kohärenten Case verbindet und so eine End-to-End-Analyse des Software Development Lifecycle ermöglicht.

Datenquelle

Dies entspricht dem Feld "ID" eines Work Items in Azure DevOps Boards. Es ist über die Azure DevOps REST API für Work Item Tracking zugänglich.

Beispiele
10234102351023610237
Aktivitätsname
ActivityName
Der Name des spezifischen Events oder der Aufgabe, das/die zu einem bestimmten Zeitpunkt im Entwicklungslebenszyklus für ein Work Item aufgetreten ist.
Beschreibung

Der Aktivitätsname beschreibt einen spezifischen Schritt oder Meilenstein im Prozess, wie "Entwicklung gestartet", "Pull Request erstellt" oder "In Produktion bereitgestellt". Diese Aktivitäten werden aus Änderungen am Status des Work Items, verknüpften Events wie Builds oder Pull Requests oder benutzerdefinierten Events abgeleitet.

Dieses Attribut ist essentiell für die Erstellung der Prozesslandkarte, die den Workflow visuell darstellt. Es ermöglicht Analysten, die Abfolge von Events zu verstehen, gemeinsame Pfade zu identifizieren, Bottlenecks zwischen spezifischen Aktivitäten zu entdecken und die Häufigkeit jedes Schrittes zu analysieren.

Bedeutung

Es definiert die Schritte im Prozess, bildet das Rückgrat der Prozesslandkarte und ermöglicht die Analyse von Workflow, Bottlenecks und Abweichungen.

Datenquelle

Dies wird typischerweise aus Änderungen im Feld "State" eines Work Items oder aus verknüpften Events wie Builds, Commits und Pull Requests abgeleitet. Die Work Item History liefert die Rohdaten für diese Events.

Beispiele
Entwicklung gestartetPull Request abgeschlossenQA Testing fehlgeschlagenIn `Production` bereitgestelltWork Item geschlossen
Ereigniszeit
EventTime
Der präzise Timestamp, der angibt, wann eine spezifische Aktivität oder ein Event für ein Development Item aufgetreten ist.
Beschreibung

Event Time erfasst Datum und Uhrzeit jeder Aktivität im Entwicklungslebenszyklus. Dieser Timestamp ist das grundlegende zeitliche Element, das verwendet wird, um Events chronologisch zu ordnen und Dauern zwischen ihnen zu berechnen.

In der Analyse ist dieses Attribute entscheidend für die Berechnung aller zeitbasierten Metriken, einschließlich Cycle Times, Verarbeitungszeiten und Wartezeiten. Es ermöglicht die Erstellung eines zeitlich geordneten Event Log, welches die erforderliche Eingabe für jede Process Mining-Analyse ist. Es wird verwendet, um Verzögerungen zu diagnostizieren, die Leistung gegenüber SLAs zu messen und Trends im Laufe der Zeit zu verfolgen.

Bedeutung

Dieser Timestamp liefert die chronologische Reihenfolge der Events, was essentiell für die Berechnung aller durationsbasierten KPIs und das Verständnis des Prozessflusses und der Bottlenecks ist.

Datenquelle

Dies ist das "Changed Date" (Änderungsdatum), das mit jeder Aktualisierung in der Historie eines Work Items verbunden ist. Für externe Events wie Builds oder Deployments ist es der Abschluss-Timestamp dieses Events.

Beispiele
2023-10-26T10:00:00Z2023-10-27T14:35:10Z2023-10-28T09: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 zeichnet auf, wann der Datensatz zuletzt aus Azure DevOps extrahiert und aktualisiert wurde. Es gibt einen klaren Hinweis auf die Aktualität der Daten und den durch die Analyse abgedeckten Zeitrahmen.

Bei jeder Prozessanalyse ist die Kenntnis der Aktualität der Daten entscheidend für fundierte Entscheidungen. Dieser Timestamp hilft Benutzern zu verstehen, ob sie Echtzeitinformationen oder einen historischen Snapshot betrachten, was die Relevanz der Ergebnisse beeinflusst.

Bedeutung

Es informiert Benutzer über die Aktualität der Daten und stellt sicher, dass Analysen und Entscheidungen auf einem verstandenen Zeitrahmen basieren.

Datenquelle

Dies ist ein Metadaten-Timestamp, der während des Datenextraktions-, Transformations- und Lade (ETL)-Prozesses generiert und gespeichert wird.

Beispiele
2024-05-20T08:00:00Z
Quellsystem
SourceSystem
Das System, aus dem die Prozessdaten extrahiert wurden, in diesem Fall Azure DevOps.
Beschreibung

Dieses Attribut identifiziert das Ursprungssystem der Daten. Es ist besonders nützlich in Umgebungen, in denen Daten aus mehreren Systemen für eine breitere Prozessansicht kombiniert werden. Für dieses spezifische Modell ist der Wert konsistent Azure DevOps.

Obwohl es in einer Einzelsystemanalyse statisch erscheinen mag, liefert es wesentlichen Kontext über die Herkunft der Daten, was entscheidend für Data Governance, Fehlerbehebung und zukünftige Integrationen mit anderen Systemen wie ServiceNow oder SAP ist.

Bedeutung

Es liefert entscheidenden Kontext über die Herkunft der Daten, was wichtig für Data Governance, Validierung und die Analyse von Multi-System-Prozessen ist.

Datenquelle

Dies ist ein statischer Wert, der während des Datenextraktions- und Transformationsprozesses hinzugefügt werden sollte, um den Datensatz zu kennzeichnen.

Beispiele
Azure DevOps
Endzeit
EndTime
Der Timestamp, der angibt, wann eine Aktivität abgeschlossen wurde. Er wird zur Berechnung der Bearbeitungszeit einer Aktivität verwendet.
Beschreibung

Die End Time markiert den Abschluss einer Aktivität. In vielen Event Logs dient die Startzeit der nächsten Aktivität als Endzeit der vorherigen. Eine eigenständige End Time ermöglicht jedoch eine genauere Berechnung sowohl der Aktivitätsbearbeitungszeit als auch der Leerlaufzeit zwischen den Aktivitäten.

Dieses Attribut ist entscheidend für die Berechnung des ProcessingTime KPI und für die Durchführung einer detaillierten Bottleneck-Analyse. Es hilft, zwischen der Zeit, die aktiv an einer Aufgabe gearbeitet wurde, und der Zeit, die auf den Beginn des nächsten Schrittes gewartet wurde, zu unterscheiden, was für das Stage Handoff Analysis Dashboard von großer Bedeutung ist.

Bedeutung

Es ermöglicht die präzise Berechnung von Aktivitätsbearbeitungs- und Wartezeiten, was grundlegend für die Bottleneck-Analyse und Effizienzverbesserungen ist.

Datenquelle

Dies wird oft abgeleitet. Es kann die Startzeit des nachfolgenden Events für denselben Case sein, oder es kann explizit aufgezeichnet werden, wenn das Quellsystem sowohl Start- als auch Endzeiten für Tasks erfasst.

Beispiele
2023-10-26T18:00:00Z2023-10-27T15:00:00Z2023-10-28T11:00:00Z
Entwicklungs-`Cycle Time`
DevelopmentCycleTime
Die Gesamtzeit, die von der Erstellung eines Development Items bis zu dessen Deployment in die Produktion vergangen ist.
Beschreibung

Development Cycle Time ist ein wichtiger Leistungsindikator, der die End-to-End-Dauer des Entwicklungsprozesses für ein einzelnes Work Item misst. Er wird berechnet als die Differenz zwischen dem Timestamp der Aktivität 'Deployed to Production' und der Aktivität 'Work Item Created'.

Diese berechnete Metrik ist der primäre KPI für das End-to-End Development Cycle Time Dashboard und die historischen Cycle Time Trends. Sie bietet ein umfassendes Maß für Prozessgeschwindigkeit und Effizienz, und deren Verfolgung über die Zeit zeigt die Auswirkungen von Prozessverbesserungsinitiativen.

Bedeutung

Dies ist ein kritischer KPI, der die Gesamtgeschwindigkeit und Effizienz des Entwicklungsprozesses von Anfang bis Ende misst.

Datenquelle

Dies wird berechnet, indem der Timestamp des finalen Deployment Events genommen und der Timestamp des Creation Events für jeden Case subtrahiert wird.

Beispiele
10 Tage 4 Stunden 30 Minuten25 Tage 8 Stunden 0 Minuten5 Tage 2 Stunden 15 Minuten
Ist Nacharbeit
IsRework
Ein boolesches Flag, das anzeigt, ob ein `Development Item` in einem früheren Stadium seines Lebenszyklus erneut eingegeben wurde.
Beschreibung

Dieses Flag ist auf "true" gesetzt, wenn ein Work Item einen Rework-Loop aufweist, z.B. wenn es von "QA Testing Completed" zurück zu "Development Started" wechselt. Es wird berechnet, indem die Abfolge der Aktivitäten für einen Case analysiert und nicht-lineare Progressionen erkannt werden.

Dieses Attribut ist essentiell für das Rework and Retesting Frequency Dashboard und den Rework Loop Frequency KPI. Es ermöglicht eine einfache Filterung und Quantifizierung von Nacharbeit und hilft, Qualitätsprobleme, Kommunikationslücken oder unzureichende Tests zu identifizieren, die zu Ineffizienzen führen.

Bedeutung

Es identifiziert und quantifiziert direkt Nacharbeit, was hilft, Qualitätsprobleme und Prozessineffizienzen aufzuzeigen, die die Cycle Times verlängern.

Datenquelle

Dies ist ein berechnetes Attribut, das durch Analyse der Abfolge von Aktivitäten im Event Log für jeden Case abgeleitet wird.

Beispiele
truefalsch
Priorität
Priority
Eine numerische oder deskriptive Rangfolge der Bedeutung des `Development Items` im Verhältnis zu anderen `Items`.
Beschreibung

Priorität gibt die Planungsrelevanz eines Work Items an. Eine höhere Priorität deutet darauf hin, dass ein Element schneller bearbeitet werden sollte als Elemente mit geringerer Priorität. Gängige Werte sind numerisch, wie 1, 2, 3, 4, wobei 1 die höchste ist.

Dieses Attribut ist essentiell für das Priority-Based Throughput & Cycle Time Dashboard. Die Analyse von Daten mit diesem Attribut hilft zu bestimmen, ob das Priorisierungssystem effektiv ist, d.h. ob hochpriorisierte Elemente tatsächlich schneller den Prozess durchlaufen als solche mit niedrigerer Priorität.

Bedeutung

Es ermöglicht die Analyse, ob der Prozess hochpriorisierte Elemente effektiv beschleunigt, was entscheidend für die Bewertung des Erfolgs von Priorisierungsstrategien ist.

Datenquelle

Dies entspricht dem Feld "Priority" (Priorität) eines Work Items in Azure DevOps.

Beispiele
1234
Status
State
Der aktuelle Status des Development Items innerhalb seines Workflows, z. B. "Neu", "Aktiv", "Resolved" oder "Geschlossen".
Beschreibung

Das State-Attribut repräsentiert den formalen Status eines Work Items zu jedem Zeitpunkt, wie er durch die Prozesstemplate des Projekts definiert ist. Übergänge zwischen diesen Status sind die primäre Quelle für die Generierung der Aktivitäten im Event Log.

Während das Attribut "Activity" oft eine deskriptivere Version einer Statusänderung ist, ist das rohe "State"-Attribut nützlich für Filterung und Analyse. Es hilft zu verstehen, wie viel Zeit Elemente in bestimmten Status verbringen, und ist grundlegend für den Aufbau des Stage Duration Dashboards und die Analyse von Handoffs.

Bedeutung

Es gibt den Status des Work Items im Lifecycle an, was grundlegend ist, um den Prozessfluss zu verstehen und die in verschiedenen Phasen verbrachte Zeit zu berechnen.

Datenquelle

Dies entspricht dem Feld "State" (Status) eines Work Items in Azure DevOps.

Beispiele
NeuAktivIn `QA`GelöstGeschlossen
Teamname
TeamName
Der Name des Entwicklungsteams, das für das Work Item verantwortlich ist.
Beschreibung

Der Team Name identifiziert das spezifische Team, dem ein Work Item zugewiesen ist. In Azure DevOps wird die Arbeit oft nach Teams organisiert, die Untergruppen eines größeren Projekts sein können.

Dieses Attribut ermöglicht es, die Prozessanalyse nach Teams zu segmentieren. Es ist von unschätzbarem Wert für den Vergleich von Prozessen und Leistungen über verschiedene Teams hinweg, die Identifizierung von Best Practices in hochperformanten Teams und das Auffinden von Bereichen, in denen spezifische Teams Unterstützung oder Prozessverbesserungen benötigen könnten.

Bedeutung

Es ermöglicht eine vergleichende Analyse zwischen verschiedenen Teams, die hilft, Leistungsunterschiede zu identifizieren und Best Practices in der Organisation zu teilen.

Datenquelle

Dies wird oft aus dem "Area Path" (Bereichspfad) eines Work Items abgeleitet, da Teams in Azure DevOps typischerweise bestimmten Bereichspfaden zugeordnet sind.

Beispiele
Team PhoenixOmega SquadPlattform-CoreFrontend-`Crew`
Work Item Typ
WorkItemType
Die Klassifizierung des Development Items, wie Bug, Feature, User Story oder Task.
Beschreibung

Der Work Item Type kategorisiert die Art der ausgeführten Arbeit. Verschiedene Typen von Work Items folgen oft unterschiedlichen Prozesspfaden und haben unterschiedliche Leistungserwartungen oder SLAs. Zum Beispiel könnte ein "Bug" einem beschleunigten Pfad folgen im Vergleich zu einem "Feature".

Dieses Attribut ist entscheidend für die vergleichende Analyse. Es ermöglicht Ihnen, die Prozesslandkarte oder KPIs nach der Art der Arbeit zu filtern, um zu verstehen, ob bestimmte Prozesse für Bugs effizienter sind als für Funktionen, oder um historische Cycle Time Trends für verschiedene Arbeitskategorien zu verfolgen.

Bedeutung

Es ermöglicht die Segmentierung der Prozessanalyse und erlaubt den Vergleich von Workflows und Performance für verschiedene Arbeitskategorien wie Bugs und Funktionen.

Datenquelle

Dies entspricht dem Feld "Work Item Type" (Work Item Typ) eines Work Items in Azure DevOps.

Beispiele
Bug`Feature`User StoryAufgabe
Zugeordnet an
AssignedTo
Der Benutzer oder das Teammitglied, dem das Development Item derzeit zugewiesen ist.
Beschreibung

Dieses Attribut identifiziert die für das Work Item in einer bestimmten Prozessphase verantwortliche Person. Die Zuweisung kann sich im Laufe des Lifecycles des Elements mehrfach ändern, z. B. von einem Entwickler zu einem Tester und dann zu einem Release Manager.

Die Analyse nach "Assigned To" ist entscheidend für das Developer und Tester Workload Overview Dashboard. Sie hilft, die Ressourcenzuweisung zu verstehen, überlastete Teammitglieder zu identifizieren und Leistungsunterschiede zwischen Einzelpersonen oder Teams zu analysieren.

Bedeutung

Es ermöglicht eine ressourcenbasierte Analyse, die dabei hilft, die Arbeitslastverteilung zu verstehen, ressourcenspezifische Bottlenecks zu identifizieren und die Teamkapazität zu verwalten.

Datenquelle

Dies entspricht dem Feld "Assigned To" (Zugewiesen an) eines Work Items in Azure DevOps. Der Wert wird aus der Work Item History für jedes Event erfasst.

Beispiele
jane.doe@example.comjohn.smith@example.comnicht zugewiesen
Genehmigungs-Wartezeit
ApprovalWaitingTime
Die Zeit, die ein Development Item nach einer Anfrage auf eine Genehmigung wartet.
Beschreibung

Diese Metrik misst die Dauer spezifischer Wartezeiten, in denen ein Work Item auf eine Genehmigung wartet. Ein Paradebeispiel ist die Zeit zwischen "UAT gestartet" und "UAT genehmigt". Sie wird berechnet, indem die Zeit zwischen diesen beiden spezifischen Aktivitäten für einen gegebenen Case gemessen wird.

Dieses berechnete Attribut unterstützt direkt das Approval Waiting Time Analysis Dashboard und den entsprechenden KPI. Durch die Isolierung dieser spezifischen Verzögerungen können Teams Kommunikations- und Entscheidungsprozesse gezielt verbessern, um Leerlaufzeiten zu reduzieren und den gesamten Lifecycle zu beschleunigen.

Bedeutung

Es misst speziell Verzögerungen, die durch das Warten auf Entscheidungen oder Freigaben entstehen, und zeigt Möglichkeiten zur Verbesserung der Kommunikations- und Entscheidungsprozesse auf.

Datenquelle

Dies wird berechnet, indem spezifische Start- und End-Genehmigungsaktivitäten im Event Log (z.B. "UAT gestartet" und "UAT genehmigt") gefunden und die Zeitdifferenz berechnet werden.

Beispiele
3 Tage 2 Stunden1 Tag 8 Stunden 30 Minuten4 Stunden
Iterationspfad
IterationPath
Der Entwicklungs-Sprint oder die Timebox, dem das Work Item zugewiesen ist.
Beschreibung

Der Iterationspfad, oder Sprint, stellt einen spezifischen zeitlich begrenzten Entwicklungszeitraum dar. Work Items werden einer Iteration zugewiesen, um innerhalb dieses Zeitrahmens abgeschlossen zu werden.

Die Analyse nach Iterationspfad hilft, die Prozess-Performance auf Sprint-zu-Sprint-Basis zu verstehen. Sie kann verwendet werden, um zu verfolgen, ob sich die Cycle Times über aufeinanderfolgende Sprints verbessern, Übertragungsarbeiten zu analysieren und die Vorhersehbarkeit der Sprintplanung zu bewerten.

Bedeutung

Es ermöglicht eine sprintbasierte Analyse, die Teams hilft, ihre Leistung im Zeitverlauf zu bewerten und ihre agilen Praktiken zu verbessern.

Datenquelle

Dies entspricht dem Feld "Iteration Path" (Iterationspfad) eines Work Items in Azure DevOps.

Beispiele
E-Commerce-Plattform\Sprint 12E-Commerce-Plattform\Sprint 13Relaunch der Mobile App\Phase 2\Sprint 4
Phasen-Handoff-Zeit
StageHandoffTime
Die Dauer der Leerlaufzeit zwischen dem Abschluss einer Hauptphase und dem Beginn der nächsten.
Beschreibung

Die Phasen-Handoff-Zeit misst die Wartezeit zwischen aufeinanderfolgenden Prozessphasen, z.B. die Zeit zwischen "Development Completed" und "QA Testing Started". Sie wird berechnet, indem diese Schlüsselübergänge identifiziert und die Zeitspanne zwischen dem Ende der ersten Aktivität und dem Beginn der zweiten gemessen wird.

Diese Metrik ist der Fokus des Dashboards für Phasen-Dauer- und Handoff-Analyse. Die Isolierung und Messung der Handoff-Zeit ist entscheidend, um verborgene Bottlenecks zu identifizieren, wo die Arbeit untätig ist, oft aufgrund von Ressourcenknappheit, Kommunikationsverzögerungen oder ineffizienten Prozessen.

Bedeutung

Es quantifiziert Wartezeiten zwischen Prozessphasen und legt direkt verborgene Bottlenecks und Verzögerungen offen, die nicht Teil der aktiven Arbeit sind.

Datenquelle

Dies ist ein berechnetes Attribut. Es erfordert die Identifizierung von Paaren sequenzieller Aktivitäten, die einen Handoff darstellen, und anschließend die Berechnung der Zeitdifferenz zwischen ihnen.

Beispiele
2 Stunden 15 Minuten1 Tag 4 Stunden0 Stunden 30 Minuten
Projektname
ProjectName
Der Name des Azure DevOps Projekts, zu dem das Development Item gehört.
Beschreibung

Dieses Attribut identifiziert das spezifische Projekt innerhalb der Azure DevOps Organisation, in dem sich das Work Item befindet. Es bietet einen übergeordneten Kontext, insbesondere in Organisationen mit vielen Projekten.

Der Projektname ist eine kritische Dimension für Filterung und Vergleich. Er unterstützt das Historical Cycle Time Trends Dashboard, indem er Analysen ermöglicht, die nach Projekten segmentiert werden, um aufzuzeigen, ob bestimmte Projekte effizienter sind als andere oder ob Prozessverbesserungen in einem Projekt positive Auswirkungen hatten.

Bedeutung

Es bietet eine übergeordnete Gruppierung für die Analyse, die den Leistungsvergleich und die Trendanalyse über verschiedene Projekte hinweg ermöglicht.

Datenquelle

Dies entspricht dem Feld "Team Project" (Teamprojekt) eines Work Items in Azure DevOps.

Beispiele
E-Commerce-PlattformRelaunch der Mobile App`Data Warehouse` Modernisierung
Pull Request ID
PullRequestId
Die ID eines Pull Requests, der mit dem Development Item verknüpft ist.
Beschreibung

Dieses Attribut verknüpft ein Work Item mit einem spezifischen Pull Request, dem Mechanismus zur Einreichung und Überprüfung von Code-Änderungen. Ein einzelnes Work Item kann mit mehreren Pull Requests verknüpft sein.

Die Pull Request ID ermöglicht eine granularere Analyse des Code Review- und Integrationsteils des Lifecycles. Sie kann verwendet werden, um die Zeit von der Erstellung bis zum Abschluss des Pull Requests zu messen und zu analysieren, wie oft Pull Requests abgelehnt werden oder erhebliche Änderungen erfordern, was ein Indikator für Codequalität oder unklare Anforderungen sein kann.

Bedeutung

Es verbindet Entwicklungsarbeit mit spezifischen Code-Review-Aktivitäten und ermöglicht eine detaillierte Analyse des Code-Integrations- und Qualitätssicherungsprozesses.

Datenquelle

Diese Informationen finden Sie im Bereich "Links" oder "Development" (Entwicklung) eines Work Items in Azure DevOps.

Beispiele
452145334589
Schweregrad
Severity
Gibt die Auswirkung eines `Bugs` oder Problems auf das System oder Endbenutzer an.
Beschreibung

Severity (Schweregrad) wird verwendet, um den Einfluss eines Bugs zu klassifizieren, von kritischen Systemausfällen bis zu kleineren kosmetischen Problemen. Dies unterscheidet sich von der Priorität, die die Reihenfolge der Arbeit bestimmt. Ein Bug mit hoher Severity kann eine niedrige Priorität haben, wenn eine sofortige Umgehungslösung verfügbar ist.

Dieses Attribut bietet eine weitere Dimension für die Analyse, insbesondere für das Priority-Based Throughput & Cycle Time Dashboard. Es ermöglicht die Untersuchung von Fragen wie "Beheben wir die kritischsten Bugs zuerst?" und hilft, das Risikoprofil der bearbeiteten Aufgaben zu verstehen.

Bedeutung

Es hilft, Work Items nach ihrem Business Impact zu kategorisieren, und ermöglicht die Analyse, wie effektiv das Team auf hochwirksame Probleme reagiert.

Datenquelle

Dies entspricht dem Feld "Severity" (Schweregrad) eines Work Items, typischerweise für Bugs, in Azure DevOps.

Beispiele
1 - Kritisch2 - Hoch3 - Mittel4 - Niedrig
Erforderlich Empfohlen Optional

Software Development Lifecycle Aktivitäten

Dies sind die entscheidenden Prozessschritte und Meilensteine, die Sie in Ihrem Event Log erfassen sollten, um eine präzise Prozessentdeckung und Engpasserkennung zu gewährleisten.
7 Empfohlen 8 Optional
Aktivität Beschreibung
Entwicklung gestartet
Diese Aktivität bedeutet, dass ein Entwickler aktiv an dem Element zu arbeiten begonnen hat. Sie wird durch die Ableitung einer Änderung im Status des Work Items auf "Active", "In Progress" oder "Committed" erfasst.
Bedeutung

Kennzeichnet den Beginn der aktiven Entwicklungsphase. Die Analyse der Zeit von "Erstellt" bis "Entwicklung gestartet" offenbart die Wartezeiten im Backlog.

Datenquelle

Abgeleitet aus der Work Item-Historie, wenn sich das Feld 'System.State' von einem 'New' oder 'Approved' Zustand in einen 'In Progress' Zustand ändert.

Erfassen

Abgeleitet aus der Änderung des State-Feldes zu 'Active' oder 'In Progress'.

Ereignistyp inferred
In `Production` bereitgestellt
Kennzeichnet die erfolgreiche Bereitstellung des zugehörigen Codes des Work Items in der Produktionsumgebung. Dies ist ein explizites Event, das aus den Release-Logs von Azure Pipelines erfasst wird.
Bedeutung

Dies ist ein kritischer Meilenstein, der die Wertlieferung darstellt. Er dient als Endpunkt für die Berechnung von Lead Time und Cycle Time.

Datenquelle

Erfasst aus Azure Pipelines Release Pipeline Daten, speziell dem Completion Event einer Deployment in eine 'Production'-Phase, die mit dem Work Item verknüpft ist.

Erfassen

Erfasst aus einem Release Pipeline Deployment Completion Event.

Ereignistyp explicit
Pull Request abgeschlossen
Stellt den erfolgreichen Abschluss eines Code Reviews dar, bei dem der Pull Request genehmigt und der Code in den Ziel-Branch gemerged wird. Dieses Event wird explizit in Azure Repos protokolliert.
Bedeutung

Kennzeichnet das Ende der Code-Review-Phase, einem häufigen Bottleneck. Die Analyse der Zeit zwischen PR-Erstellung und -Abschluss zeigt die Effizienz des Review-Zyklus.

Datenquelle

Erfasst aus dem Completion oder Merge Event eines Pull Request in Azure Repos, der mit einem Work Item verknüpft ist.

Erfassen

Erfasst aus dem Pull Request Merge Event, das mit einem Work Item verknüpft ist.

Ereignistyp explicit
Pull Request erstellt
Zeigt an, dass der Entwickler die initiale Codierung abgeschlossen und die Änderungen über einen Pull Request zur Überprüfung eingereicht hat. Dieses `Event` verknüpft das `Work Item` mit einer spezifischen `Code`-Änderung in Azure Repos.
Bedeutung

Dies ist ein wichtiger Handoff von der Entwicklung zum Code Review. Die Verfolgung hilft, die Dauer der Codierung zu messen und zu identifizieren, wann Code für das Peer Review bereit ist.

Datenquelle

Erfasst aus Azure Repos Daten durch Verknüpfung des Pull Request Erstellungs-Events mit dem zugehörigen Work Item. Dies ist oft eine explizite Verknüpfung, die vom Entwickler vorgenommen wird.

Erfassen

Erfasst aus einem Azure Repos Pull Request Erstellungs-Event, das mit einem Work Item verknüpft ist.

Ereignistyp explicit
QA Testing gestartet
Stellt den Beginn der formalen Qualitätssicherungs-Testphase dar. Diese Aktivität wird abgeleitet, wenn der Status eines Work Items auf "In QA", "Testing" oder einen ähnlichen Wert geändert wird.
Bedeutung

Kennzeichnet den Beginn des QA-Zyklus. Die Analyse der Dauer dieser Phase ist entscheidend, um Test-Bottlenecks und die Effizienz zu verstehen.

Datenquelle

Abgeleitet aus der Work Item-Historie durch Verfolgung einer Änderung im Feld 'System.State' zu 'In QA' oder einem anderen designierten Testing-Zustand.

Erfassen

Abgeleitet aus der Änderung des State-Feldes zu 'In QA' oder 'Testing'.

Ereignistyp inferred
UAT genehmigt
Diese Aktivität bedeutet, dass Business-Stakeholder die Änderungen nach dem User Acceptance Testing genehmigt haben. Dies wird typischerweise aus einer Statusänderung von "In UAT" zu "UAT Approved" oder "Ready for Release" abgeleitet.
Bedeutung

Dies ist ein kritischer Genehmigungsmeilenstein, der bestätigt, dass das Work Item die Business-Anforderungen erfüllt und bereit für das Produktions-Deployment ist.

Datenquelle

Abgeleitet aus der Work Item-Historie durch Erkennung einer Änderung im Feld 'System.State' von einem UAT-Status in einen genehmigten oder Release-bereiten Status.

Erfassen

Abgeleitet aus der Änderung des State-Feldes von 'In UAT' zu 'Ready for Release'.

Ereignistyp inferred
Work Item erstellt
Diese Aktivität kennzeichnet den Beginn des Entwicklungslebenszyklus und repräsentiert die Erstellung eines neuen Work Items wie einer User Story, eines Bugs oder einer Task. Sie wird explizit erfasst, wenn ein neuer Datensatz in Azure DevOps Boards gespeichert wird.
Bedeutung

Dies ist das primäre Start-Event für den Prozess. Es ist essentiell für die Messung der End-to-End-Entwicklungs-Cycle Time und das Verständnis der initialen Arbeitsquellen.

Datenquelle

Dieses Event wird aus dem "Created Date" (Erstellungsdatum) des Work Items selbst erfasst. Die Work Item History Tabelle zeichnet auch diesen initialen Statusübergang auf.

Erfassen

Erfasst aus dem Feld 'Created Date' des Work Items.

Ereignistyp explicit
`Build` erfolgreich
Diese Aktivität bestätigt, dass der Quellcode, einschließlich der neuen Änderungen, erfolgreich von einer Build-Pipeline kompiliert und verpackt wurde. Dies ist ein explizites Event, das von Azure Pipelines protokolliert wird.
Bedeutung

Dient als kritisches Quality Gate, das sicherstellt, dass neuer Code korrekt integriert wird, ohne den Build zu unterbrechen. Fehler in dieser Phase können auf Integrationsprobleme hinweisen.

Datenquelle

Erfasst aus Azure Pipelines Build Completion Events. Der Build muss mit dem Work Item verknüpft sein, entweder direkt oder über den zugehörigen Pull Request.

Erfassen

Erfasst aus einem Azure Pipelines Build Completion Event.

Ereignistyp explicit
Arbeitselement genehmigt
Stellt die formale Genehmigung eines Work Items dar, die bestätigt, dass es gut definiert und bereit für die Entwicklung ist. Dies wird typischerweise aus einer Änderung im Feld "State" zu einem Wert wie "Genehmigt" oder "Bereit für Entwicklung" abgeleitet.
Bedeutung

Die Verfolgung von Freigaben hilft, die Zeit zwischen Ideeneinreichung und Entwicklungszusage zu analysieren. Sie zeigt potenzielle Verzögerungen in den Planungs- und Backlog-Grooming-Phasen auf.

Datenquelle

Abgeleitet aus der Work Item-Historie durch Erkennung einer Änderung des Feldes 'System.State' zu 'Approved' oder einem ähnlichen benutzerdefinierten Zustand.

Erfassen

Abgeleitet aus der Änderung des State-Feldes zu 'Approved'.

Ereignistyp inferred
Entwicklung abgeschlossen
Bedeutet, dass alle Entwicklungs- und Unit-Testing-Aktivitäten abgeschlossen sind und das Element für formale Tests bereit ist. Dies wird typischerweise aus einer Statusänderung des Work Items zu "Resolved" oder "Ready for Test" abgeleitet.
Bedeutung

Dies kennzeichnet einen wichtigen Handoff vom Entwicklungsteam an das QA-Team. Die Messung der Zeit bis "QA Testing Started" hilft, Handoff-Verzögerungen zu identifizieren.

Datenquelle

Abgeleitet aus der Work Item-Historie, wenn das Feld 'System.State' in einen Wert wie 'Resolved' oder einen benutzerdefinierten Zustand geändert wird, der die Bereitschaft für QA anzeigt.

Erfassen

Abgeleitet aus der Änderung des State-Feldes zu 'Resolved'.

Ereignistyp inferred
QA Testing abgeschlossen
Kennzeichnet den erfolgreichen Abschluss der Qualitätssicherungsphase. Dies wird abgeleitet, wenn der Work Item-Status von einem Teststatus zu einem Zustand wie "Bereit für UAT" oder "QA Genehmigt" wechselt.
Bedeutung

Dies ist ein wichtiges Quality Gate, das anzeigt, dass das Element für das User Acceptance Testing oder den Release bereit ist. Verzögerungen nach diesem Punkt können auf UAT- oder Release-Planungs-Bottlenecks hinweisen.

Datenquelle

Abgeleitet aus der Work Item-Historie, wenn sich das Feld 'System.State' von 'In QA' in einen nachfolgenden Zustand wie 'Ready for UAT' oder 'Done' ändert.

Erfassen

Abgeleitet aus der Änderung des State-Feldes von 'In QA' zu 'Ready for UAT'.

Ereignistyp inferred
QA Testing fehlgeschlagen
Zeigt an, dass das `Work Item` die Qualitätssicherungs-`Testing` nicht bestanden hat und zur Entwicklung zurückgesendet wird. Dies wird durch einen Zustandswechsel von einem `Testing`-Zustand zurück in einen 'In Progress' oder 'Active' Zustand erfasst.
Bedeutung

Diese Aktivität ist essentiell zur Identifizierung von Rework-Loops. Eine hohe Häufigkeit dieses Events weist auf Probleme mit der Codequalität, den Anforderungen oder den Testprozessen hin.

Datenquelle

Abgeleitet aus der Work Item-Historie durch Erkennung eines Übergangs von einem Zustand wie 'In QA' zurück zu einem Zustand wie 'Active' oder 'In Progress'.

Erfassen

Abgeleitet aus der Änderung des State-Feldes von 'In QA' zurück zu 'Active'.

Ereignistyp inferred
UAT gestartet
Stellt den Beginn des User Acceptance Testing dar, bei dem Business-Stakeholder die Funktionalität validieren. Dies wird typischerweise aus einer Statusänderung zu "In UAT" oder einem ähnlichen Status abgeleitet.
Bedeutung

Misst den Beginn der finalen Validierung vor dem Release. Die Dauer der UAT und Wartezeiten für die Genehmigung sind entscheidend für die Prozessoptimierungsanalyse.

Datenquelle

Abgeleitet aus der Work Item-Historie, wenn das Feld 'System.State' auf einen benutzerdefinierten Zustand aktualisiert wird, der UAT darstellt, z.B. 'In UAT'.

Erfassen

Abgeleitet aus der Änderung des State-Feldes zu 'In UAT'.

Ereignistyp inferred
Work Item geschlossen
Stellt den endgültigen Abschluss des Work Items nach dem Deployment und jeglicher Post-Deployment-Validierung dar. Dies wird durch eine Statusänderung zu "Geschlossen" oder "Erledigt" erfasst.
Bedeutung

Diese Aktivität kennzeichnet den finalen, erfolgreichen Abschluss des gesamten Prozesses für ein Work Item. Sie ist der definitive Endpunkt des Lifecycles.

Datenquelle

Abgeleitet aus der Work Item-Historie, wenn das Feld 'System.State' auf 'Closed' oder einen ähnlichen Endzustand in der Kategorie 'Completed' geändert wird.

Erfassen

Abgeleitet aus der Änderung des State-Feldes zu 'Closed'.

Ereignistyp inferred
Work Item storniert
Zeigt an, dass das `Work Item` abgebrochen wurde und nicht abgeschlossen oder bereitgestellt wird. Dies wird durch einen Zustandswechsel zu 'Removed', 'Cancelled' oder einem ähnlichen Zustand erfasst.
Bedeutung

Dies stellt ein alternatives, nicht erfolgreiches Prozessende dar. Die Analyse stornierter Elemente kann Probleme bei der Planung, Priorisierung oder Anforderungsdefinition aufdecken.

Datenquelle

Abgeleitet aus der Work Item-Historie, wenn das Feld 'System.State' in einen Endzustand in der Kategorie 'Removed' geändert wird.

Erfassen

Abgeleitet aus der Änderung des State-Feldes zu 'Removed' oder 'Cancelled'.

Ereignistyp inferred
Empfohlen Optional

Extraktionsleitfäden

So erhalten Sie Ihre `Daten` aus Azure DevOps