Scaled Agile Framework: Using TFS to support epics, release trains, and multiple backlogs

Visual Studio 2013

Enterprise-Kunden haben die Vorteile einzelner Agile-Teams gesehen. Die Skalierung dieser Methoden über Teams hinweg und die Implementierung von Flexibilität auf Organisationsebene bringt jedoch einige Probleme mit sich. Das Scaled Agile Framework® (SAFe™) bietet eine Übersicht darüber, wie Sie diese Herausforderungen bewältigen und die Flexibilität skalieren können. Bei einer lokalen Bereitstellung von TFS 2013 können Sie SAFe verwenden.

Sie können Teamprojekte verwenden, die Sie mithilfe der standardmäßigen TFS-Prozessvorlagen erstellt haben, um SAFe-Kriterien nachzuverfolgen. In diesem Dokument erfahren Sie, wie SAFe-Konzepte sich in TFS einbinden lassen, wie Sie SAFe-Projekte in TFS planen und nachverfolgen können, und wie Sie TFS für die Unterstützung von SAFe konfigurieren und anpassen können.

Wenn Sie mit Scrum, jedoch nicht mit SAFe vertraut sind, bieten diese Videos auf Scaled Agile Framework Foundations von Inbar Oren, dem Lean-Samurai, eine gute Möglichkeit, sich zu orientieren.

Zuordnen von SAFe-Konzepten zu TFS-Konzepten

SAFe unterstützt eine Portfolio-Ansicht mehrere Agile-Teams. SAFe zeigt, wie eine Portfolio-Vision von einer Teamhierarchie erfüllt wird, die alle ihre eigenen spezifischen Ziele haben. Dieses Framework untergliedert Anforderungsblöcke (sogenannte Epics) in Features und Stories, an denen die Teams in Sprints arbeiten und die sie über Programm Increments (PIs) und Release Trains bereitstellen. Das Portfoliobacklog kann zudem nachverfolgen, wie die Lieferungen mit sogenannten Strategic Themes und verbundenen Budgets verknüpft werden können.

Bild mit freundlicher Genehmigung von Leffingwell, LLC.

Die Beispiele in diesem Artikel zeigen, wie Sie den Arbeitsaufgabentyp "Epic" und das Backlog hinzufügen, eine dreistufige Teamhierarchie konfigurieren und Teams ihrem jeweiligen Bereich und den jeweiligen Iterationspfade zuordnen. Die Beispiele wurden anhand der TFS-Agile-Prozessvorlage erstellt. Allerdings können die Änderungen auf alle TFS-Prozessvorlagen angewendet werden.

Zuordnung von SAFe-Portfolios, -Programmen und -Teams zu TFS-Teamprojekten und -Teams

Da TFS eine hierarchische Teamstruktur unterstützt, hat jedes Team seine eigene Ansicht ihrer Arbeit, die an die nächste Ebene der Teamhierarchie übertragen wird.

Zur Unterstützung von SAFe-Teams konfigurieren Sie das standardmäßige Team als Portfolio-Team, um Ihre Epics zu verwalten. Anschließend erstellen Sie für Arbeiten auf Programm- und Teamebene Unterteams. Arbeiten können über Teams und durch die Ebenen hinweg verfolgt werden.

Zuordnung von SAFe-Backlogs zu TFS-Backlogs

Standardmäßig unterstützt TFS die Ebenen "Story" und "Feature Backlog". Sie können mühelos eine dritte Ebene zum Nachverfolgen von Epics hinzufügen. User Stories können Features zugeordnet werden, die wiederum Epics zugeordnet werden können. Eine hierarchische Ansicht der Backlogs zeigt, wie der Status von User Stories zu Epics beiträgt.

Zuordnung von SAFe-Releases, -Iterationen und -Sprints zu TFS-Iterationen

SAFe Release Trains, Releases, Iterationen, Program Increments (PIs) und Sprints lassen sich leicht TFS-Iterationspfaden zuordnen. Durch die Weitergabe von Iterationen innerhalb der Teamhierarchie verwalten Sie Releases schlüssig.

Das Portfolio-Team verfolgt Epics, die sich über mehrere Release Trains oder PIs erstrecken können. Programm-Teams verfolgen ihre Feature-Lieferungen, die mit einem PI ausgeliefert werden. Und Feature-Teams arbeiten in Sprints, um mehrere Stories abzuschließen. Mit TFS wählt jedes Team, welche Iterationen ihnen bei der Nachverfolgung der Teamlieferungen helfen können.

Zuordnung von SAFe Strategic Themes und Budgets zu TFS-Tags und -Feldern

Mithilfe von Tags können Sie Epics ihren Strategic Themes oder verknüpften Budgets zuordnen.

Sie können Tags in TFS suchen und abfragen und dann wiederverwendbare Abfragen und Berichte mithilfe der Tags erstellen.

Für eine stabilere Zuordnung der Arbeit zu Strategic Themes und Budgets können Sie Ihrer Arbeitsaufgabe ein Feld hinzufügen, um nachzuverfolgen, welches Theme oder Budget jedes Epic, Feature oder jede Story unterstützt.

SAFe-Metriken und TFS-Berichte

Sie können SAFe-Metriken anzeigen, indem Sie einen Bericht hinzufügen oder anpassen. Der Feature-Statusbericht zeigt beispielsweise, ähnlich wie ein Stories-Übersichtsbericht, welche Features sich dem Abschluss nähern und welche gerade gestartet wurden. Während die Teams an den mit den Features verknüpften Stories arbeiten, wird eine Statusanzeige angezeigt. Sie zeigt den Abschluss eines bestimmten Features in Prozent (%) an. Projektbeteiligte haben Daten, mit denen einen Aktion ausgeführt werden kann, um den Umfang, die Ressourcen und Priorität zu verwalten.

