Agiles Requirements Engineering in Scrum

Anforderungen agil
Kommentare

Reift eine Idee zur Durchführung eines Softwareentwicklungsprojekts, so führt heute kein Weg mehr an einer Betrachtung agiler Vorgehensweisen vorbei. Eine immer breiter werdende Menge von Unternehmen nutzt die Vorteile der Agilität in IT-Projekten und nimmt damit auch die Herausforderungen bei der Umstellung der Herangehensweise und Kultur aktiv an.

Projekte mit agilem Zuschnitt sind dabei in Unternehmen jeglicher Branche und Größe zu finden: Große Konzerne aus den Sektoren der Finanzdienstleistung, Telekommunikation und Industrie stellen ihre IT-Abteilungen schrittweise auf Agilität um, oft werden aber zunächst nur einzelne Teilprojekte als Pilotvorhaben agil ausgeführt. Viele der strukturell beweglicheren IT-Produkthäuser sind hier meist schon weiter und setzen bereits seit Jahren vollständig auf Agilität. Auch in den tendenziell eher weniger mit den eigenen Geschäftsprozessen verzahnten IT-Vorhaben des industriellen Mittelstands gewinnt das Thema zunehmend an Gewicht – immer öfter auch dann, wenn ein bestehendes Projekt veränderten Anforderungen an die Ergebnisqualität oder die Effizienz nicht mehr genügt.
Unabhängig vom Vorgehensmodell stellt die Entwicklung eines IT-Systems von nennenswerter Größe stets ein interdisziplinäres Projekt dar: Anforderungen werden oft von unterschiedlichen Interessensgruppen eingebracht und rund um die bekannten IT-Disziplinen wie Projekt- und Anforderungsmanagement, Softwaredesign, Entwicklung und Qualitätssicherung haben sich spezielle Berufsbilder mit spezifischen Aufgaben und Verantwortungen gebildet. Das gilt neben dem IT-Projektmanagement insbesondere für den Umgang mit Anforderungen, der in den Verantwortungsbereich des Requirements Engineers fällt. Der Übergang zu einer agilen Vorgehensweise stellt nun die in bisherigen Vorgehensweisen als klar empfundene Definition der jeweiligen Aufgabenbereiche in einen neuen Kontext und erfordert ein Umdenken aller Projektbeteiligten.

Szenario

