Projektplanung und -überwachung mit dem Team Foundation Server, Teil 1: TFS-Grundlagen

Infopulse führt die Artikelreihe zu den Scrum- und Agile-Methoden fort. Sie konnten bereits unsere Erfolgsgeschichte lesen, die die Vorteile der Verwendung von Scrum in einem Festpreis-Projekt beschreibt. Im nachfolgenden Artikel zeigen wir Ihnen, wie Sie agile Softwareentwicklung meistern können.

Unabhängig von den Methoden der Softwareentwicklung und Ihrer Rolle (ob Entwickler, Manager oder Kunde) ist es wichtig, das Projekt im Griff zu haben. Es gibt viele Plattformen für die ordnungsgemäße Organisation und Überwachung der Aufgaben. Entdecken Sie unsere Einblicke in den Team Foundation Server (TFS) – die Microsoft-Plattform und Ihre perfekte Wahl für agile Projekte.

TFS als Lösung für die Verwaltung des Entwicklungslebenszyklus

Der Team Foundation Server (TFS) ist ein von der Microsoft Corporation entwickeltes Produkt zum Application Lifecycle Management (ALM). Es bietet klare und einfach zu bedienende Werkzeuge für die Planung und Überwachung von einzelnen Projekten an, sodass der TFS zur perfekten Wahl sowohl für die agile Softwareentwicklung als auch für  Wasserfall-Teams wird.

Organisation der Anforderungen im TFS

Alle Projekte beginnen mit der Planung, d.h. mit der Festlegung der Anforderungen und Einschränkungen, wie die Projektdauer und Ressourcenverfügbarkeit, und enden mit der Release-Phase und dem Reporting. Gleichzeitig kann der Ablauf der Projektentwicklung abweichen, da er meistens von der Methodenspezifik und der Umsetzungsart entsprechend der Hauptprojektanforderungen abhängt. So ist z.B. eines der Hauptmerkmale von Scrum das Product Backlog, das alle künftigen Arbeiten, die während des gesamten Projekts durchgeführt werden sollen, umreißt.

Das Produkt-Backlog ist eine Roadmap und der Speicher  für alle Kundenanforderungen, -erwartungen und Prioritäten, die in Form von User Stories angezeigt werden. Jede „Benutzergeschichte“ enthält einen Teil der Anforderungen, die unabhängig von den anderen umgesetzt werden können. Da einige Projekte bis zu 2000 User Stories enthalten können, werden alle Aufgaben im „Anforderungsbaum“ dargestellt, um die Managementprozesse zu vereinfachen.

Der TFS-Anforderungsbaum besteht aus Releases, Epics, Features und Product Backlog Items (Stories).

Abbildung 1: Der TFS-Anforderungsbaum.

Auf der Abbildung 1 ist ein normales Backlog dargestellt, das eine Anzahl an Features enthält, die einen Teil der Epics bilden. Jeder Baum-Bestandteil kann einen Wert im Business-Value-Feld haben, der seine relative Bedeutung im Rahmen des gesamten Projekts anzeigt. Da Kundenvertreter mit verschiedenen Zugriffsberechtigungen am Projekt teilnehmen, beeinflussen sie häufig das Feld der Geschäftswerte. Die Baumstruktur optimiert die Anforderungssuche und die Aktualisierungen, sodass es möglich ist, die Prioritätsstufe der spezifischen Anforderungen festzulegen und den Projektumfang auf verschiedenen Ebenen darzustellen. So kann der Kunde die aktuellen Berichte prüfen, der Supervisor kann die Features sehen, die sich derzeit in der Pipeline befinden, und der Leiter kann den Status der Kalkulation verfolgen.

In der Planungsphase kann ein Projekt eine Reihe von Releases, Features und Epics enthalten, die je nach den Geschäftsprioritäten flexibel verschoben werden können, unter Berücksichtigung der verfügbaren Ressourcen und des Aufwands, der zur Erfüllung der Anforderungen notwendig ist. Da die Releases, Features und Epics die Anforderungen verallgemeinern, um sie auf verschiedenen Ebenen und mit verschiedenen Details darzustellen, ist die User Story eine unteilbare, für die Teamarbeit verfügbare Einheit.

Die Anforderungen der User Story bilden den Kriteriensatz, nach denen Ihr Team den Arbeitsumfang, die Fristen, die Komplexität und die Interaktionen abschätzen kann. Bitte beachten Sie, dass die Verfeinerung der Spezifikationsanforderungen und der Erwartungsbeschreibungen immer viel Zeit erfordert. Die gängige Praxis ist, mit dem Schreiben der Spezifikationen im Feld Akzeptanzkriterien zu beginnen, sobald das Entwicklungsteam ein klares Verständnis von einer User Story hat. Dies impliziert, dass das Team Folgendes besitzen muss: Erfahrung bei der Umsetzung ähnlicher Szenarien, Berechtigung zur unabhängigen Umsetzung der Entscheidungen und die Fähigkeit,  adäquate Einschätzungen der Projektkomplexität vorzunehmen. Das heißt, dass das Team mit den Begriffen und Definitionen der Kriterien bereits vertraut ist und weiß, woher es die Daten bekommen kann und wo es nicht notwendig ist, mehr Zeit mit der Dokumentation zu verbringen.

Abbildung 2: Beispiel für eine User Story

In unserem nächsten Artikel werden wir über die Projektplanung und -überwachung mit dem Team Foundation Server weiter schreiben. Bleiben Sie dran, um mehr darüber zu erfahren, wie Sie mit dem TFS arbeiten können!