Brauchen agile Projekte überhaupt Requirements Engineering?


Ueli Hartmann, Senior Consultant

Keine agile Methode kennt die Funktion des Requirements Engineers. Der Schluss liegt also nahe, dass es Requirements Engineering in agilen Projekten überhaupt nicht braucht!

Kürzlich war ich in einem Projekt, wo es darum ging, ein in die Jahre gekommenes Altsystem durch eine Neuentwicklung abzulösen. Das Entwicklungsteam arbeitete nach Scrum. Alle Scrumzeremonien wurden durchgeführt. Dem Product Owner stand ein Businessanalystenteam zur Seite, welches die User Stories im Backlog kontinuierlich verfeinerte. Mit Continuous Deployment stand jederzeit eine lauffähige Software zur Verfügung. Die nachhaltige Dokumentation wurde in Enterprise Architect geführt. Ein Vorzeigeprojekt, alles paletti! Oder?

Embrace the Change – zu jedem Preis

Nachdem die Architekturfragen geklärt waren und ein Prototyp für gut befunden wurde, startete die Entwicklung. Die Anforderungen wurden „just in time“ erhoben und spezifiziert und in den User Stories dokumentiert. Die Quelle der Anforderungen war im Wesentlichen das Altsystem. In Laufe der Entwicklung stellten sich aber immer wieder neue fachliche Fragen zur Sinnhaftigkeit der Implementation im Altsystem und zur Datenmigration. Aus einer 1:1 Ablösung des Altsystems wurde eine Neuentwicklung, mit vielen Verbesserungen und Anpassungen, was zu vielen Änderungen im Projekt führte. Die Änderungen wurden im Backlog erfasst, priorisiert und abgearbeitet, ganz nach dem agilen Motto: „Embrace the Change!“.

Durch die vielen Änderungen wurde die Applikation gefühlt drei Mal entwickelt. Die Kosten vervielfachten sich und das Ende war plötzlich nicht mehr in Sicht. Der Auftraggeber wurde langsam ungehalten. Der Druck auf das Projekt stieg. Der Ton wurde gehässig und das Finger Pointing begann. Die Entwickler waren frustriert, weil sie zum x-ten Mal den Code für die gleiche Sache ändern mussten. Die „Technical Debt“ stieg ständig und plötzlich kamen Zweifel auf, ob das Projekt überhaupt erfolgreich abgeschlossen werden könne. Kurz gesagt: Es war nicht lustig.

Agile Requirements Engineering – Wer ist der Reiseleiter?

Ich bin der Meinung, dass die wichtigste Aufgabe der Business Analysis / Requirements Engineerings darin besteht, stabile Geschäftsanforderungen zu liefern. Stabile Anforderungen kann man formulieren, wenn alle Stakeholder eine Vision teilen, sich auf gemeinsame Ziele verständigen und die Geschäftsanforderungen abgestimmt sind. Diesen Zustand herbeizuführen, ist Kunst und Leistung des Requirements Engineers – der Rest ist Fleissarbeit.

Im beschriebenen – durchaus typischen Projekt – fehlten die stabilen Geschäftsanforderungen. Auch fehlte eine Vision. Das Ziel, das Altsystem abzulösen, taugt dazu nicht. Die Auswirkungen waren für alle Beteiligten unangenehm und belastend. Am Ende spielt es keine Rolle, ob man agil oder nach Wasserfall entwickelt, bevor man mit der Implementierung beginnt, muss klar sein, wohin die Reise geht.

Auch agile Projekte können scheitern

Es ist die Stärke von agilen Methoden, schnell auf Änderungen im Umfeld zu reagieren und konstant mit den Stakeholdern zu überprüfen, ob der eingeschlagene Weg noch stimmt. Agile Projekte können also per se sehr gut mit Änderungen umgehen. Wenn aber die Anzahl der Änderungen überhandnimmt, gefährdet dies den Projekterfolg.

Der Trends & Benchmark Report Schweiz „Software Development 2017“ zeigt, dass agile Projekte mit einer Erfolgsquote von 64,2% leicht besser abschneiden gegenüber konventionellen Projekten mit 58,6%. Das bedeutet aber auch, dass immer noch eine Drittel aller agilen Projekte nicht erfolgreich (nicht in Zeit, nicht in Scope, nicht in Budget) abgeschlossen werden oder gar scheitern!

Agile Software Requirements und Projekterfolg in der Schweiz

Agile Software Requirements und Projekterfolg in der Schweiz

Trends & Benchmark Report

Requirements Engineering ist eine Aufgabe des Product Management

