Befasst man sich mit der Scrum Methodologie wird man wohl oder übel feststellen müssen, dass der Requirements Engineer als Rolle oder Funktion nicht vorkommt. Braucht es den Requirements Engineer in der agilen Entwicklung etwa nicht wirklich? Falls doch, ist es vielleicht mehr eine Fähigkeit als eine Rolle?
Agilität und der Requirements Engineer
Ob Scrum oder SAFe, der Requirements Engineer als Persona wird in den weltweit gerne angewendeten Rahmenwerken in der agilen Entwicklung nicht erwähnt, zumindest nicht in deren Grundprinzipien. Dass Arbeitskräfte mit dieser Rollen- oder Funktionsbezeichnung in agilen Entwicklungen eingesetzt werden und sie als kompetente Scharniere zwischen Auftraggeber und Entwickler ihren wertvollen Beitrag leisten, ist unbestritten.
Die Definition vom Requirements Engineer stellt den Anspruch nicht, als Rolle oder Funktion in Rahmenwerken bezüglich agiler Entwicklung genannt werden zu müssen. Requirements Engineering (oder Anforderungsmanagement) entspringt aus der Lehre des Veränderungsvorhabens (Business Engineering) und stellt unter anderem sicher, dass Planänderungen, Missverständnisse, Fehler sowie Opportunitäten möglichst in den frühen Phasen erkannt werden (um nicht zuletzt unerwartete Kosten zu vermeiden). Im Wasserfall-Modell angewendet, sammelt der Requirements Engineer die Anforderungen grundsätzlich vor Beginn der Entwicklungsphase. In einer agilen Entwicklungsumgebung hingegen «schraubt» er an den Anforderungen während des gesamten Entwicklungszyklus rum. Anzumerken bleibt, dass der klassische Requirements Engineer im Gegensatz zu seinem agilen Pendant zumindest hinsichtlich Anforderungsdokumentation anderen Qualitätsansprüchen gewachsen sein muss.
Zudem sind die Agilität und das Requirements Engineering durchwegs vereinbar. Immerhin definiert die Scrum Methodologie, dass – unabhängig von Titeln und Rollenbezeichnungen – die übrigerweise der Entwicklung beitragenden Personen dem Entwicklungsteam zuzuordnen sind.
Wer erhebt die Anforderungen?
Das Erheben von Anforderungen beginnt bereits bei der Verfolgung einer Idee. Es sind der Business Owner und Product Owner, die bereits zum Zeitpunkt der Bekanntmachung eines Vorhabens eine Reihe von Anforderungen vermitteln. Dies tun sie idealerweise bereits in den gemeinsamen Tools, also dokumentieren sie gleichzeitig. An den regelmässigen Sitzungen tauschen sich die Entwickler (inklusive Tester) mit dem System Architect oder dem Product Owner aus und dokumentieren weitere Anforderungen. Dann ist es ein Spezialist aus dem Fachbereich Operations, der ebenfalls Anforderungen definiert und dokumentiert. Je nach Vorhaben springen die unterschiedlichsten (internen oder externen) Mitarbeitenden ein und üben sich im Requirements Engineering … und ja, das Vorhaben entwickelt sich. Habe ich den Requirements Engineer vergessen?
Rolle oder Fähigkeit?
Für mich drängt sich hier die Frage auf, ob der Begriff «Requirements Engineer» eigentlich gar keine Rolle oder Funktion im Sinne eines Berufstitels darstellt, sondern vielmehr die willkommene, zusätzliche Fähigkeit einer Arbeitskraft ist die ohnehin anfallenden Arbeiten effizienter und konformer zu verrichten.
passend zum Thema
https://www.microtool.de/requirements/agiles-requirements-engineering-gibt-es-das-ueberhaupt/
https://www.scrumguides.org/scrum-guide.html
https://www.scaledagileframework.com/agile-teams/