Bei dem im Folgenden betrachteten Beispiel handelt es sich um ein reales Projekt zur Weiterentwicklung einer Individualsoftware bei einem unserer Kunden aus dem industriellen Mittelstand. Ziel des Projekts ist die Bereitstellung einer Anwendung, die Fachanwender bei der technischen Auslegung bestellbarer Produkte unterstützt. Die Anwendung wird frei nutzbar auf der Website des Kunden zum Download angeboten.
Das Projekt wird bereits seit mehreren Jahren durchgeführt, wobei die Software schrittweise ausgebaut und um neue Funktionalitäten und Produkte ergänzt wurde. Aus vertrieblichen Gründen wurde das Projekt erheblich ausgeweitet: Innerhalb einer möglichst kurzen Zeit sollte das komplette Produktportfolio des Kunden in die Anwendung integriert werden, wodurch der fachliche Inhalt der Anwendung vervielfacht wurde.
Da dieses Ziel mit dem bestehenden Team nicht erreicht werden konnte, wurde beschlossen, das Team personell zu vergrößern. Die geschätzte Größenordnung des Projekts lag damit bei mehreren tausend Personentagen innerhalb eines Zeitraums von circa zwei Jahren. Eine Analyse der bis dahin existierenden Projektorganisation und des technischen Zustands der Anwendung deckte in verschiedenen Bereichen erheblichen Umstellungsbedarf auf, um ein Gelingen des nunmehr vergrößerten Vorhabens zu ermöglichen.
Die technische Ausgangssituation zeigte typische Probleme eines Brownfield-Projekts: Die Qualität der inneren Struktur der Software war unzureichend, und für permanente Maßnahmen im Sinne der Clean-Code-Developer-Prinzipien [1] wurde keine Zeit bereitgestellt. Ein nicht konsequent durchgeführtes Refactoring qualitativ kritischer Stellen im Code führte zur Vermehrung solcher Qualitätsmängel. Es waren keine automatisierten Tests möglich und der Automatisierungsgrad bei Standardprozessen wie Build und Deployment war gering. Zusätzlich wurden grundlegende Architekturprinzipien nicht eingehalten. Trotz dieser Auffälligkeiten besaß der Code der Anwendung jedoch grundsätzlich das Potenzial zur Weiterentwicklung.
Auch organisatorisch war das Projekt nicht bereit für die angestrebte Vergrößerung des Teams. Grundlegende Aufgabenstellungen in den Bereichen Anforderungsdefinition, Softwaredesign, Development, Qualitätssicherung, Deployment und Projektmanagement wurden entweder nicht oder nur unzureichend wahrgenommen. Typische Rollen eines größeren IT-Projekts wie Architekt, QS-Manager, Requirements Engineer oder Projektmanager waren nicht besetzt. Der Softwareprozess war informell geregelt, außer der Anforderung, möglichst schnell Software zu liefern, bestanden keine vereinbarten Regeln hinsichtlich der Vorgehensweise wie z. B. der Definition von strukturierten Phasen oder der Anwendung eines erprobten agilen Modells wie Scrum [2].
Fachanalysen zu den umzusetzenden Anforderungen wurden vorrangig durch das Umsetzungsteam erbracht und nicht strukturiert erfasst. Fachliche Entscheidungen wurden oftmals ad hoc getroffen, übergreifend gültige Konzepte existierten nicht oder wurden oftmals ignoriert. Es existierten jedoch neue Ansätze, nunmehr die Produktexperten mit der Erstellung von Anforderungsdokumenten zu beauftragen.
Da die Hauptlast der fachlichen Analyse beim IT-Team lag, war dieses auf die Unterstützung durch die Anforderer und Produktexperten angewiesen. Diese Unterstützung wurde als unzureichend beurteilt, fachliche Auskünfte waren nur schwer und zeitlich verzögert greifbar. Fachexperten fühlten sich eher als „Informationsgeber“ und nicht als Teil des Umsetzungsteams. Sie übernahmen daher keine Verantwortung für das auf Basis ihrer Anforderungen erstellte Ergebnis.
Aus dieser Situation wurden relativ schnell Vorschläge für erforderliche technische und organisatorische Anpassungsmaßnahmen abgeleitet. Im Kern der organisatorischen Maßnahmen stand die Umstellung des Softwareentwicklungsprozesses des Projekts auf Scrum, um die folgenden damit verbundenen Vorteile nutzen zu können:

·         Generierung von schnellem und nachhaltigem Nutzen – Software steht schnell nutzbar zur Verfügung, ohne die Umsetzung des vollständigen Funktionsumfangs abwarten zu müssen

·         Änderungen der Software sind keine Ausnahme, sondern der Standardfall

·         Das Vorgehen beinhaltet die Verpflichtung zur Einhaltung von Qualitätszielen und setzt auf gutes Design

·         Die Methodik bedingt eine aktive Zusammenarbeit zwischen Anforderern und Entwicklern

·         Kreative und eigenverantwortliche Arbeit wird im Team gefördert

·         Der Prozess beinhaltet Maßnahmen zur kontinuierlichen Verbesserung der Softwareentwicklung

·         Der Auftraggeber behält die volle Kontrolle über das Vorhaben; es kann jederzeit in eine neue Richtung gelenkt oder beendet werden

Ungeachtet der damit verbundenen Vorteile stößt die Einführung eines agilen Vorgehens in der Praxis oft auf Probleme: Es ist zwar die Erkenntnis vorhanden, dass die Einführung eines agilen Modells erforderlich ist, dessen Etablierung wird jedoch als unmöglich oder nur eingeschränkt umsetzbar empfunden.
Im Fall des hier betrachteten Projekts war es jedoch möglich, ein nahezu reines Scrum-Vorgehen zu etablieren. Neben dem Vertrauen in die Kompetenz des Teams war für den Erfolg der Umstellung vor allem entscheidend, dass eine kleine IT-Entwicklungsabteilung mit nur wenigen bereits festgelegten Regeln vorhanden war, und dass mit Kaizen in den Fertigungsbereichen des Unternehmens bereits ein vergleichbarer Ansatz genutzt wird: Berührungspunkte zur Agilität und damit auch die Bereitschaft, ein entsprechendes Vorgehen zu nutzen, waren also vorhanden.