Die Wichtigkeit der Business Analyse ist also offensichtlich. Wieso kennen dann agile Vorgehensmodelle die Disziplin Requirements Engineering nicht? Agile Vorgehensmodelle haben den Ursprung und den Fokus auf der Softwareentwicklung. Es ist nicht Aufgabe der Softwareentwicklung Vision, Strategie und stabile Geschäftsanforderung zu erarbeiten. Dies wird von der Entwicklung als Input vom Auftraggeber erwartet. Dieser Input muss erstellt werden, bevor mit der Softwareentwicklung begonnen wird. Diese Abgrenzung zeigt, dass Requirements Engineering als Funktion des Auftraggebers zu verstehen ist. Bei Produktentwicklungen ist, in der Regel, das Product Management dafür verantwortlich, abgestimmte Geschäftsanforderungen zu liefern. Bei internen Vorhaben ist aber meist nicht so klar, wer dafür die Verantwortung trägt. Oft übernimmt eine Person die Aufgaben des Product Managers und Product Owners in Personalunion. Weder im Product Management, noch in den agilen Vorgehensmethoden ist Requirements Engineering als Aufgabe explizit beschrieben. Daher hängt viel davon ab, wie die Rollen in der Organisation interpretiert werden und ob diese überhaupt existieren.

Tipp: Requirements Engineering frühzeitig einsetzen!

Achten Sie darauf, dass gleich zu Beginn ihres nächsten Projektvorhabens geklärt wird, wer für die Business Analyse und das Requirements Engineering zuständig ist. An dieser Stelle geht es weniger darum, genau zu definieren, wer, was, wann, wie liefert. Es geht vielmehr darum, sicherzustellen, dass Requirements Engineering bewusst stattfindet, bevor die Entwickler mitten in der Umsetzung sind. Ansonsten verkommt Requirements Engineering zur reinen Symptombekämpfung.

Investieren Sie also vorab in das Agile Requirements Engineering für ihr Vorhaben, es lohnt sich!

 

5 thoughts on “Brauchen agile Projekte überhaupt Requirements Engineering?”


  • oemer.dursun@axonivy.com' Ömer Dursun sagt:

    Die Projektorganisation setzt sich aus diversen Parteien – von Auftraggeber, Stakeholder bis zum (Produkt-)Lieferant zusammen. Unabhängig davon, welcher Partei den RE zur Verfügung stellt, muss das Projekt einen verantwortlichen RE sicherstellen. Auf der anderer Seite muss ein Business Analyst die Anforderungen gemäss Scope verizifieren und an PO übergeben. Aus meiner Sicht müssen die POs die Spezifikationen des REs verstehen und abnehmen können, um ihre User Stories zu erstellen. Deshalb ist es wichtig, dass POs einige Fähigkeiten des REs besitzen. Wohin auch der Wandel geht, die Aufgabe eines REs bleibt bestehen.

    Danke für den Erfahrungsaustausch!

  • max.muster@web.de' Maximilian Mustermann sagt:

    Requirements Engineer – Business Analyst – Product Owner – Product Manager: alles nur eine Frage der Terminologie. Wenn mann die Rolle richtig lebt, nach gesundem Menschenverstand handelt und mit Herzblut dabei ist, dann ergibt es sich von selbst, dass die Vision und die strategische Entwicklung des Produkts Teil vom Ganzen sind.
    Wenn man dagegen strickt nach dem Motto „it’s not in my job description“ handelt – dann ja, hat man ein Problem, und irgendwann ist es nicht mehr lustig. Aber das hat mit den Personen und deren Einstellung zu tun – weniger mit der Problematik „braucht es RE im Agile“.

    • joe.scherler@srf.ch' Joe Scherler sagt:

      Ich bin zur Zeit daran, für einen Teil der Scrum Teams Requirement Engineers zu suchen und das Thema RE zu explizieren. Im einen Team wird dazu eine Person gesucht, die explizit und dediziert diese Rolle übernehmen soll. In den anderen Teams ist die Idee, dass bestehende Teammitglieder ihren Aufgabenbereich erweitern möchten und dafür explizit die Zeit für ihre anderen Rollen herunterfahren. Ich bin der Meinung, dass es nicht nur eine Frage der Terminologie ist, sondern viel eher eine der bewussten Einnahme einer Rolle in bestimmten Situationen.
      Rollenverständnis vs. Jobdescription also.

      • Ueli Hartmann sagt:

        Ich sehe RE/BA je länger je mehr als ein Funktion oder Disziplin. Wie ihr Beispiel zeigt, lässt sich die Disziplin schlecht über die in den Unternehmen etablierten Rollen definieren. Wichtig ist, dass man sich bewusst überlegt, „wo“ und von „wem“ die Disziplin angewendet, rsp. ausgeführt wird.

  • m.a.vanderhaas@gmail.com' Marc sagt:

    Alter Wein in neuen Schläuchen.
    Wenn kein richtiges Stakeholdermanagement betrieben wird, die Systemanalyse nicht konsquent durchgeführt wird, kommt raus wie obern beschrieben. IMHO egal ob agiles Projekt oder nicht.

Schreibe einen Kommentar