Wie gehe ich mit dem aktuellen Sprint/Initeration in TFS-Abfragen um?

Bei meiner Arbeit als ALM-Berater bekomme ich viele Fragen dazu, wie Sie eine stabile Iterations- (und Bereichs)-Pfadstruktur in Ihrem TFS-Team-Projekt definieren. Ich dachte, es wäre hilfreich, Ihnen einen der Punkte mitzuteilen, die ich immer mit Teams bespreche, die mit der SCRUM- oder Agile-Prozessvorlage arbeiten: den Umgang mit dem aktuellen Sprint/der aktuellen Iteration.

Wo liegt also das Problem?

Sobald Teams mit den agilen Planungstools von TFS arbeiten, beziehen sich die meisten (gemeinsamen) Workitem-Abfragen, mit denen sie arbeiten, auf den aktuellen Sprint/die aktuelle Iteration, an der sie arbeiten. Denken Sie an eine Abfrage, die uns die offenen Fehler der aktuellen Iteration anzeigt. Oder nehmen Sie zum Beispiel die SCRUM-Standardabfragen, die bei der Erstellung eines neuen Team-Projekts auf der Grundlage der SCRUM-Prozessvorlage geliefert werden.

Aufgrund dieses Übergewichts an sprint-/iterationenbezogenen Abfragen ist es wichtig, dass die definierte Iterationspfadstruktur und die Workitem-Abfragen problemlos mit der Tatsache umgehen können, dass sich der aktuelle Sprint/die aktuelle Iteration im Laufe der Zeit ändert. Aber wie lässt sich das erreichen?

Was standardmäßig geliefert wird

Sehen wir uns zunächst die Iterationspfadstruktur und die Abfragen an, die in den Standardvorlagen für SCRUM und Agile Prozesse definiert sind.

SCRUM-Prozess-Vorlage

Wenn wir uns die Standard-Iterationspfadstruktur ansehen, die von der SCRUM-Prozessvorlage geliefert wird, sehen wir eine Iterationspfadstruktur, bei der die Freigabeknoten direkt unter dem Wurzelknoten und die Sprintknoten direkt unter dem Freigabeknoten erstellt werden, wie in der Abbildung unten dargestellt.

Wenn Sie sich die Konfiguration der aktuellen sprintbezogenen Workitem-Abfragen ansehen, die standardmäßig ausgeliefert werden, finden Sie "Scrum/Release 1/Sprint 1" als Standardwert für die Klausel Iterationspfad in den verschiedenen Workitem-Abfragedefinitionen.

Agiler Prozess Vorlage

Die Konfiguration der Agile-Prozessvorlage ist etwas anders. Wenn Sie sich die Standardstruktur des Iterationspfads ansehen, sehen Sie, dass die verschiedenen Iterationen direkt unter dem Wurzelknoten erstellt werden.

Wenn Sie sich die aktuellen iterationsbezogenen Abfragen ansehen, die standardmäßig erstellt werden, finden Sie "AgileIteration 1" als Standardwert für die Iterationspfad-Klausel in den verschiedenen Work Item Query-Definitionen, wie in der Abbildung unten dargestellt.

Bis jetzt sieht alles gut aus, aber ist es das auch? Wenn wir uns den Aufwand ansehen, der für die Pflege der Standardkonfigurationen erforderlich ist, werden wir feststellen, dass die Standardkonfigurationen nicht so effizient sind, wie wir im Vorfeld denken.

Wo liegt also das Problem?

Beginnen wir zunächst mit dem Aufwand, der für die Pflege der aktuellen sprintbezogenen Abfragen der SCRUM-Prozessvorlage erforderlich ist. Damit diese aktuellen sprintbezogenen Abfragen für einen neuen Sprint funktionieren, müssen Sie ihren Iterationspfadwert jedes Mal ändern, wenn sich der aktuelle Sprint ändert. Nehmen wir als Beispiel einen Wechsel des aktuellen Sprints von Release 1/Sprint1 zu Release 1/Sprint2, so bedeutet dies, dass Sie den Wert der Iterationspfadklausel für alle auf den aktuellen Sprint bezogenen Abfragen (zumindest den Standardwert 5) in Scrum/Release 1/Sprint 2 ändern müssen. Für einen Sprint mag dies akzeptabel sein, aber bei 26 Sprints pro Jahr und mehreren Teams, die auf diese Weise arbeiten, führt die Beibehaltung der Standardkonfiguration zu einer erheblichen Zeitverschwendung.

