TFS2012: „My Work“ im Team Explorer

Den Nutzen einiger Funktionen erkennt man erst nach längerer Arbeit damit. Genauso verhält es sich mit dem Bereich „My Work“ im neuen Team Explorer des VS2012. Dieser Artikel stellt die neuen Features vor.

Webcast

Vorbemerkungen

Was hier beschrieben wird, steht nicht allen Nutzern von TFS 2012 und VS 2012 zur Verfügung. Bedigungung ist ein Visual Studio 2012 der Premium- oder Ultimate-Version und natürlich ein Team-Projekt auf dem neuen Team Foundation Server (TFS) 2012. Hat man all dies zur Hand, könnte man die Inhalte dieses Artikels nachspielen. Für diejenigen, die sich nicht unter den Glücklichen befinden werde ich wie immer einen Webcast dazu stellen.

Ich nutze für diesen Artikeln ein sehr simples Teamprojekt und simuliere damit den absoluten Anfang des Projektes. Es sind kaum Aufgaben hinterlegt. Als Projekt-Template habe ich mich für das neue Scrum-basierte von Microsoft entschieden, das übrigens inzwischen die Standard-Einstellung ist und damit MSF for Agile ablöst. Quasi im Vorbeigehen werden wir hier also einige Scrum-typische Elemente sehen.

Rein ins Vergnügen

Gleich nach dem Anlegen des Teamprojekts und einem Blick in den Visual Studio Team Explorer wird eine neue Sicht im „Home“-Bereich gezeigt:

Abb. 1: Team Explorer mit "My Work"-Area
Abb. 1: Team Explorer mit „My Work“-Area

In Abb. 1 habe ich den eigentlichen neuen Eintrag gelb hervorgehoben. Klickt man diesen an, erscheint der eigentliche Bereich:

Abb. 2: My Work ist ausgewählt
Abb. 2: My Work ist ausgewählt

Die einzelnen Gruppen in diesem Dialog werden auch für diesen Artikel als grobe Struktur für die Darstellung dienen:

  • In Progress Work: Welche mir zugeteilten Workitems bearbeite ich gerade?
  • Suspended Work: Welche Workitems hatte ich bearbeite, konnte ich aber nicht abschließen und habe sie daher pausiert?
  • Available Work Items: Welche Workitems wurden mir überhaupt zugeordnet, die ich noch nicht in Bearbeitung oder abgeschlossen habe?
  • Code Reviews: Anzeige eigener bzw. an mich gestellt Anfragen zur Code Review.

Eingefleichte TFS-User werden beim ersten Blick auf diese Liste in tiefes Grübeln versinken, weil diese View auf Techniken basiert, die es so bislang nicht gab.

Scrum-inspiriert

Um sich dem Sinn der ersten 3 Elemente zu nähern, sollte man sich zunächst den Hilfsmitteln des Scrum-Prozesses widmen. Wie vielleicht bekannt ist, stellt Scrum eines von vielen Modellen für die agile Entwicklung von Software-Projekten dar. Solche Modelle zu beschreiben liegt mir hier fern. Ich möchte aber auf eines der vielen Darstellungs-Mittel von Scrum verweisen: das Taskboard.

Die Idee hinter diesem Visualisierungs-Hilfsmittel ist eigentlich recht simpel. Es wird eine Matrix mit 4 Spalten und so vielen Zeilen, wie es Arbeitspakete gibt erzeugt. In die erste Spalte schreibt man nun jeweils einen kurzen Titel für das Arbeitspaket rein. Im Rahmen des Prozesses zur Verteilung der identifizierten Arbeitseinheiten (Workitem) werden nun kleine Kärtchen erstellt. Auf jedem Kärtchen steht ein prägnanter Titel, ein Name und die geschätzte Zeit bis zur Beendigung der damit verknüpften Aufgabe. Jetzt wird dieses Kärtchen in Spalte 2 („ToDo“) gesteckt.