Eine herunterladbare Version des Features-Statusberichts finden Sie unter Scaling Agile and SAFe TFS Reports (möglicherweise nur in englischer Sprache).

Planen und Nachverfolgen von SAFe-Projekte in TFS

Sobald Sie TFS zur Unterstützung von SAFe konfiguriert haben, erstellen Sie Ablaufverfolgungsbeziehungen zwischen Stories bis hin zu Epics. Darüber hinaus können Sie den Fortschritt auf Portfolio-, Programm- und Feature-Teamebene anzeigen.

Zuordnen von Features zu Epics und von Stories zu Features

Das Programm-Team kann mithilfe des Zuordnungsbereich Features Epics zuordnen. Genauso können Feature-Teams ihre Stories Features zuordnen.

Statusansicht des Portfolio-Teams

Um den Status von Epics nachzuverfolgen, die mehrere Releases umfassen, enthält das Backlog des Portfolio-Teams Epics. Jedes Epic kann erweitert werden, um die Features und User Stories anzuzeigen, die es unterstützen.

Das Portfolio-Team kann auch den Status der Epics auf seinem Kanban-Board anzeigen.

Statusansicht des Programm-Teams

Programm-Teams, die sich hauptsächlich mit Release Trains befassen, können die Features in ihrem Backlog sehen, zusammen mit den PIs, mit denen sie verknüpft sind.

Genau wie das Portfolio-Team können Programm-Teams ihre Ansicht umschalten, um festzustellen, welche Epics ihre Features unterstützen, um die User Stories anzuzeigen, die ihre Features unterstützen, oder beides.

Eine weitere verfügbare Ansicht für Programm-Teams zeigt abfragebasierte Diagramme des Release Train-Status, Backlogelemente oder aktive Aufgaben während eines Versand-Sprints. Jedes Team verfügt über eine anpassbare Startseitenansicht.

Da sich ein Großteil der Arbeit eines Programm-Teams auf PIs und Release Trains bezieht, ist u. U. ein benutzerdefinierter Bericht sinnvoll, der die geplanten Lieferdaten sowie Projizierungen Lieferungen eines spezifischen Trains enthält. Darüber hinaus können Sie, sofern die TFS-Bereitstellung mit SQL Server Reporting Services oder Project Server integriert wird, die umfassenden Berichtsoptionen und die integrierte Berichte nutzen, die jeder dieser Dienste zu bieten hat.

Statusansicht des Feature-Teams

Bei den einzelnen Feature-Teams zeigt die Backlog-Ansicht die Stories, an denen sie gerade arbeiten.

Da die Feature-Teams nicht Besitzer von Epics oder Features sind, werden Epics und Features nicht in den Backlog-Ansicht auf ihrer Teamebene angezeigt. Wenn das Team allerdings wissen möchte, welche Epics und Features ihre Stories unterstützen, können sie diese Ansichten über den Backlog aktivieren.

Sie können ihre Arbeit auch in Aufgaben aufgliedern und ihren Fortschritt bei bestimmten Sprints über das Task-Board im Auge behalten.

Die Diagrammansicht von Abfragen ist sehr nützlich beim Sprint "Innovation and Planning" (IP), bei dem Feature-Teams zusammenarbeiten, um die für einen Release geplanten Features zu stabilisieren.

Alle anderen Aufgaben sind für die einzelnen Feature-Teams alltägliches Geschäft. Sie können die Sprints in ihrem üblichen Rhythmus ausführen. Sie können den Status über das Kanban-Board und das Task-Board verfolgen und die Arbeit in verwaltbare Teile aufgliedern.

Jetzt können die Programm- und Portfolio-Management-Teams jedoch den Status der einzelnen Stories sehen. Die Managementansicht zeigt, was sie gerade tun.

Konfigurieren von TFS zur Unterstützung SAFe

In diesem Abschnitt beginnen wir mit einem Projekt mit dem Namen "Fabrikam" und einem Team, das den gleichen Namen wie das Projekt hat, bis wir die folgende Struktur mit drei Ebenen und neun Teams haben. Die Bereichspfadhierarchie und die Konfiguration des Bereichspfads jedes Teams unterstützen die Backlog-Ansicht der einzelnen Teams sowie das Rollup der Ansichten innerhalb der Hierarchie.

Jedes Projekt in TFS hat ein Standardteam. Sie können zusätzliche Teams für Arbeiten auf Programmebene und Feature-Ebene konfigurieren. Und Sie können das Standardteam neu als Portfolio-Team definieren, das Epics verwaltet.

Auf diese Weise können alle Teams ihre eigene Arbeitsauslastung und Prioritäten verwalten, während sie sich dessen bewusst sind, wie ihre Arbeit diese im Backlog des Portfolio-Teams verwalteten Epics unterstützt. Zur gleichen Zeit kann das Portfolio-Team den Status seines Backlogs auf dem eigenen Kanban-Board überwachen, die Elemente im Backlog priorisieren und den Status innerhalb der Release Trains anzeigen.

Dies mag kompliziert klingen, aber es bedarf tatsächlich nur eines geringen Konfigurationsaufwands, um die Teams einzurichten und mit der Arbeit zu beginnen.

Wir beginnen mit einem Projekt mit einem Standardteam, Bereich und einem Iterationssatz. Zunächst konfigurieren wir eine Bereichspfadstruktur, um die Hierarchie der gewünschten Teams zu unterstützen. Dann müssen wir sicherstellen, dass die Iterationspfade die gewünschte Release-Struktur sowie die zu verwendenden Programm- und Feature-Teams unterstützen. Schließlich erstellen, konfigurieren und füllen wird die Mitgliedschaft der Teams.