Noch schlimmer ist der Aufwand, der für die Pflege der auf die aktuelle Iteration bezogenen Abfragen der Agile-Prozessvorlage erforderlich ist. Anstatt mindestens 5 Abfragen für Workitems zu haben, müssen Sie jedes Mal, wenn sich die aktuelle Iteration ändert, mindestens 10 Abfragen ändern, wie in der Tabelle unten dargestellt. Hmmm, das ist nicht so effizient, wie wir im Voraus denken... Aber wie kann man das einfacher machen?

Wie kann man das lösen?

Lösung 1 - Implementieren eines Platzhalterknotens im Iterationspfad für den aktuellen Sprint/Iteration (vor VS2013.5)

Die erste Lösung, die ich habe, ist für alle Versionen von Visual Studio vor VS2013 Update 5 relevant. Um diese Lösung zu implementieren, müssen Sie die folgenden Schritte ausführen:

1. Der erste Schritt, den Sie ausführen müssen, ist, dass Sie die Iterationspfadstruktur belastbarer machen. Dazu erstellen Sie in der Iterationspfadstruktur eine zusätzliche Ebene mit drei neuen Knoten direkt über der Ebene der Sprint-/Iterationsknoten: 1-Previous, 2-Current, 3-Next. Für die SCRUM-Prozessvorlage bedeutet dies, dass Sie die Knoten zwischen dem Release- und dem Sprint-Knoten erstellen müssen, wie in der Abbildung unten dargestellt. Für die Agile Prozessvorlage bedeutet dies, dass Sie die Knoten direkt unter dem Stammknoten erstellen müssen.

Nachdem Sie dies getan haben, müssen Sie die Sprint-/Iterationsknoten unter den neu erstellten Platzhalterknoten 1-Previous, 2-Current und 3-Next verteilen. Ziehen Sie dazu die vorherigen Sprints/Iterationen unter den Knoten 1-Previous, den aktuellen Sprint/die aktuelle Iteration unter den Knoten 2-Current und die kommenden Sprints/Iterationen unter den Knoten 3-Next.

2. Zweitens ändern Sie die Iterationspfad-Werte der aktuellen sprint/iteration-bezogenen Abfragen so, dass sich der Wert der Iterationspfad-Klauseln auf den soeben erstellten 2-Current-Platzhalterknoten bezieht.

Nachdem Sie beide Schritte ausgeführt haben, müssen Sie, wenn sich der aktuelle Sprint ändert, einfach nur den "alten" aktuellen Sprint unter den 1-Previous-Knoten und den "neuen" aktuellen Sprint unter den 2-Current-Knoten ziehen. Wow, was für eine Zeitersparnis!

Lösung 2 - Verwendung des Abfrage-Tokens @CurrentIteration (seit VS2013.5)

Die zweite Lösung basiert auf einem neuen Abfrage-Token, das seit VS 2013 Update 5 eingeführt wurde: @CurrentIteration. Nach einem Upgrade auf VS2013.5 oder VS2015 (einschließlich Ihres TFS-Servers) gibt dieses neue Abfrage-Token die aktuelle Iteration basierend auf dem heutigen Datum zurück und kann als Wert in der Iterationspfad-Klausel verwendet werden.

Die Lösung ist sehr einfach: Aktualisieren Sie einfach die aktuellen Abfragen, die sich auf Sprints/Iterationen beziehen, so dass sie dieses neue Abfrage-Token verwenden, und alle Abfragen aktualisieren ihren Inhalt automatisch auf der Grundlage des angegebenen Anfangs- und Enddatums der von Ihnen konfigurierten Sprints/Iterationen. Nachfolgend ein Beispiel für dieses neue Abfrage-Token. Weitere Informationen zu diesem neuen Abfrage-Token finden Sie unter  GitHub Codespaces - GitHub .