Agiles Requirements Engineering in Scrum

Eine Effizienzsteigerung in Brownfield-Projekten geht in der Regel mit veränderten Technologien und Prozessen einher. Auf beiden Ebenen müssen geeignete Strukturen geschaffen werden, die dem Team eine erfolgreiche Fortsetzung des Projekts ermöglichen. Im Folgenden gehen wir auf praxiserprobte Maßnahmen zur Absicherung eines agilen Vorgehens ein, beschränken uns dabei jedoch auf das Gebiet des Requirements Engineerings. Auch im agilen Kontext beeinflusst die Handhabung von Anforderungen maßgeblich den Erfolg des Projekts, ein immer wiederkehrendes Thema ist dabei die Kommunikation über Anforderungen.

Requirements Engineering ist Aufgabe des Product Owners

Der unstrukturierte Umgang mit Anforderungen kann in jeder Projektphase zu einem enormen Hindernis und Kostenfaktor werden: Unklare Verantwortlichkeiten, ungeeignete Spezifikationen, Ad-hoc-Aufträge einzelner Stakeholder an einzelne Entwickler, das Fehlen einer die Anforderungen in ein konsistentes Gesamtbild setzenden Produktvision und mangelnde Einsichten in die zu erwartenden Realisierungsaufwände lassen eine verlässliche Steuerung des Projekts unmöglich werden. Bei der Etablierung eines agilen Vorgehensmodells ist es daher sinnvoll, die Hauptverantwortung für das Requirements Engineeing in einer Rolle zu bündeln – in Scrum ist dies der Product Owner, der für das Erstellen und Aufrechterhalten einer Gesamtvision des Produkts verantwortlich ist und das Projekt auf die daraus resultierenden Ziele zubewegt [3]. An der Schnittstelle zwischen IT und Fachbereich erfasst, strukturiert und priorisiert der Product Owner die Anforderungen aller erfolgsrelevanten Interessensgruppen und lässt sie kontinuierlich in die Entwicklung einfließen. Zu diesem Zweck kommuniziert er regelmäßig mit Fachexperten aus der Domäne der Anwender und dem Team der Softwareentwickler und vertieft dabei beständig seine eigene fachliche Expertise, erweitert sein Wissen um relevante Anforderungen und wägt Realisierungsoptionen vor dem Hintergrund technologischer und organisatorischer Rahmenbedingungen ab. Zu den wichtigsten Aufgaben des Product Owners gehört die Pflege des Product Backlogs: Hier werden sämtliche Anforderungen an das Produkt dokumentiert und kontinuierlich fortentwickelt.
In unserem Szenario begann das Projekt mit einer kurzen Vorbereitungsphase (Abb. 1), an der neben einem Scrum Master und einem Architekten auch ein mit den Aufgaben des Requirements Engineering vertrauter Product Owner beteiligt war. Die Aufgabe des Product Owners lag in dieser Phase darin, die gegenwärtig relevanten Anforderungen und Themen zu identifizieren und in einem initialen Product Backlog zu konsolidieren, um eine geeignete Ausgangsbasis für die agile Weiterentwicklung des Produkts zu schaffen. Die dafür benötigten Informationen wurden gleichermaßen aus vorhandenen Spezifikationsdokumenten, umgesetzten Teilen des Systems und der persönlichen Kommunikation mit relevanten Stakeholdern inklusive des Entwicklerteams gewonnen.

Abb. 1: Scrum-Projekt mit Vorbereitungszeit

Architekturanforderungen frühzeitig identifizieren

