Ihr Software Development Lifecycle Daten-Template
Ihr Software Development Lifecycle Daten-Template
- Empfohlene Attribute zur Erfassung
- Schlüsselaktivitäten zur Verfolgung Ihres SDLC
- Detaillierte Extraktionsanleitung für Azure DevOps
Software Development Lifecycle Attribute
| 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
In der Analyse ist dieses
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
Diese berechnete Metrik ist der primäre KPI für das End-to-End
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
|
|||
Software Development Lifecycle Aktivitäten
| 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
Erfassen
Abgeleitet aus der Änderung des
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
Erfassen
Erfasst aus einem
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
Erfassen
Erfasst aus dem Pull Request
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
Erfassen
Erfasst aus einem Azure Repos Pull Request Erstellungs-
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
Erfassen
Abgeleitet aus der Änderung des
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
Erfassen
Abgeleitet aus der Änderung des
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
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
Erfassen
Erfasst aus einem Azure
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
Erfassen
Abgeleitet aus der Änderung des
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
Erfassen
Abgeleitet aus der Änderung des
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
Erfassen
Abgeleitet aus der Änderung des
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
Erfassen
Abgeleitet aus der Änderung des
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
Erfassen
Abgeleitet aus der Änderung des
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
Erfassen
Abgeleitet aus der Änderung des
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
Erfassen
Abgeleitet aus der Änderung des
Ereignistyp
inferred
|
|||