Im ersten Teil dieser kleinen Blogserie wurden die wesentlichen Neuerungen in den Prozess Templates des TFS 2015 beschrieben. Wie Sie mit damit einhergehenden Fallstricken umgehen und was Sie tun müssen um die neuen Elemente in Ihre bereits bestehenden, angepassten Prozess Templates einarbeiten zu können, ist Gegenstand dieses Beitrags.
Grundsätzlich gibt es zwei Ansätze, wie die Vorzüge, welche die Neuerungen in den Process Templates mit sich bringen, für bereits bestehende Templates übertragen werden können. Zum einen können die neuen Elemente in das bestehende Template eingepflegt werden oder aber die Anpassungen des eigenen Templates werden in ein neues nutzerspezifisches TFS Standardtemplate eingearbeitet.
Der erste Ansatz eignet sich vor allem dann, wenn das eigene Template eine Vielzahl an Änderungen enthält und damit einen hohen Anpassungsgrad aufweist. Hinzu kommt, dass in diesem Fall der Configure Features-Wizard nach dem TFS Upgrade verwendet werden kann um das bestehende Template mit den neuen Features auszustatten. Dies setzt jedoch voraus, dass dem eigenen Process Template eines der Standardtemplates zugrunde liegt.
Hingegen eignet sich der zweite Ansatz vor allem für Szenarien, in denen die Anpassungen im Vergleich zum Basistemplate und somit auch der Aufwand der Übertragung sehr gering ist. Dieser Ansatz bringt zudem den Vorteil mit sich, dass man sicher sein kann, alle neuen Features der neuen Templates auch tatsächlich nutzen zu können und nichts übersehen zu haben. In diesem Fall jedoch müssen die Anpassungen manuell in den Quellcode-Dateien des Process Templates vorgenommen werden.
Für diesen Artikel wird für einige der im ersten Teil des Blogs beschriebenen Neuerungen die notwendigen Schritte zur Umsetzung erklärt und zwar mittels des ersten Ansatzes. Dabei wird nicht die Umsetzung mittels des Configure Features-Wizards beschrieben, sondern die notwendigen manuellen Änderungen in den Quellcode-Dateien. Grundsätzlich ist es für beide Vorgehensweisen empfehlenswert ein Tool zum Vergleich der zugrundliegenden XML-Dateien, wie z.B. DiffMerge, zu Rate zu ziehen. Dies hilft vor allem auch dabei, eine Entscheidung im Bezug auf den zu verwendenden Ansatz zu treffen, ob bestehende Änderungen in ein neues Standard Process Template eingepflegt werden sollen oder aber ob umgekehrt die neuen Features in ein bestehendes angepasstes Process Template eingearbeitet werden.
Ein Fallstrick im Zusammenhang mit den Veränderungen der neuen Templates taucht aufgrund der neu eingeführten Unveränderbarkeit der Standard Templates auf, welche über die Guid identifiziert werden. Bisher war es zwar auch Best Practice die Guid sowie den Namen des Templates im Falle von Anpassungen zu verändern, jedoch führte es nicht zu (offensichtlichen) Problemen wenn es mal vergessen wurde. Will man nun also solch ein angepasstes Template in den TFS hochladen, welches aber noch dieselbe Guid wie eines der Standardtemplates besitzt, so erhält man eine Fehlermeldung und kann den Prozess nicht beenden. In diesem Fall muss dem Template in der Datei ProcessTemplate.xml eine neue Guid zugewiesen werden (vgl. Abbildung 1).
Abb.1: Fehlermeldung beim Hochladen eines Templates und Ursache im Template
Möchte man die Unterstützung für das Scale Agile Framework (SAFe) in ein bereits bestehendes Template einpflegen so müssen, wie im ersten Teil beschrieben, zwei Teile implementiert werden. Dies ist zum einen das Hinzufügen des Work Item Typs Epic und dessen Backlog / Board und zum anderen das Ergänzen des Feldes Value Area für alle Work Iten Typen auf Portfolio-Ebene.
Für die Implementierung des Epic-Work Item Typs sind folgende Schritte auszuführen:
Zunächst muss eine gültige Work Item Definition im Verzeichnis WorkItem Tracking/TypeDefinitions hinzugefügt werden. Hierfür kann die Definition aus einem der drei Standard-Prozess Templates verwendet werden. Dabei sollte die Definition desjenigen Templates gewählt werden, welches dem eigenen Template als Basis zugrunde liegt. Im zweiten Schritt muss dann der Datei WorkItems.xml ein neues Element Workitemtype, welches den Pfad zur Definition spezifiziert, hinzugefügt werden (vgl. Abbildung 2).
Abb.2: Categories.xml
Weiterhin muss dann in der Datei Categories.xml eine eigene Kategorie für die Epics definiert werden (vgl. Abbildung 3) , welche schließlich verwendet wird, um das Epic-Portfolio-Backlog innerhalb der ProcessConfig.xml zu konfigurieren (vgl. Abbildung 4(1)) und den Bezug zum Feature-Portfolio-Backlog zu definieren (vgl. Abbildung 4(2)).
Abb.3: Categories.xml
Abb.4: ProcessConfiguration.xml
Zuletzt kann dann dem neuen Work Item Typen Epic in der ProcessConfiguration.xml noch (optional) eine Farbe zugewiesen werden, welche im TFS Web Access benutzt wird um den Work Item Typen farblich zu markieren (vgl. Abbildung 4(4)).
Hat man diese Schritte durchgeführt und die Änderungen des Prozess Template in einem bestehenden Projekt nachgeladen (durch Benutzung von Witadmin oder aber mit Hilfe des Wizards) bzw. ein neues Projekt damit erzeugt so kann dann im Web Access in den Settings der jeweiligen Teams das Epic-Portfolio-Backlog aktiviert werden (vgl. Abbildung 5).
Abb.5: Team Settings – Backlogs
Der zweite Punkt der in den Bereich des SAFe-Support fällt, ist das Hinzufügen des Feldes Value Area für alle Work Iten Typen auf Portfolio-Ebene. Hierbei wird das Feld wie gewohnt zu einem Work Item hinzugefügt (vgl. Abbildung 6).
Abb.5: Value Area-Field
Nicht zuletzt noch einige Anmerkungen zu den Neuerungen für den Work Item Typ Bug. Wie bereits im ersten Teil des Blogs beschrieben sind die Konfigurationsmöglichkeiten für Bugs erheblich gewachsen. Neben dem im Prozess Template konfiguerbaren Standardverhalten kann ebenso wie das Ein- und Ausschalten von Portfolio-Ebenen die Behandlung von Bugs teamspezifisch in den Team-Einstellungen im TFS Access (Settings) konfiguriert werden (vgl. Abbildung 6).
Abb.6: Team Settings – Bugs
Für das Hinzufügen der dafür benötigten Felder zum Work Item Typ Bug kann die MSDN zur Rate gezogen werden. Alternativ können auch mittels einem XML-Vergleichstool die neu eingeführten Felder herausgefunden werden um dann die Änderungen in das eigene Template zu übernehmen.
Fazit
Abschließend bleibt zu sagen, dass es in den meisten Fällen empfehlenswert ist die Änderungen der neuen Versionen in den eigenen Templates nachzuziehen um auch in Zukunft schnell und einfach Team Projekte mit dem bekannten Template aber mit neuen Features nutzen zu können. Dies kann zwar einiges an Zeit in Anspruch nehmen, gewusst wie ist das aber kein Hexenwerk.