In Brownfield-Projekten existiert oft eine nicht zu vernachlässigende technische Schuld, die einer effizienten Weiterentwicklung des Systems im Wege steht und somit ein hohes Projektrisiko darstellt. Notwendige Maßnahmen des Refactorings sollten daher frühzeitig identifiziert und umgesetzt werden. In der Praxis hat es sich bewährt, dass der Product Owner in seiner Funktion als Requirements Engineer eng mit einem erfahrenen Architekten zusammenarbeitet. Im Zuge regelmäßiger Abstimmungen zwischen Product Owner und Architekt können größere Refactoring-Themen frühzeitig identifiziert und in Form von Epics und User Storys [3] eingeplant werden, Querschnittsthemen wie z. B. Leistungsanforderungen werden frühzeitig besprochen und sind bei der Umsetzung funktionsbezogener Anforderungen deshalb besser zu berücksichtigen. Der Umgang mit Architekturanforderungen setzt softwaretechnische Kenntnisse auf Seiten des Product Owners voraus: Ohne ein grundlegendes Verständnis ist es nicht möglich, einen passenden Zuschnitt zu finden und die Auswirkungen von Entwurfsentscheidungen auf zukünftige Ausbaumöglichkeiten des Systems zu bewerten.

Projektsteuerung durch Anforderungsmanagement

In einem nach Scrum durchgeführten agilen Projekt sind Anforderungsmanagement und Projektsteuerung eng miteinander verwoben. Die grundlegende Steuerung des Vorhabens erfolgt durch die Priorisierung von Anforderungen und Themen im Product Backlog, denn die Reihenfolge der dort verzeichneten User Storys und Epics hat einen direkten Bezug zur Umsetzungsreihenfolge: Beim Planen der Arbeiten für den nächsten Sprint werden Einträge aus dem Product Backlog stets Top Down entnommen. In der Praxis stellen sich dem Product Owner Priorisierungsaufgaben auf verschiedenen Ebenen (Abb. 2):

·         Übergeordnete Themen, die in einem Zeitrahmen von mehreren Monaten begonnen und bearbeitet werden sollen, werden gemeinsam mit den für das Gesamtprojekt verantwortlichen Stakeholdern identifiziert und priorisiert. In unserem Projekt geschieht dies im Rahmen der monatlichen Zusammenkunft eines Steuerungsgremiums, dem neben dem Product Owner auch der Projektsponsor und der gesamtverantwortliche Auftraggeber angehören.

·         In Abstimmung mit themenverantwortlichen Anforderungsgebern legt der Product Owner die Inhalte des nächsten Sprints fest. In unserem Projekt finden entsprechende Abstimmungen wöchentlich statt, gegen Ende des laufenden Sprints werden die für den nächsten Sprint vorgesehenen Inhalte gemeinsam verabschiedet.

·         Die Umsetzungsreihgenfolge einzelner User Storys innerhalb eines Sprints wird durch den Product Owner durch die Priorisierung des Backlogs vorgegeben, kann aber im Sprint Planning Meeting gemeinsam mit dem Team modifiziert werden, um z. B. besser auf technische Erfordernisse und Abhängigkeiten eingehen zu können.

 

Abb. 2 Verschiedene Priorisierungsebenen

Für eine sinnvolle Priorisierung werden immer auch möglichst verlässliche Aussagen zu den Realisierungsaufwänden eines Themas oder einer Anforderung benötigt. Es ist deshalb sinnvoll, User Storys möglichst frühzeitig im Rahmen von Estimation Meetings zu bewerten und verschiedene Realisierungsvarianten zu vergleichen. Der Product Owner baut dabei ein implizites Wissen über die Leistungsfähigkeit des Teams und die Komplexität der Arbeit im Kontext bestimmter Funktionsgruppen auf. Dieses Wissen ermöglicht es ihm, die Auswirkungen neuer bzw. veränderter Anforderungen besser einschätzen zu können.
Wir führen in der Regel jede Woche ein ca. zweistündiges Estimation Meeting durch, in dem hochpriore, noch nicht bewertete User Storys dem Team durch den Product Owner vorgestellt werden. Die Storys werden diskutiert, und es wird eine Lösung erdacht und durch das Team in Tasks heruntergebrochen. Per Planning Poker wird anschließend der Umsetzungsaufwand in Story Points geschätzt.
Die strenge Anwendung von Timeboxing-Verfahren drängt dabei alle Teilnehmer, sich auf das Wesentliche zu konzentrieren. Kann das Team die Anforderungen einer Story nicht ausreichend verstehen, um eine Lösung grob anzudenken, wird diese an den Product Owner zur Detaillierung zurückgereicht, die Diskussion wird abgebrochen. Sofern für die Bewertung einer Story technische Detailfragen zu klären sind, werden sie im Rahmen eines „Additional Tasks“ des laufenden Sprints durch das Team beantwortet. In beiden Fällen wird die betroffene User Story im nachfolgenden Estimation Meeting erneut aufgegriffen. Die Erfahrung unseres Projekts ist, dass eine solche Verschiebung bei ungefähr jeder zehnten User Story eintritt.