Sie müssen ein Mitglied der Gruppe "Projektadministratoren" sein, um TFS konfigurieren und anpassen zu können.

Erstellen von Bereichen zur Unterstützung der Teamhierarchie

1. Stellen Sie eine Verbindung mit dem Teamprojekt her, das Sie so konfigurieren möchten, damit es SAFe unterstützt, und verwenden Sie das Zahnradsymbol , um die Verwaltungsseite für das Standardteam zu öffnen.

2. Auf der Seite Bereiche erstellen Sie ein untergeordnetes Element unter dem obersten Bereichspfad und geben ihm einen Namen, der einem der von Ihnen erstellten Programm-Teams entspricht.

   

3. Als Nächstes erstellen Sie einen zweiten Bereich auf derselben untergeordneten Ebene, und benennen ihn nach dem zweiten Programm-Team.

4. Erstellen Sie unter jedem Programm-Bereich einen untergeordneten Bereich für die einzelnen Feature-Teams, die ihr jeweiliges Programm-Team unterstützen. Am Ende sollten Sie eine dreistufige Bereichspfadhierarchie haben.

   

Erstellen von Iterationen zur Unterstützung der Release Trains und Sprints

Erstellen Sie die Iterationspfadstruktur, um den Status von Releases zu verfolgen. Im Gegensatz zu Bereichspfaden können sich mehrere Teams die gleiche Iterationspfadstruktur teilen. Durch eine gemeinsame Nutzung der Iterationsstruktur können mehrere Teams im gleichen Sprint-Rhythmus Arbeiten für den gleichen Release Train durchführen.

Wenn Sie bereits Iterationen für das Standardteam haben, können Sie diese umbenennen. Sie möchten eine Iterationsstruktur erstellen, die die gesamte Team-Struktur unterstützt, nicht nur ein Team.

1. Erstellen Sie unter der Standarditeration, die den gleichen Namen hat wie das Projekt, eine untergeordnete Iteration, die Ihr erstes Program Increment (PI) darstellt. Fügen Sie optional ein Start- und Enddatum für das PI hinzu, aber denken Sie daran, dass die Iteration weiter in Sprints aufgeteilt wird.

   

2. Erstellen Sie als Nächstes eine untergeordnete Iteration für jeden Sprint innerhalb des PI. Legen Sie Daten für diese Sprints fest, damit sie dem Rhythmus der Feature-Teams entsprechen.

   

Erstellen und Konfigurieren von Teams

In diesem Abschnitt konfigurieren wir eine hierarchischen Teamstruktur, die den hierarchischen Bereichspfaden zugeordnet wird, die wir zuvor erstellt haben.

Diese Struktur ordnet die folgenden SAFe-Teams den TFS-Teams zu:

• Portfolio-Team -> standardmäßig Team der obersten Ebene, Fabrikam-Team

• Programm-Teams -> Teams der zweiten Ebene, Fiber-Suite und Service-Suite

• Feature-Teams -> Teams der dritten Ebene, definiert unter Fiber-Suite und Service-Suite.

Wenn Sie detailliertere Anleitungen benötigen, finden Sie weitere Informationen unter Agile-Portfolio-Verwaltung: Verwenden von TFS zur Unterstützung von Backlogs über mehrere Teams hinweg.

Sie müssen Projektadministrator in TFS sein, um diese Schritte ausführen zu können.

Erstellen und Konfigurieren der einzelnen Programm-Teams

1. Erstellen Sie ein neues Team über die Seite "Übersicht" des Teamprojekts. Stellen Sie sicher, dass das Kontrollkästchen für Einen Bereichspfad mit dem Teamnamen erstellen deaktiviert ist.

   

2. Wählen Sie das Team aus der Liste aus, gehen Sie zur Seite "Bereiche", und aktivieren Sie das Kontrollkästchen neben dem Bereichspfad, den Sie zuvor für das Team erstellt haben.

   

3. Verwenden Sie das Kontextmenü, um Unterbereiche auszuschließen. Durch Ausschließen von Unterbereichen, schließt das Backlog des Teams nur diejenigen Elemente ein, deren Bereichspfad dem Standardbereichspfad des Teams entspricht.

   

4. Als Nächstes konfigurieren Sie die Iterationen, die für das Programm-Team aktiv sein sollen. In diesem Beispiel haben wir drei PIs mit jeweils fünf zweiwöchigen Sprints konfiguriert. Vier der Sprints sind reguläre Sprints, und der letzte Sprint ist ein "Innovation and Planning" (IP)-Sprint.

   

     

   Da sich das Fiber-Suite-Programm-Team mit Release Trains befasst, wählen Sie PI 1, 2 und 3, aber keine einzelnen Sprints.

5. Nachdem Sie ausgewählt haben, welche Iterationen für das Team aktiv sind, fügen Sie dem neuen Team Benutzer hinzu. Im Idealfall würden Sie die Scrum-Master für jedes Feature-Team, Produktbesitzer sowie Release Train Engineer (RTE) dem Programm-Team, z. B. Fiber-Suite, hinzufügen.

   

6. Wenn Sie mehrere Teams auf Programmebene haben, wiederholen Sie die Schritte 1 bis 5 für jedes Programm-Team.

Erstellen und Konfigurieren der einzelnen Feature-Teams

