|
|
Ein zentrales Feature des Visual Studio Team Foundation Server ist das umfassende zentrale Reporting über alle Artefakte des Projekts. Die intensive Nutzung der Reports ist verbunden mit dem ständigen erneuten Setzen der Reportparameter - z.B. der aktuellen Iteration. Wie Sie diese Umstellung speichern und somit die wiederholte Auswertung von Reports (z.B. tägliche Statusreports) vereinfachen, zeigt dieser Beitrag.
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.
In den mitgelieferten Berichten der Prozessvorlagen "MSF for Agile" und "MSF for CMMI" findet sich unter anderem der "Remaining Work"-Bericht. Dieser zeigt die Anzahl der Work Items in den Zuständen Active, Resolved und Closed an.
In unserem ersten Report Pack ist unter anderem die stundenbasierte Version dieses Reports enthalten, welcher in der "MSF for CMMI" Prozessvorlage eingesetzt werden kann.
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.
Viele Kunden, die aus stark diversifizierten Entwicklungsumgebungen zum Visual Studio Team System migrieren, stehen vor der Herausforderung, auch ihre gesamte Testplattform entweder zu integrieren oder neu aufzubauen. Der Neuaufbau fällt schwer, wenn sehr viele Tests auf Basis von Legacy-Code existieren. Wenn bereits die vollständige Migration des Legacy-Codes nicht in Betracht kommt, so werden auch die Tests nicht ohne Aufwand und weitere Risiken zu migrieren sein. Dennoch liegt der Nutzen einer solchen Migration z.B. von NUnit-Tests nach MSTest auf der Hand. Können die Testergebnisse von MSTest doch komfortabel mit Visual Studio ausgewertet werden.
Zudem lassen sich die Testergebnisse in Form von .trx-Dateien direkt an den TFS publizieren. So erhält man ein vollständiges Reporting über die gelaufenen Tests. Zum Beispiel im Quality-Indicators-Report:
Für die einfache Integration von NUnit-Tests haben wir ein Tool namens Unit Test Result Converter geschrieben, welches Ergebnisdateien aus den verschiedenen Legacy-Testplattformen nach MSTest konvertiert.
Die Versionsverwaltung (auch Quellcodeverwaltung genannt) des TFS bietet die Möglichkeit, Pending-Changes zentral zu verfolgen. Das bedeutet, dass alle Check-Outs oder Locks eines Benutzers zentral verfügbar sind - wohlgemerkt nicht die lokalen Änderungen, die noch nicht eingecheckt worden sind.
Die Möglichkeiten, diese Funktionalität des TFS für die Steuerung eines Projekts zu nutzen, sind dagegen eingeschränkt. Nicht nur der Überblick üder die Pending-Changes, sondern z.B. auch über die gesetzten Berechtigungen der Verzeichnisse und Dateien in der Versionsverwaltung sind nur schwer zu gewinnen.
Dieser Beitrag soll aufzeigen, wie die Versionsverwaltung durch den Einsatz von wenigen einfachen Berichten besser in den Griff zu bekommen ist…
Wesentlich für das Projektmanagement ist die Statusverfolgung eines Projekts. Der TFS bietet zu diesem Zweck verschiedene anpassbare Berichte an. Aufgrund der Vielzahl von Filtern (in Form von Berichtsparametern) ist es oft mühselig, einen Bericht regelmäßig zu öffnen und immer wieder gleiche Werte einzugeben. Da kommt der Wunsch nach Standardwerten auf. Die Anpassung des Berichts selbst ist da nicht unbedingt die einfachste und beste Lösung. Das Ändern der Berichtsdefinition ist aufwändig und zudem zentral. Außerdem sind häufig Änderungen nötig, wenn z.B. anstelle von Iteration 1 nun Iteration 2 als Standardwert gelten soll. Doch es gibt eine einfachere Lösung, die im folgenden vorgestellt werden soll…
Ziel eines Pilotprojektes bei der AIT AG rund um den TFS war die automatisierte Erfassung reproduzierbarer Kennzahlen für das Software-Management. Dabei wurde ein Messprozess auf Basis der Anforderungen von CMMI v1.2 und ISO/IEC 15939 erarbeitet und mit dem Visual Studio Team System umgesetzt werden. Desweiteren entstand ein Framework zur einfacheren Integration von Drittherstellerwerkzeugen in das Visual Studio Team System. Im Rahmen eines ersten Pilotprojektes wurden für das Management wesentliche Softwaremaße ermittelt und ausgewertet. Die Ergebnisse sollen in naher Zukunft auf ein laufendes Software-Entwicklungsprojekt übertragen und ausgereift werden. Während in einem Artikel Anfang des Jahres die ersten Ansätze veröffentlicht wurden, sollen im folgenden die Ergebnisse des Pilotprojektes kurz umrissen werden.