TFS 2012 Anforderungsmanagement: Work Items und Prozessvorlagen

Von Tobias Richling

Im TFS wird das Application Lifecycle Management verwaltet. Der gewählte ALM-Prozess kann von Team zu Team sehr unterschiedlich sein, orientiert sich meist an etablierten Prozessmodellen und beinhaltet verschiedene Workflows. Diese Prozessmodelle können dabei durch Projektvorlagen festgelegt werden, der Individualität wird durch Anpassbarkeit der Templates Rechnung getragen. Zentrales Element der Prozessvorlagen sind die Typen der zur Verfügung stehenden Work-Items.
In diesem shortcut von Tobias Richling wird der Scrum-Prozess kurz umrissen und das agile Anforderungsmanagement mit dem TFS beschrieben. Außerdem wird gezeigt, wie Anpassungen an der Projektvorlage vorgenommen werden und die Integration einer Fremdanwendung funktioniert.

• Sprache: Deutsch
• Herausgeber: entwickler.press
• Erscheinungsdatum: 23. Nov. 2012
• ISBN: 9783868024357

Buchvorschau

Tobias Richling, Michael Klei

TFS 2012 Anforderungsmanagement

Work Items und Prozessvorlagen

ISBN: 978-3-86802-435-7

© 2012 entwickler.press

Ein Imprint der Software & Support Media GmbH

1 Einleitung

Im TFS wird das Application Lifecycle Management verwaltet. Der gewählte ALM-Prozess kann von Team zu Team sehr unterschiedlich sein, orientiert sich meist an etablierten Prozessmodellen und beinhaltet verschiedene Workflows.

Im TFS können diese Prozessmodelle durch Projektvorlagen festgelegt werden. Der Individualität wird durch Anpassbarkeit der Templates Rechnung getragen. Zentrales Element der Prozessvorlagen sind die Typen der zur Verfügung stehenden Work-Items.

In diesem shortcut

wird der Scrum-Prozess kurz umrissen

wird das agile Anforderungsmanagement mit dem TFS beschrieben

werden Anpassungen an der Projektvorlage vorgenommen

wird die Integration einer Fremdanwendung beschrieben

Voraussetzungen:

eine vorhandene TFS Installation

2 Agile and Scrum with your own words

In den letzten Jahren hat die Softwareindustrie, angetrieben durch die Softwarekrise, ihre Methoden bei der Produkterstellung und Projektdurchführung reflektiert und Prozessmodelle entwickelt, die einem Scheitern von Softwareprojekten entgegenwirken können. Klassische, statische Modelle wie das Wasserfallmodell haben sich als zu starr herausgestellt: Durch die zu späte Integration von Feedbackschleifen konnten Abweichungen zwischen Anforderung und Implementierung oder von Spezifikation und tatsächlichen Anforderung erst sehr spät erkannt werden. Die daraus resultierenden Änderungen waren sehr aufwändig und dadurch teuer.

Das Ergebnis dieser Überlegungen waren die agilen Methoden wie Extreme Programming und Scrum. Diese Methoden haben die Eigenart, bereits in frühen Phasen und kontinuierlich im Entwicklungsprozess Rückkopplungen zu den Kunden herzustellen und sie damit aktiv in den Prozess einzubinden. Auf diese Weise sollten teure Änderungen am Ende des Prozesses auf frühere Phasen verschoben werden.

Die agilen Methoden wurzeln in dem agilen Manifest, das folgende Kernprinzipien formuliert:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

Das Manifest erkennt an, dass die Punkte auf der rechten Seite von Wert sind, zugleich aber von den Punkten auf der linken Seite ein höherer Wert ausgeht.

Unter den Prozessen, die sich an diesem Manifest ausrichten, hat sich Scrum in der Softwarebranche einen Namen gemacht. Ziel ist es, den Erstellungsprozess der Software transparenter zu gestalten. Alle notwendigen Kompetenzen sollen im Team vorhanden sein, das Team ist gleichzeitig voll verantwortlich. Auf diese Weise werden Ausreden und das Abschieben von Verzögerungen auf externe Faktoren ausgeschlossen. Durch die Einbeziehung der Kunden wird die Akzeptanz der Anwender erhöht und verschiebt diesen Punkt nicht auf eine späte Endabnahme, während der Kunde vorher nichts von seiner Software gesehen hat. Ziel ist eine kontinuierliche Wertschöpfung, die früh brauchbare Software entstehen lässt, deren Wert im Laufe des Prozesses ständig gesteigert wird. Entspricht etwas nicht dem Wunsch des Kunden, kann es rechtzeitig erkannt und korrigiert werden.

Scrum ist im Kern simpel, denn es definiert nur wenige Rollen und Meetings. Der organisatorische Überhang bleibt dadurch gering. Der Prozess selbst ist technologieneutral und kann nicht nur für die Softwareentwicklung eingesetzt werden. Er lässt sich gut mit anderen agilen Techniken wie Pair Programming oder Test-driven Development kombinieren.

Abbildung 2.1: Überblick über den Scrum-Prozess

Der Ablauf ist in Abbildung 2.1 schematisch dargestellt. Alle Anforderungen werden im Backlog des Produkts verwaltet. Von dort aus werden die am höchsten priorisierten Aufgaben in einem Backlog für einen Sprint ausgewählt, der somit eine Teilmenge des gesamten Backlogs darstellt. Die endgültige Entscheidung darüber, wie viele Einträge für einen Sprint ausgewählt werden, trifft das Team. Ein Sprint ist ein kurzer, konstanter Zeitabschnitt. In der Regel wählt man Zeiträume zwischen einer Woche - extrem sportlich - bis zu einem Monat – moderat. Längere Zeiträume sind nicht zu empfehlen, da sich das Team sonst zu lange einkapselt und am Ende des Zeitraums wieder hohe Änderungsaufwände riskiert. Im Lauf des Sprints trifft sich das Team täglich zu kurzen Statusmeetings, in denen der Fortschritt und akute Probleme angesprochen werden. Neue Anforderungen, die während des Sprints erkannt werden, sollen im Product Backlog gesammelt werden, sie werden nicht im laufenden Sprint bearbeitet. Nur so kann gewährleistet werden, dass das Team die zuvor gesteckten Ziele erreichen kann – schließlich wird es am Ende des Sprints daran gemessen und für nicht umgesetzte Punkte verantwortlich gemacht. Es gilt die Annahme, dass die Punkte, die das Team für einen Sprint auswählt, auch erledigt werden. Am Ende des Sprints wird zu den erledigten Punkten ein Feedback des Kunden eingeholt. Auf diese Weise wird sofort festgestellt, welche Punkte erledigt sind und bei welchen Punkten noch Arbeit erforderlich ist. In jedem Fall sieht der Kunde einen Fortschritt, denn am Ende des Sprints soll immer eine fertige, installierbare Software stehen, die einen höheren Nutzen hat als die im Sprint davor. Neue Punkte werden wieder im