Als Nächstes erstellen wir einige Feature-Teams, um die Arbeit auf der dritten Ebene der Teamhierarchie durchzuführen. Jedes Feature-Team trägt Sprint-Arbeit bei, die in das PI übertragen wird. Die Anzahl der Teams, die Sie erstellen, ist von der Größe Ihrer Organisation abhängig.

1. Erstellen Sie ein neues Team über die Verwaltungsseite des ursprünglichen Teams, und geben Sie ihm einen Namen. Stellen Sie wie zuvor sicher, dass Sie das Kontrollkästchen neben Einen Bereichspfad mit dem Teamnamen erstellen deaktivieren.

   

2. Wählen Sie das Team aus der Liste aus, gehen Sie zur Seite "Bereiche", und aktivieren Sie das Kontrollkästchen neben dem Bereichspfad, den Sie zuvor für das Team erstellt haben.

   

3. Konfigurieren Sie die Iterationen für das Team mithilfe der PIs und Sprints, die Sie zuvor erstellt haben. Im Gegensatz zu den Programm-Teams wählen Sie diesmal die einzelnen Sprints als Arbeitsiterationen für das Feature-Team aus.

   

4. Fügen Sie die Konten für die Entwickler, Tester und den Scrum-Master für das Team hinzu. TFS unterstützt die Zuweisung eines Scrum-Master zu mehreren Teams. Der Scrum-Master kann die Arbeit über mehrere Teams hinweg verfolgen.

   

5. Wiederholen Sie die Schritte 1 bis 4 für jedes Feature-Team in Ihrer Organisation. Stellen Sie sicher, dass der Standardbereichspfad, den Sie für das Team konfigurieren, ein Unterbereichspfad unter dem entsprechenden Bereichspfad der Programmebene ist. Dadurch wird das Rollup von Feature-Teams zu Programm-Teams sichergestellt.

Konfigurieren des Portfolio-Teams

Nun, da Ihre untergeordnete Teamstruktur konfiguriert ist, konfigurieren Sie das Standardteam neu als Portfolio-Team. Auch wenn dieses Team weiterhin den Namen des Projekts trägt, stellen die Änderungen, die Sie an diesem Team der obersten Ebene vornehmen, sicher, dass Epics effektiv über PIs hinweg auf der höchsten Ebene verfolgt werden.

1. Ändern Sie auf der Seite "Bereiche" für das Teamprojekt die Einstellungen, sodass Unterbereiche nicht eingeschlossen sind. Stellen Sie sicher, dass Sie das Teamprojekt und nicht das Standardteam, Fabrikam, auswählen.

   

2. Deaktivieren Sie auf der Seite "Iterationen" die Kontrollkästchen neben allen Iterationen, mit Ausnahme die der Stammebene, die nicht gelöscht werden können. Da das Portfolio-Team sich nur mit Epics befassen, die sich über PIs erstrecken, werden nur die Stammiterationen, und nicht die PIs oder Sprints verwendet. Portfolio-Teams arbeiten nicht in Sprints.

   

3. Hinzufügen und Entfernen von Benutzern aus dem entsprechenden Portfolio-Team dieser Ebene. Wählen Sie auf der Seite "Übersicht" das Standardteam aus.

   

      

   Ziehen Sie es in Betracht, andere Rollen, wie z. B. Portfoliomanager, Architekten der Unternehmensebene sowie Release Train Engineers (RTEs), auf dieser Ebene hinzuzufügen und alle anderen zu entfernen.

   

Anpassen des TFS-Prozesses zur Unterstützung von SAFe

In diesem Abschnitt fügen wir den Arbeitsaufgabentyp "Epic" der Portfoliobackloghierarchie hinzu. Wir werden auch allen drei Backlog-Arbeitsaufgabentypen (WIT) das Feld "Anforderungstyp" hinzufügen. Darüber hinaus erstellen wir einige Epics und ordnen Features Epics zu.

Weitere Informationen über die Funktionsweise, nachdem Sie die Epic-Backlog-Ebene hinzugefügt haben, finden Sie hier. Wenn Sie die in diesem Schritt beschriebenen Anpassungsschritte nicht selbst durchführen möchten, bieten die ALM Ranger Ihnen einen Blog-Beitrag sowie PowerShell-Beispielskript, in denen Ihnen gezeigt wird, wie Sie diese Anpassungen für Ihr Projekt implementieren können.

Hinzufügen der Epic zum Portfoliobacklog

Wie zuvor müssen Sie ein Mitglied Gruppe "Projektadministratoren" sein, um diese Schritte ausführen zu können.

Wir werden zunächst einen vorhandenen Arbeitsaufgabentyp exportieren und ihn zum Erstellen des neuen Arbeitsaufgabentyp verwenden, den wir "Epic" nennen. Wir fügen auch ein Feld "Anforderungstyp" hinzu, um festzuhalten, um welche Art Epic es sich handelt: Architektur oder Business. Als Nächstes fügen wir eine Kategorie für die Epics hinzu. Dann ändern wir die vorhandenen Arbeitsaufgabentypen, Features und User Stories, selbst wenn sie einen anderen Namen haben, sodass sie das Feld "Anforderungstyp" enthalten. Über das Feld "Anforderungstyp" wird die Art des Ziels, das jede Arbeitsaufgabe unterstützt, verfolgt. Abschließend fügen wir das Epic dem Portfolio-Team-Backlog hinzu.

Hinzufügen des Arbeitsaufgabentyps "Epic"

Die einfachste Möglichkeit zum Erstellen eines Arbeitsaufgabentyps ist das Kopieren, Umbenennen und anschließende Bearbeiten eines vorhanden Arbeitsaufgabentyps.