Anforderungen umsetzen, Akzeptanzkriterien formulieren

Werden Anforderungen vor Beginn der Implementierung nicht hinreichend spezifiziert, so wird oft versucht, dies durch eine direkte Einflussnahme der betroffenen Stakeholder zu kompensieren. In Projekten mit geringem Organisationsgrad führt das zu spontanen Änderungsaufträgen, einer inkonsistenten Spezifikation und Zeitverlusten durch die wiederholte Produktion von prototypischen Lösungsvorschlägen. In der Folge ist es oft unklar, wann valide Ergebnisse zur Verfügung stehen und welche Vorgaben damit umgesetzt werden. Ein agiles Vorgehen nach Scrum schafft durch geschützte Sprints mit klar definierten Zielen und dem Formulieren von Akzeptanzkriterien verlässliche Strukturen: In der Vorbereitung eines Sprints arbeitet der Product Owner Anforderungen zu den dringlichsten Zielen des Projekts in einem angemessenen Detailgrad aus. Akzeptanzkriterien legen dabei für jede dieser Anforderungen die gewünschten Lösungseigenschaften fest, eine Prüfung erfolgt ausschließlich gegen diese Kriterien. Innerhalb des Sprints ist das Team vor externen Einflüssen geschützt und kann sich ungestört der Umsetzung der zu Sprintbeginn ausgewählten Anforderungen widmen.
In unserem Projekt stellen Akzeptanzkriterien den wesentliche Teil der Spezifikation dar: Sie legen die erforderlichen Lösungseigenschaften fest und beziehen dazu ggf. weitere Spezifikationsdokumente wie z. B. Mockups oder technische Berichte mit ein. Zwar stehen die Akzeptanzkriterien vor Beginn des Sprints fest, eine aufwandsneutrale Veränderung der Anforderungen zur Laufzeit eines Sprints ist jedoch möglich, setzt aber einen Konsens zwischen Entwicklungsteam und Product Owner voraus. Für den Product Owner sind daher aktuelle Informationen zum Fortschritt der Arbeiten im Sprint wichtig, die durch die tägliche Teilnahme am Daily Scrum erlangt werden.

Agiles RE mit Geduld einführen

Das Etablieren eines agilen Vorgehensmodells in einem gewachsenen Projekt benötigt Zeit: Bestehende Praktiken müssen aufgegeben und neue erlernt werden; der Fortschritt und die Wirksamkeit des agilen Handelns sind dabei regelmäßig im Team zu reflektieren. Für den Product Owner stellt sich die Aufgabe, den agilen Umgang mit Anforderungen in seinem Handeln von Beginn an vorzuleben, zum Beispiel, indem er sich regelmäßig mit dem Entwicklerteam zum Inhalt und zu Umsetzungsvarianten einzelner Anforderungen austauscht und diese Form der Kommunikation einer vermeintlich vollständigen Dokumentation vorzieht. Er muss darüber hinaus berücksichtigen, dass in den ersten Sprints nicht die volle Kapazität des Teams für die Umsetzung von Anforderungen zur Verfügung steht.
In unserem Projekt hat sich gezeigt, dass der Umstieg auf agile Praktiken auch im Requirements Engineering einen Lernprozess darstellt, der Zeit benötigt: Trotz wahrscheinlicher Anfangsschwierigkeiten sollte nicht vorschnell auf vermeintlich etablierte Methoden zurückgefallen werden, sowohl das Entwicklungsteam als auch der Product Owner müssen sich oftmals erst an die veränderten Spielregeln gewöhnen. Agile Praktiken profitieren von einer häufigen und unmittelbaren Kommunikation zwischen dem Entwicklungsteam und dem Product Owner – es ist also sinnvoll, das gesamte Scrum Team in einem gemeinsamen Projektraum unterzubringen, um eine spontane und direkte Kommunikation zu ermöglichen. Zur stetigen Verbesserung der agilen Handhabung von Anforderungen sollte das Thema der Spezifikation regelmäßig in der Sprint-Retrospektive angesprochen werden: Verbesserungsmaßnahmen können so gemeinsam identifiziert und in die Praxis übernommen werden.

