Seite 2: Velocity, Qualität

Inhaltsverzeichnis

Velocity – schnell, schneller, am schnellsten

Eine wichtige Aufgabe agiler Teams ist es vorherzusehen, wann eine bestimmte Funktion fertig und zur Auslieferung bereit ist. Bei der Velocity (Geschwindigkeit) geht es darum zu beobachten, wie viele Aufgaben innerhalb eines Zeitintervalls erledigt werden. Das Entwicklungsteam soll mit der Zeit ein besseres Gespür dafür entwickeln, welche Arbeit es in einer Iteration umsetzen kann. Damit sich die Velocity sinnvoll berechnen lässt, sind Aufgaben zu schätzen. Wie im klassischen Projektmanagement schätzen manche Teams Aufwand in Stunden und Minuten, andere verwenden lieber eine abstrakte Einheit, die die Größe und Komplexität einer Aufgabe widerspiegelt (z. B. Story Points).

Damit sich die Entwicklung der Velocity über die Zeit sinnvoll verfolgen lässt, muss sie in gleichbleibenden Intervallen betrachtet werden. Deren Länge ist individuell für jedes Team und entspricht bei Scrum normalerweise der Länge eines Sprints. Am Ende einer Iteration werden die erledigten Aufgaben betrachtet, über ihren Wert die Velocity ermittelt und diese festgehalten. So ergibt sich mit der Zeit ein Bild über die Entwicklung der Team-Performance. Tools für das Tracking agiler Projekte bieten in der Regel die Mittel, die Velocity automatisch zu ermitteln und anzuzeigen.

Die Velocity lässt große Freiheiten bei der Interpretation der Ergebnisse und gibt dem Team die Möglichkeit, die Ergebnisse zu beeinflussen. So wird die Velocity größer, wenn sich die Team-Performance steigert. Sie kann aber auch steigen, wenn die Teams ihre Aufgaben vorsichtiger schätzen. Deshalb eignet sie sich keinesfalls als Key Performance Indicator, den ein Team erreichen (oder gar steigern) soll. Das führt in der Regel im Laufe der Zeit zu konservativeren Schätzungen, um eine Verbesserung der Ergebnisse zu erreichen.

Generell steigt der Wert der erfassten Velocity mit der Kontinuität, mit der sie ermittelt wird. In der ersten Woche bietet der Wert noch wenig Nutzen. Erst wenn man die Entwicklung über einen größeren Zeitraum betrachtet, lässt sich ein Nutzen aus der Velocity ziehen. Man sollte den Wert aber nicht für sich stehen lassen. Bei stark schwankender Velocity ist die Kommunikation mit dem Team wichtig, damit man die richtigen Schlussfolgerungen über die Ursache dieser Veränderung zieht.

Quality delivered to Customer – auf das Ergebnis kommt es an

Softwaresysteme müssen eine hohe Qualität aufweisen. Aus technischer Sicht sind das beispielsweise eine ordentliche Architektur oder funktionierende Builds und Deployments. Kunden jedoch kommt es in der Regel darauf an, dass sie eine gut funktionierende und verlässliche Software erhalten. Beide Seiten der Medaille ergänzen sich: Eine hohe innere Qualität macht eine hohe Produktqualität wahrscheinlicher. Deshalb beantwortet eine wichtige Metrik in agilen Projekten die Frage, wie viel Qualität (= hochwertige Funktionen) tatsächlich beim Kunden ankommt.

Für diese Metrik gibt es keine allgemein gültige Form der Erfassung, vielmehr ist hier im jeweiligen Produktkontext zu entscheiden, wie sich ausgelieferte (und auch durch die Anwender genutzte) Funktionen pro Zeitraum ermitteln lassen. Dabei stellen sich zwei Fragen:

1. Wie findet man heraus, welche Features genutzt werden?
2. Für welche Intervalle erfasst man die Daten?

Die Antwort auf die erste Frage lässt sich auf verschiedene Arten ermitteln:

• Umfragen bei Anwendern und Kunden
• automatisiert erfolgende Erfassung direkt im Produkt (z. B. Tracking von Nutzerinteraktion in Webanwendungen)
• Aufzeichnung von Nutzerinteraktion mit unterschiedlichen Nutzergruppen unter Laborbedingungen

Bei der zweiten Frage kommt es darauf an, in welchen Intervallen das System an die Nutzer ausgeliefert wird. Bei einer Webanwendung, die im Continuous-Delivery-Verfahren entsteht, lässt sich in kürzeren Zyklen messen als bei einer Embedded-Anwendung, die auf einer Maschine in einer Fabrik installiert wird. Es gilt jedoch: Je öfter sich messen lässt, desto schneller lassen sich die ermittelten Zahlen als Feedback für die weitere Entwicklung nutzen.

Im Optimalfall kann das Entwicklungsteam die Ergebnisse des Feedbacks direkt in seine weitere Entwicklungsarbeit einfließen lassen. So sollte das Backlog anhand der Ergebnisse in Bezug auf die funktionalen und nichtfunktionalen Anforderungen angepasst und optimiert werden. Das Beste ist, absehbar nicht genutzte Funktionen gar nicht erst umzusetzen. Ganz im Sinne des agilen Manifests:

Einfachheit – die Kunst, die Menge nicht getaner Arbeit zu maximieren – ist essenziell.

Diese Metrik ist kundenorientiert, deshalb erfassen sie in der Regel Personen im agilen Team, die nahe am Kunden sind. Das ist in Scrum im Normalfall der Product Owner. Beim automatisierten Erfassen direkt im Produkt schafft das Entwicklungsteam die technischen Möglichkeiten und den Umfang der Erfassung. Das gesamte Team hat allerdings ein großes Interesse an dieser wichtigen Metrik und sollte deshalb am Optimieren der Erfassung und Aufbereitung mitarbeiten.

Obwohl diese Metrik im Vergleich zu den zwei bisher vorgestellten aufwendig und teilweise schwierig zu erfassen und bewerten ist, ist sie für die Optimierung des Produkts außerordentlich wichtig und wertvoll. Das gesamte Team sollte sich deshalb die Zeit nehmen, um die Voraussetzungen zum Ermitteln und Auswerten der benötigten Informationen zu schaffen.