Sobald ein Mitarbeiter mit seiner Arbeit beginnt, schnappt er sich ein oder mehr Kärtchen aus der Spalte 2 und verschiebt sie in die 3. Spalte („In Bearbeitung“). Jetzt sieht man schon einmal auf einen Blickl, wer gerade was tut und wie lange er dafür brauchen müsste.

Ist ein Mitarbeiter mit einer Aufgabe fertig, wird die entsprechende Karte in die 4. Spalte („Abgeschlossen“) und fertig.

Ein Kärtchen verlässt dabei im Normalfall seine Zeile niemals, sondern wandert nur horizontal. Es spricht nichts dagegen, eine Karte wieder in die linke Richtung zu schieben. Die Aussage ist dann im Prinzip, dass die Aufgabe als fertig angesehen wurde, es aber eigentlich nicht war.

Mit diesem Wissen bewaffnet kann man sich nun schon fast denken, was hinter den Punkten „In Progress Work“ (Spalte 3) und „Available Work Items“ (Spalte 2) verbirgt. „Suspended Work“ hat einen anderen Zusammenhang, doch dazu später mehr.

Die Arbeit beginnt

In Abb. 2 ist zu erkennen, dass mir insgesamt 4 Aufgaben zugewiesen wurden. Diese werden erstmal unter „Available…“ gezeigt. Ich weiß daher nicht nur, dass ich zuständig bin, sondern auch, dass ich mit diesen 4 Aufgaben noch nicht angefangen habe.

Ich schnappe mir also meine erste Aufgabe und schiebe sie per Drag & Drop in den Bereich „In Progress Work“:

Abb. 3: Arbeit an Work Item 3 wurde begonnen
Abb. 3: Arbeit an Work Item 3 wurde begonnen

Ich teile damit mir und den anderen Teammitgliedern mit, dass ich jetzt daran arbeite, die Solution und das Teamprojekt anzulegen. Das ist eine kleine aber wichtige Neuerung für die Zusammenarbeit im TFS. War es bislang eher schwierig, herauszubekommen, ob Kollege XY endlich angefangen hat, im VS aktiv zu werden, kann man dies nun recht einfach einsehen. Noch besser, als der Team Explorer eignet sich dafür eigentlich das neue Team Web Access.

Am einfachsten erreicht man es über einen entsprechenden Link im Home-Bereich des Team Explorer:

Abb. 4: Web Access Link im Team Explorer
Abb. 4: Web Access Link im Team Explorer

Ein Klick öffnet die Web-Access-Startseite im Standard-Browser:

Abb. 5: Web Access Startseite
Abb. 5: Web Access Startseite

Ein kleiner Tipp: Ich würde empfehlen, die Seite im IE zu öffnen und nicht z.B. Firefox oder andere Standardbrowser zu benutzen. Neben dem leidigen Problem der lästigen Authentifizierungsanfragen fühlt sich die Page im IE wohler. Im Firefox werden z.B. bei einigen Aktionen immer wieder neue Browser-Instanzen geöffnet, was nervtötend ist.

Aber weiter: Am rechten Rand kann man ein Menu erkennen, in dem ein Link namens „Board anzeigen“ auftaucht. Ein Klick darauf bringt das Taskboard zum Vorschein:

Abb. 6: Das Taskboard
Abb. 6: Das Taskboard

Abb. 6 zeigt sehr schön das weiter oben beschrieben Scrum-Hilfsmittel in seiner Visualisierung. Ich persönlich finde das Ganze erfrischend übersichtlich und gelungen. Das Beste daran ist, dass es auch im Browser komplett interaktiv ist. Ich kann also jedes der Kärtchen per Drag & Drop auf dem Board verschieben.

Man sieht ebenfalls sehr schön, die einzeln zusammen gerechneten Restaufwände pro Arbeitspaket (Spalte 1) oder auch nur für „TO DO“. Rechts oben wird angezeigt, wieviele Tage für den aktuellen Sprint (Sprint heißt im Beispiel „Infrastruktur“) verbleiben und kann so auf einen Blick erfassen, ob die Arbeit überhaupt noch zu bewältigen ist.

