Seite 3: Burndown Chart

Inhaltsverzeichnis

Burndown Chart – wie weit ist es denn noch?

Ein Burndown Chart erfasst die aktuell noch ausstehende Arbeit in einer Iteration. Anders als bei der Velocity wird hier nicht die erledigte, sondern die verbleibende Arbeit erfasst. Das visualisiert ein Diagramm, bei dem in der vertikalen Achse die Anzahl an Arbeit und in der horizontalen die Zeit verläuft (siehe Abb. 1).

Neben dem Sprint Burndown Chart über eine Iteration gibt es noch das sogenannte Release Burndown Chart und das Product Burndown Chart, die sich jeweils auf längere Zeiträume der Entwicklung beziehen.

Zu Beginn eines Zeitraums werden an der x-Achse die Dauer der Messung (z. B. in Tagen oder Sprints) und an der y-Achse die gesamte geplante Arbeit eingetragen. Danach lässt sich die Ideallinie vom Maximum bis zum Nullpunkt über die Laufzeit eintragen. Nach jedem Messzeitpunkt wird die verbleibende Arbeit im Diagramm eingezeichnet. Der Vergleich mit der Ideallinie zeigt, ob die Arbeiten im Plan liegen oder nicht. Tools für das Tracking agiler Projekte bieten in der Regel die Möglichkeit, ein Burndown Chart anzuzeigen.

Es ist ein Werkzeug vom Team für das Team und wird deshalb auch von Selbigem erfasst. Und es eignet sich gut, um frühzeitig zu erkennen, ob sich eine Iteration wie geplant entwickelt. Vergleicht man Daten aus mehreren Iterationen, kann man periodisch wiederkehrende Performanceengpässe, nachlassende Team-Performance und andere negative Einflüsse erkennen. Die Ursachen für Veränderungen am Burndown lassen sich aber nur durch genauere Analysen und direkte Kommunikation mit dem Team herausfinden.

Als Erweiterung zum Burndown Chart gibt es noch die Burndown Bar, die zusätzlich die Änderungen am Backlog darstellt. Dadurch wird deutlich, welche Auswirkungen es hat, wenn man Aufgaben zum Backlog hinzufügt.

Engineering Practices – hinter den Kulissen

Ein Großteil der in einem agilen Projekt von und für das Entwicklungsteam erfassten Metriken betreffen die Engineering Practices. Das sind bewährte Vorgehensweisen für Softwareentwickler, die die Qualität der erzeugten Systeme verbessern sollen. Auf diese Praktiken im Einzelnen einzugehen, würde zu weit gehen, sie sind jedoch zu wichtig, um sie nicht zu betrachten. Deshalb möchten die Autoren ein paar wichtige Beispiele aufführen, um den Leser zu weiterführenden Informationen zu leiten.

Die folgende Liste führt wichtige und häufig verwendete Praktiken auf:

• Collective Code Ownership: Der Quellcode gehört dem gesamten Entwicklungsteam, es gibt keine Wissensinseln, in denen nur bestimmte Spezialisten arbeiten dürfen.
• Peer Review: Entwickler führen Überprüfungen des Quellcodes ihrer Kollegen durch und sichern dadurch die Qualität nach dem Vier-Augen-Prinzip.
• Pair Programming: Quellcode wird in Zweierteams geschrieben, die sich gegenseitig kontinuierlich Feedback geben; beim Pair Programming ist die Peer Review gleich enthalten.
• (Acceptance) Test Driven Development: Aufgaben werden aus dem Blickwinkel der Testbarkeit angegangen, vor der Implementierung von Funktionen stehen die diese Features prüfenden Tests; diese schlagen zunächst per Definition fehl und werden durch die Implementierung erfolgreich (wichtiges Stichwort: red/green/refactor).
• Continuous Integration: kontinuierliche Integration von Quellcode auf zentralen Systemen, um Funktionen möglichst schnell im Gesamtsystem ausführen und testen zu können (weitere Themen: Continuous Deployment und Continuous Delivery).
• Refactoring: kontinuierliches Umstrukturieren von Quellcode, um wechselnden Anforderungen und Änderungen am Design Rechnung zu tragen; eine der Voraussetzungen für erfolgreiche agile Softwareentwicklung.
• Coding Standards: Regeln, wie Code im Team aufgebaut und strukturiert wird (Lektüreempfehlung ist hier Robert C. Martins "Clean Code").

Die Liste erhebt keinen Anspruch auf Vollständigkeit. Auch ist es schwierig, allgemein gültige Regeln aufzustellen, in welchem Umfang diese Praktiken eingesetzt werden sollen. Hier kommt es auf die Erfahrung des Teams und die Art des Projekts an. Jedes Team sollte bewusst für sich entscheiden, welche Regeln es in welcher Form nutzen will und die Verwendung regelmäßig auf den Prüfstand stellen. In Scrum bietet sich die Aufnahme der verwendeten Praktiken in die "Definition of Done" an, welche regelmäßig in der Sprint Retrospective hinterfragt und optimiert wird.

Für viele der genannten Praktiken gibt es Werkzeuge, die beim Einsatz unterstützen und die Arbeit damit vereinfachen. Das sind zum Beispiel Frameworks für die Implementierung und Ausführung von Tests jeder Art (Unit-, Akzeptanz- oder UI-Tests), Continuous-Integration-Server oder in die IDE eingebettete Hilfsmittel für das Refactoring oder die automatisierte Prüfung festgelegter Coding-Standards. Bei der Verwendung dieser Tools sollte jedoch immer beachtet werden, dass das Werkzeug dem Entwickler dienen soll und er nicht zum Sklaven des Tools werden darf.

Allen Praktiken gemein ist die Tatsache, dass sie vom Entwicklungsteam für das Entwicklungsteam vereinbart und eingehalten werden. Auftraggeber und fachliche Stakeholder geben zwar in der Regel vor, welchen Anspruch an Qualität und welche Vorgaben sie von fachlicher Seite haben. Die Art und Weise, wie diese Vorgaben erreicht werden, müssen die Spezialisten auf diesem Gebiet – das Entwicklungsteam – definieren. Deshalb ist es in der Regel auch keine gute Idee, die Performance oder Qualität eines Entwicklungsteams oder einer Software allein an Metriken festzumachen, die anhand der oben genannten Praktiken ermittelt wurden.

Beliebt ist die Vorgabe einer einzuhaltenden Code Coverage durch automatisierte Tests. Wird diese Vorgabe von außen ans Team gegeben, ohne dass dieses einen Vorteil für sich erkennt, ist die Folge in der Regel das stupide Automatisieren von Tests, die möglichst einfach viel Quellcode durchlaufen lassen. Das erhöht nicht die Qualität, sondern nur den Aufwand für die Pflege bestehenden Codes (und dessen Tests).

Die oben genannten Praktiken für agile Projekte sind äußerst wertvoll und sollten daher verwendet werden. Auch wenn ein Team zum Beispiel nicht testgetrieben ("test first") entwickelt, ist ein stabiles Korsett an Tests die Voraussetzung, um komfortabel und ohne Furcht neue Anforderungen umzusetzen, die auch Auswirkungen auf etwa das Design einer Anwendung haben. Es geht nicht darum, eine Vorgehensweise zu verwenden, "weil man das halt so macht", sondern darum, die Qualität der eigenen Arbeit durch den wohl überlegten Einsatz der richtigen Mittel zu erhöhen.