|
|
Der Team Foundation Server ist die zentrale Plattform für alle Artefakte von Software-Entwicklungsprojekten. Anforderungen, Code, Testfälle, Entwurfsdokumente – alles lässt sich versioniert und für die Zusammenarbeit in Teams zentral ablegen. Doch wie hängen diese verschiedenen Artefakte zusammen und wie kann das im Team Foundation Server abgebildet werden?
Anforderungen können im Team Foundation Server zum Beispiel als Requirement-Work-Item angelegt werden. Für die Einordnung von Work Items nach zeitlichen und weiteren Kriterien werden verschiedene Möglichkeiten angeboten. Dieser Beitrag soll eine Möglichkeit für die Strukturierung nach geplanter Produktversion, Iteration und Teamzugehörigkeit darstellen und Ihnen helfen, einen besseren Überblick über Ihre Softwareentwicklungsprojekte im Team Foundation Server zu behalten.
Für das Konfigurationsmanagement ist es wesentlich, verbindliche Informationen versioniert in einem zentralen System wie z.B. dem Team Foundation Server abzulegen. Für die Kommunikation im Team reicht die zentrale Datenhaltung aber nicht aus. Hier müssen z.B. Gespräche geführt und E-Mails versendet werden. Wie Sie der Team Foundation Server bei dieser Kommunikation unterstützt, soll dieser Beitrag zeigen.
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.
| M | D | M | D | F | S | S |
|---|---|---|---|---|---|---|
| « Feb | ||||||
| 1 | 2 | 3 | 4 | 5 | 6 | 7 |
| 8 | 9 | 10 | 11 | 12 | 13 | 14 |
| 15 | 16 | 17 | 18 | 19 | 20 | 21 |
| 22 | 23 | 24 | 25 | 26 | 27 | 28 |
| 29 | 30 | 31 | ||||