Zurück im Studio

Während ich nun an meinen Aufgaben arbeite, bemerke ich, dass ich die Solution nicht anlegen kann, ohne zuvor ein Teamprojekt zu haben (was ein wenig an den Haaren herbei gezogen ist, weil ich ja ohne Teamprojekt kein „My Work“ hätte, aber egal). Ich ziehe also beispielsweise noch ein Workitem in den Status „In Progress Work“ und fange an zu arbeiten. Letzteres erzeugt automatisch generierte Zusammenfassung der „Pending Changes“. In folgendem Screenshot habe ich beispielsweise bereits 2 Dateien in den Status „Edit“, also geändert, versetzt:

Abb. 7: Mehre Work Items und erste Änderungen
Abb. 7: Mehre Work Items und erste Änderungen

Hält man sich an die richtige Reihenfolge beim Herauspicken der Arbeitsaufgaben, entsteht ein richtig angenehmer Arbeitsfluss und das Team fühlt sich auch sicherer. Gerade bei Teams, die nicht immer im gleichen Gebäude sitzen, macht sich hier mehr „Aha“ bemerkbar.

Unterbrechungen

Trotz all der guten Vorsätze passiert, was passieren musste. Jemand kommt in den Raum gerannt und verteilt fröhlich ungeplante Arbeit. Ob er was dazu kann oder nicht, interessiert und nicht, wir mögen das nicht! VS 2012 ändert daran nichts, dafür wird aber der Umgang mit solchen und ähnlichen Situationen einfacher.

Was sollten wir denn aber nun eigentlich tun? Nun, der TFS-Theorie zufolge, sollten wir alle pending changes in ein Shelveset packen und es irgendwie sinnvoll benennen. „Vor Unterbrechung“, „Blöder Heini kam rein“, „Unterbrechung wegen Hotfix“. All dies wären durchaus legitime Namen für unseren Shelveset, auch wenn Variante 2 nicht nett zu nennen ist. Die Aufgabe des Shelvesets ist es ja, eigene Änderungen auf dem TFS zu sichern bzw. anderen zugänglich zu machen. Später kann man diesen Stand dann wieder unshelven und weiter arbeiten. Was man nur nicht vergessen sollte, ist seine Shelvesets irgendwann mal wieder zu löschen.

All dies bleibt auch mit dem neuen TFS weiter gültig, nur ist es nun wesentlich einfacher mit Unterbrechungen umzugehen. Konstruieren wir dazu mal ein Szenario und stellen uns vor, der „Heini“ hätte uns mitten in diesem Zustand erwischt:

Abb. 8: Zustand des VS bei Unterbrechung
Abb. 8: Zustand des VS bei Unterbrechung

Wir haben also 2 Breakpoints definiert. Einer davon ist sogar einer mit einer Bedingung. Wir haben schon 2 Änderungen vorgenommen und sind mitten drin. Nun sollen wir uns darum kümmern, ganz schnell noch etwas an der AssemblyInfo.cs zu ändern, was gar nicht zu unseren Aufgaben gehörte und so gar nicht in unseren Fluss passt.

Wir könnten nun natürlich einfach die entsprechende Datei auschecken und ändern und nur diese dann wieder einchecken, nur dass das zum einen ein später nicht mehr nachvollziehbarer Prozess wäre, sondern dass dies auch nur wirklich funktioniert, wenn wir den Änderungen einfach so einchecken dürfen. In Szenarien, die mich hier interessieren passiert allerdings hinter den Kulissen eher mehr: es werden Eincheckrichtlinien definiert, durch das Einchecken werden Builds auf dem TFS gestartet und eine Tonne weiterer Dinge würden uns um die Ohren fliegen. Mit anderen Worten: der einfache Weg ist keine Option.

