agiles anforderungsmanagement

Requirements Engineering in der agilen Softwareentwicklung

Braucht es Anforderungsmanagement im agilen Umfeld überhaupt noch?

Wie Albert Einstein früher schon sagte: „Das Problem zu erkennen ist wichtiger als die Lösung zu erkennen, denn die genaue Darstellung des Problems führt zur Lösung.“ Dieses Zitat hat auch im Zeitalter des agilen Projektmanagements und der agilen Anforderungsspezifikation seine Gültigkeit nicht verloren und ist nach wie vor von großer Bedeutung.

Im Gegensatz zu diesem Ansatz verfolgt das „Agile Manifesto“ die Ansicht, dass funktionierende Software wichtiger als eine ausführliche Dokumentation ist; die Reaktion auf Veränderungen wichtiger als das Befolgen eines Plans; die Kommunikation wichtiger als Prozesse, Verträge und Werkzeuge ist.

In diesem Beitrag möchten wir euch einen Überblick über das Wasserfall vs. Agile Projektmanagement geben. Welcher Ansatz ist der Richtige und braucht es Anforderungsmanagement – „Requirements Engineering“ im agilen Umfeld überhaupt noch?

 

Agiles Projektmanagement

Aber zuerst klären wir den Begriff des agilen Projektmanagements auf. Alles begann mit der so genannten “Krise der Anwendungsentwicklung” in den frühen 1990er Jahren. Damals gab es eine Zeitspanne von etwa drei Jahren zwischen dem Bedarf eines Unternehmens an einer Software und ihrer tatsächlichen Bereitstellung. 

Diese langen Projektvorlaufzeiten führten zur Frustration bei Softwareentwickler*innen, deshalb begannen sie nach einem Weg zu suchen, um die Softwarelösungen einfacher und effektiver zu entwickeln. Das Ergebnis war das “Agile Manifesto” das die Art und Weise wie wir heute Projekte managen, verändert hat.

Im Kern des agilen Projektmanagements steckt das Wort “Agilität”, das “Beweglichkeit, Flinkheit” bedeutet und aus dem Lateinischen “agere” stammt: “tun, handeln”. Damit ist die Fähigkeit gemeint, etwas schnell voranzubringen, so dass man leicht die Richtung wechseln kann.

In Bezug auf das Projektmanagement hat “Agilität” also fünf wesentliche Eigenschaften, die die Bausteine des agilen Prozesses bilden:

  • Transparenz
  • Kundenorientierung
  • Anpassungsfähigkeit
  • Eigenverantwortung (wirksame Führung)
  • Kontinuierliche Verbesserung

Der Grundgedanke hinter jedem agilen Entwicklungsprozess ist, dass er iterativ1 oder zyklisch ist, was bedeutet, dass die Implementierung der Software schrittweise erfolgt. Es gibt heute eine Reihe verschiedener iterativer Ansätze, z.B. Scrum, Kanban, RUP, Extreme Programming, Rapid Application Development, usw.

 

agiles anforderungsmanagement

Agiles Modell

 

Anforderungsmanagement: Wasserfall- oder agiles Modell

Die traditionelle Denkweise bei der Entwicklung von Software ist in der Regel das so genannte Wasserfallmodell. Beim Wasserfallmodell sollte ein Projekt erst dann von einer Phase zur nächsten übergehen, wenn die vorangegangene Phase vollständig abgeschlossen und perfektioniert ist. Es ist nicht möglich, zu einer früher abgeschlossenen Phase zurückzuspringen. Diese Methodik im Vergleich mit dem agilen Ansatz ist recht starr und ermöglicht keine flexiblen Änderungen. Das kann dazu führen, dass zu Beginn der Projektplanung falsche Anforderungen erhoben werden.

Anforderungen sind Erwartungen der Beteiligten und Kund*innen, die angeben, wie sich die Software verhalten soll. Sie beschreiben die Eigenschaften und Merkmale des gewünschten Softwaresystems. Daher bieten Anforderungen sowohl Richtlinien als auch Einschränkungen für die Softwareentwicklung.

