Implementieren von Scaled Agile Framework® in Azure Boards
Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2019
Viele Unternehmen profitieren von einzelnen Agile-Teams. Das Interesse an der Skalierung von Agile-Praktiken nimmt zu, wenn die Organisation wächst. Die Notwendigkeit, den Fortschritt vieler Agile-Teams über ein gesamtes Portfolio hinweg zu beobachten, wird für Unternehmen zunehmend zwingender. Zum Erfüllen dieser Anforderungen haben viele Unternehmen das Scaled Agile Framework® (SAFe®) eingeführt.
Wenn Sie mit Scrum, aber nicht mit SAFe® vertraut sind, finden Sie unter SAFe Studio Framework weitere Informationen.
Azure Boards unterstützt SAFe-Praktiken® über ihre autonomen Teams, Backlogs, Boards, Berichte und Metriken. In diesem Artikel erfahren Sie, wie Azure Boards-Artefakte SAFe-Praktiken und -Artefakte unterstützen.
- Das Scaled Agile Framework®
- Essential SAFe®
- Portfolio SAFe®
- SAFe® für große Lösungen
- Kurzreferenz
- Azure Boards-Implementierung von SAFe®
Hinweis
Dieser Artikel ist einer aus einer Reihe von Scaled Agile Framework®-Tutorials, die sich auf Azure Boards und Azure DevOps Services beziehen. Die meisten Anleitungen gelten sowohl für die cloudbasierte als auch für die lokale Version. Einige der Features und Prozeduren sind jedoch spezifisch für die Cloudversion oder die aktuelle Version von Azure DevOps Server.
Scaled Agile Framework®
Das SAFe® befasst sich mit der Erfüllung einer Portfoliovision durch eine Hierarchie von Teams, die sich alle an bestimmten Zielen orientieren. Dieses Framework teilt Epics in Features und Storys auf. Teams arbeiten an diesen Elementen in Sprints und liefern ihre Arbeit mithilfe von Programminkrementen (PIs) und Release Trains. Darüber hinaus kann das Portfolio Backlog Ergebnisse nachverfolgen, die Wertströmen und damit verbundenen Budgets zugeordnet sind.
SAFe®-Architekturübersicht Version 5.0
Reproduziert mit Genehmigung von © 2011–2020 Scaled Agile Inc.. Alle Rechte vorbehalten.
SAFe® und Scaled Agile Framework sind eingetragene Marken von Scaled Agile Inc.
SAFe® 5.0 Business Agility
Viele SAFe®-Praktiken beinhalten den Aufbau einer Kultur, die Agilität, Abstimmung und Autonomie unterstützt und dabei jederzeit kundenorientiert ist.
Reproduziert mit Genehmigung von © 2011–2020 Scaled Agile Inc.. Alle Rechte vorbehalten.
In den folgenden Artikeln werden einige Möglichkeiten erläutert, wie Azure Boards geschäftliche Agilität und die Agile-Kultur unterstützt:
Essential SAFe®
Essential SAFe® erfordert Unterstützung für die Artefakte und Methoden, die auf dem folgenden Poster dargestellt sind.
Reproduziert mit Genehmigung von © 2011–2020 Scaled Agile Inc.. Alle Rechte vorbehalten.
Alle diese Artefakte und Praktiken werden von Azure Boards unterstützt.
- Storys, Features und Enabler: Als Arbeitselemente implementiert, die Informationen und Status der Arbeit erfassen. Diese Arbeitselemente werden automatisch in Teambacklogs und -boards angezeigt.
- Team Backlogs und Programm Backlogs: Werden als Team Backlogs implementiert, die einem Team zugewiesene Arbeitselemente filtern und die Priorisierung und Gruppierung von Arbeiten unterstützen.
- Scrum und Kanban: Methoden, die in Form von Boards, Sprintbacklogs und -Taskboards, Teams und Sprintrhythmen vollständig unterstützt werden.
- Iterationen, IP-Iterationen (Innovation und Planung), Programminkremente (PI), Meilensteine und Release Trains: Implementiert über eine Flatlist oder eine hierarchische Konfiguration von Iterationspfaden.
- Agile Release Train: Wird durch eine Gruppe von Agile-Teams und Programmteams implementiert, die für die Unterstützung bestimmter Team- und Programmansichten konfiguriert sind.
- PI-Ziele, Teamziele und Lösungskontext: Teams können das integrierte Projektwiki verwenden, um Ziele, Kundeninformationen und Lösungsanforderungen auszutauschen.
Eine Übersicht dazu, wie Azure Boards Scrum und Kanban implementiert, finden Sie unter Informationen zu Sprints, Scrum und Projektmanagement und Informationen zu Boards und Kanban.
Portfolio SAFe®
Portfolio SAFe® bietet Unterstützung für die Verwaltung von Portfolios mithilfe von Epics, Enablern und Wertströmen.
Reproduziert mit Genehmigung von © 2011–2020 Scaled Agile Inc.. Alle Rechte vorbehalten.
Azure Boards bietet Unterstützung für die folgenden Portfoliokomponenten:
- Epics: Dem Epic-Arbeitselementtyp zugeordnet, erlauben sie Nachverfolgung, Gruppierung und Rollup von untergeordneten Elementen.
- Portfolio Backlogs: Als Portfolio Backlog implementiert, das die Filterung von Arbeiten ausgehend von der Überprüfung der Geschäftsanforderungen unterstützt.
- Portfolio Vision und strategische Themen: Geschäftsinhaber und Portfoliomanager können das integrierte Projektwiki verwenden, um ihre Visionen und Ziele zu teilen.
- Wertströme: Wertströme können mithilfe von Tags oder benutzerdefinierten Feldern nachverfolgt werden.
- Schlanke Budgets: Budgetinformationen können in benutzerdefinierten Feldern erfasst und summiert werden, um Erkenntnisse zu den Feature- und Epic-Ebenen zu erhalten.
- KPIs: Mehrere Berichte und Dashboard Widgets bieten sofort einsatzbereite Metriken. Power BI und der Analytics-Dienst unterstützen die schnelle Erstellung benutzerdefinierter Berichte.
SAFe® für große Lösungen
SAFe® für große Lösungen beinhaltet Unterstützung für ein Lösungsbacklog, Solution Trains und Funktionen.
Reproduziert mit Genehmigung von © 2011–2020 Scaled Agile Inc.. Alle Rechte vorbehalten.
Sie können große Lösungen auf die gleiche Weise wie Portfolio SAFe® implementieren. Sie können jedoch darüber hinaus benutzerdefinierte Arbeitselementtypen und benutzerdefinierte Backlogs hinzufügen, um andere Lösungsanforderungen zu unterstützen.
Full SAFe®
Full SAFe® umfasst die drei Ebenen Essential SAFe®, Large Solution SAFe® und Portfolio SAFe®.
Zuordnung von SAFe®-Artefakten zu Azure Boards
In der folgenden Tabelle werden SAFe®-Begriffe oder -Artefakte dem entsprechenden Azure Boards-Begriff oder -Artefakt zugeordnet. Wählen Sie den Link aus, um mehr über Implementierungsdetails zu erfahren.
SAFe®-Begriff oder -Artefakt
Azure Boards-Begriff oder -Artefakt
Agile-Teams
Teams. Sie definieren eine Hierarchie von Teams, um die Anforderungen von Feature- oder Entwicklungsteams, Programm- und Portfolioteams oder Solution Train-Teams zu erfüllen.
Agile Release Train (ART)
Teams. Agile-Teams verwalten die Arbeit der Lieferungen für eine Gruppe von Features. Jedes Agile-Team verfügt über eine Reihe von Agile-Tools, um den Arbeitsfluss zu unterstützen und Fortschritte und Lieferleistungen zu überprüfen.
Budgets
Tags, Wertbereich. Sie können Tags oder das Feld Wertbereich verwenden, um die Arbeit nachzuverfolgen, die einem bestimmten Budget oder Wertstrom zugeordnet ist.
Funktionen
Arbeitselement. Sie dienen der Definition, Planung und Nachverfolgung von Funktionen ähnlich wie Epics und Features. Sie erfassen sie in Arbeitselementen und in verschiedenen Team Backlogs.
Grundvoraussetzungen
Arbeitselement. Die Definition, Planung und Nachverfolgung von Enablern erfolgt ähnlich wie bei Epics, Features und Storys. Sie erfassen sie in Arbeitselementen und in verschiedenen Team Backlogs.
Epics
Epic-Arbeitselement. Sie definieren ein Epic mithilfe des Epic-Arbeitselementtyps. Epics stehen ganz oben in der Hierarchie der Arbeitselemente von Epics, Features und Storys.
Funktionen
Feature-Arbeitselement. Sie definieren ein Feature mithilfe des Arbeitselementtyps Feature. Features sind ein Container für viele Storys und werden in ihrem eigenen Portfolio Backlog dargestellt.
IP-Iteration (Innovation und Planung)
Iterationspfad. Sie definieren Iterationspfade für ein Projekt und legen ihre Start- und Endtermine fest. Jedes Team abonniert die Iterationen, an denen es arbeitet.
Iteration
Iterationspfad. Sie definieren Iterationspfade für ein Projekt und legen ihre Start- und Endtermine fest. Jedes Team abonniert die Iterationen, an denen es arbeitet.
Meilensteine
Meilensteine und wichtige Ereignisse. Meilensteine treten am Ende jeder Iteration auf. Benutzerdefinierte Felder und Tags können ebenfalls verwendet werden, um Arbeit mit Meilensteinen und Schlüsselereignissen zu verknüpfen.
Portfolio Backlog
Portfolio Backlog. Ein Portfolio Backlog listet die Epics auf, die einem Portfolio zugeordnet sind, mit der Option zum Erweitern und Anzeigen der untergeordneten Features und Storys.
Portfolio Kanban
Portfolio Epics-Board. Das Board des Portfolioteams zeigt das Epics-Backlog als Karten in einem interaktiven, konfigurierbaren und filterbaren Board an.
Portfolio Vision
Wiki. Nutzen Sie das Projekt-Wiki, um innerhalb der Organisation Informationen über die Strategie, die Lösungen und die Art und Weise, wie Teams zusammenarbeiten, um Portfolio- und Programmergebnisse zu erstellen, auf breiter Basis zu teilen.
Programm Backlog
Feature Backlog. Ein Feature Backlog listet die einem Programm zugeordneten Features mit der Option zum Aufklappen und Anzeigen der untergeordneten Storys auf.
Programm-Kanban
Programmfeatureboard. Das Programmboard zeigt das Feature-Backlog in Form von Karten in einem interaktiven, konfigurierbaren und filterbaren Board.
PI-Iterationspfad (Programminkrement)
Iterationspfad. Iterationspfade definieren einen Zeitrahmen für ein Projekt mit Start- und Enddatum. Iterationspfade können von einer Woche bis zu 12 Wochen oder länger definiert werden.
Retrospektiven und Bewertungen
Retrospektiven. Jedes Team kann ein Board hinzufügen, um Aktionselemente zu erfassen, zu priorisieren und zu erstellen, um seine Verbesserungsprozesse zu unterstützen.
Roadmap
Lieferpläne, Featurezeitachse. Azure Boards bietet konfigurierbare und interaktive Ansichten zur Überprüfung von Roadmaps und Teamlieferungen.
Gemeinsame Dienste
Teamstruktur für gemeinsame Dienste: Ressourcen, die teamübergreifend gemeinsam genutzt werden, können durch ein eigenes Agile-Featureteam dargestellt werden. Jeder kann sein Backlog verwalten, während seine Arbeit zugleich in den Backlogs der von ihm unterstützten Teams angezeigt wird.
Lösungen
Lösungen: Lösungen können durch einen benutzerdefinierten Lösungs-Arbeitselementtyp dargestellt werden.
Lösungsbacklog
Lösungs-Portfolio Backlog. Sie können einen benutzerdefinierten Arbeitselementtyp und ein Portfolio Backlog definieren, um spezielle Geschäftsanforderungen großer Lösungen zu erfassen, oder Sie können Epics- und Epic-Portfolio Backlogs verwenden, um Lösungen zu erfassen.
Strategische Themen
Wiki. Strategische Themen können ähnlich wie Portfolio Vision in einem Projektwiki erfasst werden.
Storys
User Story-Arbeitselement. User Storys erfassen die Funktionalität, die Sie liefern möchten. Sie sind in der Regel so dimensioniert, dass sie mit einer einzelnen Iteration abgeschlossen werden können.
Team Backlog
Story Backlog. Das Story Backlog listet die User Storys auf, die dem Bereichspfad zugewiesen sind, der mit dem Team verknüpft ist.
Team-Kanban
Storys-Board. Das Storys-Board zeigt das Storys-Backlog in Form von Karten in einem interaktiven, konfigurierbaren und filterbaren Board.
Wertströme
Tags, Wertbereich. Sie können Tags oder das Feld „Wertbereich“ verwenden, um die Arbeit nachzuverfolgen, die einem bestimmten Budget oder Wertstrom zugeordnet ist.
Azure Boards-Implementierung von SAFe®
Jeder der folgenden Artikel in dieser Reihe von Tutorials enthält Details dazu, wie Sie Azure Boards konfigurieren, anpassen und verwenden können, um Ihre SAFe®-Programme und -Projekte zu implementieren.
Nächste Schritte
Verwandte Artikel
- Skalieren von agile auf große Teams
- Agile-Kultur
- Skalierbare Praktiken
- Über Sprints, Scrum und Projektmanagement
- Informationen zu Boards und Kanban
- Scaled Agile Framework: SAFe®-Ressourcenwebsite.
- Skalieren von Agile- und SAFe®-Metriken mit TFS: Blogbeitrag, der einen von InCycle entwickelten SQL Server-Bericht veranschaulicht, um darzustellen, wie TFS verwendet werden kann, um Scaled Agile oder SAFe zu unterstützen.
Über die Autoren
Vielen Dank an die folgenden Mitwirkenden für ihre Bewertung und Ihr Feedback zu den aktuellen Inhalten.
- Phillip Eng ist Senior Architect bei Microsoft, Digital Pursuit and Guidance.
- Hosam Kamel ist ein Experte für Technologielösungen für Microsoft und ALM Ranger.
- Willy-Peter Schaub ist ein ehemaliger Program Manager bei den Visual Studio ALM Rangers im Microsoft Canada Development Center. Sie können Willy-Peter auf Twitter unter twitter.com/wpschaub folgen.
Die Artikel in dieser Reihe wurden aus einem früheren Whitepaper aktualisiert, das in Zusammenarbeit mit den folgenden Autoren entwickelt wurde:
- Gordon Beeming ist Softwareentwickler bei Derivco im sonnenverwöhnten Durban in Südafrika. Er verbringt den größten Teil seiner Zeit mit der Arbeit in Visual Studio oder entspannt im Kreise seiner Familie. Seinen Blog finden Sie unter gordonbeeming.xyz, und Sie können ihm auf Twitter unter twitter.com/gordonbeeming folgen.
- Brian Blackman ist Principal Consultant bei Microsoft Premier Developer, wo er sich hauptsächlich für den Erfolg von ISV-Partnern und Unternehmen im Bereich Engineering und auf dem Markt einsetzt. Er hat einen MBA-Abschluss und ist CSM, CSP, MCSD (C++) und MCTS sowie ein Visual Studio ALM Ranger. Wenn er sich nicht gerade als Ruck Master betätigt und mit Beiträgen zu Visual Studio ALM Ranger-Projekten befasst, schreibt er Code, konzipiert und leitet er Workshops und bietet er in verschiedenem Ausmaß seine Beratungsdienste an, wobei er insbesondere Organisationen bei der Umsetzung von Geschäftsflexibilität unterstützt.
- Gregg Boer ist Principa Program Manager bei Microsoft. Gregg ist der Produktbesitzer für die Agile-Verwaltungsumgebung, die von Azure DevOps und lokalem TFS bereitgestellt wird.
- Kathryn Elliott ist leitende technische Redakteurin bei Microsoft.
- Susan Ferrell ist leitende technische Redakteurin und ein Visual Studio ALM Ranger.
- Willy-Peter Schaub ist ein ehemaliger Program Manager bei den Visual Studio ALM Rangers im Microsoft Canada Development Center. Seit Mitte der 80er kämpft er um Einfachheit und Wartungsfreundlichkeit im Bereich Software-Engineering. Sie können ihm auf Twitter unter twitter.com/wpschaub folgen.
- Besonderer Dank gilt den folgenden technischen Experten für die Durchsicht dieses Artikels: Mike Douglas (unabhängiger Berater, ALM Ranger), Richard Hundhausen (unabhängiger Berater, ALM Ranger) und Bill Heys (unabhängiger Berater, ALM Ranger).