Wir müssen stattdessen:

  1. Unsere bisherigen Änderungen sichern.
  2. Die neue Aufgabe isoliert erledigen.
  3. Unsere Arbeit kurz vor der Unterbrechung wieder aufnehmen.

Suspend

Und genau das geht nun erschreckend einfach. Ich wähle einfach alle Elemente unterhalb von „In Progress Work“ aus und klicke auf „Suspend“ jetzt vergebe ich eine Beschreibung des Grundes der Unterbrechung und klicke abschließend auf den Button „Suspend“:

Abb. 9: Suspend einleiten
Abb. 9: Suspend einleiten

Nach einigen Aufräumarbeiten präsentiert sich „My Work“ nun wie folgt:

Abb. 10: My Work nach Suspend
Abb. 10: My Work nach Suspend

Wie man erkennen kann, ist „In Progress Work“ nun leer, „Suspended…“ enthält meine eben angelegte Unterbrechung und die Workitems sind anscheindend immer noch in Bearbeitung (sind sie tatsächlich, wie ein Blick ins Board zeigt). Wer sich noch schnell davon überzeugen möchte, dass es sich beim Suspend technisch wirklich um einen Shelve handelt, der kann bei „Find Shelvesets“ (Home -> Pending Changes -> Actions -> Find Shelvesets) nachsehen:

Abb. 11: Shelveset des Suspends
Abb. 11: Shelveset des Suspends

OK! Nun ändere ich die AssemblyInfo.cs wunschgemäß ab. Während ich dies tue, erhalte ich bei „In Progress Work“ natürlich automatisch einen neuen Edit. Aus irgendwelchen Gründen kann ich dabei meine bisherigen Haltepunkte nicht gebrauchen und daher muss ich sie entfernen. Habe ich meine Interims-Arbeit abgeschlossen, checke ich diese (und nur diese) ein.

Resume

Jetzt, wo ich meine ungebetene Unterbrechung erledigt habe, möchte ich natürlich so schnell, wie möglich weiter machen. Auch hierfür bietet mir der Team Explorer einen schnellen Ausweg. Direkt im Bereich „Suspended Work“ befindet sich der Link „Resume“. Man klickt einfach eine Unterbrechung an und klickt auf „Resume“. Das Visual Studio ist wieder ein wenig beschäftigt. Sobald es fertig ist und ich mir meine „Program.cs“ ansehe, stelle ich erfreut fest, dass ich nicht nur an der letzten Stelle bin. Auch „Metadaten“, wie Position und Einstellungen der Haltepunkte sind wiederhergestellt worden.

Und noch etwas. Mein in Abb. 11 gezeigter Shelveset ist automatisch gelöscht und verbraucht keinen unnötigen Platz mehr.

Das Ganze ist wirklich hervorragend gelöst und sollte unbedingt genutzt werden. Unterbrechungen waren noch nie so einfach zu handhaben!

Hilf mal bitte!

Ein sehr oft gespieltes Szenario ist das Folgende. Ein Mitarbeiter hat eine Arbeitsaufgabe erhalten. Er fängt an, ist aber eher unsicher, ob seine Änderungen in die gewünschte Richtung gehen. Er fragt also eine Kollegen und bittet um Bewertung. Was aber ist hier zu tun? Im TFS ist die Antwort technisch wieder ein Shelveset. Es geht halt einfach darum, eine Änderung nicht einzuchecken, sondern anderen zugänglich zu machen. Bisher hieß das aber eine Menge zusätzlicher Dinge neben dem Shelveset an sich (Kollegen per Mail informieren, auf Antwort warten, Shelveset wieder löschen usw.).

Die Funktion „Request Review“ macht nun Schluss mit dem Aufwand. Man selektiert einfach alle oder einzelne Elemente aus (egal, ob bei „In Progress“ oder „Suspended“) und klickt auf „Request Review“. Hier kann man nun einen oder mehrere Reviewer eingeben und neben einem Titel für den Review auch einen Kommentar eingeben:

