Agile / Anforderungsmanagement

Anforderungen messen – Erfolg ernten!

Wenn es in Projekten zu Problemen kommt, ist es relativ einfach, die Wurzel des Problems zu finden, nämlich dort wo alles anfängt – bei den Anforderungen wird man immer fündig.

Mètre ruban et monnaie d'euro

Anforderungen stellen stets die treibende Kraft in Software-Entwicklungsprojekten dar. Wenn also im Bereich der Anforderungsdokumentation etwas schiefläuft, kann das ganze Projekt gefährdet werden. Nun ist es trotzdem nicht so einfach, herauszufinden, woran es im Speziellen liegen könnte. Maßnahmen zur Verbesserung der Gesamtsituation im Projekt sollten ja stets auf fundierten Sachverhalten aufbauen. Daher müssen zuerst Messungen vorgenommen werden, um zumindest aus den Erfahrungen der nahen Vergangenheit lernen zu können.

Kennzahlen sollten immer eine zweifache Aussagekraft besitzen. Einerseits sollten sie als Performance Indikator für die beobachteten Artefakte dienen und damit eine Aussage über den Gesundheitszustand des Projektes ermöglichen. Andererseits sollte sich aus der Interpretation einiger weniger Kennzahlen ein konkreter Handlungsbedarf ableiten lassen. In der Fachliteratur werden oft Metriken für Anforderungen angeführt, die mit extrem hohem Aufwand Daten generieren, die es nicht unbedingt leichter machen, daraus Verbesserungspotentiale für den Anforderungsanalyseprozess abzuleiten.

Als Anforderungsmanager überlege ich mir für strategisch wichtige Projekte vorab, welche besonderen Fragestellungen durch Metriken beantwortet werden sollten. Diese Fragen lassen sich am besten aus den Zielen für das Requirements Engineering ableiten. Diese Ziele ergeben sich wiederum aus der Analyse der übergeordneten Projektziele. Aufgrund der sich für ein Projekt abzeichnenden wichtigen Herausforderungen kann der Bedarf an besonderen Messgrößen abgeleitet werden, um in diesem speziellen Fall gezielte Aussagen über den Zustand in der Anforderungsanalyse treffen können. Da manuelle Messungen in der Regel zu teuer sind, sollte auf bestehende Tools zurückgegriffen werden, um möglichst automatisiert Auswertungen zu bekommen. Im Zweifelsfall reicht ein einfaches Bug-Trackingtool, das individuelle Auswertungen ermöglicht, um hier möglichst ressourcenschonend vorzugehen.

 

Ein Szenario aus der Praxis

Ein Unternehmen hat das Problem, dass beim Review der Pflichtenhefte regelmäßig mehrere hundert zu behebende Mängel entdeckt werden. Das Pflichtenheft stellt die Basis für das Fixpreis-Angebot des mit der Umsetzung betrauten IT-Dienstleisters dar. Release-Termine können fast nie gehalten werden. Eine Unmenge an Change Requests belastet zusätzlich die Timeline und das Budget.

Ein naheliegendes Ziel in diesem Szenario könnte demnach eine Reduktion des Volumens an Change Requests auf maximal 20% des Umsetzungsvolumens beim nächsten Projekt sein. Daraus lassen sich folgende Fragenkomplexe ableiten:

  • Wie hoch ist die Fehlerrate in der Spezifikation?
  • Wie hoch ist die Fehlerrate während der Umsetzungsphase?
  • Wie stabil sind die Anforderungen?
  • Wie realistisch ist die Planung aus heutiger Sicht?

Aus der Erhebung von Änderungsrate und Volatilität lassen sich schon sehr viele Hinweise auf Prozess-Verbesserungen ableiten.

 

Änderungsrate bei Anforderungen

Zu berücksichtigen ist stets die Tatsache, dass mit steigendem Umfang der Spezifikation, der Grad der Vollständigkeit der Anforderungen sinkt. So kann man beispielsweise bei einer Spezifikation mit rund 100 Seiten von einer realistischen Vollständigkeit von 95% ausgehen. Bei einem Pflichtenheft mit 300 Seiten wird der Grad der Vollständigkeit auf an die 80% sinken. Dazu kommt die Tatsache, dass sich Anforderungen je nach Reifegrad der Projektkultur und Dynamik in der relevanten Projektumwelt zwischen 3 und 5% pro Monat verändern. Bei einem Umsetzungshorizont von 4 Monaten und einer durchschnittlichen Änderungsrate von 4% ergibt das einen Vollständigkeitsgrad in der Spezifikation von 79%. Wenn keine zusätzlichen Schwächen im Anforderungsanalyseprozess enthalten sind, kann demnach mit einem Change-Budget von 21% des Auftragsvolumens gerechnet werden. Bei Pflichtenheften mit 300 Seiten und einer durchschnittlichen Änderungsrate von 4% ergibt das einen Änderungsbudget-Bedarf von 36% des ursprünglichen Auftragsvolumens. Angesichts dieser Zahlen wird sehr rasch klar, dass jede Planung, die diesen Umstand ignoriert, im Laufe der Umsetzung ad absurdum geführt wird und erhöhter Erklärungsbedarf beim Projektmanagement entsteht.

umso größer das Pflichtenheft, desto größer das Änderungspotential

Abhängigkeit zwischen Größe des Pflichtenheftes und Änderungspotential