Wir exportieren den Arbeitsaufgabentyp "Feature" und verwenden ihn als Grundlage für den Arbeitsaufgabentyp "Epic".

1. Öffnen Sie im Administratormodus ein Eingabeaufforderungsfenster. Ändern Sie das Verzeichnis, in dem Sie Visual Studio (oder Team Explorer) installiert haben.

   cd %programfiles%\Microsoft Visual Studio 12.0\Common7\IDE

   Verwenden Sie auf 64-Bit-Editionen von Windows %programfiles(x86)%.

2. Verwenden Sie das Tool witadmin, um die Feature-WIT-Definition herunterzuladen und als "Epic.xml" zu speichern.

   witadmin exportwitd /collection:"https://ServerName:8080/tfs/CollectionName" /p:"ProjectName" /n:Feature /f:"DirectoryPath/Epic.xml"

3. Öffnen Sie die Datei "Epic.xml", ersetzen Sie <WORKITEMTYPE name="Feature"> durch <WORKITEMTYPE name="Epic">, und aktualisieren Sie die Beschreibung.

   <witd:WITD application="Work item type editor" version="1.0" xmlns:witd="https://schemas.microsoft.com/VisualStudio/2008/workitemtracking/typedef">
   <WORKITEMTYPE name="Epic">
      <DESCRIPTION>Tracks an Epic that will span Releases. </DESCRIPTION>
   

4. Bearbeiten Sie den Abschnitt <Tab Label="Implementation"> oder für CMMI den Abschnitt <Tab Label="Requirements">, indem Sie die folgenden Zeilen durch <Filter WorkItemType="Feature" /> ersetzen.

   • Agile: <Filter WorkItemType="User Story" />

   • Scrum: <Filter WorkItemType="Product Backlog Item" />

   • CMMI: <Filter WorkItemType="Requirement" />

     Durch diese Änderung wird die Linksteuerung eingeschränkt, um Features als untergeordnete Arbeitsaufgaben von Epics zu unterstützen.

   <Tab Label="Implementation">
      <Control Type="LinksControl" Name="Hierarchy" Label="" LabelPosition="Top">
         <LinksControlOptions>
             <WorkItemLinkFilters FilterType="include">
                <Filter LinkType="System.LinkTypes.Hierarchy" FilterOn="forwardname" />
             </WorkItemLinkFilters>
             <WorkItemTypeFilters FilterType="include">
                <Filter WorkItemType="Feature" />
             </WorkItemTypeFilters>
             <ExternalLinkFilters FilterType="excludeAll" />
             <LinkColumns>
                <LinkColumn RefName="System.ID" />
                <LinkColumn RefName="System.Title" />
                <LinkColumn RefName="System.AssignedTo" />
                <LinkColumn RefName="System.State" />
                <LinkColumn LinkAttribute="System.Links.Comment" />
             </LinkColumns>
          </LinksControlOptions>
   

5. Fügen Sie das Feld "Anforderungstyp" der Epic-WIT-Definition hinzu. Hierzu leihen wir uns ein vorhandenes Feld (das ursprünglich zur Unterstützung von CMMI-Projekten erstellt wurde, aber hier gleichermaßen geeignet für unsere Zwecke geeignet ist) Microsoft.VSTS.CMMI.RequirementType aus und fügen es dem Epic-Abschnitt FIELDS hinzu.

   Suchen Sie den Abschnitt FIELDS, und fügen Sie diesen Code hinzu:

   <FIELD name="Requirement Type" refname="Microsoft.VSTS.CMMI.RequirementType" type="String" reportable="dimension">
      <REQUIRED />
      <ALLOWEDVALUES>
         <LISTITEM value="Architecture" />
         <LISTITEM value="Business" />
      </ALLOWEDVALUES>
      <DEFAULT from="value" value="Business" />
      <HELPTEXT>Indicates whether this supports business or architectural objectives.</HELPTEXT>
   </FIELD>
   

6. Als Nächstes fügen Sie das Feld dem Formular hinzu. Fügen Sie unter dem Abschnitt FORM das Feld dort hinzu, wo es Ihrer Meinung nach, am nützlichsten für Ihr Unternehmen ist. Im folgenden Beispiel haben wir das Feld unterhalb des Felds "Iteration" hinzugefügt.

   <Group Label="Classification">
      <Column PercentWidth="100">
         <Control FieldName="System.AreaPath" Type="WorkItemClassificationControl" Label="&amp;Area" LabelPosition="Left" />
         <Control FieldName="System.IterationPath" Type="WorkItemClassificationControl" Label="Ite&amp;ration" LabelPosition="Left" />
         <Control FieldName="Microsoft.VSTS.CMMI.RequirementType" Type="FieldControl" Label="Type" LabelPosition="Left" />
   

7. Speichern und importieren Sie dann die Datei.

   witadmin importwitd /collection:"https://ServerName:8080/tfs/CollectionName" /p:"ProjectName" /f:"DirectoryPath/Epic.xml"

Hinzufügen der Epic-Kategorie

Jetzt haben wir einen Arbeitsaufgabentyp "Epic", fügen Sie anschließend eine Kategorie für Epics hinzu. TFS verwaltet Backlogs basierend auf Kategorien.

1. Exportieren Sie die Kategoriedefinition in eine XML-Datei.

   witadmin exportcategories /collection:"https://ServerName:8080/tfs/CollectionName" /p:"ProjectName" /f:"DirectoryPath/categories.xml"

2. Öffnen Sie die Datei, und fügen Sie die Kategorie "Epic" hinzu. Sie können auch Microsoft durch den Namen Ihres Unternehmens ersetzen, um anzugeben, dass es sich um eine Anpassung handelt.

   <CATEGORY name="Epic Category" refname="Microsoft.EpicCategory">
      <DEFAULTWORKITEMTYPE name="Epic" />
   </CATEGORY>
   

