Ihr Daten-Template für den Softwareentwicklungslebenszyklus

Azure DevOps
Ihr Daten-Template für den Softwareentwicklungslebenszyklus

Ihr Daten-Template für den Softwareentwicklungslebenszyklus

Dieses Template zeigt Ihnen, wie Sie Daten zu Ihrem Softwareentwicklungslebenszyklus für Process Mining vorbereiten. Es beschreibt die erforderlichen Datenattribute und wichtigen Aktivitäten, die Sie erfassen sollten, und erklärt, wie Sie diese Informationen gezielt aus Azure DevOps extrahieren. So strukturieren Sie Ihre Daten für aussagekräftige Analysen und die Optimierung Ihrer Prozesse.
  • Empfohlene Attribute für die Datenerfassung
  • Wichtige Aktivitäten für die Analyse Ihres SDLC
  • Detaillierte Anleitungen zur Datenextraktion aus Azure DevOps
Neu bei Event Logs? Erfahren Sie, wie Sie ein Event Log für Process Mining erstellen.

Attribute des Softwareentwicklungslebenszyklus

Diese empfohlenen Datenfelder sollten Sie in Ihr Event Log aufnehmen, um den Softwareentwicklungslebenszyklus umfassend zu analysieren und zu optimieren.
5 Erforderlich 7 Empfohlen 6 Optional
Name Beschreibung
Aktivitätsname
ActivityName
Der Name des konkreten Ereignisses oder der Task, die zu einem bestimmten Zeitpunkt im Entwicklungslebenszyklus eines Arbeitselements stattgefunden hat.
Beschreibung

Der Aktivitätsname bezeichnet einen konkreten Prozessschritt oder Meilenstein, etwa „Entwicklung gestartet“, „Pull Request erstellt“ oder „In der Produktionsumgebung bereitgestellt“. Die Aktivitäten werden aus Statusänderungen des Arbeitselements, verknüpften Ereignissen wie Builds oder Pull Requests sowie benutzerdefinierten Ereignissen abgeleitet.

Dieses Attribut ist entscheidend für die Erstellung der Prozessübersicht, die den Workflow visualisiert. Es hilft Analysten, die Ereignisabfolge nachzuvollziehen, häufige Abläufe zu erkennen, Engpässe zwischen bestimmten Aktivitäten aufzudecken und die Häufigkeit einzelner Schritte zu analysieren.

Warum das wichtig ist

Das Attribut legt die Prozessschritte fest. Sie bilden das Grundgerüst der Prozessübersicht und ermöglichen die Analyse von Workflow, Engpässen und Abweichungen.

Woher beziehen

Wird in der Regel aus Änderungen des Felds „State“ eines Arbeitselements oder aus verknüpften Ereignissen wie Builds, Commits und Pull Requests abgeleitet. Die Rohdaten für diese Ereignisse stammen aus dem Verlauf des Arbeitselements.

Beispiele
Entwicklung gestartetPull Request abgeschlossenQA-Test nicht bestandenIn der Produktionsumgebung bereitgestelltArbeitselement geschlossen
Entwicklungselement
DevelopmentItem
Die eindeutige Kennung einer einzelnen Arbeitseinheit, etwa einer Funktion, eines Bugs oder einer User Story. Sie dient als Case-ID des Prozesses.
Beschreibung

Das Entwicklungselement steht für eine einzelne Arbeitseinheit, die in Azure DevOps erfasst wird. Jedes Element hat eine eindeutige ID und bildet den zentralen Bezugspunkt für alle Prozessaktivitäten, vom Erstellen und Planen über die Entwicklung und Tests bis zur Bereitstellung.

Bei der Process-Mining-Analyse ist dieses Attribut entscheidend, um alle zugehörigen Ereignisse zu einem einzelnen Case zusammenzuführen. So lässt sich der End-to-End-Lebenszyklus jedes Arbeitselements rekonstruieren und Zykluszeiten, Prozessabweichungen sowie Schleifen durch Nacharbeit für jedes Element einzeln analysieren.

Warum das wichtig ist

Diese zentrale Kennung verbindet alle Prozessschritte zu einem zusammenhängenden Case. Dadurch wird die End-to-End-Analyse des Softwareentwicklungslebenszyklus möglich.

Woher beziehen

Entspricht dem Feld „ID“ eines Arbeitselements in Azure DevOps Boards. Das Feld ist über die Azure-DevOps-REST-API für Work Item Tracking verfügbar.

Beispiele
10234102351023610237
Ereigniszeitpunkt
EventTime
Der genaue Zeitstempel, der angibt, wann eine bestimmte Aktivität oder ein Ereignis für ein Entwicklungselement stattgefunden hat.
Beschreibung

Der Ereigniszeitpunkt erfasst Datum und Uhrzeit jeder Aktivität im Entwicklungslebenszyklus. Dieser Zeitstempel bildet die Grundlage, um Ereignisse chronologisch zu ordnen und Zeitspannen zwischen ihnen zu berechnen.

