|
|
Der Team Foundation Server bietet eine Integration in Microsoft Project (ab Version 2003). Diese ist allerdings sehr rudimentär und lässt z.B. eine Funktion zum Öffnen eines Work Items vermissen. So würde man gerne einen Task in MS Project auswählen und dann das komplette Work-Item-Formular einsehen wollen, da dieses weitere Informationen enthält.
Das kann mit einem angepassten Feld in MS Project gelöst werden.
Auf der MSDN ist seit heute ein neuer Webcast des AIT TeamSystemPro Teams über das Scrum for TeamSystem Process Template der Firma Conchango online (hier geht’s zum Webcast). Dieser entstand in Zusammenarbeit mit Christian Binder von Microsoft Deutschland, der wahrscheinlich vielen ein Begriff von den Visual Studio Team System Info Days ist.
Der Webcast zeigt die Inhalte des Process Templates und stellt Kriterien vor, anhand derer man bewerten kann, ob das Template für den Einsatz in der eigenen Software-Entwicklung geeignet ist. In diesem Zusammenhang soll eine ganze Reihe über die verfügbaren Process Templates entstehen.
Übrigens: Näheres zu Scrum insbesondere beim Einsatz im formalen Zertifizierungskontext bieten auch unsere Vorträge auf der TeamConf im Mai in München.
Microsoft hat eine Version des intern verwendeten Process Templates veröffentlicht. Es ist auf Codeplex unter http://mpt.codeplex.com zum Download verfügbar.
Der dabei abgebildete Prozess verfolgt den u.A. von Sam Guckenheimer propagierten "Value-Up Approach" oder zu deutsch Wertsteigerungsansatz (mehr Informationen). Wir werden an dieser Stelle in Zukunft noch weitere Informationen zur Anwendung des Process Templates bereit stellen.
In den Standardprozessvorlagen von Visual Studio Team System sind die Felder “Remaining Work”, “Completed Work” und “Baseline Work” definiert. Diese werden auch in MS Project synchronisiert.:
Die Spalten “Actual Work” und “Remaining Work” in MS Project sind mit “Completed Work” und “Remaining Work” der Work Items im TFS verknüpft. Die Standardeinheit für die Berechnungen ist dabei “Stunde”. D.h., dass auch eine Umstellung der Ansicht in MS Project hin zu “Tagen” sich nicht auf die Synchronisation im Hintergrund auswirkt. Dafür ist etwas mehr nötig.
Der TFS bietet ein Berechtigungskonzept, welches auch die Work Items einschließt. Für Work Items gelten zunächst einmal die Grenzen des Teamprojektes, in dem sie enthalten sind. Innerhalb eines Teamprojektes, lassen sich die Berechtigungen zum Anzeigen und Editieren von Work Items auf Area-Level festlegen. Areas bieten dabei folgende Rechtetabelle an:
Die Abbildung zeigt, die Rechte auf dem Area-Knoten „Specification“ eines Beispielprojektes. Diese sind für unseren Beispielnutzer entzogen. Versucht dieser Nutzer, auf diesem Knoten, Berechtigungen einzusehen oder zu editieren, bekommt er eine Fehlermeldung.
Man könnte meinen, dass das Recht “View this node” einschließt, dass der Knoten z.B. in einem Work Item Formular sichtbar bzw. versteckt bleibt. Doch ist dem nicht so. Areas und Iterations sind generell sichtbar, wenn man im TFS nicht die Metadaten nach Berechtigungen filtert (siehe Blog von Martin Woodward).
Die Reports hingegen kümmern sich nicht um Work Item Security. Alle Daten, die ein Report abfragt sind dem Nutzer, der den Report ansehen darf zugänglich (read-only). Das liegt daran, dass die Berichte als User ReportService o.ä. auf das Data-Warehouse zugreifen und das Rechtekonzept dort nicht so feingranular umgesetzt wird. Man muss sich also genau überlegen, wer auf welche Reports zugreifen darf.
Hier ein Beispiel für einen Work-Item-Bericht, der auch Work Items aus der “sicheren” Area (siehe oben) anzeigt.
Und das obwohl der Benutzer keine Berechtigung hat, dieses Work Item direkt mit dem TFS zu öffnen.
Das vorgestellte Konzept sollte in die Überlegungen zum Aufbau einer Teamprojektstruktur einfließen. Je nachdem, welche Sicherheit benötigt wird, muss man in mehrere Teamprojekte aufteilen und von einem einzelnen Teamprojekt absehen bzw. sich dafür entscheiden, mehr Informationen sichtbar zu machen.
Für ein gutes Projektcontrolling sind die Erfassung von Arbeitszeiten zu Arbeitsaufgaben (Work Items) die Basis.
Täglich zeigt sich, dass diese Routinetäglichkeit leider mangelhaft wahrgenommen durch die verschiedenen Projektbeteiligten wird. Die Gründe hierfür sind vielfältig, beispielhaft sei hier genannt, dass Aufwände mit einer zeitlichen Verzögerung erfasst und/oder geschätzt werden.
Wir haben für die Erfassung von Arbeitszeiten eine TFS Erweiterung mit dem Namen CheckinTimeTracker entwickelt.
Einige Zertifizierungen im Bereich des Application Lifecycle Managements setzen für das Audit voraus, dass sich alle Artefakte des Konfigurationsmanagements im nachhinein zu einem Datum in der Vergangenheit wiederherstellen lassen. Das trifft also im Falle des Visual Studio Team System auch die Work Items.
Doch nicht nur für ein Audit, sondern auch für Vergleichszwecke zwischen den Work Items vor und nach einer Iteration ist das relevant. Können doch so sehr genau offengebliebene Aufgaben sowie kleinere Veränderungen an Work Items ausgemacht werden.
Die Work Item Queries im VSTS besitzen schon diese Funktionalität. Über den "As of" Parameter lassen sich Queries wie zu einem zurückliegenden Datum ausführen. Im Normalfall ist diese Funktion nicht über das Visual Studio zu erreichen. Wir haben daher ein Visual Studio Addin geschriebe, welches diese Lücke schließt.
Beim Editieren von Work Item Typen mit dem XML-Editor von Visual Studio tut man sich schwer. Ist doch anscheindend keine Intellisense-Unterstützung vorhanden…
Aber es gibt sie doch.
Nun muss im Work Item Type XML noch das Root-Element angepasst werden. Der Knoten muss “witd:WITD” heißen und nicht nur “WITD”. Außerdem muss der Namespace-Name eingetragen werden. Das Root-Element sieht dann in etwa wie folgt aus:
<witd:WITD application=”Work item type editor” version=”1.0″ xmlns:witd=”http://schemas.microsoft.com/VisualStudio/2005/workitemtracking/typedef”>
Das Ende-Tag nicht vergessen (”</witd:WITD>”) und nach dem erneuten Öffnen gibt es auch Intellisense für die Work Item Typen.
Das kleine Helferlein “Stickies” ist ein Programm welches digitale Notizzettel auf dem Desktop darstellt und verwaltet.
Wir haben ein Add-In für Stickies gebaut, welches das Öffnen und Refreshen von Work Items in einem Sticky - den digitalen Notizzetteln -vereinfacht.