3. Importieren Sie wie zuvor die Datei.

   witadmin importcategories /collection:"https://ServerName:8080/tfs/CollectionName" /p:"ProjectName" /f:"DirectoryPath/categories.xml"

Fügen Sie das Feld "Anforderungstyp" hinzu, um Architektur-/Business-Arbeiten zu verfolgen.

Als Nächstes fügen wir das Feld "Anforderungstyp" Features und dem Backlogelement der dritten Ebene hinzu, unabhängig davon, ob es sich um User Story, Product Backlog Items oder optional Fehler handelt. Sie müssen es nicht "Anforderung" hinzufügen, da es bereits in der CMMI-Standarddefinition enthalten ist.

1. Exportieren Sie die Feature-WIT-Definition.

   witadmin exportwitd /collection:"https://ServerName:8080/tfs/CollectionName" /p:"ProjectName" /n:Feature /f:"DirectoryPath/Feature.xml"

2. Fügen Sie das Feld "Anforderungstyp" wie zuvor für den Arbeitsaufgabentyp "Epic" hinzu. Suchen Sie den Abschnitt FIELDS, und fügen Sie diesen Code hinzu:

   <FIELD name="Requirement Type" refname="Microsoft.VSTS.CMMI.RequirementType" type="String" reportable="dimension">
       <REQUIRED />
       <ALLOWEDVALUES>
           <LISTITEM value="Architecture" />
           <LISTITEM value="Business" />
       </ALLOWEDVALUES>
       <DEFAULT from="value" value="Business" />
        <HELPTEXT>Indicates whether this supports business or architectural objectives</HELPTEXT>
   </FIELD>
   

3. Fügen Sie das Feld an derselben Position wie bei Epic in das Formular ein. Beispiel:

   <Group Label="Classification">
      <Column PercentWidth="100">
         <Control FieldName="System.AreaPath" Type="WorkItemClassificationControl" Label="&amp;Area" LabelPosition="Left" />
         <Control FieldName="System.IterationPath" Type="WorkItemClassificationControl" Label="Ite&amp;ration" LabelPosition="Left" />
         <Control FieldName="Microsoft.VSTS.CMMI.RequirementType" Type="FieldControl" Label="Type" LabelPosition="Left" />
   </Column>
   

4. Speichern und importieren Sie dann die Datei.

   witadmin importwitd /collection:"https://ServerName:8080/tfs/CollectionName" /p:"ProjectName" /f:"DirectoryPath/Feature.xml"

5. Wiederholen Sie die Schritte 1 bis 4 für die User Story- und Product Backlog Item-WIT-Definitionen. Bearbeiten Sie optional die Fehler-WIT-Definition, wenn Sie nachverfolgen möchten, welche Anforderung Fehler unterstützen, oder wenn Sie Fehler im Backlog nachverfolgen.

Hinzufügen der Kategorie "Epic" zur Portfoliobackloghierarchie

Als Nächstes fügen wir Epics der Hierarchie an Arbeitsaufgaben hinzu, die das Backlog bilden.

1. Exportieren Sie die XML-Definitionsdatei für die Prozesskonfiguration.

   witadmin exportprocessconfig /collection:"https://ServerName:8080/tfs/CollectionName" /p:"ProjectName" /f:"DirectoryPath/ProcessConfiguration.xml"

2. Öffnen Sie die Datei, und fügen Sie für Epics einen Abschnitt PortfolioBacklog innerhalb des Abschnitts PortfolioBacklogs hinzu. Ändern Sie zugleich das PortfolioBacklog-Element für FeatureCategory, damit Epics ein übergeordnetes Element für Features sind.

   Ändern Sie die Metastatus-Zuordnungen nach Bedarf auf Grundlage der Prozessvorlage. Das folgende Beispiel unterstützt Agile- und CMMI-Projekte. Fügen Sie darüber hinaus das Feld "Anforderungstyp" dem Abschnitt Columns hinzu.

   <PortfolioBacklogs>
     <PortfolioBacklog category="Microsoft.EpicCategory" pluralName="Epics" singularName="Epic">
         <States>
         <State value="New" type="Proposed" />
         <State value="Active" type="InProgress" />
         <State value="Resolved" type="InProgress" />
         <State value="Closed" type="Complete" />
         </States>
   <Columns>
        <Column refname="System.WorkItemType" width="100"/>
        <Column refname="System.Title" width="400"/>
        <Column refname="System.State" width="100"/>
        <Column refname="Microsoft.VSTS.Common.BusinessValue" width="50"/>
        <Column refname="Microsoft.VSTS.CMMI.RequirementType" width="100"/>
        <Column refname="System.Tags" width="200"/>
   </Columns>
       . . .
   </PortfolioBacklog>        
   

   Bei Scrum-Projekten müssen die Workflowstatus "Neu", "In Bearbeitung" und "Fertig" zuordnen. Hierbei handelt es sich um die gleichen Status, die für das Feature-Portfolio-Backlog-Element zugeordnet wurden.

           <State type="Proposed" value="New" />
           <State type="InProgress" value="In Progress" />
           <State type="Complete" value="Done" />
   

   Zudem müssen für CMMI-Projekte die Workflowstatus "Vorgeschlagen", "Aktiv", "Gelöst" und "Geschlossen" zugeordnet werden.

           <State value="Proposed" type="Proposed" />
           <State value="Active" type="InProgress" />
           <State value="Resolved" type="InProgress" />
           <State value="Closed" type="Complete" /> 
   