Bei der Analyse ist dieses Attribut entscheidend für alle zeitbasierten Kennzahlen, darunter Zyklus-, Verarbeitungs- und Wartezeiten. Es ermöglicht die Erstellung eines chronologisch geordneten Event Logs, das als Eingabe für jede Process-Mining-Analyse erforderlich ist. Damit lassen sich Verzögerungen untersuchen, Leistungen anhand von SLAs messen und Entwicklungen im Zeitverlauf verfolgen.

Warum das wichtig ist

Dieser Zeitstempel gibt die chronologische Reihenfolge der Ereignisse an. Das ist entscheidend, um zeitbasierte KPIs zu berechnen und Prozessabläufe sowie Engpässe zu verstehen.

Woher beziehen

Dies ist das Feld „Changed Date“ für jede Aktualisierung im Verlauf eines Arbeitselements. Bei externen Ereignissen wie Builds oder Bereitstellungen entspricht es dem Abschlusszeitstempel des Ereignisses.

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 erfasst, wann der Datensatz zuletzt aus Azure DevOps extrahiert und aktualisiert wurde. Es zeigt, wie aktuell die Daten sind und welchen Zeitraum die Analyse abdeckt.

Für fundierte Entscheidungen ist es bei jeder Prozessanalyse wichtig zu wissen, wie aktuell die Daten sind. Anhand dieses Zeitstempels können Benutzer erkennen, ob sie Echtzeitinformationen oder einen historischen Datenstand betrachten. Das beeinflusst, wie relevant die Erkenntnisse sind.

Warum das wichtig ist

Das Attribut zeigt, wie aktuell die Daten sind. So ist klar, auf welchen Zeitraum sich Analysen und Entscheidungen beziehen.

Woher beziehen

Dies ist ein Metadaten-Zeitstempel, der während des ETL-Prozesses (Extraktion, Transformation und Laden) erstellt und gespeichert wird.

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

Dieses Attribut gibt an, aus welchem System die Daten stammen. Es ist besonders hilfreich, wenn Daten aus mehreren Systemen für eine umfassendere Prozessübersicht zusammengeführt werden. In diesem Modell lautet der Wert immer Azure DevOps.

Bei einer Analyse mit nur einem System mag das Attribut unveränderlich erscheinen. Dennoch liefert es wichtige Informationen zur Herkunft der Daten, die für Data Governance, Fehlerbehebung und künftige Integrationen mit anderen Systemen wie ServiceNow oder SAP entscheidend sind.

Warum das wichtig ist

Das Attribut liefert wichtige Informationen zur Herkunft der Daten. Diese sind für Data Governance, Validierung und die systemübergreifende Prozessanalyse relevant.

Woher beziehen

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

Beispiele
Azure DevOps
Arbeitselementtyp
WorkItemType
Die Klassifizierung des Entwicklungselements, etwa Bug, Funktion, User Story oder Task.
Beschreibung

Der Arbeitselementtyp kategorisiert die Art der ausgeführten Arbeit. Für unterschiedliche Arbeitselementtypen gelten häufig verschiedene Prozessabläufe, Leistungserwartungen oder SLAs. Ein Bug kann beispielsweise einen beschleunigten Ablauf durchlaufen, während eine Funktion einen anderen Prozess hat.

Dieses Attribut ist für Vergleichsanalysen wichtig. Sie können die Prozessübersicht oder KPIs nach Arbeitstyp filtern und so feststellen, ob bestimmte Abläufe bei Bugs effizienter sind als bei Funktionen. Außerdem lassen sich historische Zykluszeittrends für verschiedene Arbeitskategorien verfolgen.

Warum das wichtig ist

Damit können Sie die Prozessanalyse nach Arbeitskategorien aufschlüsseln und Workflows sowie Leistungen für unterschiedliche Arbeitstypen wie Bugs und Funktionen vergleichen.

Woher beziehen

Entspricht dem Feld „Arbeitselementtyp“ eines Arbeitselements in Azure DevOps.

Beispiele
FehlerFunktionUser StoryTask
Endzeit
EndTime
Der Zeitstempel, der angibt, wann eine Aktivität abgeschlossen wurde. Er dient zur Berechnung ihrer Verarbeitungszeit.
Beschreibung

Die Endzeit markiert den Abschluss einer Aktivität. In vielen Event Logs gilt die Startzeit der nächsten Aktivität als Endzeit der vorherigen. Eine separate Endzeit ermöglicht jedoch eine genauere Berechnung der Verarbeitungszeit einer Aktivität und der Leerlaufzeit zwischen Aktivitäten.

Dieses Attribut ist entscheidend für die Berechnung der KPI „Verarbeitungszeit“ und für eine detaillierte Engpassanalyse. Es hilft dabei, die aktive Bearbeitungszeit einer Task von der Wartezeit bis zum Beginn des nächsten Schritts zu unterscheiden. Das ist wichtig für das Dashboard zur Analyse von Phasenübergaben.

Warum das wichtig ist