RE als begleitende Aktivität verstehen

Wo klassische Vorgehensmodelle danach streben, in einer in sich abgeschlossenen frühen Projektphase eine möglichst vollumfängliche Spezifikation der gewünschten Software zu erstellen und das Vorhandensein einer solchen stabilen Anforderungsbasis als Vorbedingung der erfolgreichen Softwareentwicklung sehen, gehen agile Verfahren von einer kontinuierlichen Weiterentwicklung der Spezifikationsbasis im Projektverlauf aus: Parallel und in Wechselwirkung zur Entwicklung der Software werden Anforderungen ermittelt, bewertet, detailliert und nicht selten auch revidiert. Die Detaillierung von Anforderungen nimmt von der Grobplanung bis zur Umsetzung kontinuierlich zu (Abb. 3).
Rückmeldungen der Nutzer zu regelmäßig erzeugten Releases der Software und das im gesamten Team beständig zunehmende Verständnis der Fachlichkeit sind wesentliche Treiber dieses Vorgangs. In agilen Projekten ist der Umgang mit Anforderungen auf Veränderung ausgerichtet und will durch eine vermeintlich unvollständige Spezifikation den notwendigen Raum für Erkenntnisgewinn und das Entstehen neuer Anforderungen schaffen.
In der Praxis beginnen wir oft erst ein bis zwei Sprints vor der geplanten Umsetzung einer Funktion damit, detaillierte Anforderungen aus den bis dahin grob gehaltenen Themenbeschreibungen zu entwickeln. Der Product Owner integriert dabei die fachlichen Sichtweisen der relevanten Stakeholder und bespricht die technischen Voraussetzungen und Auswirkungen sowie die resultierenden Aufwände der Umsetzung mit dem Entwicklungsteam. Bis zum Beginn des zur Umsetzung dienenden Sprints wird so schrittweise eine detaillierte Darstellung der Anforderung erstellt. Während eines Sprints steht der Product Owner dem Team täglich für Rückfragen zur Verfügung. Die Nähe zwischen Product Owner und Team erlaubt es, die jeweils beste und effektivste Lösung gemeinsam und flexibel zu entwickeln.

Abb. 3: Verfeinerung der Anforderungen

Um diese gemeinschaftliche Verantwortung für das Produkt, und damit für Anforderungen und Lösungen, gewährleisten zu können, mussten einige Regeln und Rahmenbedingungen im Entwicklungsverfahren festgelegt werden.

·         Der Product Owner ist völlig unabhängig und autark in der Wahl der geeigneten Requirements-Engineering-Methoden.

·         Die Kapazitätsplanung des Teams sieht Kontingente für Unterstützung von RE-Tätigkeiten vor, bspw. um im Rahmen von regelmäßigen Estimation Meetings Feedback zu Anforderungen zu geben und die Auswirkungen verschiedener Lösungsalternativen zu eruieren Die Praxis zeigt, dass die Unterstützung des Requirements Engineerings ca. 10 Prozent der Teamkapazität in Anspruch nimmt.

·         Der Product Owner muss autorisiert sein, konzeptionelle Entscheidungen zu treffen und relevante Stakeholder nach Bedarf einzubinden.

