Seite 3: Neue Weboberfläche

Inhaltsverzeichnis

Wer auf der Startseite ein Projekt anlegt, hat derzeit weder Einfluss auf die Projektmanagementmethode noch das Quellcodeverwaltungssystem. Man erhält automatisch ein "agiles" Projekt mit Git als Quellcodeverwaltung. Wer hingegen unter Organization Settings | Projects die Funktion New team project (s. Abb. 2) wählt, erhält wie bisher die Auswahl zwischen drei Projektmanagementmethoden (CMMI, Scrum und Agile, zu den Unterschieden s. Abb. 3) und zwei Quellcodeverwaltungssystemen (Team Foundation Version Control und Git). Da Team Foundation Version Control nicht mehr weiterentwickelt wird, ist Git zu bevorzugen. Microsoft zieht mit seinen eigenen Projekten zu Git um.

Die Projektmanagementmethoden haben Einfluss auf die Benennung und Funktionen der Aufgabenverwaltung (Azure Boards). Abbildung 3 zeigt die wichtigsten Unterschiede. Weitere Änderungen betreffen die Benennung der Arbeitsintervalle: Bei CMMI und Agile spricht Microsoft von "Iteration", bei Scrum wie üblich von "Sprint". Man kann für sein Projekt von einer der Projektmanagementmethoden erben (s. "Angepasster Scrum-Prozess" rechts unten in Abb. 2) und dann Einfluss auf die Aufgabenelementtypen (Work Item Type, WIT), deren Eigenschaften und Zustände nehmen.

Nach dem Anlegen des Projekts präsentiert sich die neu gestaltete Hauptansicht (s. Abb. 4) mit einer einklappbaren Menüleiste links, die die Azure DevOps-Dienste zeigt:

• Boards: Aufgaben- und Bugverwaltung
• Repos: Quellcodeverwaltung
• Pipelines: Build- und Release-Pipelines
• Test Plans: Testpläne
• Artifacts: Bereitstellung von Softwarepaketen (npm, NuGet, Maven)

Wer ein VSTS-Projekt vor dem Stichtag 10. September 2018 besaß, landet noch in der alten Weboberfläche mit dem Menü oben auf der Seite. Hier kann man in den Benutzereinstellungen unter Preview Features den Schalter New Navigation aktivieren. Zwei zentrale Schwächen der alten Oberfläche hat Microsoft in der neuen nicht beseitigt: Es ist kein Responsive Web Design, die Anwendung lässt sich also auf kleinen Bildschirmen nur schwer bedienen. An einigen Stellen erscheinen neu angelegte Elemente nicht automatisch in der Liste, sondern erst nach einem Mausklick auf die Refresh-Schaltfläche direkt über der Liste. Das gilt zum Beispiel für Project Settings | Security beim Hinzufügen von Mitgliedern zu einer Sicherheitsgruppe.

Viele Optionen bei der Aufgabenverwaltung

Im Bereich "Boards" gibt es mehrere Ansichten. "Work Items" bietet eine Listenansicht aller Work-Item-Typen. Für Einsteiger ist es irritierend, dass gerade erfasste Elemente nur in der Liste erscheinen, wenn man eine Benutzerzuordnung zu sich selbst vorgenommen hat. Sie ist aber optional, sodass diese Eigenschaft oft erst mal nicht gesetzt wird. Diese Elemente erscheinen dann nicht in der Work-Item-Liste, weil dort standardmäßig die Ansicht "Assigned to me" aktiv ist. Erst "My activity" zeigt alle Elemente, die man selbst erfasst hat, unabhängig von der Zuweisung.

Der zweite Eintrag unterhalb von "Boards" heißt dann wieder "Boards", in denen sich die Aufgaben in Kartendarstellung bearbeiten lassen (s. Abb. 4). Die Namensgebung "Boards" auch als übergeordneten Begriff zu verwenden, ist unglücklich. In diesem Board im Kanban-Stil können Nutzer die Elemente per Drag&Drop in einen anderen Status verschieben (s. Element Kategorien löschen in Abb. 4). Mit sogenannten Swimlanes kann man für bessere Ordnung sorgen (s. Swimlanes "Eilbedürftig" und "Standard" in Abb. 4). Unter Boards | Sprints | Taskboard versteckt sich eine weitere Form von Drag&Drop-Board in Azure DevOps. Hier verschiebt man Task-Elemente, die Unterelemente von Backlog Items sind (s. Abb. 5).

Die Backlog-Ansicht zeigt eine Liste der Elemente, wahlweise als Hierarchie.

Eine Zuordnung zwischen Elementen, zum Beispiel Epic und Feature, erfolgt, indem man ein neues Element direkt als Unterelement anlegt (mit dem Pluszeichen vor dem Element) oder nachträglich Change Parent wählt. Mit View as board und View as backlog können Nutzer zwischen Board- und Backlog-Ansicht wechseln. Eine weitere Backlog-Ansicht finden sie unter caps]Sprints | Backlog[/caps]; hier sieht man nur die Backlog Items und Bugs des gewählten Sprints.

In den Ansichtseinstellungen für Board und Backlog kann man zunächst nur zwischen Features und Backlog Items wählen. Um auch die Epic-Elemente zu sehen, muss man im Einstellungsrad unter General | Backlogs das Häkchen "Epics" aktivieren. Optional gibt es eine vierte Backlog-Ebene: das Portfolio, das Nutzer aber durch Anpassungen erst mühsam aktivieren müssen.

Mit zwei Boards (Kanban und Task) sowie drei Backlog-Ansichten (inkl. Portfolio) kommen Anwender demnach auf fünf Aufgabenansichten. Microsoft bietet eine Tabelle, die Aufschluss gibt, welche Funktionen in welcher der Ansichten verfügbar sind.

In den Projekteinstellungen können Anwender unter Working with Bugs festlegen, ob sie Bugs als "Requirements" oder als "Tasks" verwalten – oder gar keine explizite Fehlerverwaltung wollen. Die Sprints und deren Terminierung legen sie in den Projekteigenschaften fest. Auch eine Trennung in verschiedene Teams ist möglich, wobei jedes Team seine eigenen Boards und Listen bekommt. Den teamübergreifenden Überblick behalten Anwender, in dem sie sich ihr eigenes Dashboard (im Menü Overview) zusammenklicken (s. Abb. 7).