Damit lassen sich Verarbeitungs- und Leerlaufzeiten von Aktivitäten genau berechnen. Das ist eine wichtige Grundlage für die Engpassanalyse und Effizienzsteigerungen.

Woher beziehen

Dieser Wert wird häufig abgeleitet. Er kann der Startzeit des nachfolgenden Ereignisses im selben Case entsprechen oder ausdrücklich erfasst werden, wenn das Quellsystem sowohl Start- als auch Endzeiten für Tasks speichert.

Beispiele
2023-10-26T18:00:00Z2023-10-27T15:00:00Z2023-10-28T11:00:00Z
Nacharbeit
IsRework
Ein boolesches Kennzeichen dafür, ob ein Entwicklungselement im Lebenszyklus in eine frühere Phase zurückgekehrt ist.
Beschreibung

Dieses Kennzeichen erhält den Wert „true“, wenn ein Arbeitselement eine Nacharbeitsschleife durchläuft, etwa wenn es von „Qualitätssicherung abgeschlossen“ zu „Entwicklung gestartet“ zurückkehrt. Der Wert wird berechnet, indem die Aktivitätsfolge eines Cases analysiert und nichtlineare Abläufe erkannt werden.

Dieses Attribut ist eine wichtige Grundlage für das Dashboard zur Häufigkeit von Nacharbeit und erneuten Tests sowie für die Kennzahl zur Häufigkeit von Nacharbeitsschleifen. Damit können Sie Nacharbeit einfach filtern und quantifizieren. So lassen sich Qualitätsprobleme, Kommunikationslücken oder unzureichende Tests erkennen, die zu ineffizienten Abläufen führen.

Warum das wichtig ist

Das Attribut erfasst und quantifiziert Nacharbeit direkt. So werden Qualitätsprobleme und Prozessineffizienzen sichtbar, die die Zykluszeiten verlängern.

Woher beziehen

Dieses berechnete Attribut wird aus der Aktivitätsfolge im Event Log für jeden Case abgeleitet.

Beispiele
truefalse
Priorität
Priority
Eine numerische oder beschreibende Einstufung der Bedeutung eines Entwicklungselements im Vergleich zu anderen Elementen.
Beschreibung

Die Priorität gibt an, wie dringend ein Arbeitselement eingeplant werden sollte. Bei hoher Priorität sollte ein Element schneller bearbeitet werden als Elemente mit niedrigerer Priorität. Übliche Werte sind Zahlen wie 1, 2, 3 und 4, wobei 1 die höchste Priorität bezeichnet.

Dieses Attribut ist eine wichtige Grundlage für das Dashboard zu Durchsatz und Zykluszeit nach Priorität. Die Analyse der Daten zeigt, ob die Priorisierung funktioniert, also ob Elemente mit hoher Priorität den Prozess tatsächlich schneller durchlaufen als solche mit niedriger Priorität.

Warum das wichtig ist

Damit lässt sich prüfen, ob Elemente mit hoher Priorität im Prozess tatsächlich bevorzugt bearbeitet werden. Das ist entscheidend, um die Wirksamkeit der Priorisierungsstrategie zu bewerten.

Woher beziehen

Dies entspricht dem Feld „Priority“ eines Arbeitselements in Azure DevOps.

Beispiele
1234
Status
State
Der aktuelle Status des Entwicklungselements im Workflow, zum Beispiel „Neu“, „Aktiv“, „Behoben“ oder „Geschlossen“.
Beschreibung

Das Attribut „Status“ gibt den formalen Status eines Arbeitselements zu einem bestimmten Zeitpunkt an, wie im Prozess-Template des Projekts festgelegt. Übergänge zwischen diesen Statuswerten bilden die wichtigste Grundlage für die Aktivitäten im Event Log.

Das Attribut „Aktivität“ beschreibt einen Statuswechsel häufig genauer. Der ursprüngliche Wert des Attributs „Status“ eignet sich jedoch für Filter und Analysen. Damit lässt sich nachvollziehen, wie lange Arbeitselemente in bestimmten Statuswerten verbleiben. Außerdem ist das Attribut eine wichtige Grundlage für das Dashboard zur Dauer der Prozessphasen und für die Analyse von Übergaben.

Warum das wichtig ist

Das Attribut zeigt den Status des Arbeitselements im Lebenszyklus an. Es ist entscheidend, um den Prozessablauf zu verstehen und die Verweildauer in den einzelnen Phasen zu berechnen.

Woher beziehen

Dies entspricht dem Feld „State“ eines Arbeitselements in Azure DevOps.

Beispiele
NeuAktivIn der QualitätssicherungBehobenGeschlossen
Teamname
TeamName
Der Name des Entwicklungsteams, das für das Arbeitselement verantwortlich ist.
Beschreibung

Der Teamname bezeichnet das Team, dem ein Arbeitselement zugewiesen ist. In Azure DevOps sind Arbeitselemente häufig Teams zugeordnet, die Teil eines größeren Projekts sein können.