3. Fügen Sie als Nächstes parent="Microsoft.EpicCategory" zu PortfolioBacklog category="Microsoft.FeatureCategory" hinzu. Fügen Sie das Feld "Anforderungstyp" auch dem Abschnitt Columns hinzu.

   <PortfolioBacklog category="Microsoft.FeatureCategory" parent="Microsoft.EpicCategory" pluralName="Features" singularName="Feature">
      . . .
   <Columns>
        <Column refname="System.WorkItemType" width="100"/>
        <Column refname="System.Title" width="400"/>
        <Column refname="System.State" width="100"/>
        <Column refname="Microsoft.VSTS.Common.BusinessValue" width="50"/>
        <Column refname="Microsoft.VSTS.CMMI.RequirementType" width="100"/>
        <Column refname="System.Tags" width="200"/>
   </Columns>
       . . .
   
   </PortfolioBacklogs>
   

4. Fügen Sie dann das Feld "Anforderungstyp" dem Abschnitt Columns des Abschnitts RequirementsBacklog hinzu.

   <RequirementBacklog singularname="User Story" pluralName="User Stories" category="Microsoft.RequirementCategory">
      . . .
   <Columns>
        <Column refname="System.WorkItemType" width="100"/>
        <Column refname="System.Title" width="400"/>
        <Column refname="System.State" width="100"/>
        <Column refname="Microsoft.VSTS.Scheduling.Effort" width="50"/>
        <Column refname="Microsoft.IterationPath" width="200"/>
        <Column refname="Microsoft.VSTS.CMMI.RequirementType" width="100"/>
        <Column refname="System.Tags" width="200"/>
   </Columns>
      . . .
   </RequirementBacklog>
   

5. Fügen Sie die Farben, die für Epic verwendet werden sollen, im Abschnitt WorkItemColors hinzu. Sie können alle Farben wählen, die Sie möchten, aber nutzen Sie idealerweise keine bereits vom System verwendete Farbe.

   Die von uns gewählte Farbe ist Orange (Hexadezimalfarbcode = FF7B00). Stellen Sie dem Hexadezimalfarbcode das Präfix FF voran.

   <WorkItemColor primary="FFFF7B00" secondary="FFFFD7B5" name="Epic" />
   

6. Speichern und importieren Sie die Datei.

   witadmin importprocessconfig /collection:"https://ServerName:8080/tfs/CollectionName" /p:"ProjectName" /f:"DirectoryPath/ProcessConfiguration.xml"

Aktualisieren des Bereichspfads für vorhandene Arbeitsaufgaben

Damit eine vorhandene Arbeitsaufgabe im Backlog des Teams angezeigt wird, müssen Sie den Bereichspfad für jede Arbeitsaufgabe in den Standardbereichspfad des Teams aktualisieren. Sie können dazu die Massenbearbeitungsfunktion Ihres Webbrowsers oder Excel verwenden.

1. Erstellen Sie eine Abfrage, die die Arbeitsaufgaben enthält, wählen Sie diejenigen aus, die Sie bearbeiten möchten, und öffnen Sie dann das Kontextmenü einer der ausgewählten Aufgaben.

   

2. Wählen Sie den Bereichspfad, der dem Standardbereichspfad des Teams entspricht.

   

3. Speichern Sie alle Arbeitsaufgaben, die Sie geändert haben, in einem Vorgang.

   

Weitere Informationen über die Massenbearbeitung von Arbeitsaufgaben finden Sie hier.

Hinzufügen von Epics und Zuordnen von Epics zu Features

Nun, da Sie den Arbeitsaufgabentyp "Epic" hinzugefügt haben, möchten Sie auch einen erstellen. Der Prozess entspricht dem Erstellen von jeder andere Backlog-Arbeitsaufgabe. Fügen Sie aus der Backlog-Seite des Portfolio-Teams ein Epic-Backlogelement hinzu.

Fügen Sie so viele Epics wie benötigt hinzu. Um die Elemente gemäß ihrer Priorität anzuzeigen, ziehen Sie sie innerhalb der Liste an die gewünschte Position.

Der Standard-Anforderungstyp für Epics ist "Business", Sie können jedoch den Anforderungstyp eines Epic von Business in Architektur ändern.

Sie können Ihren Epics auch Tags hinzufügen, um die Investment Themes zu verfolgen, die jede Epic unterstützt.

Ihre Epics werden nun auf dem Kanban-Board angezeigt. Für diese Ansicht müssen Sie die Kanban-Spalten anpassen, um Zwischen-Workflowstatus umzubenennen und hinzuzufügen. Eine Beschreibung dieser Status finden Sie unter Business Epic Kanban Abstract (möglicherweise nur in englischer Sprache).

Dies ist jedoch noch nicht allzu sehr von Interesse. Es wird nichts ausgeführt, und Sie können kein Drilldown durchführen, um herauszufinden, welche Features Ihre Epics unterstützen. Sie sollten vorhandene Features den soeben erstellten Epics zuordnen und User Stories diesen Features zuordnen, sofern noch nicht geschehen.

Zuordnen mehrerer Elemente bei vorhandenem Backlog

Das Zuordnen von Arbeitsaufgaben ist einfach, wenn Sie den Zuordnungsbereich verwenden. Aktivieren Sie auf der Features- oder Stories-Backlog-Seite den Zuordnungsbereich. In unserem Beispiel haben wir das Fiber-Suite-Team gewählt und den Zuordnungsbereich sowie die Ansicht aktiviert, um die Hierarchie der Features anzuzeigen, die den Epics zugeordnet sind.

