Mit Visual Studio Team System (VSTS) und dem darin enthaltenen Work Item Tracking System adressiert Microsoft dieses Dilemma. Die Verwendung dieses Werkzeugs wird vor allem durch die Integration der beliebten Projektmanagement- Werkzeuge Excel und Project versüßt. In diesem Artikel wird das Work Item Tracking System von VSTS vorgestellt und es wird beschrieben, wie es im Projektalltag verwendet sowie angepasst und erweitert werden kann. Dabei werden sowohl die Grenzen aufgezeigt als auch Wege und Tools, um diese möglichst unbeschadet zu überwinden.
Das Work Item (WI) ist das zentrale Element, um den Zusammenhang zwischen Arbeitsaufgaben, dem erzeugten und kompilierten Quellcode sowie den Testergebnissen innerhalb eines Projektes herzustellen (siehe Abbildung 1).
Für Projektleiter sind sie ein Mittel, um die zu erledigende Arbeit zu planen und den Erledigungsstand zu verfolgen. Für Teammitglieder bieten Work Items die Möglichkeit, die eigene Arbeit in Form von ToDo-Listen zu organisieren oder Aufgaben anderen Teammitgliedern zuzuweisen. Da die Work Items automatisch in ein Data Warehouse fließen, können damit aussagekräftige Metriken generiert werden, die in Form von mitgelieferten Berichten in Echtzeit den Projektstatus darstellen können. Das Thema Reporting ist allerdings nicht Thema dieses Artikels.
Die mit dem Team Foundation Server (TFS) installierten Prozess-Vorlagen MSF for Agile Software Development und MSF for CMMI Process Improvement bringen vordefinierte Work Item-Typen (WIT) mit. Tabelle 1 gibt einen Überblick über diese Typen und deren Bedeutung. Es gibt weitere Prozessvorlagen, wie z.B. Scrum for Teamsystem [1], die andere Work Item- Typen enthalten.
Arbeiten mit Work Items
Um die Arbeit mit den Work Items zu veranschaulichen, wird ein mögliches Vorgehen beschrieben, das sich an der Prozessvorlage MSF for Agile Software Development anlehnt. In einem Workshop, der am Anfang des Projekts durchgeführt wird und während des Projekts wiederholt werden sollte, werden mögliche Szenarien ([2], S. 77) ermittelt. Hilfreich ist dabei die Verwendung von so genannten Personas, d.h. lebensnahen Charakteren ([3] S.55), und der Überlegung, welche Ziele diese mit der Benutzung der Anwendung verfolgen und auf welchen Wegen sie diese erreichen können. Diese unterschiedlichen Wege (sowohl Erfolg als auch Misserfolg) werden als Szenarien mit einem aussagekräftigen Titel erfasst. Szenarien entsprechen damit den unterschiedlichen Pfaden eines Use Cases. ...