Mit diesem Attribut können Sie Prozesse nach Team aufschlüsseln. So lassen sich Prozesse und Leistung verschiedener Teams vergleichen, bewährte Vorgehensweisen leistungsstarker Teams erkennen und Bereiche identifizieren, in denen einzelne Teams Unterstützung oder Verbesserungen ihrer Abläufe benötigen.

Warum das wichtig ist

Damit können Sie die Teams miteinander vergleichen, Leistungsunterschiede erkennen und bewährte Vorgehensweisen organisationsweit teilen.

Woher beziehen

Dieser Wert wird häufig aus dem Feld „Area Path“ eines Arbeitselements abgeleitet, da Teams in Azure DevOps in der Regel bestimmten Bereichspfaden zugeordnet sind.

Beispiele
Team PhoenixOmega-TeamPlattformkernFrontend-Team
Zugewiesen an
AssignedTo
Der Benutzer oder das Teammitglied, dem das Entwicklungselement aktuell zugewiesen ist.
Beschreibung

Dieses Attribut gibt an, wer in einer bestimmten Prozessphase für das Arbeitselement verantwortlich ist. Die Zuweisung kann sich im Lebenszyklus des Elements mehrfach ändern, etwa vom Entwickler zum Tester und anschließend zum Release-Manager.

Die Analyse nach „Zugewiesen an“ ist entscheidend für das Dashboard zur Arbeitsauslastung von Entwicklern und Testern. Sie hilft dabei, die Ressourcenverteilung zu verstehen, überlastete Teammitglieder zu erkennen und Leistungsunterschiede zwischen Personen oder Teams zu untersuchen.

Warum das wichtig ist

Das Attribut ermöglicht eine ressourcenbezogene Analyse. So lassen sich die Arbeitslastverteilung nachvollziehen, ressourcenspezifische Engpässe erkennen und die Teamkapazität steuern.

Woher beziehen

Entspricht dem Feld „Zugewiesen an“ eines Arbeitselements in Azure DevOps. Der Wert wird für jedes Ereignis aus dem Verlauf des Arbeitselements übernommen.

Beispiele
jane.doe@example.comjohn.smith@example.comNicht zugewiesen
Iterationspfad
IterationPath
Der Entwicklungs-Sprint oder festgelegte Zeitraum, dem das Arbeitselement zugewiesen ist.
Beschreibung

Der Iterationspfad, also der Sprint, bezeichnet einen festgelegten Entwicklungszeitraum. Arbeitselemente werden einer Iteration zugewiesen und sollen innerhalb dieses Zeitraums abgeschlossen werden.

Eine Analyse nach Iterationspfad zeigt die Prozessleistung für jeden einzelnen Sprint. Damit können Sie verfolgen, ob sich die Zykluszeiten von Sprint zu Sprint verbessern, übernommene Arbeit untersuchen und die Planbarkeit der Sprintplanung bewerten.

Warum das wichtig ist

Damit können Teams ihre Leistung für einzelne Sprints auswerten und ihre agilen Arbeitsweisen im Zeitverlauf verbessern.

Woher beziehen

Dies entspricht dem Feld „Iteration Path“ eines Arbeitselements in Azure DevOps.

Beispiele
E-Commerce-Plattform\Sprint 12E-Commerce-Plattform\Sprint 13Neustart der mobilen App\Phase 2\Sprint 4
Projektname
ProjectName
Der Name des Azure-DevOps-Projekts, zu dem das Entwicklungselement gehört.
Beschreibung

Dieses Attribut bezeichnet das Projekt innerhalb der Azure-DevOps-Organisation, in dem sich das Arbeitselement befindet. Es liefert einen übergeordneten Kontext, besonders in Organisationen mit vielen Projekten.

Der Projektname ist eine wichtige Dimension zum Filtern und Vergleichen. Im Dashboard zu historischen Zykluszeittrends können Sie damit die Analyse nach Projekt aufschlüsseln. So erkennen Sie, ob bestimmte Projekte effizienter arbeiten als andere und ob Prozessverbesserungen in einem Projekt positive Auswirkungen hatten.

Warum das wichtig ist

Das Attribut fasst Daten für die Analyse auf übergeordneter Ebene zusammen und ermöglicht Leistungsvergleiche sowie Trendanalysen über mehrere Projekte hinweg.

Woher beziehen

Dies entspricht dem Feld „Team Project“ eines Arbeitselements in Azure DevOps.

Beispiele
E-Commerce-PlattformNeustart der mobilen AppModernisierung des Data Warehouse
Pull-Request-ID
PullRequestId
Die Kennung eines Pull Requests, der mit dem Entwicklungselement verknüpft ist.
Beschreibung

Dieses Attribut verknüpft ein Arbeitselement mit einem bestimmten Pull Request, über den Codeänderungen eingereicht und geprüft werden. Ein Arbeitselement kann mehreren Pull Requests zugeordnet sein.

