Ihr Software Development Life Cycle (SDLC) Daten-Template
Ihr Software Development Life Cycle (SDLC) Daten-Template
- Empfohlene Attribute zur Erfassung
- Schlüsselaktivitäten zur Verfolgung Ihres SDLC
- Detaillierte Extraktionsanleitung für Azure DevOps
Software Development Life Cycle (SDLC) Attribute
| Name | Beschreibung | ||
|---|---|---|---|
|
`Development Item`
DevelopmentItem
|
Der eindeutige Identifikator für eine einzelne Arbeitseinheit, wie ein Funktion, Bug oder eine Benutzer Story, der als Case-ID 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 wichtig, um alle zugehörigen Ereignisse zu einer einzigen Fallverlauf zu korrelieren. Es ermöglicht die Rekonstruktion des End-to-End-Lebenszyklus für jedes Work Item und die Analyse von Durchlaufzeits, Prozessabweichungen und Rework-Loops auf individueller Elementbasis.
Bedeutung
Dies ist der Kern-Identifikator, der alle Prozessschritte zu einem kohärenten Fall verbindet und so eine End-to-End-Analyse des Software Development Life Cycle (SDLC) 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 Ereignisse oder den Antrag bearbeitet.er 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 Ereignisse wie Builds oder Pull Requests oder benutzerdefinierten Ereignisse abgeleitet. Dieses Attribut ist wichtig für die Erstellung der Prozessablauf, die den Workflow visuell darstellt. Es ermöglicht Analysten, die Abfolge von Ereignisse zu verstehen, gemeinsame Pfade zu identifizieren, Engpässe zwischen spezifischen Aktivitäten zu entdecken und die Häufigkeit jedes Schrittes zu analysierenn.
Bedeutung
Es definiert die Schritte im Prozess, ist die Basis der Prozessablauf und ermöglicht die Analyse von Workflow, Engpässe und Abweichungen.
Datenquelle
Dies wird in der Regel aus Änderungen im Feld "State" eines Work Items oder aus verknüpften Ereignisse wie Builds, Commits und Pull Requests abgeleitet. Die Work Item History liefert die RohDaten für diese Ereignisse.
Beispiele
Entwicklung gestartetPull Request abgeschlossenQA Testing fehlgeschlagenIn `Production` bereitgestelltWork Item geschlossen
|
|||
|
Ereigniszeit
EventTime
|
Der präzise Zeitstempel, 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 Zeitstempel liefert die chronologische Reihenfolge der Ereignisse, was wesentlich für die Berechnung aller durationsbasierten KPIs und das Verständnis des Prozessflusses und der Engpässe ist.
Datenquelle
Dies ist das "Changed Date" (Änderungsdatum), das mit jeder Aktualisierung in der Historie eines Work Items verbunden ist. Für externe Ereignisse wie Builds oder Deployments ist es der Abschluss-Zeitstempel dieses Ereignisse.
Beispiele
2023-10-26T10:00:00Z2023-10-27T14:35:10Z2023-10-28T09:00:00Z
|
|||
|
Letzte Datenaktualisierung
LastDataUpdate
|
Der Zeitstempel, 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 wichtig für fundierte Entscheidungen. Dieser Zeitstempel hilft Benutzern zu verstehen, ob sie EchtzeitHinweisrmationen oder einen historischen Momentaufnahme betrachten, was die Relevanz der Resultate beeinflusst.
Bedeutung
Es Hinweisrmiert Benutzer über die Aktualität der Daten und stellt sicher, dass Analysen und Entscheidungen auf einem verstandenen Zeitrahmen basieren.
Datenquelle
Dies ist ein MetaDaten-Zeitstempel, 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 wichtig für Daten Governance, Fehlerbehebung und zukünftige Integrationen mit anderen Systemen wie ServiceNow oder SAP ist.
Bedeutung
Es liefert wichtigen Kontext über die Herkunft der Daten, was wichtig für Daten 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 Zeitstempel, 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 maßgeblich für die Berechnung des ProcessingTime KPI und für die Durchführung einer detaillierten Engpassanalyse. 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 Engpassanalyse und Effizienzverbesserungen ist.
Datenquelle
Dies wird oft abgeleitet. Es kann die Startzeit des nachfolgenden Ereignisse für denselben Case sein, oder es kann explizit aufgezeichnet werden, wenn das Quellsystem sowohl Start- als auch Endzeiten für Aufgaben erfasst.
Beispiele
2023-10-26T18:00:00Z2023-10-27T15:00:00Z2023-10-28T11:00:00Z
|
|||
|
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 "Ja" 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 wesentlich 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 Durchlaufzeits 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
JaNein
|
|||
|
Priorität
Priority
|
Eine numerische oder den Antrag bearbeitet.eskriptive 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 wesentlich für das Priority-Based Throughput & Durchlaufzeit 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 wichtig 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 die Basis für den Aufbau des Stage Dauer Dashboards und die Analyse von Übergaben.
Bedeutung
Es gibt den Status des Work Items im Lebenszyklus 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 besonders wertvoll 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 Prozessoptimierungen 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 in der Regel bestimmten Bereichspfaden zugeordnet sind.
Beispiele
Team PhoenixOmega SquadPlattform-CoreFrontend-`Crew`
|
|||
|
Work Item Typ
WorkItemType
|
Die Klassifizierung des Development Items, wie Bug, Funktion, Benutzer Story oder Aufgabe. | ||
|
Beschreibung
Der Work Item Typ kategorisiert die Art der ausgeführten Arbeit. Verschiedene Typn 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 "Funktion". Dieses Attribut ist maßgeblich für die vergleichende Analyse. Es ermöglicht Sie, die Prozessablauf 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 Durchlaufzeit Trends für verschiedene Arbeitskategorien zu verfolgen.
Bedeutung
Es ermöglicht die Segmentierung der Prozessanalyse und erlaubt den Vergleich von Workflows und Leistungsfähigkeit für verschiedene Arbeitskategorien wie Bugs und Funktionen.
Datenquelle
Dies entspricht dem Feld "Work Item Typ" (Work Item Typ) eines Work Items in Azure DevOps.
Beispiele
Bug`Funktion`Benutzer StoryAufgabe
|
|||
|
Zugeordnet an
AssignedTo
|
Der Benutzer oder den Antrag bearbeitet.as 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 Lebenszykluss des Elements mehrfach ändern, z. B. von einem Entwickler zu einem Tester und dann zu einem Release Manager. Die Analyse nach "Assigned To" ist maßgeblich für das Developer und Tester Workload Übersicht Dashboard. Sie hilft, die Ressourcenzuweisung zu verstehen, überlastete Teammitglieder zu identifizieren und Leistungsunterschiede zwischen Einzelpersonen oder Teams zu analysierenn.
Bedeutung
Es ermöglicht eine Ressourcenbasierte Analyse, die dabei hilft, die Arbeitslastverteilung zu verstehen, Ressourcenspezifische Engpässe 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 Wartezeit 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 Lebenszyklus 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 den Antrag bearbeitet.ie 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-Leistungsfähigkeit auf Sprint-zu-Sprint-Basis zu verstehen. Sie kann verwendet werden, um zu verfolgen, ob sich die Durchlaufzeits über aufeinanderfolgende Sprints verbessern, Übertragungsarbeiten zu analysierenn 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 maßgeblich, um verborgene Engpässe 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 Engpässe 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 Durchlaufzeit Trends Dashboard, indem er Analysen ermöglicht, die nach Projekten segmentiert werden, um aufzuzeigen, ob bestimmte Projekte effizienter sind als andere oder ob Prozessoptimierungen 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`Daten 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 detailliertere Analyse des Code Review- und Integrationsteils des Lebenszykluss. Sie kann verwendet werden, um die Zeit von der Erstellung bis zum Abschluss des Pull Requests zu messen und zu analysierenn, 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 & Durchlaufzeit 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, in der Regel für Bugs, in Azure DevOps.
Beispiele
1 – Kritisch2 – Hoch3 – Mittel4 – Niedrig
|
|||
Software Development Life Cycle (SDLC) 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 den Antrag bearbeitet.ie Wertlieferung darstellt. Er dient als Endpunkt für die Berechnung von Lead Time und Durchlaufzeit.
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 maßgeblich, um Test-Engpässe 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 den Antrag bearbeitet.ie Änderungen nach dem Benutzer Acceptance Testing genehmigt haben. Dies wird in der Regel 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 Benutzer Story, eines Bugs oder einer Aufgabe. 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 wesentlich für die Messung der End-to-End-Entwicklungs-Durchlaufzeit 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 in der Regel 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 analysierenn. 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 in der Regel 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 Benutzer Acceptance Testing oder den Antrag bearbeitet.en Release bereit ist. Verzögerungen nach diesem Punkt können auf UAT- oder Release-Planungs-Engpässe 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 wesentlich zur Identifizierung von Rework-Loops. Eine hohe Häufigkeit dieses Ereignisse weist auf Probleme mit der Codequalität, den Anforderungen oder den Antrag bearbeitet.en Testprozessen hin.
Datenquelle
Abgeleitet aus der
Erfassen
Abgeleitet aus der Änderung des
Ereignistyp
inferred
|
|||
|
UAT gestartet
|
Stellt den Beginn des Benutzer Acceptance Testing dar, bei dem Business-Stakeholder den Antrag bearbeitet.ie Funktionalität validieren. Dies wird in der Regel 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 wichtig 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 den Antrag bearbeitet.efinitive Endpunkt des Lebenszykluss.
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', 'Abbrechenled' 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
|
|||