Der Anforderungsmanagement-Prozess besteht aus einer Reihe von Aktivitäten, die darauf abzielen, die Wünsche der Kund*innen zu verstehen und zu ermitteln, mit Anforderungskonflikten und -änderungen umzugehen und die Erwartungen der Interessengruppen in Spezifikationen zu verfeinern, die von den Softwareentwicklern umgesetzt werden können:

  • Erkundung: Identifizieren und Sammeln von Informationsquellen über das Softwaresystem.
  • Analyse: Verstehen der Anforderungen der Kunden, einschließlich Überschneidungen und Herausforderungen.
  • Validierung: Prüfen, ob die Anforderungen den Erwartungen der Beteiligten entsprechen.
  • Aushandeln: Anforderungskonflikte ausgleichen, um die Konsistenz zu erreichen.
  • Dokumentation: Dokumentieren der Anforderungen.
  • Verwaltung: Wenn Anforderungsänderungen auftreten, sollten sie sorgfältig verwaltet werden.

 

Der agile Geist im Anforderungsmanagement

Die meisten, wenn nicht alle agilen Methoden, erfordern die Nähe zwischen Benutzer*innen und Entwickler*innen. Dies hat unter anderem den Vorteil, dass die Kommunikation gefördert wird und somit der Bedarf an schriftlichen Anforderungen minimiert wird. Kurze Iterationen und kontinuierliches Feedback helfen beim Aufspüren von Missverständnissen, (unklaren Anforderungen) und erleichtern die Ausrichtung auf den tatsächlichen Bedarf. Konträr dazu erlaubt Wasserfall teilweise eine rigorose Entwicklung von Design, Code und Tests entsprechend „fixierter“ Anforderungen. Eine frühzeitige Entdeckung dieser Fehler hätte die Nacharbeit minimiert.

Bei Scrum oder Extreme Programming werden User Stories verwendet, um die Erwartungen der Benutzer*innen mit “good enough” Präzision zu erfassen. User Stories sind kurze Beschreibungen von Funktionen, die aus der Sicht des Benutzers erzählt werden. Der Schwerpunkt liegt darauf, warum und wie die Benutzer*innen mit der Software interagiert. Eine User Story ist im Wesentlichen eine Definition dessen, was die Software können sollte. In der Regel kann jedes Feedback oder jede Anfrage, die vom Unternehmen oder den Endbenutzer*innen kommt, als User Story geschrieben werden.

Wenn wir alle Vorteile der Agilität bewahren möchten, wollen wir nicht vorschreiben, dass ein vollständiger Satz an Anforderungen vorliegen muss, bevor wir die Entwicklung zulassen. So können zu jedem beliebigen Zeitpunkt, z. B. während der Demo eines Releases, neue Anforderungen entdeckt und bestehende Anforderungen geändert oder fallen gelassen werden. Tatsächlich kann es sogar das Ziel eines bestimmten Sprints sein, eine bestimmte Anforderung zu klären, akzeptable Werte zu bestimmen oder ihre Machbarkeit zu überprüfen.

 

Fazit

Es gibt nicht die eine richtige Antwort auf die Frage, wie man Software entwickelt. Obwohl viele Unternehmen zu agilen Methoden übergehen, sind sie wahrscheinlich immer noch auf Teams angewiesen, die nach dem Wasserfallprinzip arbeiten. In diesem Fall müssen Teams lernen, wie sie kommunizieren, koordinieren und das Projekt planen können. Letztendlich haben alle Teams das gemeinsame Ziel den Kunden*innen einen Mehrwert zu bieten. Die Zusammenarbeit und Kommunikation zwischen den Teams unabhängig von der Methodik ist der Schlüssel zum Erfolg.

Haben wir dein Interesse geweckt? Wenn du gerne mehr über die unterschiedlichen Projektmanagement-Ansätze erfahren möchtest, dann kontaktiere uns für ein kostenloses Beratungsgespräch.

 

1Sprint/Iteration – Ein begrenzter Zeitraum, in der Regel eine bis vier Wochen. Am Ende jedes Sprints/jeder Iteration wird ein Arbeitsprodukt geliefert.

Wir freuen uns auf ein Gespräch!

Jetzt kontaktieren

Kontaktformular

© 2022 Deloitte Consulting GmbH. All rights reserved.