Mit der Pull-Request-ID können Sie die Codeprüfung und Integration im Lebenszyklus detaillierter analysieren. Sie können die Zeit zwischen dem Erstellen und Abschließen eines Pull Requests messen und untersuchen, wie oft Pull Requests abgelehnt werden oder umfangreiche Änderungen erfordern. Das kann auf die Codequalität oder unklare Anforderungen hinweisen.

Warum das wichtig ist

Damit ordnen Sie Entwicklungsarbeit bestimmten Codeprüfungen zu und können die Integration sowie Qualitätssicherung detailliert analysieren.

Woher beziehen

Diese Information finden Sie im Bereich „Links“ oder „Development“ eines Arbeitselements in Azure DevOps.

Beispiele
452145334589
Schweregrad
Severity
Gibt an, welche Auswirkungen ein Fehler oder Problem auf das System oder die Endbenutzer hat.
Beschreibung

Der Schweregrad stuft die Auswirkungen eines Fehlers ein, von kritischen Systemausfällen bis hin zu geringfügigen Darstellungsfehlern. Er unterscheidet sich von der Priorität, die die Reihenfolge der Bearbeitung festlegt. Ein Fehler mit hohem Schweregrad kann eine niedrige Priorität haben, wenn eine einfache Umgehungslösung verfügbar ist.

Dieses Attribut ergänzt die Analyse, insbesondere im Dashboard zu Durchsatz und Zykluszeit nach Priorität. Damit können Sie Fragen untersuchen wie: „Beheben wir zuerst die kritischsten Fehler?“ Außerdem hilft es, das Risikoprofil der bearbeiteten Arbeitselemente besser einzuschätzen.

Warum das wichtig ist

Damit lassen sich Arbeitselemente nach ihren geschäftlichen Auswirkungen kategorisieren und Sie können analysieren, wie wirksam das Team Probleme mit hohen Auswirkungen bearbeitet.

Woher beziehen

Dies entspricht dem Feld „Severity“ eines Arbeitselements in Azure DevOps, das üblicherweise für Fehler verwendet wird.

Beispiele
1 - Kritisch2 - Hoch3 - Mittel4 - Niedrig
Übergabezeit zwischen Prozessphasen
StageHandoffTime
Die Dauer der Wartezeit zwischen dem Abschluss einer wichtigen Prozessphase und dem Beginn der nächsten.
Beschreibung

Die Übergabezeit zwischen Prozessphasen misst die Wartezeit zwischen aufeinanderfolgenden Phasen, zum Beispiel zwischen „Entwicklung abgeschlossen“ und „Qualitätssicherung gestartet“. Sie wird berechnet, indem die entsprechenden Übergänge ermittelt und die Zeit zwischen dem Ende der ersten und dem Beginn der zweiten Aktivität gemessen wird.

Diese Kennzahl steht im Mittelpunkt des Dashboards zur Dauer von Prozessphasen und Übergaben. Die Übergabezeit gesondert zu erfassen und zu messen, ist entscheidend, um verborgene Engpässe zu erkennen, an denen Arbeit stillsteht. Häufige Ursachen sind fehlende Ressourcen, verzögerte Kommunikation oder ineffiziente Abläufe.

Warum das wichtig ist

Die Kennzahl erfasst Wartezeiten zwischen Prozessphasen und macht so verborgene Engpässe und Verzögerungen außerhalb der aktiven Arbeit sichtbar.

Woher beziehen

Dieses Attribut wird berechnet. Dazu müssen aufeinanderfolgende Aktivitäten ermittelt werden, die eine Übergabe darstellen. Anschließend wird der Zeitunterschied zwischen ihnen berechnet.

Beispiele
2 Stunden 15 Minuten1 Tag 4 Stunden30 Minuten
Wartezeit auf Freigaben
ApprovalWaitingTime
Die Zeit, die ein Entwicklungselement nach einer Freigabeanfrage auf die Freigabe wartet.
Beschreibung

Diese Kennzahl misst die Dauer bestimmter Wartezeiten, in denen ein Arbeitselement auf eine Freigabe wartet. Ein Beispiel ist die Zeit zwischen „UAT gestartet“ und „UAT freigegeben“. Für einen Case wird die Zeit zwischen diesen beiden Aktivitäten berechnet.

Dieses berechnete Attribut unterstützt direkt das Dashboard und die entsprechende Kennzahl zur Analyse der Wartezeit auf Freigaben. Wenn Teams diese Verzögerungen gesondert erfassen, können sie gezielt Kommunikation und Entscheidungsprozesse verbessern, Leerlauf verringern und den gesamten Lebenszyklus beschleunigen.

Warum das wichtig ist

Das Attribut misst gezielt Verzögerungen durch ausstehende Entscheidungen oder Freigaben. Dadurch werden Möglichkeiten zur Verbesserung der Kommunikation und Entscheidungsfindung sichtbar.

Woher beziehen

Der Wert wird berechnet, indem bestimmte Aktivitäten für den Beginn und das Ende einer Freigabe im Event Log ermittelt werden, zum Beispiel „UAT gestartet“ und „UAT freigegeben“, und der Zeitunterschied zwischen ihnen bestimmt wird.

