Agiles Requirements Engineering – Gibt es das überhaupt?

Requirements Engineering ist Requirements Engineering – Punkt.

Und Requirements Engineering ist auch nicht viel schwieriger als über Wasser zu wandeln – zumindest, wenn beides eingefroren ist. Während aber Wasser in manchen Regionen gelegentlich tatsächlich eingefroren ist, gilt das für Anforderungen – entgegen anders lautender Behauptungen – nicht. Und hier kommt die Agilität ins Spiel. Menschen mit agiler Geisteshaltung können mit nicht-eingefrorenen Anforderungen umgehen, sie schätzen Veränderungen und neue Herausforderungen.

Wir erheben, dokumentieren, konsolidieren und stimmen Anforderungen ab, und das nach allen Regeln der Requirements Engineering – Kunst; und wir erwarten, dass am Ende etwas herauskommt, das genau diese Anforderungen erfüllt. Das ist nicht-agiles Requirements Engineering.

Wir erwarten, dass die Anforderungen, die am Anfang nach allen Regeln der Requirements Engineering – Kunst erhoben werden, nicht die Anforderungen sind, die am Ende implementiert werden. Das ist agiles Requirements Engineering.

Wir haben über Jahrzehnte schmerzhaft gelernt, dass Feedback basierend auf Anforderungsspezifikationen, auch wenn diese noch so sorgfältig nach allen Regeln der Requirements Engineering – Kunst erstellt werden, uns nicht davor bewahrt, Software zu liefern, die der Kunde so doch nicht haben will. Fast scheint es so, als hätten wir uns schon daran gewöhnt, dass wir unseren Kunden alle 6 Monate oder alle 12 Monate Software liefern, die diese gar nicht haben wollen. Bei agilem Vorgehen können wir unseren Kunden schon nach 2 Wochen Software liefern, die sie nicht haben wollen. Dann höhren wir unseren Kunden zu, nach allen Regeln der Requirements Engineering – Kunst, und liefern ihnen nach weiteren 2 Wochen Software, die sie dann doch haben wollen. Es ist übrigens bei agilem Vorgehen nicht verboten, die Anforderungen, die dann tatsächlich implementiert wurden, zu dokumentieren – auch wenn sie nicht mehr denen entsprechen, die ursprünglich geäußert wurden.

Egal, ob Sie nicht-agil oder agil vorgehen, professionelles Requirements Engineering bleibt die Basis für jegliche Entwicklung – das Handwerkszeug und die „Regeln der Kunst“ sind die gleichen. Wenn Sie wirklich agil sein wollen, müssen Sie bereit sind, früh und oft zu scheitern und es dann schnell richtig zu machen. Und ihr Kunde muss bereit sein, früh und oft Feedback zu geben auf Basis lauffähiger Software. Und mit oft meinen wir oft. Wenn Sie nicht fähig sind, spätestens alle 4 Wochen potentiell releasefähige Software zu liefern, sind Sie nicht agil – Punkt.

Requirements Engineering ist also Requirements Engineering, egal, welches Vorgehensmodell Sie anwenden. Die Methoden und Techniken sind immer anwendbar.

Und doch ist Agiles Requirements Engineering fundamental anders. Das liegt an den beiden Agilen Prinzipien:

Prinzip #1
Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Auslieferung wertvoller Software zufrieden zu stellen.

Prinzip #2
Heiße Anforderungsänderungen selbst spät in der Entwicklung willkommen. Agile Prozesse nutzen Veränderungen zum Wettbewerbsvorteil des Kunden.

Die eindeutige Fokussierung auf den Kundenwert und die Anerkennung, dass Anforderungen sich ändern, machen den Unterschied aus. Nicht-agiles Requirements Engineering ist rückwärtsgewandt, Entscheidungen werden auf Basis alter, überholten Anforderungen getroffen. Agiles Requirements Engineering ist vorwärtsgewandt, Entscheidungen werden auf Basis aktuellen Wissens getroffen, wohlwissend, dass in wenigen Wochen (schnelles Feedback) die Welt wieder anders aussehen kann. Entscheidungen, die schnell korrigiert werden können, müssen nicht von Anfang an richtig sein – keine Angst vor falschen Entscheidungen!

Uwe Valentini

Kontaktieren Sie Uwe Valentini

Uwe Valentini arbeitet bei Agile-by-HOOD als Berater und Coach mit viel persönlichem Engagement mit Menschen, Teams und Organisationen auf ihrem Weg zu mehr Agilität. Uwe ist leidenschaftlicher Agilist, er lernt jeden Tag etwas Neues und hat viel Spaß daran. Sein Motto: Agilität beginnt im Kopf.