TFS2012 – Teamstruktur mit Team Field statt mit Areas

Mit der ersten Version des Team Foundation Servers 2012 wird Entwicklungsteams mehr Bedeutung zugemessen. Durch ein neues Team-Konzept besteht nun die Möglichkeit die Teamstrukturen eines Unternehmens im TFS abzubilden. Die Teams bekommen in den Team Projekten einen Arbeitsbereich zugewiesen, indem sie Arbeitspakete verwalten und organisieren können, d.h. jedem Team liegt eine Area (Area Path) zu Grunde. Müssen Teams aber bereichsübergreifend agieren, stößt dieses Konzept an seine Grenzen. Aber auch dafür gibt es eine Lösung.

Die agilen Planungswerkzeuge im TFS 2012 ermöglichen erstmals eine Visualisierung der Arbeitspakete. Neben einem allgemeinen Product Backlog, das alle Anforderungen anzeigt, gibt es ein Team Backlog, welches nur Anforderungen und Bugs des Teams wiedergibt. Außerdem gibt es ein Scrum- und Kanban-Board, sowie ein Burndown Chart.

TeamField_BacklogBoardAbbildung 1: Product Backlog, Board und Burndown Chart

Das Konzept jedem Team einen Arbeitsbereich zu zuordnen funktioniert gut, solange sich Teams ausschließlich um ihren Bereich kümmern. Hat ein Projekt ein Produkt mit mehreren Produktbereichen und Teams die bereichsübergreifend agieren, dann stößt dieses Konzept an seine Grenzen.

TeamField_TeamvsAreaAbbildung 2: Areas eines Projekt und area-unabhängige Teams

Damit Projektteams weiterhin die Planungs-Tools verwenden und Requirements organisieren können, muss das System erweitert werden. Das Anlegen eines Team Fields, über das eine neue Zuordnung der Teams zu den Work Items erfolgen kann, löst dieses Problem.

Folgende vier Schritte sind dafür notwendig:TeamField_RoadmapAbbildung 3: Fahrplan zum Team Field

Global List mit Teams erstellen

Als erstes erstellt man eine Global List, in der eine Liste mit den Teamnamen hinterlegt wird. Eine Global List ist immer dann sinnvoll, wenn Änderungen an einer zentralen Stelle durchgeführt werden sollen. Man stelle sich vor, dass bei einer Änderung der Teamnamen sowohl das Product Backlog Item als auch das Bug Work Item betroffen wären. Mit einer Global List spart man sich somit Aufwand und reduziert das Ausfallrisiko, falls bei der Änderung etwas schief läuft.

Hinweis: Dem Beispiel basiert auf dem Microsoft Visual Studio Scrum 2.2 Template

TeamField_OpenGlobalListAbbildung 4: Global List auf dem Server öffnen

Tipp: Zum Bearbeiten von Work Item Definitionen oder der Global List empfiehlt es sich den Process Editor der TFS Power Tools zu verwenden.

Zum Öffnen einer Global List wählt man TOOLS | Process Editor | Global List | Open Global List from Server und klickt dann mit der rechten Maustaste in die weiße Editorfläche. Über das Kontextmenü lässt sich dann ein neuer Eintrag vornehmen.

TeamField_CreateGlobalListAbbildung 5: Global List erzeugen und Teamnamen hinterlegen

Wenn die Global List direkt am Server editiert wird, muss die Liste lediglich abspeichert werden und die Änderungen sind aktiv.

Tipp: Vor dem Editieren der Global List sollte diese exportiert und in der Version Control gespeichert werden.

Team Field in Work Items hinterlegen

Als nächstes muss ein zusätzliches Feld in allen Work Item Definitionen angelegt werden, die in der Requirement Category des Prozess Templates aufgelistet sind. Durch diese Kategorie wird bestimmt, welche Work Items auf der Backlog-Ansicht des Web Access angezeigt und verwaltet werden können.

witadmin exportcategories /collection:vsalm\conpletosocollection /p:conpletoso /f:”c:\temp\categories.xml”

Das Exportieren der Kategorie kann leider nicht über den Process Editor durchgeführt, sondern muss über die Konsolenanwendung witadmin.exe erfolgen.

TeamField_RequirementCategoryAbbildung 6: Auszug aus den Kategorien des Prozess Templates

Wie in der obigen Abbildung zu sehen ist, befinden sich nur das PBI und der Bug in dieser Kategorie, so dass auch nur die Definitionen dieser Work Items angepasst werden müssen.