Beispiele
3 Tage 2 Stunden1 Tag 8 Stunden 30 Minuten4 Stunden
Erforderlich Empfohlen Optional

Aktivitäten im Softwareentwicklungslebenszyklus

Diese wichtigen Prozessschritte und Meilensteine sollten Sie in Ihrem Event Log erfassen, um den Prozess zuverlässig zu entdecken und Engpässe zu erkennen.
7 Empfohlen 8 Optional
Aktivität Beschreibung
Arbeitselement erstellt
Diese Aktivität markiert den Beginn des Entwicklungslebenszyklus. Sie steht für das Erstellen eines neuen Arbeitselements, etwa einer User Story, eines Bugs oder einer Task. Das Ereignis wird ausdrücklich erfasst, sobald ein neuer Datensatz in Azure DevOps Boards gespeichert wird.
Warum das wichtig ist

Dies ist das primäre Start-Event des Prozesses. Es ist entscheidend, um die End-to-End-Zykluszeit der Entwicklung zu messen und die ursprünglichen Quellen der Arbeit zu verstehen.

Woher beziehen

Das Ereignis wird anhand des Felds „Created Date“ im Arbeitselement erfasst. Auch die Verlaufstabelle des Arbeitselements hält diesen ersten Statusübergang fest.

Erfassung

Wird aus dem Feld „Created Date“ des Arbeitselements übernommen.

Ereignistyp explicit
Entwicklung gestartet
Diese Aktivität zeigt an, dass ein Entwickler aktiv mit der Arbeit am Element begonnen hat. Sie wird aus einer Änderung des Status des Arbeitselements auf „Aktiv“, „In Bearbeitung“ oder „Zugesagt“ abgeleitet.
Warum das wichtig ist

Markiert den Beginn der aktiven Entwicklungsphase. Die Analyse der Zeit zwischen „Erstellt“ und „Entwicklung gestartet“ zeigt Wartezeiten im Backlog.

Woher beziehen

Wird aus dem Verlauf des Arbeitselements abgeleitet, wenn sich das Feld System.State von „Neu“ oder „Genehmigt“ zu „In Bearbeitung“ ändert.

Erfassung

Wird aus einer Änderung des Felds State auf „Aktiv“ oder „In Bearbeitung“ abgeleitet.

Ereignistyp inferred
In der Produktionsumgebung bereitgestellt
Markiert die erfolgreiche Bereitstellung des mit dem Arbeitselement verknüpften Codes in der Produktionsumgebung. Dieses Ereignis wird ausdrücklich in den Release-Protokollen von Azure Pipelines erfasst.
Warum das wichtig ist

Dies ist ein wichtiger Meilenstein, der die Bereitstellung des Ergebnisses markiert. Er dient als Endpunkt für die Berechnung von Durchlauf- und Zykluszeit.

Woher beziehen

Wird anhand der Release-Pipeline-Daten von Azure Pipelines erfasst, insbesondere anhand des Abschlussereignisses einer Bereitstellung in einer mit dem Arbeitselement verknüpften Phase „Produktion“.

Erfassung

Wird anhand des Abschlussereignisses einer Bereitstellung in einer Release-Pipeline erfasst.

Ereignistyp explicit
Pull Request abgeschlossen
Steht für den erfolgreichen Abschluss der Codeprüfung: Der Pull Request wurde genehmigt und der Code in den Zielbranch übernommen. Dieses Ereignis wird ausdrücklich in Azure Repos protokolliert.
Warum das wichtig ist

Markiert das Ende der Codeprüfung, die häufig einen Engpass darstellt. Die Analyse der Zeit zwischen dem Erstellen und dem Abschließen eines PR zeigt, wie effizient die Prüfung abläuft.

Woher beziehen

Wird anhand des Abschluss- oder Merge-Ereignisses eines Pull Requests in Azure Repos erfasst, der mit einem Arbeitselement verknüpft ist.

Erfassung

Wird anhand des Merge-Ereignisses eines Pull Requests erfasst, der mit einem Arbeitselement verknüpft ist.

Ereignistyp explicit
Pull Request erstellt
Zeigt an, dass der Entwickler die erste Programmierung abgeschlossen und die Änderungen über einen Pull Request zur Prüfung eingereicht hat. Dieses Ereignis verknüpft das Arbeitselement mit einer konkreten Codeänderung in Azure Repos.
Warum das wichtig ist

Dies ist eine wichtige Übergabe von der Entwicklung an die Codeprüfung. Die Erfassung hilft dabei, die Dauer der Programmierung zu messen und festzustellen, wann der Code zur Prüfung durch andere bereit ist.

Woher beziehen

Wird anhand von Azure-Repos-Daten erfasst, indem das Erstellungsereignis des Pull Requests mit dem zugehörigen Arbeitselement verknüpft wird. Häufig stellt der Entwickler diese Verknüpfung ausdrücklich her.

