Meine Behauptung am Anfang des Talks war, dass Requirements Engineering nur ein Hilfsmittel ist, um ein Produkt zu erschaffen. Über den Umweg der Wissensarbeit im Projekt hoffte ich zu zeigen, dass sich die agile Form des Requirements Engineering vorrangig mit dem Erkennen und Schließen von Wissenslücken im Produktwissen und auch im Prozesswissen beschäftigt. Die Optimierung des jeweiligen Kontext spezifischen Prozesses an sich ist hierbei dem Leben des agile Gedankenguts überlassen.
Diese Diskussion lässt – so erhoffe ich mit diesem Beitrag – erkennen, dass eine agile Arbeitsform einen Effizienzbooster für diese Wissensarbeit bedeutet.
Der Effizienzbooster – so hoffte ich zu zeigen – kann auf zwei eng verwobenen Kontextebenen in einer Organisation zur Wirkung kommen, taktisch auf der Produktebene und operativ auf der Projektebene. Auf der Projektebene sollte dies immer möglich sein. Eigentlich, so denkt man, sollte jede Organisation danach streben.
Auf der Produktebene besitzen die Randbedingungen der Organisation erheblichen Einfluss, um über Invest in Agilität einen Wettbewerbsvorteil zu erzielen. Ein bottom-up Ansatz, ideal unter dem Schutz des Top-Managements, ermöglicht das Überprüfen dieser Randbedingungen.
Wichtig ist die Erkenntnis, dass es nicht den agilen Requirements Engineer geben wird, so wie es den klassischen Requirements Engineer gibt, also den Spezialisten, welcher (nur) die Rolle Requirements Engineers einnimmt. Vielmehr ist Requirements Engineering eine der Disziplinen, die ein Mitarbeiter neben anderen Disziplinen, wie zum Beispiel Testing oder das Schreiben des Handbuchs, beherrschen muss.
Spannend für uns ist, dass in agilen Organisationen die Disziplin des Requirements Engineering eine deutlich wichtigere Stellung im Verhältnis der Disziplinen einnimmt, als in klassischen Projekten. Diese Disziplin trägt nämlich durch die kommunikative Komponente sehr viel zum Aufbau und Verbreitung von Wissen bei.
Mit einem Wort und zusammenfassend: Ja, es gibt agiles Requirements Engineering und nein, es gibt nicht den agilen Requirements Engineer, sondern die multidisziplinären Mitarbeiter, die agile arbeiten können und Requirements Engineering als Disziplin beherrschen.
Referenzen
Referenzen
Definition des Begriffs Wissen im Kontext der Informatik, siehe Wikipedia unter http://de.wikipedia.org/wiki/Wissen#Kulturphilosophische_Beschreibungen
Definition des Begriffs Wissen nach Von Alexandra Frisch und Denise Walter, Hochschule der Medien, Institut für angewandte Kindermedienforschung, siehe Link http://www.hdm-stuttgart.de/ifak/medienwissenschaft/wissen_medienereignis/hoerbuch/definition_wissen
Buch: Software entwickeln mit Verstand, Jörg Dirbach, Markus Flückiger, Steffen Lentz, Dpunkt Verlag, erste Ausgabe 2011, ISBN-13: 978-3898646543), eine dringende Empfehlung, um etwas über den Umgang mit Wissen in der Software Entwicklung zu erfahren.
T. Gorschek and C. Wohlin, "Requirements Abstraction Model", Requirements Engineering Journal, Vol. 11, No. 1, pp. 79-101, 2006, der Artikel ist zwar nicht agil, das Gedankengut dahinter ist jedoch sehr wohl agil einsetzbar.