Abb. 12: Code Review starten
Abb. 12: Code Review starten

Ist der TFS entsprechend konfiguriert, gehen nun E-Mails an die ausgewählten Reviewer raus, sodass diese auf jeden Fall von der Anfrage erfahren. In Abb. 12 habe ich mich testweise selbst als Reviewer ausgewählt. In „My Work“ erhalte ich daher sofort nach dem Absenden des Reviews einen Eintrag im Bereich „Code Reviews“:

Abb. 13: Code Review mit Tooltip
Abb. 13: Code Review mit Tooltip

Dahinter steht natürlich wieder ein Shelveset, aber nicht nur das. Klicke ich nun das Element doppelt an, wird der Shelveset im VS des Reviewers abgeholt und dargstellt. Das Beste aber: der Reviewer nutzt das Visual Studio selbst zum Kommentieren des Reviews.

Zunächst einmal kann jeder Reviewer den Review ablehnen („Decline“). Hier kann er einen Kommentar reinschreiben, wie z.B. „Kann grad nicht“ oder ähnlich. Dabei sollte man natürlich darauf achten, ob mehr als ein Reviewer angegeben wurde. Ansonsten hat der Review sich natürlich erledigt und das Element wird an den Sender zurück übermittelt – ohne Ergebnis.

Ist man gewillt, den Review durchzuführen, kann man zunächst einen oder mehrere allgemeine Kommentare eintragen:

Abb. 14: Overview comment
Abb. 14: Overview comment

Noch schöner ist allerdings die Möglichkeit, eine der unter „Files“ aufgelisteten Dateien anzuklicken. Jetzt wird zunächst eine vergleichende Ansicht (Diff) der Review- und der aktuellen Server-Version der Datei gegeben, sodass man die Änderungen sofort sehen kann. Nun kann jeder Reviewer einfach Inhalte der Dateien markieren und diese Markierung mit Kommentaren versehen:

Abb. 15: Kontextmenu an beliebiger Markierung.
Abb. 15: Kontextmenu an beliebiger Markierung.
Abb. 16: Neuer Markierungskommentar
Abb. 16: Neuer Markierungskommentar

Ist der Reviewer der Meinung, genug für einen Review getan zu haben, kann er diesen schließen („Close Review“). Dabei kann er angeben, ob der Review tatsächlich abgeschlossen werden oder aufgegeben werden soll.

Der Requester des Reviews sieht während dessen live, was die Reviewer an seiner Anfrage anstellen und kann sich sogar in die Comments einschalten. Jeder Reviewer und sogar der Requester können jederzeit Kommentare beantworten, sodass eine Art Diskussion im Review entstehen kann. Alle diese Aktionen werden natürlich ggf. per Mail kommuniziert.

Fazit

Spielt man die neuen durch „My Work“ hinzu gekommenenen Möglichkeiten einmal gemeinsam durch, möchte man nichts davon mehr missen. Natürlich machen die Funktionen bei einem Einzelprogrammierer oder 2 Kumpels, die nebeneinander programmieren nicht sofort Sinn. Aber auch in kleinen Teams ist mal einer unterwegs oder arbeitet einfach nicht im gleichen Raum. Nie war es nun im Rahmen der Zusammenarbeit so einfach, logisch und konsequent, gemeinsam an Problemen zu arbeiten und zu sehen, was die andere so treiben.

Für mich ist erst jetzt der Zeitpunkt gekommen, mich ernsthaft mit den Möglichkeiten von Scrum auseinander zu setzen, weil mir immer genau diese Form der Unterstützung gefehlt hatte. Jetzt ist Scrum endlich handhabbar, selbst wenn kein Master im Büro rumlungert.

Ich kann nur jedem empfehlen, sich die Möglichkeiten anzusehen und, wenn machbar, einzusetzen.

2 Antworten auf „TFS2012: „My Work“ im Team Explorer“

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.