Erfassung

Wird anhand des Erstellungsereignisses eines Pull Requests in Azure Repos erfasst, das mit einem Arbeitselement verknüpft ist.

Ereignistyp explicit
QA-Tests gestartet
Steht für den Beginn der formellen Qualitätssicherungsphase. Diese Aktivität wird abgeleitet, wenn der Status eines Arbeitselements auf „In QA“, „Test“ oder einen ähnlichen Wert geändert wird.
Warum das wichtig ist

Markiert den Beginn des QA-Zyklus. Die Dauer dieser Phase zu analysieren, ist entscheidend, um Engpässe und die Effizienz der Tests zu verstehen.

Woher beziehen

Wird aus dem Verlauf des Arbeitselements abgeleitet, indem eine Änderung des Felds System.State auf „In QA“ oder einen anderen festgelegten Teststatus erfasst wird.

Erfassung

Wird aus einer Änderung des Felds State auf „In QA“ oder „Test“ abgeleitet.

Ereignistyp inferred
UAT genehmigt
Diese Aktivität zeigt an, dass die Fachabteilungen die Änderungen nach dem Benutzerakzeptanztest genehmigt haben. Sie wird in der Regel aus einer Statusänderung von „In UAT“ zu „UAT genehmigt“ oder „Bereit für Veröffentlichung“ abgeleitet.
Warum das wichtig ist

Dieser wichtige Freigabeschritt bestätigt, dass das Arbeitselement die geschäftlichen Anforderungen erfüllt und für die Bereitstellung in der Produktionsumgebung bereit ist.

Woher beziehen

Wird aus dem Verlauf des Arbeitselements abgeleitet, indem eine Änderung des Felds System.State von einem UAT-Status zu einem genehmigten oder für die Veröffentlichung bereiten Status erkannt wird.

Erfassung

Wird aus einer Änderung des Felds State von „In UAT“ zu „Bereit für Veröffentlichung“ abgeleitet.

Ereignistyp inferred
Arbeitselement abgebrochen
Zeigt an, dass das Arbeitselement abgebrochen wurde und weder abgeschlossen noch bereitgestellt wird. Erfasst wird eine Statusänderung auf „Entfernt“, „Abgebrochen“ oder einen ähnlichen Status.
Warum das wichtig ist

Dies ist ein alternativer, nicht erfolgreicher Prozessabschluss. Die Analyse abgebrochener Elemente kann Probleme bei der Planung, Priorisierung oder Definition von Anforderungen aufdecken.

Woher beziehen

Wird aus dem Verlauf des Arbeitselements abgeleitet, wenn das Feld System.State auf einen Endstatus in der Kategorie „Entfernt“ gesetzt wird.

Erfassung

Wird aus einer Änderung des Felds State auf „Entfernt“ oder „Abgebrochen“ abgeleitet.

Ereignistyp inferred
Arbeitselement genehmigt
Steht für die formelle Genehmigung eines Arbeitselements. Damit wird bestätigt, dass es klar definiert und bereit für die Entwicklung ist. Dies wird in der Regel aus einer Änderung des Felds „State“ auf einen Wert wie „Genehmigt“ oder „Bereit für Entwicklung“ abgeleitet.
Warum das wichtig ist

Die Erfassung von Genehmigungen hilft dabei, die Zeit zwischen dem Einreichen einer Idee und der Zusage für die Entwicklung zu analysieren. So werden mögliche Verzögerungen in der Planung und bei der Pflege des Backlogs sichtbar.

Woher beziehen

Wird aus dem Verlauf des Arbeitselements abgeleitet, indem eine Änderung des Felds System.State auf „Genehmigt“ oder einen ähnlichen benutzerdefinierten Status erkannt wird.

Erfassung

Wird aus einer Änderung des Felds State auf „Genehmigt“ abgeleitet.

Ereignistyp inferred
Arbeitselement geschlossen
Steht für den endgültigen Abschluss des Arbeitselements nach der Bereitstellung und etwaigen Prüfungen danach. Erfasst wird eine Statusänderung auf „Geschlossen“ oder „Abgeschlossen“.
Warum das wichtig ist

Diese Aktivität markiert den erfolgreichen Abschluss des gesamten Prozesses für ein Arbeitselement. Sie ist der eindeutige Endpunkt des Lebenszyklus.

Woher beziehen

Wird aus dem Verlauf des Arbeitselements abgeleitet, wenn das Feld System.State auf „Geschlossen“ oder einen ähnlichen Endstatus in der Kategorie „Abgeschlossen“ gesetzt wird.

Erfassung

Wird aus einer Änderung des Felds State auf „Geschlossen“ abgeleitet.

Ereignistyp inferred
Build erfolgreich
Diese Aktivität bestätigt, dass der Quellcode einschließlich der neuen Änderungen von einer Build-Pipeline erfolgreich kompiliert und paketiert wurde. Azure Pipelines protokolliert dieses Ereignis ausdrücklich.
Warum das wichtig ist