Durch die starke Einbeziehung des Teams in die Aufgaben des Requirements Engineerings entsteht sowohl in den Estimation Meetings als auch in den Review Meetings ein Rückkanal, in dem das Team sein Feedback zu Anforderungen kommunizieren kann und auch gehört wird. Dadurch nimmt das Team aktiv an der Gestaltung der Anwendung teil. Im Entwicklungsteam entsteht in sehr kurzer Zeit fast beiläufig wertvolles fachliches Domänenwissen.

Kommunikation vor Dokumentation setzen

Eine auf respektvoller Offenheit, Vertrauen und einem gemeinsamen Zielverständnis beruhende Kommunikationskultur trägt in agilen Projekten wesentlich dazu bei, dass auf strikt formalisierte Formen der Anforderungsdokumentation verzichtet werden kann. Während in klassischen Projekten Anforderungen wegen ihres Vertragscharakters oft umfangreich abgestimmt und abgenommen werden müssen, kann der Schritt der Abnahme bei konsequenter Anwendung der Prinzipien der Agilität entfallen: Kurze Entwicklungszyklen ermöglichen es allen Beteiligten, unmittelbar über konkrete Ergebnisse zu sprechen und flexibel auf Notwendigkeiten der Veränderung zu reagieren (Abb. 4). Entwicklung und Spezifikation sind Bestandteile eines Lernprozesses: Anforderungen ändern sich im Verlauf des Projekts, sie werden verändert, fallen gelassen oder kommen neu hinzu – das ist kein Zeichen unzureichender Projektorganisation, sondern im Gegenteil ein Indiz dafür, dass das agile Vorgehen wirkt.
In unserem Projekt wählen wir einen bedarfsorientierten Ansatz der Dokumentation: Anforderungen werden in Form von User Storys mit Akzeptanzkriterien niedergeschrieben und um weitere Dokumente wie z. B. Mockups, technische Detailspezifikationen und fachliche Modelle ergänzt, sofern dies für ihre Umsetzung notwendig oder hilfreich ist. Product Owner und Team entwickeln im Verlauf des Projekts ein gemeinsames Verständnis des erforderlichen Detailgrads: Beispielsweise werden in unserem Projekt komplexe Dialoge mit schnell erstellten Mockups beschrieben, für einfache Änderungen des UI genügt jedoch die direkte Kommunikation mit dem Team zum Zeitpunkt der Umsetzung. Gerade auf Ebene der Nutzerschnittstelle erfolgen Detailabstimmungen zum UI-Design oft mehrfach im Sprint, Zwischenergebnisse und Entwürfe werden regelmäßig zwischen Product Owner und Team abgestimmt.

 

Abb. 4: Kommunikationswege zu Anforderungen

Stakeholdermanagement durch den Product Owner etablieren

In der Realität gibt es verschiedenste Gruppen, die ein Interesse an der Ausprägung der zu entwickelnden Software haben, der Bedarf zur Abstimmung von Anforderungen ist auch in agilen Projekten weiterhin vorhanden. Aufgabe des Requirements Engineers ist es, unterschiedliche Sichtweisen in zueinander konsistenten Anforderungen zusammenzuführen. Der Product Owner tritt dabei als alleiniger Mittler zwischen dem Entwicklungsteam und den fachlichen Stakeholdern auf: das Entwicklungsteam wird so von einer direkten Einflussnahme durch fachliche Stakeholder abgeschirmt, eine effiziente Selbstorganisation im Rahmen von geschützten Sprints mit klaren Zielsetzungen wird möglich.
In unserem Projekt gibt es regelmäßige Abstimmungsrunden zwischen Product Owner und fachlichen Anforderungsgebern und Projektsponsoren. Der Product Owner verantwortet die vollständige Transparenz über Prioritäten, Zielsetzungen und Inhalte: Nur so kann das erforderliche gemeinsame Commitment aller Stakeholder hergestellt werden.
Im Scrum folgt unmittelbar auf das Review Meeting, in dem die Ergebnisse durch das Team vorgestellt werden, das nächste Planning Meeting. Im Review Meeting kommunizieren Stakeholder oftmals spontan Feedback. Die Zeit, um diese Anmerkungen zu reflektieren und wiederum in Anforderungen für den nächsten Sprint umzusetzen, ist kurz. Um Feedback jedoch möglichst unmittelbar in die Planung einzuarbeiten, setzen wir im Projekt auf eine Sprint-begleitende Kommunikation zu den täglichen Zwischenständen der Software anhand von Daily Builds. Teamexternes Feedback wird durch den Product Owner kontinuierlich erfasst, nicht nur episodisch im Rahmen des Reviews. Für das Ausarbeiten und Abstimmen ergänzender Anforderungen bleibt so mehr Zeit, und Überraschungen im Review sind eher die Ausnahme. Hierbei bleibt jedoch zu beachten, dass der Einfluss auf die Ebene der Requirements beschränkt bleibt. Das aktuelle Sprintziel bleibt stets unverändert.

