Allgemein Für Administratoren Für Architekten Für Entwickler Für Projektleiter Für Tester News Produkte Publikationen
X
Thomas Rümmler
Thomas Rümmler arbeitet als Managing Consultant und Projektleiter bei AIT und ist von Microsoft als Most Valuable Professional (MVP) für Visual Studio & Development Technologies ausgezeichnet worden. Sein Arbeitsschwerpunkt liegt auf Application Lifecycle Management und DevOps. Thomas hilft Unternehmen ihren Entwicklungsprozess ganzheitlich zu verbessern. Seine Erfahrung gibt er als Autor des TFS-Blogs und Sprecher im Microsoft DevOps Umfeld weiter.

Thomas Rümmler

Neu in TFS 2015 – das Kanban Board wird erwachsen

Freitag, 07. August 2015

Wie beliebt sie doch sind: Boards in allen Varianten. Wir sehen sie immer wieder, gezeichnet auf dem Flipchart oder Whiteboard, selbstgebaut an Pinnwänden, Karten an großen Glasscheiben in Großraumbüros, vorgefertigte Boards und manchmal sogar digital. Der TFS bietet seit einiger Zeit neben dem Taskboard auch Kanban Boards für die verschiedenen Ebenen der Portfolioplanung. Mit dem TFS 2015 ist das Board noch etwas reifer geworden. Die wichtigsten Neuerungen in der Bedienung stellen wir hier vor.

Um welche Boards geht es genau?

Das TFS Web Access stellt grundsätzlich zwei verschiedene Arten von Boards zur Verfügung. Im Task Board sind einzelne Aufgaben als “Kärtchen” dargestellt, welche wahlweise nach Requirement, User Story bzw. Product Backlog Item (je nach Process Template)  oder nach zuständigem Benutzer gruppiert sind. Dieses Board wird häufig benutzt, um z.B. im Daily Standup Meeting die erledigten und geplanten Aufgaben durchzusprechen.

Die den Tasks übergeordneten Work Item Typen, wie z.B. User Story, Feature oder evtl. Epic haben für sich jedoch ebenfalls verschiedene Zustände, die ebenfalls in einem Board visualisiert werden können. Die Anwendungsgebiete hierfür sind vielfältig. Man kann diese Kanban Boards verwenden, um sich einen grafischen Überblick zu verschaffen, wo die Produktentwicklung gerade steht. Man kann aber auch direkt Kärtchen in einen anderen Zustand verschieben.

Letzteres ist der Weg, den Teams gerne einschlagen, die eher der Kanban-orientierten Methodik folgen. Auch gibt es Teams, die keine Tasks verwenden, für diese ist dies ebenfalls eine gute Option. Genau für diese Nutzergruppen gibt es ein paar nützliche Verbesserungen in der Bedienbarkeit. Der nachfolgende Screenshot zeigt ein Board auf Ebene der User Stories und wird nachfolgend noch näher erklärt.

SNAGHTML880f63f