Beachten Sie, dass die Features-Liste leer sein wird, wenn Sie den Bereichspfad aller Features bereits in das entsprechende Team der Programmebene geändert haben, da das Portfolio-Team keine Features besitzt! Wechseln Sie in diesem Fall zu einem der Programm-Teams.

Ziehen Sie Elemente aus dem Backlog auf das Element, das Sie als übergeordnetes Element zuordnen möchten. Sie können Epics nur Features zuordnen. Gleichermaßen können Sie Features nur die dritte Ebene der Backlogelemente zuordnen (unabhängig davon, ob es sich um User Story, Backlogelemente oder Anforderungen handelt).

Wiederholen Sie diesen Vorgang für jede Backlog-Ebene, bis Sie die gewünschte Hierarchie erstellt haben.

Was geschieht mit Features, die bereits in Bearbeitung sind? Sie werden definitiv nicht im Backlog des Portfolio-Teams angezeigt. Für sie sind die Programm-Teams verantwortlich, die dafür sorgen müssen, dass sie im Backlog des Teams angezeigt werden. (Dies ist im Grunde eine Funktion des Bereichspfads, der für die Arbeitsaufgabe festgelegt wurde; eine Arbeitsaufgabe wird nur dann im Team-Backlog angezeigt, wenn Sie sie dem Bereichspfad zuweisen, den Sie für das Team erstellt haben.) Sie können sie von dort aus zuordnen.

Sie können Arbeitsaufgaben auch in großen Mengen bearbeiten und ihre Hierarchie in Microsoft Excel verwalten.

Da ein wichtiger Aspekt von SAFe die Zuordnung von Arbeit zu Business- oder Architektur-Zielen ist, sollten Sie sicherstellen, dass Sie für jedes Features, das einer Epic-Architektur zugeordnet ist, den Anforderungstyp "Architektur" festlegen. (Da standardmäßig "Business" ausgewählt ist, müssen Sie den Typ für kein Element ändern, das ein Business-Epic unterstützt.) Sie können auch Tags zum Nachverfolgen der Investition hinzufügen.

Die gleichen Prinzipien gelten für User Stories mit dem Status "In Bearbeitung". Sie können sie Features zuordnen, den Anforderungstyp in Architektur ändern für Arbeit, die Sie zur Unterstützung von Architektur-Epics ausführen, und Tags zum Nachverfolgen von Themes hinzufügen.

Ressourcen

Als praktische Referenz wurden hier alle in diesem Whitepaper genannten Ressourcen und noch einige andere mehr (möglicherweise nur in englischer Sprache) aufgelistet.

• SAFe-fähige Prozessvorlagen: Link zum Download der drei Prozessvorlagen, die TFS bereitstellt, nämlich Scrum, Agile und CMMI, die die in diesem Whitepaper erwähnten Anpassungen enthalten.

• Upgrade/Publish TFS 2013 Process Templates with PowerShell: Blog-Beitrag von Gordon Beeming, der ein PowerShell-Skript enthält, mit dem Sie die in diesem Whitepaper genannten Änderungen übernehmen können.

• Scaled Agile Framework: Website mit SAFe-Ressourcen.

• SAFe in 7 minutes: Video von Inbar Oren, dem Lean-Samurai.

• Scaling Agile and SAFe TFS Reports: Herunterladbarer Feature-Statusbericht, der mit der Scrum-Prozessvorlage arbeitet für lokale TFS 2012- und 2013-Bereitstellungen.

• Agile-Portfolio-Verwaltung: Verwenden von TFS zur Unterstützung von Backlogs über mehrere Teams hinweg: Whitepaper über das Konfigurieren von TFS zur Unterstützung mehrerer Teams und mehrerer Backlogs.

• Suchen von Arbeitsaufgaben mithilfe von Abfragen (Zu aktualisieren): Beschreibt, wie Sie TFS zur Rollup-Unterstützung konfigurieren können, wobei die Werte ausgewählter Felder für alle untergeordneten Arbeitsaufgaben eines übergeordneten Elements summiert werden. Da TFS beim Rollup mehrere Schachtelungsebenen unterstützt, sollten Sie sicherstellen, dass Sie Werte nicht doppelt zählen.

• Standardberichte (SQL Server Reporting Services): Bietet einen Überblick über die von TFS bereitgestellten Berichte zur Überwachung des Status und der Codequalität.

• Synchronisieren von Team Foundation Server mit Project Server: Beschreibt wie Projektmanager und Entwicklungsteams die von ihnen bevorzugten Tools nutzen können und Informationen transparent weitergeben können, um den Datenfluss von Arbeitsaufgaben in TFS zu Aufgaben in Unternehmensprojektplänen in Project Server zu ermöglichen.

• Nachverfolgen der Arbeit, die zwei oder mehreren Teams zugewiesen ist: Zeigt, wie Entwickler oder Tester die Arbeit nachverfolgen können, wenn sie mehrere Feature-Teams unterstützen.

Über die Autoren

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 31og.com, 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 in TFS.

Kathryn Elliott ist leitende technische Redakteurin bei Microsoft.

Susan Ferrell ist leitende technische Redakteurin und ein Visual Studio ALM Ranger.

Willy-Peter Schaub ist Program Manager bei den Visual Studio ALM Rangers im Microsoft Canada Development Center. Seit Mitte der 80er kämpft er um Einfachheit und Verfechtbarkeit im Bereich Software-Engineering. Seinen Blog finden Sie unter blogs.msdn.com/b/willy-peter_schaub. Darüber hinaus können Sie ihm auf Twitter unter twitter.com/wpschaub folgen.