Dieses wichtige Quality Gate stellt sicher, dass sich neuer Code korrekt integrieren lässt, ohne den Build zu beeinträchtigen. Fehler in dieser Phase können auf Integrationsprobleme hindeuten.

Woher beziehen

Wird anhand der Build-Abschlussereignisse von Azure Pipelines erfasst. Der Build muss mit dem Arbeitselement verknüpft sein, entweder direkt oder über den zugehörigen Pull Request.

Erfassung

Wird anhand des Build-Abschlussereignisses von Azure Pipelines erfasst.

Ereignistyp explicit
Entwicklung abgeschlossen
Zeigt an, dass alle Entwicklungsarbeiten und Unit-Tests abgeschlossen sind und das Element für formelle Tests bereit ist. Dies wird in der Regel aus einer Statusänderung des Arbeitselements auf „Behoben“ oder „Bereit für Test“ abgeleitet.
Warum das wichtig ist

Markiert eine wichtige Übergabe vom Entwicklungsteam an das QA-Team. Die Zeit bis zum Start der QA-Tests hilft dabei, Verzögerungen bei der Übergabe zu erkennen.

Woher beziehen

Wird aus dem Verlauf des Arbeitselements abgeleitet, wenn sich das Feld System.State auf einen Wert wie „Behoben“ oder einen benutzerdefinierten Status ändert, der die QA-Bereitschaft anzeigt.

Erfassung

Wird aus einer Änderung des Felds State auf „Behoben“ abgeleitet.

Ereignistyp inferred
QA-Test nicht bestanden
Zeigt an, dass das Arbeitselement die Qualitätssicherungstests nicht bestanden hat und zur Entwicklung zurückgeht. Erfasst wird eine Statusänderung von einem Teststatus zurück zu „In Bearbeitung“ oder „Aktiv“.
Warum das wichtig ist

Diese Aktivität ist wichtig, um Schleifen durch Nacharbeit zu erkennen. Tritt sie häufig auf, kann das auf Probleme mit der Codequalität, den Anforderungen oder den Testprozessen hindeuten.

Woher beziehen

Wird aus dem Verlauf des Arbeitselements abgeleitet, indem ein Übergang von einem Status wie „In QA“ zurück zu einem Status wie „Aktiv“ oder „In Bearbeitung“ erkannt wird.

Erfassung

Wird aus einer Änderung des Felds State von „In QA“ zurück zu „Aktiv“ abgeleitet.

Ereignistyp inferred
QA-Tests abgeschlossen
Markiert den erfolgreichen Abschluss der Qualitätssicherungsphase. Dies wird abgeleitet, wenn sich der Status des Arbeitselements von einem Teststatus zu einem Status wie „Bereit für UAT“ oder „QA genehmigt“ ändert.
Warum das wichtig ist

Dieses wichtige Quality Gate zeigt an, dass das Element für den Benutzerakzeptanztest oder die Veröffentlichung bereit ist. Verzögerungen danach können auf Engpässe bei UAT oder der Release-Planung hindeuten.

Woher beziehen

Wird aus dem Verlauf des Arbeitselements abgeleitet, wenn sich das Feld System.State von „In QA“ zu einem nachfolgenden Status wie „Bereit für UAT“ oder „Abgeschlossen“ ändert.

Erfassung

Wird aus einer Änderung des Felds State von „In QA“ zu „Bereit für UAT“ abgeleitet.

Ereignistyp inferred
UAT gestartet
Markiert den Beginn des Benutzerakzeptanztests (UAT), bei dem die Fachabteilungen die Funktionalität prüfen. Dies wird in der Regel aus einer Statusänderung auf „In UAT“ oder einen ähnlichen Status abgeleitet.
Warum das wichtig ist

Misst den Beginn der abschließenden Prüfung vor der Veröffentlichung. Für die Prozessoptimierung sind die Dauer von UAT und die Wartezeiten auf Freigaben wichtige Analysegrößen.

Woher beziehen

Wird aus dem Verlauf des Arbeitselements abgeleitet, wenn das Feld System.State auf einen benutzerdefinierten UAT-Status wie „In UAT“ gesetzt wird.

Erfassung

Wird aus einer Änderung des Felds State auf „In UAT“ abgeleitet.

Ereignistyp inferred
Empfohlen Optional

Anleitungen zur Datenextraktion

So exportieren Sie Ihre Daten aus Azure DevOps

Möchten Sie loslegen?

Beginnen Sie noch heute damit, Ihren Softwareentwicklungslebenszyklus zu optimieren. Dieses Template ist Ihr erster Schritt zu wertvollen Erkenntnissen über Ihre Prozesse.

Optimieren Sie Ihren SDLC in Azure DevOps. Starten Sie noch heute!

Verkürzen Sie die Zykluszeit um 30 % und beseitigen Sie Engpässe in Ihrem SDLC-Workflow.

Starten Sie Ihre kostenlose Testphase

Keine Kreditkarte erforderlich. Sie können in wenigen Minuten loslegen.