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, sind diese Videos bei Scaled Agile eine gute Orientierungshilfe.

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

SAFe®-Architekturübersicht Version 5 © D. Leffingwell

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.

SAFe®-Übersicht 5.0 © D. Leffingwell

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.

Essential SAFe®-Poster zur Architekturübersicht © D. Leffingwell

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 Team Backlogs und Kanban-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 Kanban-Boards, Sprint Backlogs und -Taskboards, Teams und Sprintintervallen 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.

Portfolio SAFe®-Poster zur Architekturübersicht © D. Leffingwell

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.

Poster zur Architekturübersicht von SAFe® für große Lösungen © D. Leffingwell
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®.

Full SAFe®-Poster zur Architekturübersicht © D. Leffingwell

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 Kanban-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 als Karten in einem interaktiven, konfigurierbaren und filterbaren Kanban-Board an.

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 Feature Backlog als Karten in einem interaktiven, konfigurierbaren und filterbaren Kanban-Board an.

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

Ü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).