Teilen von Spalten (#1)

Eines der Grundprinzipien vieler agiler Vorgehensmodelle ist das Pull-Prinzip. Hierbei werden sich Aufgaben “geholt”. Doch wenn man nacheinander abhängige Schritte durchzuführen hat, dann ist nicht immer klar, ob ein Element bereits bereit ist zur Weiterverarbeitung.

Wenn man beispielsweise innerhalb des Teams ein Review durchführt, bevor eine User Story den Status Resolved erhält, so kann es sinnvoll sein, innerhalb des Active Zustands zwischen Doing und Done zu unterscheiden (#1 im Screenshot). Es ist im Screenshot zu sehen, dass der Active Zustand in zwei Spalten unterteilt ist. Sobald eine Story abgearbeitet ist und für das Review bereit steht, kann sie auf Done geschoben werden. Sie ist jedoch noch immer Active und keinesfalls Resolved. Im vorliegenden Beispiel soll die Story erst den Status Resolved erhalten, wenn teamintern ein Review erfolgt ist. Der Übergang von Resolved auf Closed kann dann dem Product Owner vorbehalten bleiben.

Anzeige der Definition of Done (#2)

Die Definition of Done (DoD) ist eine Art Checkliste fürs Team, die hilft, gewisse Qualitätsmerkmale einzuhalten, bevor man ein Arbeitspaket abschließt. Das Prinzip ist in keiner Weise neu sondern vielmehr fest verankert in den agilen Methoden. Neu hingegen ist die Möglichkeit, die Definition of Done omnipräsent im Kanban Board zu hinterlegen.

So muss sich die DoD nicht länger in irgendeiner Power Point Präsentation in den Tiefen des SharePoints verstecken sondern kann sich dem Team leicht zugänglich im Kanban Board präsentieren. Dabei kann man sogar je Zustand eine eigene DoD hinterlegen, welche separat über das kleine (i) neben dem Status erreichbar ist.

Direktes Bearbeiten im Board (#3)

Die Karten im Board visualisieren bestimmte Attribute wie beispielsweise den Titel oder den Zuständigen (Assigned To). Möchte man diese Felder ändern, im Titel eine kleine Korrektur vornehmen oder evtl. die User Story einer anderen Person zuordnen, so muss man mittlerweile nicht mehr das Work Item öffnen und dann die Bearbeitung beginnen. Vielmehr kann man direkt im Board die Werte verändern. Zum Anpassen des Titels steht der kleine Bearbeiten Button (#3) zur Verfügung, der bei Annäherung des Mauszeigers auftaucht. Bewegt man den Mauszeiger hingegen zum Assigned To Feld, so wird aus dem Label automatisch eine DropDown-Box, in der man die Zuständigkeit verändern kann.

Swimlanes als Überholspur

Ein weiteres sehr nützliches Feature sind die s.g. Swimlanes. Diese ermöglichen es, das Board horizontal zu teilen. Dadurch lässt sich z.B. eine Art Überholspur einrichten. Während bei der Scrum-Methodik die Sprintplanung heilig ist, gibt es durchaus Szenarien, in denen man je nach Vorgehensmodell und Branche, bewusst schnell innerhalb einer Iteration reagieren muss. Um dieses Vorgehen besser zu unterstützen, kann man beispielsweise eine “Emergency” Swimlane einrichten (siehe nachfolgender Screenshot).

image

Dadurch kann man wie hier im Beispiel geschäftskritische Bugs bevorzugt behandeln und das Board wirkt dabei aufgeräumt und übersichtlich. Das Drag&Drop-Verhalten innerhalb einer Swimlane unterscheidet sich nicht vom bisherigen. Es handelt sich lediglich um eine bessere Kategorisierung, die der Übersichtlichkeit dient.

Wie stellt man das alles ein?

Die Konfiguration ist sehr einfach. Jedes Board hat ein eigenes Einstellungsmenü, was nachfolgend dargestellt ist.

image

Diese Einstellungen sind pro Team individuell, da Teams durchaus unterschiedlich arbeiten können.

Möchte man diese Einstellungen hingegen zentral administrieren, wird es schon etwas komplizierter. Hier fügen sich die neuen Einstellungen in die bestehende Logik ein. Dies bedeutet, dass man viele Einstellungen im s.g. Process Template vornehmen kann und für manches den Weg über die API, z.B. mittels Power Shell Skripten gehen sollte. Wenn Sie dabei Unterstützung benötigen, sprechen Sie uns einfach an.

Fazit

Microsoft bleibt seiner Linie treu: Neue Funktionen, wie die Boards, werden in einer frühen Version veröffentlicht, in der die Funktionalität noch nicht so stark ausgereift ist. Dann wird auf Feedback aus der Community gewartet und meist auch gehört, um so die einzelnen Bestandteile zielgerichtet und iterativ zu verbessern. Durch dieses Vorgehen ist das Kanban Board in gewisser Weise erwachsen geworden und lässt sich nunmehr noch leichter bedienen und individuell konfigurieren. Neben den hier gezeigten Möglichkeiten, kann man noch mehr anpassen. Die Details sind in der MSDN i.d.R. sehr gut dokumentiert. Für den TFS 2015 gibt es jedoch auch noch den einen oder anderen leeren Fleck auf der Dokumentationslandkarte. Wir stehen Ihnen in solchen Fällen auch gerne zur Seite.

Verwandte Artikel:

Benötigen Sie Unterstützung bei der Software-Entwicklung und Architektur von .NET basierten Lösungen oder bei Einführung und Anpassung von Visual Studio / Microsoft Test Manager / Team Foundation Server?

Wir stehen Ihnen unter info(at)aitgmbh.de gerne zur Verfügung.

Tags: , ,

Hinterlasse eine Antwort