Wie Volatilität hilft, Probleme in der Entwicklung frühzeitig zu erkennen

Wenn sich Anforderungen ändern, so kann dies große Probleme verursachen. Daher sollte „darauf geachtet werden“. Doch das ist leichter gesagt als getan. Schließlich reden wir nicht nur von Kundenanforderungen sondern auch solchen im Design oder der Architektur.

Diese potentiellen Probleme können frühzeitig erkannt (und gebannt) werden, wenn wir die Volatilität von Anforderungen während der Entwicklung überwachen. Dies ist eines der Muster, das ich auf meinem ReConf-Vortrag vorstellen werde.

Ziel

Ziel dieses Musters ist es, frühzeitig zu erkennen, ob Änderungen im Projekt zu Problemen führen können, um dann proaktiv einzugreifen.

Motivation

Auch wenn wir Änderungen am liebsten verbieten würden, werden wir häufiger denn je damit konfrontiert. Dabei sind Änderungen von Kundenanforderungen noch am einfachsten zu handhaben. Schließlich gibt es jemanden (der Kunde), der die Änderung explizit anspricht.

Schwieriger sind Änderungen, die in der Entwicklungskette entstehen, sei es durch einen anderen Lösungsansatz, eine neue Technologie oder gar eine Änderung der Architektur. Wenn sie nicht drastisch sind, dann werden kleinere Änderungen gar nicht explizit angesprochen, können aber dennoch einen langen Rattenschwanz hinter sich herziehen.

Das Gute ist, dass der Grad von Änderungen gemessen werden kann. Dies wird als Volatilität bezeichnet und kann automatisiert generiert werden. Gerade in großen Teams ist dies wichtig, denn der Einzelne erkennt oft nicht, dass das Maß an Änderungen eine kritische Schwelle überschreitet. Falls über die Volatilität so eine Situation erkannt wird, können die Beteiligten darauf aufmerksam gemacht werden, zum Beispiel um sich frühzeitig auf Schnittstellen zu einigen, um die Auswirkungen der Änderungen einzudämmen.

Definition Volatilität: Anzahl der geänderten Elemente im Verhältnis zur Gesamtzahl der Elemente, pro Zeiteinheit.

Die konkrete Berechnung wird weiter unten (Struktur) beschrieben.

Anwendungsbereiche

Um die Volatilität sinnvoll einzusetzen, müssen:

• Elemente sinnvoll gruppiert werden können (Es macht wenig Sinn, Volatilität eines Word-Dokuments zu messen)
• Relevante Änderungen erfasst werden können (bspw. sollte die Änderung von „Complete“ zu „Approved“ nicht berücksichtigt werden)
• Die Auswertung automatisiert und regelmäßig erfolgen.

Struktur

Um die Volatilität erfassen zu können, wird ein Werkzeug benötigt, welches das atomare Arbeiten mit einzelnen Elementen ermöglicht. Das wäre bspw. Jama, wenn es um Anforderungen geht, oder Jira, wenn es um User Stories geht. Mit Vorbehalt ist der Einsatz auch mit nichtatomaren Elementen möglich, bspw. Zeilen Code in der Softwareentwicklung.

Weiterhin muss eine Analyse über die Zeit möglich sein. In der Praxis hat sich ein 24-Stunden-Zyklus bewährt.

Zuletzt müssen in diesem Zeitraum relevante Änderungen erfasst werden. Dies sind in der Regel Hinzufügungen, Löschungen und Bearbeitungen. Beim Bearbeiten sollte qualifiziert werden, welche Attribute für die Volatilität relevant sind: Das ist sicherlich der beschreibende Text, aber nicht unbedingt Status oder Priorität.

Mit dieser Information kann die Volatilität berechnet werden als:

Diese sollte zur Analyse auf eine Zeitachse aufgetragen werden, um dann regelmäßig (bspw. wöchentlich) die Entwicklung zu verfolgen.

Auswirkungen

Neue Projekte haben typischerweise eine hohe Volatilität, da im Anfangsstadium der Entwicklung viele Elemente hinzugefügt und bearbeitet werden. Im Laufe der Entwicklung sollte die Volatilität dann aber absinken. Kurz vor Fertigstellung, oder direkt nach Reviews bilden sich üblicherweise auch kleine Spitzen, und nach Auslieferung flacht die Kurve ab. Eine „gesunde“ Volatilität könnte so aussehen:

Hier sehen wir, wie die Anzahl der Anforderungen (grau) anfangs schnell steigt, und sich dann stabilisiert. Die Kurven in rot/orange/gelb zeigen die Anzahl der Änderungen, Hinzufügungen und Löschungen. Daraus leitet sich die Volatilität in blau ab.

Im Gegenzug dazu, hier ein Bild einer „ungesunden“ Volatilität:

Implementierung

Um Volatilität messen zu können, müssen atomare Anforderungen verwaltet und relevante Änderungen erkannt werden können. Das ist grundsätzlich bei jedem anspruchsvollen Anforderungswerkzeug wie Jama oder DOORS der Fall.

Die Volatilitätsdaten müssen dann wie oben gezeigt in einem Graph ausgewertet werden. Es gibt Werkeuge, die das Können. Die gezeigten Graphen zeigen die Volatilität von Anforderungen in Jama Connect, ausgewertet in Jama Analyze.

Wichtig ist es, die korrekten Gruppen zu erfassen. So sollten User Need, Systemanforderungen und Designelemente separat pro Projekt erfasst werden.

Photo by Leio McLaren (@leiomclaren) on Unsplash
Graph images by Jama Software