Ereignisse
Nehmen Sie sich die Microsoft Learn-Herausforderung an
19. Nov., 23 Uhr - 10. Jan., 23 Uhr
Ignite Edition - Erstellen Sie Fähigkeiten in Microsoft Azure und verdienen Sie bis zum 10. Januar ein digitales Badge!
Jetzt registrierenDieser Browser wird nicht mehr unterstützt.
Führen Sie ein Upgrade auf Microsoft Edge durch, um die neuesten Features, Sicherheitsupdates und den technischen Support zu nutzen.
Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2019
Wie können Sie Fehler in Ihrem Code nachverfolgen und verwalten? Wie stellen Sie sicher, dass Softwareprobleme und Kundenfeedback schnell behoben und umgesetzt werden, um qualitativ hochwertige Softwarebereitstellungen zu unterstützen? Wie machen Sie gute Fortschritte bei neuen Features, und wie gehen Sie Ihre technischen Schulden an?
Sie benötigen mindestens eine Möglichkeit, um Ihre Softwareprobleme zu erfassen, sie zu priorisieren, einem Teammitglied zuzuweisen und den Fortschritt nachzuverfolgen. Sie sollten Ihre Codefehler auf eine Weise verwalten, die mit Ihren Agile-Methoden in Einklang steht.
Um diese Szenarien zu unterstützen, stellt Azure Boards einen spezifischen Arbeitselementtyp zur Nachverfolgung von Codefehlern mit dem Namen Bug (Fehler) bereit. Fehlerarbeitselemente besitzen alle Standardmerkmale, über die andere Arbeitselementtypen auch verfügen, sowie ein paar mehr. Eine Übersicht über Standardfeatures finden Sie unter Informationen zu Arbeitselementen und Arbeitselementtypen.
Fehler bieten auch folgende Features:
Hinweis
Fehlerarbeitselement-Typen sind im Basic-Prozess nicht verfügbar. Der Basic-Prozess verfolgt Fehler als Probleme nach und ist verfügbar, wenn Sie ein neues Projekt aus Azure DevOps Services oder Azure DevOps Server 2019.1 oder höher erstellen.
Berechtigungen:
Wenn Sie Arbeitsaufgaben Tags hinzufügen möchten, müssen Sie die Berechtigung "Neue Tagdefinition erstellen" auf Projektebene auf "Zulassen" festlegen. Die Gruppe Mitwirkende verfügt standardmäßig über diese Berechtigung.
Zugriffsebenen:
Hinweis
Hinweis
Tipp
Um einen Fehler melden zu können, muss ein Benutzer mindestens über Zugriff vom Typ Stakeholder verfügen. Für einen Benutzer muss die Berechtigung Arbeitselemente in diesem Knoten bearbeiten für den Bereichspfad, an dem der Fehler hinzugefügt wird, auf Zulassen festgelegt sein. Weitere Informationen finden Sie unter Festlegen von Berechtigungen für die Arbeitsnachverfolgung.
Die folgende Abbildung zeigt den Fehler-Arbeitselementtyp für den Scrum-Prozess. Der Arbeitselementtyp „Bug“ für Agile- und CMMI-Prozesse (Capability Maturity Model Integration) verfolgt ähnliche Informationen nach. Er wird im Product Backlog zusammen mit Anforderungen oder im Taskboard zusammen mit Aufgaben angezeigt.
Hinweis
Die Anzeige in Ihrem Webportal kann sich von den Screenshots in diesem Artikel unterscheiden. Diese Unterschiede ergeben sich aus an Ihrer Web-App vorgenommenen Aktualisierungen, Optionen, die Sie oder Ihr Administrator aktiviert haben, sowie daraus, welcher Prozess beim Erstellen Ihres Projekts ausgewählt wurde: Agile, Basic, Scrum oder CMMI. Der Basic-Prozess ist mit Azure DevOps Server 2019, Update 1 und höheren Versionen verfügbar.
Der Arbeitselementtyp „Fehler“ verwendet einige fehlerspezifische Felder. Verwenden Sie die in der folgenden Tabelle beschriebenen Felder, um sowohl das anfängliche Problem als auch die laufenden Ermittlungen und Erkenntnisse zu erfassen. Informationen zu Feldern, die für den für den CMMI-Prozess (Capability Maturity Model Integration) definierten Fehler spezifisch sind, finden Sie unter Feldreferenz für Fehler, Probleme und Risiken. Informationen zu allen anderen Feldern finden Sie unter Index der Arbeitselementfelder.
Feld, Gruppe oder Registerkarte
Verwendung
Schritte zum Reproduzieren (Anzeigename=Repro-Schritte)
Erfassen Sie hier genügend Informationen, damit andere Teammitglieder den Codefehler vollständig verstehen können. Hierzu gehören Aktionen zum Finden oder Reproduzieren des Fehlers und des erwarteten Verhaltens.
Informationen zur Software und zur Systemkonfiguration, die für den Fehler und anzuwendende Tests relevant sind. Die Felder Systeminformationen und In Build gefunden werden automatisch ausgefüllt, wenn Sie einen Fehler über ein Testtool erstellen. Diese Felder geben Informationen zur Softwareumgebung und dem Build an, in der/dem der Fehler aufgetreten ist. Weitere Informationen finden Sie unter Testen verschiedener Konfigurationen.
Geben Sie die Kriterien an, die erfüllt werden müssen, bevor der Fehler geschlossen werden kann. Beschreiben Sie vor Beginn der Arbeit die Kundenakzeptanzkriterien so klar wie möglich. Teams sollten diese Kriterien als Grundlage für Akzeptanztests verwenden und um zu bewerten, ob ein Element zufriedenstellend abgeschlossen wurde.
Gibt den Namen des Builds an, der den Code enthält, mit dem der Fehler korrigiert wird. Dieses Feld sollte angegeben werden, wenn Sie den Fehler auflösen.
Für Azure DevOps in der lokalen Umgebung: Wenn Sie auf ein Dropdownmenü aller Builds zugreifen möchten, die ausgeführt wurden, können Sie die FIELD
-Definitionen für Gefunden in Build und In den Build integriert aktualisieren, um eine globale Liste heranzuziehen. Die globale Liste wird jedes Mal automatisch aktualisiert, wenn der Build ausgeführt wird. Weitere Informationen finden Sie unter Auf Build- und Testintegrationsfeldern basierende Abfrage.
Informationen zum Definieren von Buildnummern finden Sie unter Konfiguration klassischer Pipelines.
Eine subjektive Bewertung der Auswirkungen eines Fehlers oder Arbeitselements auf das Projekt oder Softwaresystem. Beispiel: Wenn ein Remotelink auf der Benutzeroberfläche dazu führt, dass eine Anwendung oder Webseite abstürzt (was selten vorkommt, aber eine äußerst negative Kundenerfahrung darstellt), können Sie Schweregrad = 2 – Hoch und Priorität = 3 angeben. Zulässige Werte und vorgeschlagene Richtlinien sind:
Das Deployment-Steuerelement (Bereitstellung) unterstützt Links zu und die Anzeige von Releases, die Arbeitselemente enthalten. Um das Steuerelement verwenden zu können, müssen Sie Einstellungen für das Release aktivieren. Weitere Informationen finden Sie weiter unten in diesem Artikel unter Verknüpfen von Arbeitselementen mit Releases.
Das Development-Steuerelement (Entwicklung) unterstützt Links zu Entwicklungsobjekten sowie die Anzeige von Links, die zu Entwicklungsobjekten erstellt wurden. Zu diesen Objekten gehören Git-Commits und Pull Requests oder TFVC-Changesets sowie versionierte Elemente. Sie können Links aus dem Arbeitselement oder aus den Commits, Pull Requests oder anderen Entwicklungsobjekten definieren. Weitere Informationen finden Sie weiter unten in diesem Artikel unter Verknüpfen von Arbeitselementen mit der Entwicklung.
1 Informationen zum Ändern der Menüauswahl oder der Auswahlliste finden Sie unter Anpassen der Arbeitsnachverfolgung. Die Anpassungsmethode hängt vom Prozessmodell ab, das von Ihrem Projekt verwendet wird.
Ihr Team kann Fehler als Anforderungen oder als Aufgaben nachverfolgen. Berücksichtigen Sie die folgenden Faktoren, um die Teamauswahl zu unterstützen.
In der folgenden Tabelle sind die drei Optionen zusammengefasst, die Teams zum Nachverfolgen von Fehlern haben. Weitere Informationen und Informationen zum Festlegen der Option für Ihr Team finden Sie unter Anzeigen von Fehlern in Backlogs und Boards.
Option
Für diese Zwecke geeignet...
Fehlern als Anforderungen nachverfolgen
Hinweis
Fehler als Aufgaben nachverfolgen
Hinweis
Fehler werden weder in Backlogs noch Boards angezeigt
Hinweis
Sie können den Fehler und andere Arbeitselementtypen anpassen. Oder benutzerdefinierte Typen erstellen, um Softwareprobleme oder Kundenfeedback nachzuverfolgen. Bei allen Arbeitselementtypen können Sie die folgenden Elemente anpassen:
Bevor Sie Ihren Prozess anpassen, sollten Sie den Artikel Über die Konfiguration und Anpassung von Azure Boards lesen.
Informationen zum Anpassen Ihres spezifischen Prozesses finden Sie unter Anpassen eines Vererbungsprozesses.
Informationen zum Anpassen Ihres spezifischen Prozesses finden Sie unter Anpassen eines Vererbungsprozesses oder Anpassen des lokalen XML-Prozessmodells.
Sie können Fehler aus verschiedenen Azure DevOps-Tools heraus definieren. Diese Tools umfassen Backlogs und Boards sowie Testtools.
Tipp
Standardmäßig ist das Feld Titel das einzige Pflichtfeld bei der Erstellung eines Fehlers. Fehler können auf die gleiche Weise hinzugefügt werden wie User Storys oder Product Backlog Items mit Azure Boards. Sie können einige Felder zu Pflichtfeldern machen, indem Sie bedingte Regeln auf der Grundlage einer Zustandsänderung hinzufügen. Weitere Informationen finden Sie unter Hinzufügen einer Regel zu einem Arbeitsaufgabentyp (Vererbungsprozess).
Wenn sich Ihr Team für die Verwaltung von Fehlern mit Anforderungen entschieden hat, können Sie Fehler über Ihr Product Backlog oder Board definieren. Weitere Informationen finden Sie unter Erstellen Ihres Backlogs in Azure Boards oder unter Verwenden des Boards.
Hinzufügen eines Fehlers aus dem Kanban-Board
Hinzufügen eines Fehlers über das Board
Tipp
Wenn Sie einen Fehler aus Ihrem Product Backlog oder Board hinzufügen, werden dem Fehler automatisch der standardmäßige Bereichspfad und Iterationspfad zugewiesen, die für das Team definiert sind. Weitere Informationen finden Sie unter Standardeinstellungen für Teams, auf die von Backlogs und Boards verwiesen wird.
Wenn sich Ihr Team für die Verwaltung von Fehlern mit Aufgaben entschieden hat, können Sie Fehler über Ihr Board, Product Backlog, Sprintbacklog oder Sprint-Taskboard definieren. Sie fügen einen Fehler einem Product Backlog-Arbeitselement als untergeordnetes Element hinzu.
Hinzufügen eines verknüpften untergeordneten Fehlers aus dem Sprint Backlog
Sie fügen einen Fehler auf die gleiche Weise hinzu, wie Sie einem Sprint Backlog eine Aufgabe hinzufügen. Weitere Informationen finden Sie unter Hinzufügen von Aufgaben zu Backlog Items.
Hinzufügen eines verknüpften untergeordneten Fehlers aus dem Board
Sie fügen einen Fehler auf die gleiche Weise hinzu, wie Sie einem Backlog Item eine Aufgabe hinzufügen. Weitere Informationen finden Sie unter Hinzufügen von Aufgaben oder untergeordneten Elementen als Prüflisten.
Zu den beiden Testtools, mit denen Sie beim Testen Fehler hinzufügen können, gehören im Webportal „Test Runner“ und die Erweiterung „Testen Feedback“.
Test Runner: Beim Ausführen manueller Tests können Sie Fehler erstellen auswählen. Weitere Informationen finden Sie unter Ausführen manueller Tests.
Erweiterung „Testen und Feedback“: Wenn Sie explorative Tests ausführen, können Sie zwischen „Fehler erstellen“ und Aufgabe erstellen auswählen. Weitere Informationen finden Sie unter Exploratives Testen mit der Erweiterung „Test und Feedback“.
Wie bei allen anderen Arbeitselementtypen verfügt auch der Fehler-Arbeitselementtyp über einen klar definierten Workflow. Jeder Workflow besteht aus drei oder mehr Zuständen und einem Grund. Gründe geben an, warum das Element von einem Zustand in einen anderen gewechselt ist. Die folgenden Abbildungen veranschaulichen den standardmäßigen Fehlerworkflow, der für die Prozesse Agile, Scrum und CMMI definiert ist.
Agilität | Scrum | CMMI |
---|---|---|
Bei Scrum-Fehlern ändern Sie den Zustand von Committet (ähnlich wie Aktiv) in Fertig. Für Agile und CMMI lösen Sie zunächst den Fehler auf und wählen dann einen Grund aus, der anzeigt, dass der Fehler korrigiert wurde. In der Regel überprüft die Person, die den Fehler erstellt hat, den Fix und aktualisiert den Zustand von Aufgelöst in Geschlossen. Sollten nach dem Beheben oder Schließen eines Fehlers weitere Arbeiten erforderlich sein, können Sie den Fehler reaktivieren, indem Sie den Zustand auf Committet oder Aktiv festlegen.
Hinweis
Der Arbeitselementtyp „Fehler“ im Agile-Prozess verfügte zuvor über eine Regel, die den Fehler wieder der Person zuwies, die ihn erstellt hatte. Diese Regel wurde aus dem Standardsystemprozess entfernt. Sie können diese Automatisierung reaktivieren, indem Sie eine Regel hinzufügen. Informationen zu einem Vererbungsprozess finden Sie unter Automatisieren der Neuzuweisung basierend auf Zustandsänderungen.
Um einen Fix zu überprüfen, versucht ein Entwickler oder Tester, den Fehler zu reproduzieren, und sucht dann nach weiterem unerwartetem Verhalten. Nötigenfalls sollte der Fehler reaktiviert werden.
Wenn Sie eine Fehlerkorrektur (Fix) überprüfen, stellen Sie möglicherweise fest, dass der Fehler nicht korrigiert wurde, oder Sie sind möglicherweise nicht mit der Auflösung einverstanden. In diesem Fall besprechen Sie den Fehler mit der Person, die ihn aufgelöst hat, erzielen Sie eine Übereinkunft, und aktivieren den Fehler eventuell erneut. Wenn Sie einen Fehler erneut aktivieren, nehmen Sie die Gründe für das erneute Aktivieren des Fehlers in die Fehlerbeschreibung auf.
Sie schließen einen Fehler, wenn ein Teammitglied bestätigt, dass er behoben wurde. Sie können jedoch auch einen Fehler aus einem der folgenden Gründe schließen. Die verfügbaren Gründe hängen vom Projektprozess und den Fehlerübergangszuständen ab.
Agile-Prozess:
Scrum-Prozess:
CMMI-Prozess:
Tipp
Nachdem ein Fehler geschlossen wurde und der Fix in Bereitstellungen aktiv freigegeben wurde, besteht die empfohlene Vorgehensweise darin, ihn aus Regressionsgründen nicht erneut zu öffnen. Stattdessen sollten Sie erwägen, einen neuen Fehler zu öffnen und diesen mit dem älteren geschlossenen Fehler zu verknüpfen.
Es ist immer ratsam, weitere Details zum Schließen eines Fehlers im Feld Diskussion zu beschreiben, um zukünftige Verwirrung darüber zu vermeiden, warum der Fehler geschlossen wurde.
Wenn Ihr Team ein Git-Repository verwendet, können Sie den Zustand in verknüpften Fehlern und anderen Arbeitselementen auf „Schließen“ festlegen, nachdem Pull Requests erfolgreich zusammengeführt wurden. Weitere Informationen finden Sie weiter unten in diesem Artikel unter Festlegen des Zustands von Arbeitselementen in Pull Requests .
Die meisten Teams definieren, unabhängig davon, welche Option sie zum Nachverfolgen von Fehlern gewählt haben, eine oder mehrere Fehlerabfragen. Mit Abfragen können Sie aktive Fehler, nicht zugewiesene Fehler, veraltete Fehler, Fehlertrends und mehr auflisten. Sie können Ihren Teamdashboards Abfragen und Abfragediagramme hinzufügen, um den Fehlerstatus und -fortschritt zu überwachen.
Öffnen Sie eine freigegebene Abfrage, oder verwenden Sie den Abfrage-Editor, um nützliche Fehlerabfragen zu erstellen, z. B. wie die folgenden Optionen:
State <> Done
oderState <> Closed
)State = Committed
oder State = Active
)Tags Contains RTM
)Created Date > @Today-21
)Wenn Sie über die für Ihr Team interessanten Abfragen verfügen, können Sie Status- oder Trenddiagramme erstellen. Sie können das von Ihnen erstellte Diagramm auch einem Dashboard hinzufügen.
Halten Sie nach Beginn der Programmier- und Testarbeiten regelmäßige Selektierungsbesprechungen ab, um Ihre Fehler zu überprüfen und zu priorisieren. In der Regel hält der Projektbesitzer die Fehlerselektierungsbesprechungen ab. Teamleiter, Geschäftsanalysten und andere Projektbeteiligte, die zu spezifischen Projektrisiken sprechen können, nehmen an den Selektierungsbesprechungen teil.
Der Projektbesitzer kann eine freigegebene Abfrage für neue und erneut geöffnete Fehler definieren, um Fehler für die Selektierung aufzulisten.
Auf der Seite mit den Abfrageergebnissen können Sie innerhalb der Liste der Fehlerarbeitselemente mithilfe der Auf- und Abwärtspfeile nach oben und unten navigieren. Während Sie jeden Fehler überprüfen, können Sie ihn zuweisen, Details hinzufügen oder die Priorität festlegen.
Wenn Ihr Team Fehler als Anforderungen nachverfolgt, zeigen Sie die Liste der aktiven Fehler aus Ihrem Backlog an. Mit der Filterfunktion können Sie sich ausschließlich auf Fehler konzentrieren. Aus dem Product Backlog heraus können Sie ebenfalls die folgenden Aufgaben ausführen:
Wenn Ihr Team Fehler als Aufgaben nachverfolgt, verwenden Sie verwaltete Abfragen, um Fehler aufzulisten und zu selektieren. In jedem Sprint werden die dem Sprint zugewiesenen Fehler aus dem Sprint-Backlog oder -Taskboard angezeigt.
Möglicherweise bemerken Sie und fragen sich, warum sich die in einem Sprint Taskboard angezeigten Elemente von einer Abfrageliste unterscheiden können, die in einem entsprechenden Sprint Backlog erstellt wurde.
Es ist möglich, Aufgaben oder Fehler einer Iteration zuzuweisen, ohne sie mit einem übergeordneten Backlog Item zu verknüpfen. Diese Elemente werden in der erstellten Abfrage angezeigt, möglicherweise aber nicht im Taskboard selbst. Das System führt die Abfrage durch und wendet dann ein paar Hintergrundprozesse an, bevor die Taskboardelemente angezeigt werden.
Diese Gründe können dazu führen, dass zur Kategorie „Aufgabe“ gehörende Arbeitselemente nicht in einem Sprint Backlog oder Taskboard angezeigt werden:
Wenn Ihr Team Fehler als Anforderungen nachverfolgt, können Sie das Board verwenden, um Tests zum Überprüfen von Fehlerbehebungen hinzuzufügen.
Sie können den Fehlerstatus aktualisieren, indem Sie Fehler in eine neue Spalte auf einem Board ziehen und ablegen.
Wenn Ihr Team Fehler als Anforderungen nachverfolgt, verwenden Sie das Board wie in der folgenden Abbildung gezeigt. Weitere Informationen finden Sie unter Aktualisieren des Arbeitselementstatus.
Wenn Ihr Team Fehler als Aufgaben nachverfolgt, verwenden Sie das Taskboard. Weitere Informationen dazu finden Sie unter Aktualisieren und Überwachen Ihres Taskboards.
Sie können Zwischenspalten hinzufügen, um Ihren Fehlerstatus auf dem Board nachzuverfolgen. Sie können auch Abfragen definieren, die basierend auf dem Status einer Boardspalte filtern. Weitere Informationen finden Sie in den folgenden Artikeln:
Um ausgewählte Aktionen zu automatisieren, fügen Sie Ihrem Fehler-Arbeitselementtyp benutzerdefinierte Regeln hinzu. Fügen Sie beispielsweise eine Regel hinzu, wie in der folgenden Abbildung gezeigt. Diese Regel gibt an, dass ein Fehler, der von einem Teammitglied behoben wurde, wieder der Person zugewiesen werden soll, die ihn geöffnet hatte. In der Regel überprüft diese Person, ob der Fehler korrigiert wurde, und schließt den Fehler. Weitere Informationen finden Sie unter Anwenden von Regeln auf Workflowzustände (Vererbungsprozess).
Wenn Sie einen Pull Request erstellen, können Sie den Zustandswert (state) der verknüpften Arbeitselemente in der Beschreibung festlegen. Befolgen Sie die Syntax: {state value}: #ID
.
Wenn Sie den Pull Request zusammenführen, liest das System die Beschreibung und aktualisiert den Arbeitselementzustand. Im folgenden Beispiel werden die Arbeitselemente 300 und 301 auf „Gelöst“ und die Arbeitselemente 323 und 324 auf „Geschlossen“ festgelegt:
Hinweis
Dieses Feature erfordert die Installation von Azure DevOps Server-Update 2020.1. Weitere Informationen finden Sie unter Azure DevOps Server 2020 Update 1 RC1 Versionshinweise, Boards.
Eine der Methoden, die von Azure DevOps zur Unterstützung der Integration verwendet werden, besteht darin, Objekte mit anderen Objekten zu verknüpfen. Neben dem Verknüpfen von Arbeitselementen mit Arbeitselementen können Sie auch Arbeitselemente mit anderen Objekten verknüpfen. Sie können mit Objekten wie Builds, Releases, Branches, Commits und Pull Requests verknüpfen, wie in der folgenden Abbildung dargestellt.
Sie können einen Link vom Arbeitselement aus oder von den Build- und Releaseobjekten aus hinzufügen.
Das Steuerelement Entwicklung unterstützt das Erstellen und Anzeigen von Links zu Builds, Git-Commits und Pull Requests. Bei Verwendung eines TFVC-Repositorys unterstützt es Links zu Changesets und versionierten Elementen. Wenn Sie den Link auswählen, wird das zugehörige Element auf einer neuen Browserregisterkarte geöffnet. Weitere Informationen finden Sie unter Steuern der Git-Entwicklung von einem Arbeitselement aus.
Das Deployment-Steuerelement (Bereitstellung) unterstützt Links zu und die Anzeige von Releases, die Arbeitselemente enthalten. Die folgende Abbildung zeigt beispielsweise mehrere Releases, die Links zum aktuellen Arbeitselement enthalten. Sie können jedes Release erweitern, um Details zu den einzelnen Stages (Phasen) anzuzeigen. Sie können den Link für jedes Release und jede Stage auswählen, um das zugehörige Release oder die zugehörige Stage zu öffnen. Weitere Informationen finden Sie unter Verknüpfen von Arbeitselementen mit Builds und Bereitstellungen.
Pipelines werden häufig so definiert, dass sie automatisch ausgeführt werden, wenn ein neuer Commit in ein Git-Repository erfolgt. Arbeitselemente, die den Commitpipelines zugeordnet sind, werden als Teil der Pipelineausführung angezeigt, wenn Sie Ihre Pipelineeinstellungen anpassen. Weitere Informationen finden Sie unter Anpassen Ihrer Pipeline.
Wenn Sie klassische Pipelines (nicht YAML) verwenden, können Sie bei einem Buildfehler Arbeitselemente erstellen. Weitere Informationen finden Sie unter Erstellen einer Arbeitsaufgabe bei Fehler.
Sie können den Fehlerstatus, Zuweisungen und Trends mithilfe von Abfragen nachverfolgen, die Sie einem Dashboard als Diagramme hinzufügen können. Hier sehen Sie beispielsweise zwei Beispiele, die „Aktive Fehlertrends nach Zustand“ sowie „Aktive Fehler nach Priorität“ im Zeitverlauf zeigen.
Weitere Informationen zu Abfragen, Diagrammen und Dashboards finden Sie unter Nachverfolgen Ihrer Arbeit mithilfe von verwalteten Abfragen in Azure Boards bzw. unter Verfolgen des Fortschritts mit auf Status- und Trendabfragen basierenden Diagrammen oder unter Hinzufügen, Umbenennen und Löschen von Dashboards in Azure DevOps.
Der Analysedienst ist die Berichtsplattform für Azure DevOps. Er ersetzt die vorherige, auf SQL Server Reporting Services basierende Plattform.
Analyseansichten bieten vordefinierte Filter zum Anzeigen von Arbeitselementen. Für die Fehlerberichterstattung werden vier Analyseansichten unterstützt. Sie können diese Ansichten wie definiert verwenden oder weiter bearbeiten, um eine benutzerdefinierte, gefilterte Ansicht zu erstellen.
Weitere Informationen zur Verwendung von Analyse- bzw. Analytics-Ansichten finden Sie unter Informationen zu Analytics-Ansichten sowie unter Erstellen eines aktiven Fehlerberichts in Power BI basierend auf einer benutzerdefinierten Analyseansicht.
Sie können Power BI verwenden, um komplexere Berichte zu erstellen als eine Abfrage. Weitere Informationen finden Sie unter Herstellen einer Verbindung mit dem Power BI-Datenconnector.
Die folgenden Berichte werden für Agile- und CMMI-Prozesse unterstützt.
Für diese Berichte müssen SQL Server Analysis Services und SQL Server Reporting Services für Ihr Projekt konfiguriert sein. Informationen zum Hinzufügen von SQL Server-Berichten für ein Projekt finden Sie unter Hinzufügen von Berichten zu einem Projekt.
Es gibt mehrere fehlerbezogene Marketplace-Erweiterungen. Weitere Informationen finden Sie unter Marketplace für Azure DevOps.
Weitere Informationen zu Erweiterungen finden Sie unter Von Microsoft entwickelte Azure Boards-Erweiterungen.
Ereignisse
Nehmen Sie sich die Microsoft Learn-Herausforderung an
19. Nov., 23 Uhr - 10. Jan., 23 Uhr
Ignite Edition - Erstellen Sie Fähigkeiten in Microsoft Azure und verdienen Sie bis zum 10. Januar ein digitales Badge!
Jetzt registrierenTraining
Lernpfad
Finanz‑ und Betriebs-Apps implementieren - Training
Planen und entwerfen Sie Ihre Projektmethodik, um Finanz‑ und Betriebs-Apps mit FastTrack-Diensten, Datenverwaltung und mehr erfolgreich zu implementieren.
Dokumentation
Anzeigen von Fehlern in Backlogs und Boards - Azure DevOps
Wählen Sie aus, wie Fehler und Benutzergeschichten in Agile-Tools in Azure Boards angezeigt werden. Sie können Fehler als Anforderungen oder Aufgaben nachverfolgen.
Nachverfolgen von Fehlern, Problemen und Risiken in Azure Boards - Azure Boards
Hier erfahren Sie, wie Sie Informationen zu Fehlern, Problemen und Risiken in Azure Boards nachverfolgen.
Verwalten und Lösen von Issues oder Impedimenten in Azure Boards - Azure Boards
Erfahren Sie, wie Sie mit Azure Boards Issues oder Impedimente nachverfolgen, um Pläne effektiver auszuführen oder den Zeitplan einzuhalten.