TeamField_CreateTeamFieldPBIAbbildung 7: Team Field in Product Backlog aufnehmen

Tipp: Auch hier ist es besser die Work Item Definition vor dem Editieren in der Version Control abzulegen.

Bei der Anlage von neuen Work Item Feldern sollte man sich an ein einheitliches Format halten. Als Referenznamen bietet sich das Format [Firmenname].[FeldName] an. So lässt sich das Feld leichter wieder finden. Wenn man dieses Feld einem Report zum Filtern benötigt, dann sollte man es außerdem als Dimensionsfeld deklarieren.

TeamField_CreateTeamFieldGlobalList2Abbildung 8: Verknüpfung der Global List mit dem Feld

Nachdem man die Field Definition ausgefüllt hat, wechselt man auf das Tab Rules und legt die folgenden zwei Regeln an. ALLOWEDEXISTINGVALUES, damit das Work Item nicht einen undefinierten „Zustand“ bekommt, wenn in der Zukunft ein Teamname gelöscht werden würde. Und ALLOWEDVALUES, um die Liste (Global List) mit den Teamnamen zu hinterlegen.

Bevor die neue Work Item Definition an den Server hochgeladen werden kann, muss noch das Layout des Work Items angepasst werden.

TeamField_BacklogOhneTeamFieldAbbildung 9: Product Backlog Item ohne Teamauswahlfeld

Um ein neues Control in die Work Item Maske einzufügen, muss man auf die Lasche Layout wechseln. Dort legt man über den Punkt New Control aus dem Kontextmenü ein neues Control an. Als Field Name muss der Referenzname des zuvor angelegten Feldes [conpletoso.Teams] verwendet werden.

TeamField_CreateTeamFieldLayoutAbbildung 10: Layout des PBI erweitern

Nach einem erfolgreichem Upload und einem Refresh in Visual Studio kann man ein neues Work Item erstellen, in dem die Teams über eine Drop-Down-List auswählbar sind.

TeamField_CreateNewWorkitemAbbildung 11: Neues Work Item anlegen

Hinweis: Das Feld muss an jedes Work Item der Requirement Category hinzugefügt werden, damit der nächste Schritt erfolgreich durchgeführt werden kann.

Common Process Config anpassen

Nachdem die Definition der Work Items erfolgreich angepasst worden ist, müssen nun die  Common Process Configuration geändert werden.

witadmin exportcommonprocessconfig /collection:vsalm\conpletosocollection /p:conpletoso /f:”c:\temp\commonprocess.xml”

 TeamField_CommonProcessConfigAbbildung 12: Common Process Configuration File

Um dies zu erreichen muss für das TypeField Team der Referenzname geändert werden.

Der bisherige Referenzname System.AreaPath

<TypeField refname=“System.AreaPath“ type=“Team“ />

muss durch das neue Feld mit Referenznamen conpletoso.Teams ersetzt werden.

<TypeField refname=”conpletoso.Teams” type=”Team” />

Nach dem Speichern und Importieren auf den Team Foundation Server steht dem Web Access die neue Konfiguration zur Verfügung und eine neue Einstellungsseite Team Fields wird innerhalb der Team-Administration sichtbar.

witadmin importcommonprocessconfig /collection:vsalm\conpletosocollection /p:conpletoso /f:”c:\temp\commonprocess.xml”

Mapping Team zu Team Field

Der finale Schritt, um Teams ohne Areas organisieren zu können, findet in der Team-Administration statt. Dort muss für jedes Team auf der Einstellungsseite Team Field ein Teamname ausgewählt werden.

TeamField_TeamFieldMappingAbbildung 13: Name zuordnen in der Team Administration

Damit ist das Mapping von Team zu Team Field abgeschlossen und in den Team Backlogs werden nun nur noch Work Items angezeigt, wenn der Name des Teams im Work Item ausgewählt ist.

TeamField_BacklogTeamBlackAbbildung 14:: Backlog von Team Black

Fazit

Durch die Erweiterung der Work Item Definitionen und der Neukonfiguration des Web Access, bekommt man durch das Team Field eine weitere Möglichkeit Team-Strukturen im TFS abzubilden.

Wie immer gilt natürlich auch hier. Änderungen sollten auf einer Testumgebung eingespielt und ausführlich getestet werden, bevor das Produktivsystem angepasst wird.