Fazit

Agiles Requirements Engineering hat sich in der Praxis bewährt. Über ein Jahr Requirements Engineering in der Rolle des Product Owners hat in unserem Projekt die erwarteten Vorteile der Agilität klar zu Tage treten lassen. Das Verständnis und die Rolle des Requirements Engineers werden in der agilen Praxis zwangsläufig und erfolgreich weiter aufgewertet. Individualsoftwareentwicklungen sind herausfordernde Vorhaben; die typischen und komplexen „Twists and Turns“ eines solchen Projekts als wünschenswerte Flexibilität, und damit als Wert zu begreifen, wird durch agile Methoden optimal unterstützt. Durch agiles Requirements Engineering in der Rolle des Product Owners rückt die klassische IT-Disziplin Requirements Engineering ganz nah an die zu erstellende Lösung. Im Vergleich zu nicht agilen Vorgehensweisen werden die an das Ergebnis gestellten Erwartungen nahezu immer erfüllt.
Fast alle typischen Requirements Engineering Skills, wie sie beispielsweise im CPRE Foundation Level [4] vermittelt werden, bilden die entscheidende Grundlage zur erfolgreichen Ausübung der Rolle des Product Owners in Scrum-Projekten. Ergänzt wird dies durch umfassendes Know-how zu agilen Methoden und einem ernst gemeinten Commitment zu den Prinzipien des agilen Manifests [5].
Unsere Erfahrung zeigt jedoch auch, dass agiles Requirements Engineering in der Rolle des Product Owners keine triviale Aufgabe ist. In einem fachlich und technologisch komplexen Umfeld können die Aufgaben eines Product Owners nur durch einen erfahrenen Requirements Engineer erfolgreich ausgeübt werden. So wird vom Product Owner erwartet, dass

·         hohe Entscheidungskompetenz bei der Wahl der geeigneten Requirements Engineering Mittel vorhanden ist

·         professionelles Requirements Engineering mit geringem Zeitbedarf durchgeführt werden kann

·         Teile der klassischen Projektmanagementaufgaben übernommen werden können

·         wichtige kommunikative Fähigkeiten vorhanden sind und auch genutzt werden

Wird im Scrum-Kontext über die Rolle des Product Owners gesprochen, so steht in vielen Fällen die Frage nach der Macht im Vordergrund. Tatsächlich hat der Product Owner ja auch den größten Einfluss auf das entstehende Softwareprodukt. Als Resultat dieser eingeschränkten Sichtweise wird dann vorrangig erörtert, wie Personen, die bisher den größten Einfluss im Projekt hatten – meist Projektmanager – diesen weiterhin wahren können. In Scrum wird der Product Owner seinen Einfluss genau dann zum Vorteil des Ergebnisses nutzen können, wenn er tief in Zielsetzung und Fachlichkeit der zu erstellenden Anwendung eingetaucht ist. Hierzu ist Kompetenz erforderlich, und diese besteht vorrangig im Beherrschen des „Handwerks“ Requirements Engineering.

Links & Litertaur

[1] http://www.clean-code-developer.de/
[2] Schwaber, K. (2009): „Agile Project Management with Scrum“, O‘Reilly
[3] Pichler, R. (2010): „Agile Product Management with Scrum“, Addison-Wesley

[3] Wirdemann, R. (2009): „Scrum mit User Storys“, Hanser
[4] Pohl, K.; Rupp, C. (2011):
Basiswissen Requirements Engineering“, dpunkt.verlag
[5] http://agilemanifesto.org/

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -