TFS 2013 Prozess Templates im Vergleich

Visual Studio Scrum 2013 vs. MSF Agile 2013

scrumvsagile

Jedes TFS Team Projekt basiert auf einem Prozess Template, das die einzelnen Artefakte und Workflows für das Projekt definiert. Auf die Frage „Welches Prozess Template ist jetzt das Richtige?“ gibt es leider keine eindeutige Antwort. Die Entscheidung hängt nämlich maßgeblich davon ab, wie Sie und Ihr Team arbeiten.

Der Vergleich der Prozess Templates basiert auf den zwei agilen Basis Prozess Templates, die mit dem Team Foundation Server 2013 (Stand Nov. 2013) ausgeliefert werden. Die Auswahl des am besten geeigneten Prozess Templates hängt sehr stark von Ihrem Prozess ab. Eventuell kann ein Template Ihren Prozess auch nur zum Teil abbilden und Sie müssen es noch weiter anpassen, damit es Ihrem gelebten Prozess entspricht.

Der folgende Beitrag gibt eine Übersicht über die zwei Basis Prozess Templates. Er zeigt Ihnen wie sich die Templates voneinander unterscheiden und unterstützt Sie bei der Auswahl für Ihren Prozess.

Visual Studio Scrum 2013

Die Hilfe des MSDN schreib zum Visual Studio Scrum 2013 Template sinngemäß Folgendes: Das Scrum Template wurde entwickelt, um die Scrum Methodologie zu unterstützen.

Dies lässt vermuten, dass der Einsatz dieses Templates vor allem dann sinnvoll ist, wenn sich der Entwicklungsprozess, sowohl im Vorgehen als auch im Sprachgebrauch, sehr stark am Entwicklungsmodell „Scrum“ anlehnt.

Doch ganz so strikt muss man das nicht sehen. Natürlich finden sich im Template viele Begriffe aus Scrum wieder und auch die Workflows und Eigenschaften der Work Items sind auf das nötigste reduziert. Aber das hat auch Vorteile. Benutzt man dieses schlanke Template als Basis und erweitert es um das Benötigte, hat man ein sehr flexibles und leichtgewichtiges Template zur Verfügung.

Ein weiterer Vorteil für agile Teams ist die Integration des Bug Work Items in die Backlog Ansicht im TFS Web Portal. Somit können Bug-Fixes genauso einfach geplant werden wie neue Anforderungen.

MSF for Agile Developement 2013

Zum Template MSF for Agile Development 2013 schreibt die MSDN ungefähr Folgendes: „Das Template MSF for Agile Development 2013 (MSF Agile) wurde entworfen, um alle Teams zu unterstützen, die sich nicht dem reinen Scrum verschrieben haben, aber dennoch einen agilen Entwicklungsprozess verfolgen.“

In diesem Template fällt sofort die unterschiedliche Namensgebung für Anforderungen und Probleme auf. Eine Anforderung wird User Story und ein Problem Issue genannt. Ausserdem unterscheiden sich die Workflows und die Eigenschaften der Work Items vergleichen mit den Work Items aus den Scrum Template.

Bevor ich die beiden Template noch näher vergleichen werde, möchte ich auf einen Post von Martin Hinshelwood auf nakedalm.com verweisen. Er ist der Meinung, dass das MSF Agile Template nicht agil sei und sogar einige agile Anti-Patterns beinhaltet.

Zitat: My reason is that the ‘MSF for Agile Software Development’ template is not in any way agile and in fact enshrines many anti-patterns for agile teams.

Ich folgenden Vergleich werde ich noch detailliert auf die Unterschiede der beiden Template eingehen und gegenüberstellen, jedoch nicht über die generelle agile oder nicht agile Ausrichtung der Templates urteilen.

Vergleich

Work Item Typen des Scrum und Agile Templates

Beide Templates stellen insgesamt elf Work Item Typen bereit, wovon fünf für die Planung und Entwicklung benötigt werden (Feature, Product Backlog Item bzw. User Story, Task, Bug und Impediment bzw. Issue), zwei für das Test Management (Test Case und Shared Steps), zwei für die Feedback-Funktionalität (Feedback Request und Feedback Response) und zwei für die Code-Review-Funktionen (Code Review Request und Code Review Response).

Einen großen Einfluss auf die Entscheidung hat meiner Meinung nach die Auswahl der Work Items, die für die Planung und Entwicklung benötigt werden.

ComparePT_ScrumWorkflow

Abbildung 1: Übersicht über die planungsrelevanten Work Items des Scrum Prozess Templates

ComparePT_AgileWorkflow

Abbildung 2: Überblick über die planungsrelevanten Work Items des MSF for Agile Development Templates

Wie in den Abbildungen zu erkennen ist, unterscheidet sich auch der Prozess für Fehlerbehebungen. Während in Scrum ein Bug als Anforderung ins Backlog aufgenommen wird und anschließend genauso wie ein Product Backlog Item eingeplant wird, ist im Prozess des MSF Agile Templates das Bug Work Item davon losgelöst. Der Bug Tracking Prozess im MSF Agile Template ist eigenständig und für die Beseitigung eines Problems muss ein vom Anforderungsmanagement unabhängiger Prozess definiert werden. Zusätzlich muss auch die Tatsache berücksichtigt werden, dass der Aufwand zur Beseitigung von Bugs in der Kapazitätsplanung des TFS Web Portals nicht berücksichtigt wird.

Feature

Ein Feature Work Item ermöglicht die Planung oberhalb der Product Backlog Item Hierarchie und damit eine Planung über mehrere Entwicklungszyklen hinweg. Ein Feature gilt beispielsweise als umgesetzt, wenn alle darunter verknüpften Product Backlog Items oder User Stories abgearbeitet wurden.

ComparePT_FeatureScrum_Workflow

Abbildung 3: Workflow des Feature Work Items im Scrum Template

Die Feature Work Items beider Prozess Templates unterscheiden sich im Wesentlichen durch den Workflow. Neben der differierenden Benennung der Work Item Zustände, hat das Feature Work Item des MSF Agile Templates auch einen Zustand mehr. Zwischen den Zuständen Active und Closed existiert noch der Zustand Resolved. Resolved heißt so viel wie „Das Feature wurde umgesetzt, aber noch nicht endgültig vom Product Owner abgenommen“.

Ebenfalls zu erwähnen wäre, dass der Übergang von Active auf Removed im Template MSF Agile nicht existiert und somit ein aktives Feature nicht mehr direkt vom Backlog genommen werden kann.

ComparePT_FeatureAgile_Workflow

Abbildung 4: Workflow des Feature Work Item aus MSF for Agile Development

Product Backlog Item vs. User Story

Im Visual Studio Scrum Prozess Template heißen Anforderungen an die Entwicklungsabteilung Product Backlog Items (PBI). Ein PBI wird in der Regel innerhalb eines Entwicklungszyklus (Sprint) umgesetzt und besteht aus einem oder mehreren Aufgaben (Tasks).

Zur Klassifizierung eines PBI stehen dem Nutzer die Felder Business Value und Effort zur Verfügung, mit deren Hilfe der Product Owner eine Priorisierung vornehmen kann. Der Business Value schätzt den Kundennutzen ab und der Effort den Aufwand für die Entwicklung.

Das Pendant zum Product Backlog Item (PBI) ist das Work Item User Story. Genau wie beim PBI wird der Aufwand einer User Story mit Story Points geschätzt, allerdings wird dieser Wert nicht im Feld Effort sondern unter Story Points hinterlegt. Das Feld Business Value ist im User Story Work Item verschwunden und kann somit nicht mehr für die Priorisierung im Backlog behilflich sein. Dafür gibt es das Feld Risk, welches die Bewertung des Risikos einer Anforderung bezogen auf das Gesamtsystem zulässt.

Hinweis: Der Business Value kann im MSF Agile Template über das Feature Work Item definiert werden, dem eine gewisse Anzahl von User Stories untergeordnet sind.

In Tabelle 1 ist eine Gegenüberstellung der wichtigsten Felder zu finden.

ComparePT_Table1

Tabelle 1: Gegenüberstellung wichtiger unterschiedlicher Felder von PBI und User Story

ComparePT_PBI_Workflow

Abbildung 5: Workflow des Product Backlog Item des Scrum Templates

Der Workflow des PBI und der User Story unterscheidet sich nur leicht. Die Namen der Zustände haben sich geändert und die Transitions von Active zu Removed und Resolved zu Removed sind entfallen.

ComparePT_UserStory_Workflow

Abbildung 6: Workflow User Story des MSF for Agile Development Templates

Task

Eine Aufgabe wird über ein Task Work Item abgebildet. In Scrum interessiert das Entwicklungsteam nur der verbleibende Aufwand bis zur Umsetzung der Aufgabe. Dieser verbleibende Aufwand wird über das Feld Remaining Work verfolgt und mittels des Burndown Charts visualisiert.

ComparePT_Task_Workflow

Abbildung 7: Workflow des Task Work Item des Scrum Templates

ComparePT_TaskAgile_Workflow

Abbildung 8: Workflow des Task Work Item des MSF for Agile Development Templates

Der Task des Template MSF Agile unterscheidet sich nicht so sehr im Workflow, hier werden nur andere Zustandsnamen verwendet, sondern vielmehr in den angebotenen Feldern und deren Verwendung.

ComparePT_Table2

Tabelle 2: Gegenüberstellung wichtiger Felder des Task Work Items

Während im reinen Scrum die ursprünglich geschätzte Umsetzungsdauer und die bereits geleistete Arbeit keine Rolle spielen und weswegen die Felder im Work Item nicht verfügbar sind, können diese Felder im Task des Agile Templates verwendet werden.

Bug

Ein Bug wird in Scrum wie eine Anforderung behandelt, d.h. der Bug wird ins Product Backlog aufgenommen und darüber verwaltet. Für die konkrete Umsetzung einer Fehlerbehebung werden Task Work Items angelegt und mit dem Bug Work Item verknüpft.

ComparePT_Bug_Workflow

Abbildung 9: Workflow des Bug Work Item des Scrum Templates

ComparePT_BugAgile_Workflow

Abbildung 10: Workflow des Bug Work Item in MSF for Agile Development

Bei der Gegenüberstellung beider Workflows ist auch sehr offensichtlich, dass dieser sehr unterschiedlich ist. Während sich das Template MSF Agile mit drei Zuständen begnügt, wird im Scrum Template der Zustand Active durch die Zustände Approved und Commited abgebildet. Darüber hinaus gibt es noch einen Zustand Removed, um Bug Work Items aus der Planung zu entfernen.

ComparePT_Table3

Tabelle 3: Gegenüberstellung wichtiger Felder des Bug Work Items

Hinweis: Das Bug Work Item im Template MSF for Agile Development ist nicht der Work Item Kategorie der Anforderungen (Requirements Category) zugeordnet und wird dadurch nicht in der Backlogansicht des TFS Web Access angezeigt.

Impediment vs. Issue

Das Impediment Work Item dient zur Verwaltung von auftretenden Problemen während eines Entwicklungszyklus. Die Impediments sind unabhängig von den Anforderungen und werden in erster Linie nicht von einem Entwicklungsteam bearbeitet.

Ein Issue Work Item ist dem Impediment Work Item sehr ähnlich. Es wird ebenso benutzt, um Probleme nachzuverfolgen, die zu einem Stocken des Entwicklungsprozesses führen könnten.

ComparePT_Impediment_Workflow

Abbildung 11: Workflow des Impediment Work Item des Scrum Templates

ComparePT_Issue_Workflow

Abbildung 12: Workflow Issue Work Item des Templates MSF for Agile Development

ComparePT_Table4

Tabelle 4: Gegenüberstellung Impediment zu Issue

Reports und Dashboards

Relativ große Unterschiede gibt es im Bereich der Report-Vorlagen, speziell in der Anzahl der Reports zur Überwachung des Projektfortschritts. Das Template MSF for Agile Development bringt ein paar Vorlagen mehr bei der Installation mit.

ComparePT_Reports

Abbildung 13: Vergleich der Report-Vorlagen

Hinweis: Report-Vorlagen stehen nur zur Verfügung, wenn die SQL Server Analysis Services und Reporting Services installiert und für den TFS konfiguriert sind.

Die beiden Standard-Templates unterscheiden sich ebenfalls in der Bereitstellung von Sharepoint Dashboards. Während das Scrum Template nur ein Release Dashboard zur Verfügung stellt, gibt es im Template MSF Agile fünf Dashboard-Vorlagen zusätzlich. Wer also viel und gerne mit dem Sharepoint arbeitet und auf Dashboards wert legt, sollte sich das MSF Agile Template genauer ansehen.

ComparePT_Dashboards

Abbildung 14: Vergleich der Dashboard-Vorlagen

Zusammenfassung

Die beiden Prozess Templates Visual Studio Scrum 2013 und MSF for Agile Development 2013 unterscheiden sich nicht sehr stark. Beide haben dieselbe Anzahl von Work Items, die teilweise anders heißen und auch andere Felder zur Verfügung stellen. Die meisten Unterschiede befinden sich in den Workflows der einzelnen Work Item Typen, also in den Zuständen und Zustandsübergängen. Für eine genauere Übersicht sind in der nachfolgenden Tabelle noch einmal alle Zustände der vergleichbaren Work Item Typen aufgeschlüsselt.

Wenn man eher ein sehr schlankes und flexibles Template haben möchte, dann sollte man das Visual Studio Scrum 2013 Template als Grundlage wählen. Auch wenn man kein Verfechter der reinen Scrum-Lehre ist, kann man damit sehr gut arbeiten.

Wenn man eher ein Template sucht, in dem Bugs und Anforderungen getrennt voneinander verwaltet und geplant werden können, dann findet man sich wahrscheinlich eher im MSF for Agile Development Template zurecht.

Grundsätzlich gilt, beide Templates können an individuelle Wünsche angepasst werden.

Ich für meinen Teil benutze am liebsten das Visual Studio Scrum Template, da mir die Scrum-Terminologie am meisten liegt und ich auch Bug Work Items in meiner Backlog Ansicht organisieren und planen möchte.

ComparePT_Table5

Tabelle 5: Übersicht über die zur Verfügung stehenden Zustände

[1] MSDN: http://msdn.microsoft.com/en-us/library/jj920147.aspx

[2] MSDN: http://msdn.microsoft.com/en-us/library/dd997897.aspx

[3] Martin Hinshelwood – nakedalm.com: http://nakedalm.com/agile-vs-scrum-process-templates-team-foundation-server/

[4] Scrum.org: http://scrum.org