Wenn das sich abzeichnende Änderungsbudget inakzeptabel für das Management ist, sollte eigentlich vor Beginn der Umsetzungsphase ein Plan B zurecht gelegt werden, denn das Unvermeidliche wird kommen – ob es das Management wahrhaben möchte oder eben auch nicht. Eine Verbesserung der Qualität der Anforderungen ist eine mögliche Antwort auf hohe Volatilität bei Anforderungsdokumentationen. Auch die Größe der Projekte bzw. Iterationen bietet Spielraum für die Verbesserung der Gesamtsituation innerhalb eines größeren Projektes oder Programmes. Wenn die Änderungsrate trotz hohem Reifegrad in der Organisation auffällig hoch ist, könnte auch bei den Product Ownern angesetzt werden. Eine fehlende Produkt-Strategie oder unsauberes Stakeholder Management können sich ebenfalls in außergewöhnlich großen Mengen an Änderungswünschen manifestieren.

 

Fehlerrate bei Anforderungen

Interessant ist die Liste der während der Inspektion einer Anforderungsdokumentation gefundenen Mängel. Abhängig von der gewählten Methode stellt die Anzahl an Anforderungen, Use Cases, User Stories oder auch nur die Anzahl der Seiten einer Spezifikation die Grundmenge für die Beurteilung der Fehlerrate dar. Auch hier lässt sich ein gewisser Zusammenhang zwischen der Größe des geplanten Systems bzw. der Komplexität der Lösung und der Anzahl der gefundenen Mängel erkennen.

Erfahrungsgemäß sind Änderungen an Anforderungen stärker von Fehlern behaftet als Original-Anforderungen. Auch qualitätssichernde Maßnahmen sind bei Änderungsanforderungen, aber auch bei Delta-Anforderungen, nicht so effektiv wie bei ursprünglichen Anforderungen. Das liegt primär an der höheren Komplexität der impliziten und expliziten Abhängigkeiten zu bereits bestehenden Aspekten der Lösung. Fehler werden also primär erst in der Testphase bemerkt und deren Behebung ist dann entsprechend teuer.

Wenn in einer Spezifikation mit 70 Seiten während der Inspektion beispielsweise 300 Mängel, die zu einer Überarbeitung der Anforderungsdokumentation führen, identifiziert werden konnten, besteht definitiv Handlungsbedarf. Die Vermutung liegt nahe, dass bei der Erhebung der Anforderungen möglicherweise das Stakeholder Management zu kurz gekommen ist. Maßnahmen im Bereich der Anforderungserhebung, aber auch im Bereich der Abstimmung der Anforderungen könnten hier zu weitaus besser abgestimmten Anforderungsdokumentationen verhelfen.

 

Der Blick über den Tellerrand

Wenn die Anwendung von Inspektionen von Anforderungsdokumenten und der Einsatz von Prototypen nicht ausreichen, um eine höhere Qualität in die Software-Entwicklungsprojekte zu bringen, verspricht eine ganzheitliche Betrachtung der offensichtlichen Symptome mehr Erfolgsaussicht. Ganzheitliche Betrachtungen haben den Vorteil, dass nicht nur der Fokus rein auf den Anforderungsprozessen liegt, sondern auch die relevanten Umwelten untersucht werden. Meist ist das Zusammenarbeitsmodell in den einzelnen Projektphasen kritisch zu durchleuchten. In der täglichen Praxis zeigt sich immer wieder, dass eine Organisation bezüglich iterativem und inkrementellem Vorgehen noch nicht das geeignete Maß gefunden hat. Die Anwendung von agilen Praktiken könnte hier gezielt überlegt werden. Ein Schwenk vom klassischen Wasserfall-Modell mit Fixpreis zu einer agilen Vorgehensweise, wie sie etwa in SCRUM gelebt wird, ist oft zu radikal, speziell, wenn er in einem Schritt vollzogen wird. Mit Rücksicht auf etablierte „Kulturen“ ist auch bei strukturellen Veränderungen iterativ und inkrementell vorzugehen besser geeignet, um möglichst nachhaltig die Vorteile der Veränderung der Projekt-Kultur zu lukrieren.

 

Zusammenfassung:

Die Volatilität der Anforderungen darf in der Anfangsphase eines Softwareentwicklungsprojektes durchaus hoch sein. Sie sollte mit Projektfortschritt immer geringer werden, damit die weitere Entwicklung nicht negativ beeinflusst wird. Bleibt sie über die Zeit auf einem ähnlich hohen Niveau, so ist das ein Indiz dafür, dass entweder der Reifegrad speziell des Anforderungsanalyseprozesses zu steigern ist oder das gewählte Vorgehensmodell bzw. das Zusammenarbeitsmodell problematisch ist. Bei all den Überlegungen stellt sich stets die Frage: Wieviel „Agilität“ verträgt meine Organisation? Dies impliziert, dass es zwischen dem Wasserfall-Modell und etwa SCRUM sehr viel Spielraum für die Art und Weise, wie die einzelnen Rollen in einem Projekt miteinander interagieren. In der Beratungspraxis zeigt sich immer wieder, dass eine gesunde Mischung aus klassischen und agilen Praktiken mehr Erfolgspotential hat als die radikale Hinwendung zu agilen Praktiken.

 

Quellen:

Capers Jones, Olivier Bonsignour, The Economics of Software Quality, Boston 2012.

Passende Artikel

3 Kommentare

  1. Sehr interessanter Arikel Herr Braun! Werd ich mir in meiner Favoritenliste abspeichern! Hoffe auf mehr Artikel wie diesen ! 🙂 LG aus dem Ruhrpott! Tamara

  2. Hab ab 1. Januar ebenso eine Stelle neu angenommen im Bereich der Beratung von Softwareentwicklungsprojekten und finde ihren Beitrag wirklich sehr wertvoll. Vielen Dank dafür! Bei dieser Gelegenheit möchte ich natürlich nicht verabsäumen, auch die besten Wünsche für das neue Jahr 2017 zu übermitteln 

  3. wirklich wertvolle Tipps für jeden in der Anfangsphase eines Softwareentwicklungsprojektes steckt! 🙂