Requirements Engineering für die agile Softwareentwicklung E-Book

Johannes Bergsmann

• Herausgeber: dpunkt.verlag
• Kategorie: Wissenschaft und neue Technologien
• Sprache: Deutsch
• Veröffentlichungsjahr: 2023

Seitenzahl: 609

Beschreibung

Das Handbuch für agile Requirements Engineers - Umfassend und anwendungsbezogen - Ein Buch aus der Praxis für die Praxis - Mit durchgängigem Projektbeispiel und wertvollen Hinweisen für pragmatische Lösungen Dieses Buch gibt einen praxisorientierten Überblick über die am weitesten verbreiteten Techniken für die Anforderungsspezifikation und das Requirements Management in agilen Projekten. Es beschreibt sowohl sinnvolle Anwendungsmöglichkeiten als auch Fallstricke der einzelnen Techniken. Behandelt werden im Einzelnen: - Grundlagen und die fünf Grundprinzipien des Requirements Engineering in der agilen Softwareentwicklung - Requirements-Ermittlung und -Dokumentation - Requirements-Validierung und -Abstimmung - Qualität im Requirements Engineering - Requirements Management - Organisatorische Aspekte - Rollen im Requirements Engineering Darüber hinaus werden rechtliche und wirtschaftliche Themen erläutert sowie auf die Herausforderungen in größeren Organisationen eingegangen. Das Buch ist Hilfestellung und Nachschlagewerk, um in der täglichen Praxis der agilen Projekte Requirements Engineering und Requirements Management professionell und mit nachhaltigem Nutzen umzusetzen. Die 3. Auflage wurde vollständig überarbeitet und berücksichtigt den Lehrplan "RE@Agile Primer" des International Requirements Engineering Board (IREB) sowie die neue Fassung des Scrum Guide von November 2020.

Leseprobe

Johannes Bergsmann hat technische Informatik studiert und arbeitete ca. 11 Jahre als Softwareentwickler, Projektleiter, Technischer Leiter, Architekt, Produktmanager und Berater in einem internationalen Systemhaus und als selbstständiger Unternehmer. Im März 2003 gründete er »Software Quality Lab« und begleitet seither als Berater und Trainer viele Unternehmen im Bereich Requirements Engineering und Prozessgestaltung.

Johannes Bergsmann ist zertifizierter Scrum Master, Sachverständiger für Informatik bei Gerichten, als Lehrbeauftragter an Fachhochschulen im Bereich Softwarequalitätsmanagement tätig, ist Autor vieler Fachartikel und hält Fachvorträge bei verschiedenen Veranstaltungen und Konferenzen.

Unter Mitwirkung von Markus Unterauer:

Markus Unterauer hat Wirtschaftsinformatik studiert. In seiner Berufspraxis war er in vielen Bereichen der Softwareentwicklung wie Architektur, Entwurf, Entwicklung, Testen, Testautomatisierung bis zu Deployment tätig. Er lernte dabei sowohl klassische als auch agile Projekte und Methoden intensiv kennen.

Seit 2012 arbeitet Markus Unterauer bei Software Quality Lab als Berater und Trainer. Er ist zertifizierter Scrum Master und hat sich auf die Bereiche Softwareprozesse und Anforderungsmanagement spezialisiert. Markus Unterauer ist auch als Vortragender in diesen Themenbereichen immer wieder auf Konferenzen tätig.

Coypright und Urheberrechte:Die durch die dpunkt.verlag GmbH vertriebenen digitalen Inhalte sind urheberrechtlich geschützt. Der Nutzer verpflichtet sich, die Urheberrechte anzuerkennen und einzuhalten. Es werden keine Urheber-, Nutzungs- und sonstigen Schutzrechte an den Inhalten auf den Nutzer übertragen. Der Nutzer ist nur berechtigt, den abgerufenen Inhalt zu eigenen Zwecken zu nutzen. Er ist nicht berechtigt, den Inhalt im Internet, in Intranets, in Extranets oder sonst wie Dritten zur Verwertung zur Verfügung zu stellen. Eine öffentliche Wiedergabe oder sonstige Weiterveröffentlichung und eine gewerbliche Vervielfältigung der Inhalte wird ausdrücklich ausgeschlossen. Der Nutzer darf Urheberrechtsvermerke, Markenzeichen und andere Rechtsvorbehalte im abgerufenen Inhalt nicht entfernen.

Johannes Bergsmann

Requirements Engineering für die agile Softwareentwicklung

Methoden, Techniken und Strategien

Unter Mitwirkung von Markus Unterauer

3., überarbeitete und aktualisierte Auflage

Johannes Bergsmann

[email protected]

Markus Unterauer

[email protected]

Lektorat: Christa Preisendanz

Lektoratsassistenz: Julia Griebel

Copy-Editing: Ursula Zimpfer, Herrenberg

Layout & Satz: Birgit Bäuerlein

Herstellung: Stefanie Weidner

Umschlaggestaltung: Helmut Kraus, www.exclam.de

Bibliografische Information der Deutschen Nationalbibliothek

Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar.

ISBN:

Print

978-3-86490-929-0

PDF

978-3-96910-953-3

ePub

978-3-96910-954-0

mobi

978-3-96910-955-7

3., überarbeitete und aktualisierte Auflage 2023

Copyright © 2023 dpunkt.verlag GmbH

Wieblinger Weg 17

69123 Heidelberg

Teile dieses Buches orientieren sich am Lehrplan RE@Agile des IREB e. V. Der Besitz und das Urheberrecht dieses Lehrplans und Studienleitfadens liegt bei IREB e. V. und den Autoren: Lars Baumann, Stefan Gärtner, Peter Hruschka, Kim Lauenroth, Markus Meuten, Sacha Reis, Gareth Rogers, Francois Salazar, Hans-Jörg Steffe, Thorsten Weyer.

Hinweis:

Dieses Buch wurde auf PEFC-zertifiziertem Papier aus nachhaltiger Waldwirtschaft gedruckt. Der Umwelt zuliebe verzichten wir zusätzlich auf die Einschweißfolie.

Schreiben Sie uns:

Falls Sie Anregungen, Wünsche und Kommentare haben, lassen Sie es uns wissen: [email protected].

Die vorliegende Publikation ist urheberrechtlich geschützt. Alle Rechte vorbehalten. Die Verwendung der Texte und Abbildungen, auch auszugsweise, ist ohne die schriftliche Zustimmung des Verlags urheberrechtswidrig und daher strafbar. Dies gilt insbesondere für die Vervielfältigung, Übersetzung oder die Verwendung in elektronischen Systemen.

Es wird darauf hingewiesen, dass die im Buch verwendeten Soft- und Hardware-Bezeichnungen sowie Markennamen und Produktbezeichnungen der jeweiligen Firmen im Allgemeinen warenzeichen-, marken- oder patentrechtlichem Schutz unterliegen.

Alle Angaben und Programme in diesem Buch wurden mit größter Sorgfalt kontrolliert. Weder Autoren noch Verlag können jedoch für Schäden haftbar gemacht werden, die in Zusammenhang mit der Verwendung dieses Buches stehen.

5 4 3 2 1 0

Vorwort

Viele Projekte werden aus verschiedenen Gründen nicht so effizient und effektiv abgewickelt, wie dies möglich wäre: Zum Beispiel wenn die Fachexperten zwar wissen, dass sie mit den Entwicklerinnen täglich kommunizieren sollten, dies jedoch nicht können,

weil sie im Tagesgeschäft schon zu stark involviert und überlastet sind,

weil sie von ihrer Persönlichkeit her keine aktiv kommunizierenden Typen sind,

weil sie mitten im Projekt andere Aufgaben zugewiesen bekommen,

weil sie die Abteilung oder Firma wechseln,

weil es schwierig ist, das Wissen in den Köpfen der Beteiligten bewusst zu machen und an andere zu kommunizieren,

weil Kommunikation zwischen zwei Personen immer auch mit einer Interpretation und evtl. mit einer Veränderung der Information einhergeht oder

aus verschiedensten anderen Gründen.

Als Berater habe ich in meiner bisherigen beruflichen Tätigkeit mehr als 200 verschiedene Projekte begleitet oder auch selbst in unterschiedlichen Rollen (Entwickler, Tester, Projektleitung, Architekt, Produktmanager, Analytiker, Coach, Berater etc.) mitgearbeitet. Viele dieser Projekte – vor allem in den letzten 20 Jahren – waren agile Projekte oder Projekte, in denen die Mitwirkenden zumindest versuchten, einige der agilen Prinzipien umzusetzen.

Am erfolgreichsten und effizientesten waren in dieser langen Zeit immer diejenigen Projekte, bei denen ich agile Vorgehensweisen mit Elementen aus dem klassischen Requirements Engineering und Projektmanagement ergänzte und so die Stärken jeder Methodik voll ausnutzen konnte.

Man könnte alle diese Softwareprojekte mit einer Autofahrt von München nach Rom vergleichen. Im Idealfall fahren wir auf gerader Strecke mit konstanter und optimaler Geschwindigkeit mit unserem Auto alleine auf der Straße. In der Praxis aber hat die Straße Kurven, es gibt Verkehrsbeschränkungen, in den Bergen ist evtl. auch Eis auf der Straße, es gibt Staus, andere Autofahrer, die rücksichtslos unterwegs sind und nur ihr eigenes Ziel im Blick haben, unser Auto hat eine Panne etc.

Auf alle diese individuellen Situationen sollten wir vorbereitet sein und unser Vorgehen der jeweiligen Situation entsprechend anpassen, damit wir unser Ziel auch erreichen. Generell werden wir grob planend vorgehen, z. B. den Startzeitpunkt bestimmen, den ungefähren Zeitrahmen der Fahrt abschätzen und den Streckenverlauf z. B. für die Alpenüberquerung über den Brenner planen. Wir sollten auch ungefähr wissen, welches Wetter zu erwarten ist, und abhängig davon die Reifen, den Frostschutz, die Klimaanlage etc. entsprechend vorbereiten. Im Verlauf der Fahrt wird es vielleicht zu Änderungen kommen, z. B. wenn der Brennertunnel wegen eines Unfalls gesperrt ist. In diesem Fall werden wir agil darauf reagieren müssen und die Umleitungsstrecke über den Pass nehmen (schließlich haben wir ja Google Maps dabei ). Wenn wir im Vorfeld in der »Architektur« unseres Autos diese Situation mangels vorausschauender Planung nicht berücksichtigt haben und beim ersten kurzen Anstieg der Passstraße feststellen, dass wir ohne Winterreifen und Schneeketten auf der verschneiten Straße nicht weiterkommen, müssen wir wiederum agil reagieren und nun einen großen Umweg über die Tauernautobahn nehmen. Beide Vorgehensweisen haben daher ihre Berechtigung. Als Softwareentwicklerin, Projektleitung, Scrum Master, Product Owner – oder welche Verantwortlichkeit auch immer wir im Projekt innehaben – sollten wir viele unterschiedliche Methoden im Köcher haben und diese für unser Projekt zur optimalen Vorgehensweise kombinieren.

Das Agile Manifest

Das Agile Manifest [Agile Manifesto] (siehe auch Abschnitt 1.2) beschreibt in seinen vier Leitsätzen und zwölf Prinzipien die Eckpfeiler, an denen sich praktisch alle agilen Vorgehensweisen orientieren. Darin wird unter anderem festgehalten, dass funktionierende Software und Zusammenarbeit mit den Kunden wichtiger sind als umfassende Dokumentation und Vertragsverhandlungen, wobei im Zusatz angeführt ist, dass umfassende Dokumentation und Vertragsverhandlungen auch als wichtig angesehen werden. So sollten Projekte idealerweise ablaufen. Wenn man die Praxis in vielen Softwareprojekten erlebt hat, wird man dem Agilen Manifest begeistert zustimmen und die Aussage und Sichtweise uneingeschränkt unterstützen.

Die aus dem Agilen Manifest entstandenen verschiedenen Vorgehensweisen wie z. B. Scrum greifen bestimmte Aspekte und Themen daraus auf und lassen andere Themen bewusst offen und unkonkret. Unter Berücksichtigung der Projektsituation und Rahmenbedingungen müssen diese offenen Themen selbst passend definiert werden.

Wenn Requirements zum Problem werden

Sehr oft wurde und wird in verschiedenen Stadien eines Projekts das Requirements Engineering und Requirements Management zum Thema, z. B. wenn …

… eine externe Kundschaft schon bei Projektstart einen Festpreis vereinbaren will und seine Juristen oder Einkäufer vorab wissen wollen, was denn schlussendlich für den vereinbarten Preis geliefert wird.

… bei der Abnahme eines Produkts durch die Kundschaft plötzlich wichtige Personen fehlende Funktionen bemängeln und nicht klar ist, ob dies vom Lieferanten noch als Auftragsbestandteil geschuldet wird oder ob das nun ein kostenpflichtiger Change Request ist.

… im Laufe des Projekts eine auf Basis von User Stories (siehe

Abschnitt 3.4.2

) entwickelte Eingabemaske schon zum x-ten Mal über mehrere Iterationen hinweg wieder und wieder angepasst und verändert wird, weil der Kunde sich immer wieder etwas anderes als Ergebnis vorstellt.

… Entwicklungsverantwortliche, die auf die Frage »Was kann denn das Produkt, das Sie entwickeln, nun eigentlich alles?« nur sagen können, dass sie Tausende User Stories in ihrem Request-Tool dokumentiert haben und dort nachzulesen ist, was umgesetzt wurde.

… das Projektteam zwar weiß, was es die letzten zwei, drei Iterationen entwickelt hat und was es die kommenden zwei Iterationen entwickeln wird, jedoch keinen Überblick mehr darüber hat, welche Funktionalität das Produkt insgesamt hat.

… »der Wald vor lauter Bäumen nicht mehr erkannt« wird und die Zusammenhänge für die Beteiligten möglicherweise schon verloren gegangen sind.

Alle diese geschilderten Fälle sind primär auf mangelndes Requirements Engineering und Requirements Management zurückzuführen. Tendenziell treten solche Probleme in Projekten auf, in denen ein Vorgehensmodell gewählt wurde, das viele thematische Freiheiten bietet, die offengelassenen Teile aber nicht vorab zwischen den beteiligten Personen festgelegt wurden oder das Modell nicht an die gegebene Situation angepasst wurde.

Gerade agile Vorgehensweisen überlassen die konkrete Ausgestaltung des Requirements Engineering (RE) zum Großteil der Entscheidung des Teams. RE wird in den verschiedenen agilen Methoden nur sehr grob beschrieben. In der Begeisterung der ersten Stunde möchten viele Teams möglichst rasch starten und erste Erfolge zeigen und beginnen mit einem sehr intuitiven Ansatz, wie z. B. einer einfachen Liste von User Stories. User Stories sind eine sinnvolle Technik aus den agilen Vorgehensweisen und ich baue in vielen Abschnitten dieses Buches auf dieser Technik auf. Es gibt jedoch auch viele Techniken aus dem Requirements Engineering, die in agilen Vorgehensweisen angewendet werden können. Aus meiner Erfahrung bietet die Kombination der verschiedenen Herangehensweisen gute Lösungen für die Requirements-Herausforderungen, nicht nur in agilen Projekten.

In diesem Buch werden daher viele verschiedene Techniken und Methoden aus den agilen Vorgehensweisen vorgestellt, mit klassischen Methoden verknüpft und ergänzt und in einen strukturierten und systematischen Zusammenhang mit Requirements Engineering gebracht.

Über dieses Buch

In meiner Beratungspraxis habe ich über viele Jahre hinweg Management und Teams hinsichtlich Requirements Engineering beraten und gecoacht und gesehen, wie schwierig es den Beteiligten in vielen Projekten fällt, agil und RE in Einklang zu bringen. Daher entschloss ich mich im Jahr 2014 dazu, die erste Auflage dieses Buches zu schreiben.

Der Fokus dieses Buches liegt darauf, gute Methoden und Techniken – egal aus welchem Zeitalter oder mit welcher Ausrichtung – unvoreingenommen aufzugreifen und sie nicht von vornherein auszuschließen, nur weil es sich dabei um »plangetriebene« oder »agile« Methoden oder Techniken handelt. Aussagen wie »klassische plangetriebene Methoden sind überfrachtet, ineffizient und schlecht« oder »agile Methoden sind was für Individualisten oder Dokumentationsverweigerer« gehören für mich nicht zu einer weitsichtigen und nachhaltigen Denkweise.

Jede genannte Methode und Technik stellt ein Werkzeug im Werkzeugkasten der Softwareentwicklung dar und soll hier mit ihren Vorteilen und Nachteilen in bestimmten Projektsituationen betrachtet werden. Es soll klar werden, wo und wie diese Methoden und Techniken in agilen Projekten eingesetzt werden können, um einen Nutzen für das Projekt zu stiften. Es werden daher auch sinnvolle Anwendungsmöglichkeiten und Fallstricke der einzelnen Methoden und Techniken dargestellt und im Kontext eines nachhaltigen, systematischen und praxisorientierten Requirements Engineering in der agilen Softwareentwicklung betrachtet.

Ziel ist es, einen Überblick und einen Werkzeugkasten anzubieten, der zeigt, welche Methoden und Techniken zusätzlich zu den sehr oft angewendeten User Stories noch sinnvoll sind und welche Hindernisse und Problemstellungen im Zusammenhang mit Requirements Engineering in agilen Projekten auftreten können.

Abgerundet wird das Thema durch die Behandlung von Qualitätsaspekten für Requirements, durch organisatorische Aspekte, einen Blick auf die Zusammenhänge der RE-Techniken und durch rechtliche Aspekte sowie durch Tipps und Tricks bei der konkreten Anwendung von Requirements-Themen im agilen Umfeld.

Das Buch richtet sich an Product Owner, Produktverantwortliche, Projektleitung, Softwareauftraggeber, Scrum Master, Entwicklerinnen, Tester und alle anderen Personen, die sich mit nachhaltigem und systematischem Requirements Engineering und Requirements Management in der agilen Softwareentwicklung beschäftigen oder davon betroffen sind.

Dieses Buch ist keine komplette Einführung in agile Methoden. Kapitel 1 und 2 geben zwar einen kurzen Überblick über das Agile Manifest, wesentliche agile Konzepte und Scrum, als den am häufigsten eingesetzten Vertreter agiler Methoden. Der Hauptfokus des Buches liegt jedoch auf dem Requirements Engineering und Requirements Management.

Hilfreich beim Lesen ist ein grundlegendes Verständnis im Bereich Requirements Engineering und insbesondere die Kenntnis der allgemein anerkannten Begriffe, Techniken und Vorgehensweisen dieses Themenbereichs. Die Inhalte und die Begriffe, die das International Requirements Engineering Board (IREB®) [IREB] für die Ausbildung zum »Certified Professional for Requirements Engineering (CPRE) – Foundation Level« in seinem Lehrplan [IREB CPRE FL] vorgibt, stellen den derzeitigen Stand der Technik zum Thema Requirements Engineering dar, der als Grundlage für das Lesen dieses Buches empfohlen wird.

Das Buch soll Einführungslektüre sowie Praxisleitfaden sein und ist nicht als wissenschaftlich komplette Abhandlung über das Thema Requirements Engineering in der agilen Softwareentwicklung gedacht. Es kann daher sequenziell oder auch auszugsweise gelesen werden. Als Autor ist es mir natürlich am liebsten, wenn Sie dieses Buch ständig an Ihrem Arbeitsplatz griffbereit haben und bei Fragen oder Unklarheiten zu Requirements-Engineering-Techniken oder -Vorgehensweisen darin einen schnellen Rat und brauchbare Infos finden.

In der Praxis hat man leider oft nicht die Zeit, beim Auftauchen einer Frage ein ganzes Buch z. B. zu Use Cases, User Stories oder Behavior Driven Development zu lesen. Ich habe daher auf eine möglichst große Unabhängigkeit der einzelnen Themen und Kapitel geachtet, sodass das Buch auch als Nachschlagewerk in der täglichen Arbeit verwendet werden kann. Mit entsprechendem Vorwissen in agilen Methoden und Requirements Engineering kann es auszugsweise gelesen und verstanden werden. Für die Leserschaft aus der Praxis müssen das Wichtigste und die Zusammenhänge in Kürze ersichtlich sein. Daher gibt es in vielen Kapiteln eine tabellarische Übersicht über wesentliche Punkte und verschiedene Überblicksgrafiken, die die Zusammenhänge auf einen Blick darstellen.

Auch wenn in vielen Kapiteln Begriffe aus Scrum verwendet oder zitiert werden, so wurde darauf geachtet, die einzelnen Themenbereiche möglichst allgemeingültig zu halten. Das Buch adressiert nicht »Requirements Engineering in Scrum-Projekten«, sondern behandelt generell das Thema Requirements Engineering im agilen Umfeld. Die beschriebenen Techniken und Methoden können auch in anderen agilen Vorgehensweisen angewendet werden.

Beispiele werden mit einem grauen Hintergrund versehen:

In diesem Buch werden verschiedene Beispiele und Formulierungen aus der Praxis und für die Praxis aufgeführt. Die meisten dieser Beispiele sind abgeleitet aus einem Projekt zum Thema »Zeiterfassung«. Es geht in diesem Beispielszenario darum, dass die Tagesarbeitszeiten inklusive der Pausen und Abwesenheitszeiten von Mitarbeitenden eines Unternehmens erfasst, ausgewertet und verwaltet werden können und dass auch die Erfassung, Auswertung und Verwaltung von Projektarbeitszeiten durchgeführt werden kann – also von einzelnen Zeitblöcken der Tagesarbeitszeit, die bestimmten Projekten zugeordnet werden.

Weiterführende Literatur zum Thema Requirements Engineering und agile Vorgehensweisen ist im Anhang E zu finden.

Ich freue mich, wenn dieses Buch für Sie als Anwenderin oder Experte in Ihrer täglichen Praxis eine Unterstützung und Anregung ist und für Sie als an der Schulung und Zertifizierung RE@Agile interessierte Person eine gute Informations- und Lerngrundlage darstellt.

Für die Weiterentwicklung dieses Themas hoffe ich natürlich auch auf zahlreiches Feedback und interessante Diskussionen (bitte direkt an [email protected]).

Johannes Bergsmann       Linz, im November2022

Hinweise zur 2. Auflage

2017 wurde der Lehrplan RE@Agile für eine Ausbildung des International Requirements Engineering Board (IREB®) herausgegeben, der die Lücke zwischen Requirements-Engineering-Methoden und agilen Methoden schließt. Sehr viele Inhalte dieses Lehrplans deckten sich bereits mit der ersten Auflage dieses Buches und die Motivation hinter diesem Lehrplan ist dieselbe, wie sie hinter meinem Buch steht.

Daher waren eine Anpassung und Überarbeitung der ersten Auflage ein logischer und sinnvoller Schritt zur zweiten Auflage dieses Buches, damit dieses nun auch als Lernunterlage für am RE@Agile interessierte Personen verwendet werden kann.

Hinweise zur 3. Auflage

Nachdem Mitte 2022 auch der Advanced Level RE@Agile in der Version 2 herausgegeben wurde, habe ich dies zum Anlass genommen, dieses Buch erneut entsprechend anzupassen, viele Bereiche auf den neuesten Stand zu bringen und einige Stellen auch wesentlich zu überarbeiten.

Die Struktur und die Inhalte dieses Buches orientieren sich am Lehrplan RE@Agile des International Requirements Engineering Board (IREB®). Damit bietet es den an dieser Ausbildung und Zertifizierung interessierten Personen nun eine praxisnahe Vorbereitung und Lerngrundlage sowie noch viele ergänzende Inhalte, die über den Lehrplan hinausgehen. In Abschnitt 1.1.3 ist angeführt, welche Kapitel zur Berücksichtigung des Lehrplans Advanced Level RE@Agile neu hinzugenommen bzw. wesentlich ergänzt wurden. Da die Ausrichtung und der Umfang der in diesem Buch behandelten Themen jedoch weiter gefasst sind, war es erforderlich, einige wenige Abschnitte in unterschiedlicher Reihenfolge zu behandeln (insbesondere der Themenblock »Skalierung von RE@Agile«) sowie zusätzliche Inhalte aufzunehmen, die für den Gesamtfokus des Buches relevant sind.

Ende 2020 wurde der Scrum Guide an einigen Stellen wesentlich angepasst und diese Änderungen wurden in dieser Auflage ebenfalls eingearbeitet.

Danksagung

Ich bedanke mich bei allen Personen, mit denen ich im Laufe der letzten Jahre zum Thema Requirements Engineering und agile Methoden diskutieren durfte und die schlussendlich dazu beigetragen haben, dass ich mich zum Schreiben der 1. Auflage und auch weiterer Auflagen dieses Buches entschlossen habe und entsprechende Sichtweisen aus der Praxis mit einfließen lassen konnte. Insbesondere auch dem IREB® und seinen Mitgliedern, die dieses Thema weiter vorantreiben, den Lehrplan stetig weiterentwickeln und anpassen, um den Anforderungen in der Praxis gerecht zu werden.

Ein besonderer Dank gilt Markus Unterauer, der mich als Koautor bei der Erstellung der ersten Auflage dieses Buches maßgeblich unterstützt hat und wesentliche Teile vor allem im Kapitel 4 »Requirements-Validierung und -Abstimmung«, Kapitel 6 »Requirements Management« und Kapitel 8 »Requirements-Engineering-Rollen« beigetragen und viele gute Anregungen gegeben hat.

Vielen Dank auch dem dpunkt.verlag – insbesondere Christa Preisendanz – für die initiale Anregung und für die wertvolle Unterstützung im Laufe der Ausarbeitung dieses Buches sowie für die Motivation zur Überarbeitung und Erstellung der Neuauflagen.

Und schlussendlich gilt ein ganz großer Dank meiner Frau Petra und meinen Kindern Beate und Barbara, die mich dadurch unterstützt haben, dass sie mir die Zeit zum Schreiben dieses Buches gegeben haben.

Inhaltsübersicht

1Einleitung und Motivation

2Grundlagen

3Requirements-Ermittlung und -Dokumentation

4Requirements-Validierung und -Abstimmung

5Qualität im Requirements Engineering

6Requirements Management

7Organisatorische Aspekte

8Requirements-Engineering-Rollen

9Rechtliche Themen

Anhang

AAgile Methoden zur Unterstützung des Requirements Engineering

BRollenbeschreibungen – Beispiele

CAbkürzungen

DGlossar

ELiteratur

Index

Inhaltsverzeichnis

1Einleitung und Motivation

1.1Fokus dieses Buches

1.1.1Zielgruppen

1.1.2Abbildung des Lehrplans IREB CPRE RE@Agile Primer

1.1.3Abbildung des Lehrplans IREB CPRE Advanced Level RE@Agile – Practitioner/Specialist

1.1.4Allgemeine Begriffseinordnung

1.2Verbindung zwischen RE und agilem Vorgehen

1.2.1Denkweisen und Werte im RE und agilen Vorgehen

1.2.2Zusammenhang zwischen RE und Agile

1.2.3Was ist RE@Agile

1.2.4RE im Kontext des Agilen Manifests

1.2.5Nutzen von RE im agilen Vorgehen

1.2.6Vorurteile und Probleme beim RE im agilen Umfeld

1.2.7Fallstricke bei RE@Agile

1.2.8Resümee

2Grundlagen

2.1Methodenüberblick

2.1.1Allgemeine agile Vorgehensweisen

2.1.2Scrum »in a Nutshell«

2.1.3Methoden zur Unterstützung des Requirements Engineering

2.2Requirements Engineering im agilen Umfeld

2.3Grundprinzipien des RE in der agilen Softwareentwicklung

2.4Umfang des Requirements Engineering

3Requirements-Ermittlung und -Dokumentation

3.1Ein kurzer Überblick

3.1.1Anforderungsarten

3.1.2Requirements-Dokumente vs. Product Backlog

3.1.3Granularität funktionaler Requirements

3.1.4Grafische Modelle und textuelle Beschreibungen

3.1.5Definition von Begriffen, Glossare und Informationsmodelle

3.1.6Akzeptanz- und Abnahmekriterien

3.1.7Definition of Ready & Definition of Done

3.1.8Prototyp vs. Inkremente

3.1.9Ermittlung

3.1.10Dokumentation

3.1.11Artefakte

3.1.12Ein Blick auf das große Ganze

3.2Übergeordnete Artefakte

3.2.1Zusammenhänge und Abhängigkeiten

3.2.2Vision und Ziele

3.2.3Systemgrenze und Kontext

3.2.4Stakeholder

3.2.5Epics

3.2.6Personas

3.3Geschäftsprozesse und Systemverhalten

3.3.1Prozesse

3.3.2Use Cases

3.3.3Use-Case-Szenario bzw. -Template

3.4Funktionale und nicht funktionale Sicht

3.4.1Features

3.4.2User Stories

3.4.2.1Schneiden, Aufteilen bzw. Gruppieren von User Stories

3.4.2.2Wann sollte man aufhören zu zerlegen?

3.4.2.3Nicht funktionale User Stories

3.4.2.4Technische User Stories

3.4.3Qualitätsanforderungen und Randbedingungen

3.4.3.1Qualitätsanforderungen

3.4.3.2Randbedingungen (Constraints)

3.4.3.3Abnahme und Backlog-Management

3.5Benutzerschnittstelle

3.5.1Wireframes

3.5.2Sketchy User Interface/Sketches

3.5.3Finales User Interface

3.5.4Szenariobasierte UI-Spezifikation

3.5.5Hinweise zur GUI-Spezifikation

3.6Systemschnittstelle

3.7Prototypen und Inkremente

3.8Entwicklersicht

3.8.1Spikes

3.8.2Architektur und technisches Design

3.8.3Developer Story

3.8.4Systemszenarien

3.8.5Developer Constraints

3.8.6Tasks

3.9Inhaltliche Strukturierungshilfsmittel

3.9.1Themes

3.9.2Epics und Features

4Requirements-Validierung und -Abstimmung

4.1Verfeinerung von Anforderungen

4.1.1Backlog Refinement

4.1.2Refinement-Meeting

4.2Machbarkeitsanalyse

4.2.1Technische und funktionale Analyse mit Spikes

4.2.2Organisatorische und personelle Machbarkeit

4.3Ermitteln von Geschäftswert und Nutzen

4.3.1Messung des Nutzens

4.3.2Das Kano-Modell

4.3.3Ordnung nach relativem Nutzen

4.3.4Abstrakter Geschäftswert (Business Value)

4.3.5MVP – Minimum Viable Product

4.3.6MMP – Minimum Marketable Product

4.4Risikobewertung

4.4.1Risiken identifizieren und bewerten

4.4.2Maßnahmen planen

4.4.3Risiken überwachen und steuern

4.5Aufwands- und Kostenschätzung

4.5.1Aufwandsschätzung in nicht agilen Softwareprojekten

4.5.2Prinzipien agiler Schätzungen

4.5.3Schätzen im Projektverlauf

4.5.4Schätztechniken

4.5.5Ermitteln von Aufwand und Kosten aus Story Points

4.6Bewertung der Qualität der Anforderungen

4.7Priorisierung

4.7.1Prioritätsskala

4.7.2Basis für die Priorisierung

5Qualität im Requirements Engineering

5.1Qualitätskriterien für Requirements

5.1.1Qualitätskriterien nach IEEE 830-1998 und IREB

5.1.1.1Qualitätskriterien für einzelne Anforderungen

5.1.1.2Qualitätskriterien für mehrere Anforderungen

5.1.2DEEP-Qualitätskriterien

5.1.3INVEST-Qualitätskriterien

5.2Definition of Ready (DoR)

5.2.1Definition of Ready für einen einzelnen Backlog-Eintrag

5.2.2Definition of Ready für eine übergreifende Prüfung

5.3Definition of Done (DoD)

5.4Review von Requirements

5.5Produktvalidierung

6Requirements Management

6.1Allgemeines

6.2Inhalt vs. Management des Inhalts

6.3Requirements-Management-Aktivitäten

6.4Planende Aktivitäten des Requirements Management

6.4.1Portfolio- und Programmplanung

6.4.2Produkt-Roadmap, Delivery Roadmap

6.4.3Produktplanung

6.4.4Releaseplanung

6.4.5Sprint-Planung

6.4.6Daily Scrum

6.5Artefakte für das Requirements Management

6.5.1Backlog

6.5.2Listen

6.5.3Story Maps – Story Cards

6.5.4Agiles Requirements-Board

6.5.5Taskboard

7Organisatorische Aspekte

7.1Einfluss der Organisation

7.2Agile Entwicklung im nicht agilen Umfeld

7.2.1Interaktion mit Stakeholdern außerhalb der Softwareorganisation

7.2.2Produkt- vs. Projektorganisation

7.2.3Die Rolle des Managements im agilen Kontext

7.3Skalierung

7.3.1Motivation für die Skalierung

7.3.2Ansätze für das Organisieren von Teams

7.3.3Ansätze für das Organisieren der Kommunikation

7.3.4Frameworks für das Skalieren von RE@Agile

7.3.5Einfache skalierte Entwicklungsorganisation

7.3.6Kriterien für die Strukturierung von Anforderungen und Teams im Großen

7.3.7Auswirkungen der Skalierung auf RE@Agile

7.4Vorab- und kontinuierliche Aufgaben des Requirements Engineering im Zusammenhang mit Skalierung

7.4.1Initiale Requirements-Definition

7.4.2Detaillierungsgrad für Backlog Items

7.4.3Validität von Backlog-Einträgen

7.4.4Feedback zum Backlog und dessen Aktualisierung

7.4.5Zeitlicher Ablauf des Entwicklungszyklus

8Requirements-Engineering-Rollen

8.1Product Owner

8.1.1Product Owner als Stellvertretung des Kunden im Team

8.1.2Unterschiedliche Product-Owner-Verantwortlichkeiten im skalierten Umfeld

8.1.3Schwierige Ausprägungen von Product Ownern

8.2Chief Product Owner (CPO)

8.2.1Der Chief Product Owner als Dirigent mehrerer Teams

8.2.2Schwierige Ausprägungen des Chief Product Owners

8.3Agile Entwickler

8.3.1Die Entwickler als Umsetzer und Berater des Product Owners

8.3.2Schwierige Ausprägungen bei den Entwicklern

8.4Agile Master

8.4.1Agile Master als Coach und Problemlöser

8.4.2Schwierige Ausprägungen von Agile Masters

8.5Tester

8.5.1Der Tester als Prüfer und Qualitätsberater

8.5.2Schwierige Ausprägungen von Testern

8.6Architekt

8.6.1Der Architekt als beratende Person für das Gesamtsystem

8.6.2Schwierige Ausprägung beim Architekten

9Rechtliche Themen

9.1Allgemeine rechtliche Aspekte

9.2Vertragsbasis und Vertragserfüllungspflicht

9.3Gewährleistung

9.4Agile Vorgehensweisen und Festpreis

9.5Das Vier-Stufen-Modell für agile Festpreisprojekte

9.5.1Stufe 1: Definition der Projektziele und ersten Kundenanforderungen

9.5.2Stufe 2: Agiles Erstellen der Vertragsbasis

9.5.3Stufe 3: Festpreisangebot durch den Lieferanten

9.5.4Stufe 4: Agile Projektabwicklung

9.6Öffentliche Ausschreibungen

9.7Standards und Normen

9.8Absicherung der Auftraggeberin

9.9Absicherung des Lieferanten

Anhang

AAgile Methoden zur Unterstützung des Requirements Engineering

A.1Specification by Example

A.2Test Driven Development

A.3Behavior Driven Development

BRollenbeschreibungen – Beispiele

B.1Product Owner (PO)

B.2Chief Product Owner (CPO)

B.3Feature & Component Owner (FO, CO)

B.4Proxy Product Owner (PPO)

CAbkürzungen

DGlossar

ELiteratur

Index

1Einleitung und Motivation

1.1Fokus dieses Buches

Der Fokus dieses Buches liegt auf einer unvoreingenommenen Betrachtung von guten Methoden und Techniken – egal welchen Alters oder welcher Ausrichtung – für die Anwendung des Requirements Engineering in agilen Projekten, um einen Nutzen für die Projektarbeit zu stiften.

Nachhaltiges, systematisches und praxisorientiertes Requirements Engineering in der agilen Softwareentwicklung steht dabei im Vordergrund und nicht die wissenschaftlich vollständige Aufarbeitung.

Abgerundet wird das Buch durch die Behandlung von Qualitätsaspekten für Requirements, organisatorische Aspekte sowie durch rechtliche Aspekte bei der Anwendung von Requirements im agilen Umfeld.

1.1.1Zielgruppen

Das Buch richtet sich an Product Owner, Produktverantwortliche, Projektleitung, Softwareauftraggeberin, Scrum Master, Entwicklerinnen, Tester und alle anderen Personen, die sich mit nachhaltigem und systematischem Requirements Engineering und Requirements Management in der agilen Softwareentwicklung beschäftigen oder davon betroffen sind.

Folgende Zielgruppen werden primär durch den Lehrplan [IREB RE@Agile Primer] wie auch [IREB RE@Agile AL] adressiert:

Requirements Engineers, die sich mit agiler Entwicklung befassen und ihre Techniken in dieser Umgebung erfolgreich anwenden möchten.

Requirements Engineers, die etablierte Konzepte und Techniken agiler Ansätze anwenden und ihre Requirements-Engineering-Prozesse verbessern möchten.

Fachkräfte für agile Entwicklungsprozesse, die die Werte und Vorteile des Requirements Engineering in agilen Projekten verstehen möchten.

Fachkräfte für agile Entwicklungsprozesse, die die agile Entwicklung durch bewährte Requirements-Engineering-Techniken und -Methoden verbessern möchten.

Personen aus verwandten Disziplinen – IT-Management, Tester, Entwicklerinnen, Architekten und andere Vertreter im Bereich der Entwicklung (überwiegend, aber nicht ausschließlich Softwareentwicklung) –, die verstehen möchten, wie sie Requirements-Engineering- und agile Ansätze in Entwicklungsprozessen erfolgreich kombinieren können.

1.1.2Abbildung des Lehrplans IREB CPRE RE@Agile Primer

[IREB RE@Agile Primer]

Seit 2017 gibt es den Lehrplan CPRE RE@Agile Primer des International Requirements Engineering Board (IREB®), der die Lücke zwischen Requirements-Engineering-Methoden und agilen Methoden schließt.

Einerseits wird die Sicht des IREB-Standards auf agile Werte abgebildet und andererseits wird eine agile Sicht auf die Werte des Requirements Engineering dargestellt. Zum Inhalt des Lehrplans CPRE RE@Agile Primer gehören Klassifizierung und Beurteilung von Requirements-Engineering-Artefakten und -Techniken im Zusammenhang mit Agilität, agilen Artefakten und Techniken, Requirements Engineering und wesentlichen Prozesselementen in der agilen Produktentwicklung. Das Modul RE@Agile Primer zeigt die Motivation für die Verwendung agiler Methoden in Entwicklungsprozessen auf und betont die Synergie zwischen Requirements Engineering und Agilität.

Da dieses Buch viele ergänzende und vertiefende Inhalte umfasst, die nicht im Lehrplan CPRE RE@Agile Primer enthalten sind, ist in einigen Bereichen eine andere Strukturierung gegeben. Nachfolgend sind ein erster Überblick und einige Hinweise angeführt, wo in diesem Buch die wichtigsten Inhalte des Lehrplans zu finden sind:

Lehrplan RE@Agile Primer

LE

in diesem Buch

LE 1Motivation und Denkweisen

1.11.2

Abschnitt 1.2

Abschnitt 1.2.1

1.3

Abschnitt 1.1.4

und

1.2.2

1.4

Abschnitt 1.2.5

,

1.2.6

und

1.2.7

1.5

Abschnitt 2.1.3

LE 2Grundlagen von RE@Agile

2.1

Abschnitt 2.1

und

3.2.2

2.2

Abschnitt 2.1.2

2.3 – 2.7

Abschnitt 2.2

LE 3Artefakte und Techniken in RE@Agile

3.1

Abschnitt 3.1

mit den

Abschnitten 3.1.1

bis

3.1.8

Abschnitte 3.2.2

und

3.2.3

3.2

Abschnitt 3.1

mit den

Abschnitten 3.1.9

und

3.1.10

Die Einleitungen von

Kapitel 4

und

6

LE 4Organisatorische Aspekte von RE@Agile

4.1

Abschnitt 7.1

4.2

Abschnitt 7.2

4.3

Abschnitte 7.3

und

7.4

LE 5Begriffsdefinitionen, Glossar

Siehe auch [

IREB Glossar

] und [

IREB RE@Agile Glossar

]

Wenn die Bezeichnung »RE@Agile« als Kurzbegriff verwendet wird, so bezieht sich dies immer auf den Lehrplan [IREB RE@Agile Primer].

Weiterführende Literatur zu den Themen Requirements Engineering und agile Vorgehensweisen ist im Literaturverzeichnis im Anhang E des Buches zu finden.

1.1.3Abbildung des Lehrplans IREB CPRE Advanced Level RE@Agile – Practitioner/Specialist

[IREB Advanced Level RE@Agile – Practitioner/Specialist]

Der Lehrplan IREB CPRE Advanced Level RE@Agile wurde in Version 2 im Sommer 2022 veröffentlicht und richtet sich an Requirements Engineers und Experten für agile Entwicklungsprozesse. Der Schwerpunkt liegt auf dem Verständnis und der Anwendung von Verfahren und Techniken aus der Disziplin des Requirements Engineering in agilen Entwicklungsprozessen sowie auf dem Verständnis und der Anwendung von Konzepten, Techniken und essenziellen Prozesselementen agiler Ansätze in Requirements-Engineering-Prozessen. Die Zertifizierung versetzt Personen mit Requirements-Engineering-Kenntnissen in die Lage, in agilen Umgebungen zu arbeiten, und Experten für agile Entwicklungsprozesse erlaubt sie, bewährte Requirements-Engineering-Verfahren und -Techniken in agilen Projekten anzuwenden.

Wie bei allen anderen Advanced-Level-Modulen des IREB CPRE-Ausbildungsmodells ist das Zertifikat CPRE FL (Foundation Level) eine Voraussetzung für die Teilnahme an den Advanced-Level-Zertifizierungsprüfungen zum RE@Agile – Practitioner und RE@Agile – Specialist. Zudem wird dringend angeraten, dass Teilnehmende mindestens über ein Zertifikat für agile Entwicklung (d.h. RE@Agile Primer oder ein Scrum-Zertifikat) verfügen oder vergleichbare Kenntnisse über agile Ansätze besitzen.

Da dieses Buch viele ergänzende und vertiefende Inhalte umfasst, die nicht im Lehrplan IREB CPRE Advanced Level RE@Agile – Practitioner/Specialist enthalten sind, ist in einigen Bereichen eine andere Strukturierung gegeben. Nachfolgend sind ein erster Überblick und einige Hinweise angeführt, wo in diesem Buch die wichtigsten Inhalte des Lehrplans für das Modul Advanced Level RE@Agile zu finden sind:

Lehrplan Advanced Level RE@Agile – Practitioner/Specialist

LE

in diesem Buch

LE 1Was ist RE@Agile

1

Abschnitt 1.2.3

LE 2Projekte erfolgreich starten

2.1

Abschnitt 3.2.2

2.2

Abschnitt 3.2.3

2.3

Abschnitt 3.2.4

2.4

Abschnitt 3.2.1

LE 3Umgang mit funktionalen Anforderungen

3.1

Abschnitt 3.9

, Einleitung

3.2

Abschnitt 3.1.9

, zweiter Teil

3.3

Abschnitte 3.4.2

und

5.1.3

3.4

Abschnitt 3.4.2

, erster Unterabschnitt

3.5

Abschnitt 3.4.2

, zweiter Unterabschnitt

3.6

Abschnitt 3.1.10

LE 4Umgang mit Qualitätsanforderungen und Randbedingungen

4.1

Abschnitt 3.4.3

4.2

Abschnitt 3.4.3.1

4.3

Abschnitt 3.4.3.3

4.4

Abschnitt 3.4.3.2

LE 5Priorisieren und Schätzen von Anforderungen

5.1

Abschnitt 4.3

5.2

Abschnitt 4.4

, Einleitung

5.3

Abschnitte 4.5.2

und

4.5.4

, zweiter und dritter Unterabschnitt

LE 6Skalierung von RE@Agile

6.1

Abschnitt 7.3.4

6.2

Abschnitt 7.3.6

6.3

Abschnitt 6.4.2

6.4

Abschnitt 5.5

Begriffsdefinitionen, Glossar

Siehe auch [

IREB Glossar

] und [

IREB RE@Agile Glossar

]

Generell gilt für Verweise auf die IREB-Lehrpläne: Wenn der Verweis direkt unter einer Kapitel- oder Unterkapitelüberschrift steht, ist das ganze Kapitel oder Unterkapitel von Bedeutung. Wenn der Verweis im Fließtext steht, ist dies bis zum nächsten Verweis bzw. zur nächsten Kapitel- oder Unterkapitelüberschrift relevant.

1.1.4Allgemeine Begriffseinordnung

[IREB RE@Agile] LE 1.3

Das umfangreiche Wissen in der Softwarebranche wird in unterschiedlichen Abstraktionsebenen beschrieben: [Meyer 2014] unterscheidet zwischen Prinzipien, Praktiken/Verfahren und Techniken. Diese Ebenen werden durch die Begriffe »präskriptiv« (vorschreibend), »abstrakt« und »falsifizierbar« (widerlegbar) unterschieden (siehe auch das Glossar im Anhang D des Buches).

Abb. 1–1Abstraktionsebenen beim Wissen über die Softwareentwicklung

Ein »Prinzip« ist eine präskriptive Aussage, die abstrakt und falsifizierbar ist. Ein Prinzip ist z. B. »Prüfe die Requirements vor der Implementierung auf ausreichende Qualität«. Dies ist präskriptiv, da eine Aktion vorgegeben wird. Und es ist abstrakt, da keine konkreten Praktiken oder Techniken, die verwendet werden sollen, vorgegeben werden. Diesem Prinzip kann in bestimmten Situationen auch widersprochen werden. Zum Beispiel könnte es in einer Forschungssituation sinnvoll sein, ohne vorherige Requirements-Spezifikation mehrere Prototypen zu erstellen und diese gegeneinander zu validieren. Dieses Prinzip ist somit auch falsifizierbar. Die Kenntnis der Prinzipien ist wichtig, um bewusste Entscheidungen treffen zu können. Die Falsifizierbarkeit ist wichtig, um Diskussionen und Nachdenken über Prinzipien und auch Praktiken in Gang zu bringen und zu entscheiden, ob diese in einem bestimmten Kontext angewendet werden sollen.

Ein »Verfahren« oder auch »Praktik« ist ebenfalls präskriptiv, jedoch nicht so abstrakt, sondern eine konkretere »Instanz« des Prinzips in einem bestimmten Kontext, die Hinweise auf die Umsetzung des Prinzips gibt, ohne jedoch die tatsächliche Durchführung einer Aktivität zu beschreiben. Zum Beispiel »Prüfe jedes Backlog Item gegen die ›Definition of Ready‹, bevor es in das Sprint Backlog eingefügt wird« ist eine allgemeine Praktik, die schon konkret bestimmte Artefakte (Backlog Items, DoR und Sprint Backlog) zur Verwendung anspricht (die Begriffe werden in den Kapiteln dieses Buches erläutert – siehe auch den

Index

im Anhang des Buches). Abhängig von der jeweiligen Situation und Kontext können auch jeweils unterschiedliche Praktiken zur Erfüllung eines Prinzips angewendet werden.

Eine »Technik« ist eine Konkretisierung der Umsetzung des Verfahrens bzw. der Praktik wie z. B. »Teste durch die Verwendung von Unit Tests«.

Eine »Aktivität« ist die reale Umsetzung eines Verfahrens/einer Praktik bzw. Technik wie z. B. »Erstelle die Unit Tests für die Funktion ›Neukunden anlegen‹«.

Sowohl der Lehrplan [IREB RE@Agile] als auch dieses Buch mit seinen erweiterten Ausführungen und Inhalten vermitteln Wissen von Requirements Engineering im Kontext der agilen Vorgehensweisen und stellen diese Abstraktionselemente in sachlicher Form vor bzw. regen zum Nachdenken und zur Diskussion über deren Anwendbarkeit an.

1.2Verbindung zwischen RE und agilem Vorgehen

[IREB RE@Agile Primer] LE 1.1

Heute ist die Software und IT ein »Enabler« und Treiber in vielen Bereichen. Viele über lange Jahre etablierte plangetriebene Entwicklungsmethoden wurden nicht für ein sich schnell änderndes Umfeld ausgelegt. Agile Methoden (siehe auch Abschnitt 2.1) haben sich hier mittlerweile etabliert und schließen diese Lücke.

»Agile« oder »Agilität« wird in [Sheppard & Young 2006] wie folgt definiert: »A rapid whole-body movement with change of velocity or direction in response to a stimulus.«

Die Motivation für die Verwendung agiler Methoden ist hier definiert als Reaktion (z. B. eine schnelle Veränderung der Ausrichtung oder der Umsetzungsgeschwindigkeit) auf eine Stimulation (z. B. aus dem Projektumfeld).

Wenn man sich das Agile Manifest [Agile Manifesto] und die agilen Methodenbeschreibungen durchliest, dann geht es darin um mehr als nur Schnelligkeit. Im Grunde fokussieren alle agilen Prinzipien und Vorgehensweisen auf eine Lieferung von für die Kunden nützlichen Ergebnissen in kurzen, kontrollierten Intervallen.

Agile Methoden oder Agilität sind jedoch kein Selbstzweck. Nicht in allen Situationen passt dieses Vorgehen gleich gut. Wenn z. B. längerfristige Planung, Vorhersagbarkeit oder Nachvollziehbarkeit erforderlich ist, müssen ggf. andere Vorgehensweisen oder Anpassungen der agilen Methoden angewendet werden.

Es ist daher wichtig, im Vorfeld darüber nachzudenken und ein passendes bzw. angepasstes Entwicklungsvorgehen zu wählen. Dies kann grundsätzlich auch dazu führen, dass in unterschiedlichen Teams entsprechend dem jeweiligen Bedarf unterschiedliche Vorgehensweisen oder auch Kombinationen aus agilen und plangetriebenen Vorgehensweisen angewendet werden (z. B. wenn im Maschinenbau in der Hardwareentwicklung plangetriebenes Vorgehen und in der dazugehörenden Softwareentwicklung agiles Vorgehen in Kombination eingesetzt werden). Gartner hat dafür den Begriff »bimodale IT« geprägt. Dieses angepasste pragmatische Vorgehen ist auch einer der wesentlichen Erfolgsfaktoren der Softwareentwicklung und IT in dem heute sehr dynamischen Umfeld.

1.2.1Denkweisen und Werte im RE und agilen Vorgehen

[IREB RE@Agile Primer] LE 1.2 und Einleitung

Requirements Engineering (RE)

In der IREB-Definition von Requirements Engineering sind Denkweisen und Werte von Requirements Engineering angegeben:

Requirements Engineering ist eine systematische und disziplinierte Herangehensweise zur Spezifikation und zum Management von Anforderungen mit den folgenden Zielen:

Die relevanten Anforderungen kennen, einen Konsens zwischen den Stakeholdern dieser Anforderungen erreichen, konform zu vorgegebenen Standards dokumentieren und die Anforderungen systematisch managen.

Die Wünsche und Bedürfnisse der Stakeholder verstehen und dokumentieren.

Die Anforderungen spezifizieren und managen, um ein System auszuliefern, das möglichst weitgehend den Wünschen und Bedürfnissen der Stakeholder entspricht.

Im Lehrplan des IREB CPRE Foundation Level sind die vier Hauptaktivitäten des Requirements Engineering definiert:

Ermittlung,

Dokumentation,

Validierung und

Verwalten von Anforderungen.

Diese bilden keinen Prozess oder eine vorgegebene Folge von Aktivitäten, sondern stellen einen prozessunabhängigen Ansatz dar. Es sind Aktivitäten, die unabhängig von der gewählten Vorgehensweise durchgeführt werden sollen. In jeder dieser Aktivitäten des Requirements Engineering gibt es verschiedene Methoden und Techniken, die in allen Vorgehensweisen – sowohl in nicht agilen als auch in agilen – angewendet werden können. Dabei gibt es natürlich Unterschiede in den Detailausprägungen der angewandten Methoden und Techniken.

Zu beachten ist auch, dass im Requirements Engineering grundsätzlich von »System« gesprochen wird und nicht von Software, Produkt, Hardware, Prozess oder sonstigen spezifischen Begriffen. »System« umfasst all diese Begriffe und bedeutet, dass dieses System eine Gruppe von Teilen oder Elementen umfasst, die in einer Umgebung (»Systemkontext«) zusammenwirken.

Agiles Umfeld

Der Ausdruck »agile Methoden« referenziert auf ein umfangreiches Set an Vorgehensweisen, die sich im Umfeld von »Agile« entwickelt haben (siehe auch Kap. 2). Für andere Entwicklungsmethoden wird auch der Ausdruck »plangetrieben« oder »nicht agile Methoden« verwendet.

Die verschiedenen Methoden sind in unterschiedlichen Kontexten unterschiedlich wirksam und haben jeweils Anwendungsbereiche, in denen sie sinnvoll und wertschöpfend anzuwenden sind.

Das Mindset von »Agile« ist im »Agilen Manifest« [Agile Manifesto] und den darauf basierenden zwölf Prinzipien definiert. Im Februar 2001 traf sich eine Gruppe von 17 Personen in den Bergen von Utah, um über die Gemeinsamkeiten von verschiedenen Ansätzen der Softwareentwicklung zu diskutieren. Diese Gruppe nannte sich »The Agile Alliance« [Agile Alliance] und das Ergebnis dieses Meetings waren der Begriff »agil« und das »Agile Manifest« [Agile Manifesto].

Das Agile Manifest besteht aus vier Leitsätzen und zwölf Prinzipien, die die Leitsätze erläutern. Es ist das Fundament für agiles Arbeiten und damit für alle agilen Methoden.

Manifest für Agile Softwareentwicklung:

Wir erschließen bessere Wege, Software zu entwickeln, indem wir es selbst tun und anderen dabei helfen.

Durch diese Tätigkeit haben wir diese Werte zu schätzen gelernt:

Individuen und Interaktionen mehr als Prozesse und WerkzeugeFunktionierende Software mehr als umfassende DokumentationZusammenarbeit mit dem Kunden mehr als VertragsverhandlungReagieren auf Veränderung mehr als das Befolgen eines Plans

Das heißt, obwohl wir die Werte auf der rechten Seite wichtig finden, schätzen wir die Werte auf der linken Seite höher ein.

Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas

Die zwölf Prinzipien hinter dem Agilen Manifest:

Wir folgen diesen Prinzipien:

Unsere höchste Priorität ist es, die Kunden durch frühe und kontinuierliche Auslieferung wertvoller Software zufrieden zu stellen.Heiße Anforderungsänderungen selbst spät in der Entwicklung willkommen. Agile Prozesse nutzen Veränderungen zum Wettbewerbsvorteil des Kunden.Liefere funktionierende Software regelmäßig innerhalb weniger Wochen oder Monate und bevorzuge dabei die kürzere Zeitspanne.Stakeholder und Entwickler müssen während des Projekts täglich zusammenarbeiten.Errichte Projekte rund um motivierte Individuen. Gib ihnen das Umfeld und die Unterstützung, die sie benötigen, und vertraue darauf, dass sie die Aufgabe erledigen.Die effizienteste und effektivste Methode, Informationen an und innerhalb eines Entwicklungsteams zu übermitteln, ist im Gespräch von Angesicht zu Angesicht.Funktionierende Software ist das wichtigste Fortschrittsmaß.Agile Prozesse fördern nachhaltige Entwicklung. Die Auftraggeber, Entwickler und Benutzer sollten ein gleichmäßiges Tempo auf unbegrenzte Zeit halten können.Ständiges Augenmerk auf technische Exzellenz und gutes Design fördert Agilität.Einfachheit – die Kunst, die Menge nicht getaner Arbeit zu maximieren – ist essenziell.Die besten Architekturen, Anforderungen und Entwürfe entstehen durch selbstorganisierte Teams.In regelmäßigen Abständen reflektiert das Team, wie es effektiver werden kann, und passt sein Verhalten entsprechend an.

Das Agile Manifest ist ein Meilenstein in der Geschichte der Softwareentwicklung. Es gab bisher nur wenig Literatur, die so große Auswirkungen auf die Softwareentwicklung hatte wie dieses kurze Dokument. Heute kann man sagen, dass das Agile Manifest und seine Prinzipien praktisch alle Bereiche der Softwareentwicklung erreicht haben. Auf Basis des Agilen Manifests haben sich verschiedene Vorgehensweisen etabliert wie z. B. Scrum, Kanban, Extreme Programming, Feature Driven Development oder Test Driven Development.

Bei den agilen Vorgehensweisen stehen das Ergebnis und der Wert für die Kunden im Vordergrund. Anstelle einer einmaligen umfassenden Vorausplanung wird eine ständig rollierende Planung in Verbindung mit schnellem Feedback durch kurze Iterationen zur Risikominimierung verwendet. Dies zielt darauf ab, dass der Kunde möglichst rasch ein erstes Ergebnis ansehen und am besten auch gleich verwenden kann. Ein starker Fokus liegt auf Transparenz, Kommunikation und einem Team, das sich selbst steuert.

Neben diesen im Agilen Manifest und in Vorgehensmodellen wie Scrum explizit genannten Werten und Themen gibt es viele weitere Aspekte in der Softwareentwicklung, die in einem Projekt berücksichtigt werden müssen, auch wenn sie nicht durch die agilen Basiskonzepte explizit abgedeckt sind. Bereiche wie Risikomanagement, Testen und eben auch Requirements Engineering sind nach wie vor kritisch für den Erfolg von Softwareprojekten.

Für die erfolgreiche Einführung und den Einsatz agiler Vorgehensweisen ist es daher wichtig, dass einerseits eine Ausrichtung des Teams bzw. der Organisation an den agilen Werten und einer disziplinierten Anwendung der Regeln der von der Organisation gewählten agilen Vorgehensweise erfolgt und andererseits auch alle anderen für den Erfolg wesentlichen Themen berücksichtigt werden, sodass diese in einer sinnvollen Art und Weise zu einem effektiven Framework für die Softwareentwicklung integriert werden.

1.2.2Zusammenhang zwischen RE und Agile

[IREB RE@Agile Primer] LE 1.3

Die Aussagen, Methoden und Werte zwischen Requirements Engineering und agilen Vorgehensweisen stehen nicht im Widerspruch zueinander, auch wenn dies manchmal so vermutet wird oder dies aus manchen Grundprinzipien heraus so interpretiert wird.

Requirements Engineering hat wie oben erwähnt den Fokus auf der systematischen Ermittlung, Spezifikation und dem Management von Anforderungen unabhängig vom Detaillierungsgrad und der Phase, in der man sich im Projekt befindet.

Agile Vorgehensweisen fokussieren primär auf ein lauffähiges Produkt und stellen Individuen und Kommunikation höher als einen Prozess und Tools. Sie bieten ein Mindset und Methoden in der Projektabwicklung und Teamsteuerung, ohne spezifisch auf das Thema Requirements einzugehen – so enthält z. B. der [Scrum Guide] nichts zum Thema Spezifikation von Anforderungen. Dies besagt nicht, dass in agilen Projekten keine Spezifikation erforderlich oder sinnvoll ist. Es wird ja im Scrum Guide auch nichts zu Risikomanagement, Versionsverwaltung, Konfigurationsmanagement, Continuous Integration und anderen Themen vorgegeben und doch ist es sinnvoll, auch in agilen Softwareprojekten diese Themen in den Projekten zu berücksichtigen.

Eine übertriebene bzw. dogmatische Betrachtung von Grundsätzen und Prinzipien führt typischerweise zu Konflikten. Es ist daher eine sehr eingeschränkte Sichtweise, wenn man meint, dass es durch Requirements Engineering möglich ist, ein vollständiges, konsistentes und abgestimmtes Requirements-Dokument zu erstellen, das dann noch ohne künftige Änderungen umgesetzt wird. Dies ist außer bei ganz kleinen Projekten in der Praxis nicht der Fall.

Eine ebenso eingeschränkte Sicht ist es, wenn man meint, dass durch agile Prinzipien ein Entwicklungsprojekt ohne irgendwelche vorbereitenden Arbeiten oder begleitenden Prozesse gestartet und ausschließlich durch regelmäßige Auslieferung von Software und Verbesserungen aufgrund des Feedbacks durch die Stakeholder erfolgreich implementiert werden kann. Auch hier gelingt dies nur unter »Laborbedingungen« und in sehr kleinen Projekten.

Abb. 1–2Mindset- und Werteüberschneidung zwischen Requirements Engineering und Agile (nach [IREB RE@Agile Primer])

Requirements Engineering und agile Vorgehensweisen fokussieren grundsätzlich auf verschiedene Bereiche und sind damit in großen Teilen nicht überschneidend. Das Verbindende zwischen ihnen ist jedoch ganz klar der Fokus darauf, dass eine bedarfsgerechte und nützliche Lösung entwickelt und der Kunde zufriedengestellt wird.

Der [IREB RE@Agile Primer] fokussiert auf diese Gemeinsamkeiten zwischen Agilität und RE und nennt einige wesentliche verbindende und zentrale Prinzipien:

Requirements-Engineering- und agile Ansätze können voneinander profitieren

Schlanke und in hohem Maße adaptive Prozesse

Wichtig ist die Differenzierung zwischen prädiktiven und adaptiven Entwicklungsprozessen sowie ein schlanker und hochgradig adaptiver Ansatz für die Durchführung von Requirements-Engineering-Aktivitäten im Rahmen agiler Entwicklungen.

Enge Zusammenarbeit mit dem Team und mit zentralen Stakeholdern und »Just-in-Time-Anforderungen«

Häufiger Austausch und enge Zusammenarbeit zwischen allen Teammitgliedern und wichtigen Stakeholdern sowie die Analyse, Verfeinerung und Dokumentation der Anforderungen auf hochgradig interaktive Art und Weise sind für den Erfolg relevant.

Situative und selektive Anforderungsermittlung, Analyse, Spezifikation und Verfeinerung

Nicht jede Anforderung muss präzise und in einem hohen Detaillierungsgrad vor der Implementierung eines Systems spezifiziert werden, sondern nur sehr komplexe oder kritische Anforderungen.

Weniger relevante Aktivitäten und Funktionalitäten vermeiden und das Minimum Viable Product sicherstellen

»Einfachheit« ist das Prinzip in der ersten Phase einer System- oder Produktentwicklung. Das MVP (Minimum Viable Product) ist ein klar abgegrenztes, bereitstellbares System mit hinreichendem betriebswirtschaftlichem Wert, das lediglich grundlegende Merkmale aufweist, um validiertes Lernen zu ermöglichen. Überflüssiges soll vermieden und schnelleres Kundenfeedback eingeholt werden. MMP (Minimum Marketable Product) ist eine Weiterführung des MVP mit mehr Fokus auf Nutzung und Vermarktung. RE@Agile [IREB RE@Agile Primer] beantwortet zwei sehr wichtige Fragen: »Wie lassen sich das Release-Management und der Produktdefinitionsprozess vereinfachen?« und »Wie definiert man das MVP oder das MMP auf Basis der Anforderungen?«.

Requirements Engineering und die agilen Vorgehensweisen widersprechen sich nicht und überlappen sich nur in wenigen Punkten. Beiden gemeinsam ist, dass für die Kunden Wert in Form von lauffähiger, qualitativ guter Software geschaffen wird und sie zufriedengestellt werden.

Agile Methoden helfen dabei, dass lauffähige Software effizient und schnell erstellt wird. Requirements Engineering stellt gute Techniken zur Verfügung, um die Bedürfnisse der Stakeholder zu verstehen, damit gute Software im Sinne der Stakeholder entwickelt wird.

Agilität macht die Softwareentwicklung effizient, Requirements-Entwicklung macht die Softwareentwicklung effektiv!

Unter diesem Gesichtspunkt liefert Requirements Engineering einen wesentlichen Beitrag für folgende agile Prinzipien:

1. Prinzip

Requirements Engineering erleichtert das Verstehen der Wünsche und Bedürfnisse, um eine für die Kunden wertvolle Software zu entwickeln.

2. Prinzip

Requirements Engineering erleichtert durch passende Tools das Erkennen von Veränderungen bei Kunden bzw. im Markt, damit die Stakeholder einen Vorteil haben.

4. Prinzip

Requirements Engineering erleichtert durch passende Tools und Techniken die Zusammenarbeit zwischen den Stakeholdern und Entwicklern.

6. Prinzip

Requirements Engineering erleichtert durch passende Tools und Techniken die Kommunikation.

10. Prinzip

Requirements Engineering erleichtert das Verständnis der Stakeholder-Wünsche und -Bedürfnisse und hilft, die Entwicklung von nicht notwendiger Software zu minimieren.

Diese Überlappung und der Zusammenhang von Requirements Engineering und Agilität ist der Bereich, der in diesem Buch und im Lehrplan [IREB RE@Agile Primer] adressiert wird.

Hinweis: Im Lehrplan RE@Agile wird der Begriff »RE@Agile« über den Begriff »agiles Requirements Engineering« gestellt, um damit klarzumachen, dass Requirements Engineering prozessunabhängig ist.

1.2.3Was ist RE@Agile

[IREB Advanced Level RE@Agile – Practitioner/Specialist] LE 1

RE@Agile ist nach [IREB] ein kooperativer, iterativer und inkrementeller Ansatz, der vier Ziele adressiert:

Kenntnis der relevanten Anforderungen auf einem angemessenen Detaillierungsgrad (jederzeit während der Systementwicklung)

Erreichen einer ausreichenden Übereinstimmung über die Anforderungen unter den relevanten Stakeholdern

Erfassen (und Dokumentieren) der Anforderungen gemäß den Rahmenbedingungen der Organisation

Durchführung aller anforderungsbezogenen Aktivitäten nach den Prinzipien des Agilen Manifests [

Agile Manifesto

]

Die Kerngedanken dieser Definition sind:

RE@Agile ist ein kooperativer Ansatz:

Das Produkt häufig überprüfen, Feedback geben und dann basierend auf den neuen Erkenntnissen Anpassungen und Klärungen vornehmen, betont den agilen Gedanken der intensiven Stakeholder-Interaktion [

Agile Manifesto

].

RE@Agile ist ein iterativer Prozess:

Dies legt die Idee von »Just-in-time-Anforderungen« nahe. Anforderungen müssen nicht vollständig sein, bevor mit der technischen Konzeption und Implementierung begonnen wird. Stakeholder können iterativ jene Anforderungen im erforderlichen Detaillierungsgrad definieren (und verfeinern), die zeitnah umgesetzt werden sollen.

RE@Agile ist ein inkrementeller Prozess:

Jene Anforderungen, die den höchsten Geschäftswert liefern oder zur Reduzierung der größten Risiken dienen, sollen in den ersten Inkrementen umgesetzt werden. Hier wird ein Minimum Viable Product (MVP) oder ein Minimum Marketable Product (MMP) angestrebt. Danach fügt man dem Produkt in den weiteren Inkrementen diejenigen Anforderungen hinzu, die den nächsthöheren Nutzen versprechen und somit den Gesamtwert des Ergebnisses bestmöglich steigern.

Das erste Ziel (relevante Anforderungen sind in angemessener Detailtiefe bekannt) bezieht sich wieder auf das iterative Vorgehen: »Relevant« sind jene Anforderungen, die zeitnah umgesetzt werden sollen. Diese müssen sehr genau verstanden werden (einschließlich ihrer Akzeptanzkriterien) – insbesondere von den Entwicklerinnen und sie müssen der »Definition of Ready« (DoR) entsprechen. Sonstige Anforderungen mit einer niedrigeren Priorität können allgemeiner beschrieben und erst dann näher betrachtet und spezifiziert werden, wenn sie an Bedeutung gewinnen und die geplante Umsetzung absehbar ist.

Voraussetzung für das zweite Ziel (ausreichende Übereinstimmung unter den relevanten Stakeholdern) ist es, alle Stakeholder und deren Relevanz für das zu entwickelnde System zu kennen. Die für die Anforderungen verantwortliche Person (normalerweise der Product Owner) muss die Anforderungen mit den relevanten Stakeholdern verhandeln und die Reihenfolge der Umsetzung festlegen.

Agile Ansätze legen mehr Wert auf eine intensive und kontinuierliche Kommunikation über die Anforderungen als auf ihre Dokumentation. Dennoch betont das dritte Ziel (Erfassen und Dokumentieren der Anforderungen gemäß den Rahmenbedingungen) die Bedeutung von Dokumentation in einem angemessenen Detaillierungsgrad (der von Situation zu Situation unterschiedlich ist). Es gibt verschiedene Situationen (für rechtliche Zwecke, zur Rückverfolgbarkeit, für die Wartung usw.), in denen die Dokumentation von Anforderungen hilfreich ist oder auch zwingend existieren muss. Hier müssen auch die agilen Ansätze sicherstellen, dass dies der Fall ist. In vielen Fällen ist es nicht notwendig, die gesamte Dokumentation im Voraus zu erstellen. Wenn die benötigte Dokumentation parallel zur Implementierung oder sogar danach erstellt wird, kann Zeit und Aufwand gespart werden, indem viele Anpassungen von Dokumenten während der Entwicklung des Produkts vermieden werden.

Das Anforderungsmanagement (siehe auch Kap. 6) umfasst alle durchzuführenden Aktivitäten für die fertig vorliegenden Anforderungen und anforderungsbezogenen Artefakte. Dazu gehören:

Versionsverwaltung

Konfigurationsmanagement

Rückverfolgbarkeit zwischen Anforderungen

Rückverfolgbarkeit zu anderen Entwicklungsartefakten

Ein sorgfältiges Management dieser Aktivitäten ist wichtig, um den Aufwand im Rahmen zu halten und ein ausgewogenes Kosten-Nutzen-Verhältnis zu erreichen. Zum Beispiel:

Wenn der Änderungsverlauf der Anforderungen von geringerem Interesse ist als der aktuell gültige Status, dann kann umfangreiches Versionsmanagement mitunter durch schnelle Iterationen zur Erstellung von Produktinkrementen ersetzt werden.

Das iterative Erstellen der einzelnen Sprint Backlogs (also die Gruppierung der Anforderungen, die aktuell den meisten Geschäftswert haben) umfasst auch das Konfigurationsmanagement (Baselining).

1

Verschiedene der zeit- (und papier-)intensiven Anforderungsmanagement-Aktivitäten in nicht agilen Vorgehensweisen können durch Aktivitäten nach agilen Prinzipien ersetzt werden. Damit wird das vierte Ziel (»Durchführung aller anforderungsbezogenen Aktivitäten nach den Prinzipien des Agilen Manifests«) adressiert.

Der Product Owner (PO) trägt die Verantwortung für gutes Requirements Engineering in einem agilen Umfeld. Andere Stakeholder wie Business-Analysten, Requirements Engineers und die Entwicklerinnen sollen den Product Owner bei diesem Prozess unterstützen und erledigen möglicherweise sogar die meiste Arbeit im Zusammenhang mit Requirements Engineering. Im Lehrplan RE@Agile wird der Kürze halber nur der Product Owner als verantwortliche Person für anforderungsbezogene Aufgaben genannt. Dies soll die genannten weiteren Beteiligten dabei keinesfalls ausschließen.

1.2.4RE im Kontext des Agilen Manifests

Im Agilen Manifest selbst steht wenig über Requirements Engineering. Trotzdem haben seine Leitsätze großen Einfluss darauf, wie ein agiles Team mit Anforderungen umgeht:

Individuen und Interaktionen zählen mehr als Prozesse und Werkzeuge

Aus Sicht des Requirements Engineering bezieht sich diese Aussage auf die Interaktion und Kommunikation zur Ermittlung und Abstimmung von Anforderungen sowie auf den Prozess und die Tools zu deren Verwaltung und Dokumentation.

Dass die Interaktion und Kommunikation der Beteiligten und Betroffenen der wichtigste Faktor im Requirements Engineering ist, ist seit Langem bekannt. Wichtig ist es aber auch, die Aussagen der Individuen und die Ergebnisse im Rahmen der Interaktion auf angemessene Art und Weise zu dokumentieren.

Eine große Herausforderung in der Praxis ist die Definition des Requirements-Engineering-Prozesses. Dieser wird oft zu formal und sequenziell beschrieben. Um die Agilität zu gewährleisten, ist es hilfreich, wenn man bei der Prozessdefinition nicht den Prozess insgesamt, sondern nur die einzelnen Teilprozesse und Techniken, wie z. B. Erhebungstechniken, Darstellungstechniken, einzelne Artefakte, Analysemethoden und Managementtechniken, beschreibt und dies dann zu einem modularen, flexibel einsetzbaren Methodenbaukasten zusammenstellt. In Kapitel 4 ist ein Teil eines solchen Baukastens zu finden.

Flexible Requirements-Werkzeuge helfen, das Requirements Engineering agil umzusetzen. Vor allem auch die Integration mit anderen Werkzeugen und das Vermeiden von Brüchen im Entwicklungsprozess sind essenziell für das effiziente Funktionieren des Requirements-Engineering-Prozesses. Microsoft Word und Excel als die am meisten verwendeten Requirements-Werkzeuge sind nicht gerade dazu geeignet, das Requirements Engineering nachhaltig und effizient zu gestalten. Aber auch »echte« Requirements-Management-Werkzeuge haben oft zu starre Prozesse implementiert oder ergehen sich in einer Attributierungsorgie. Die Integration mit anderen Werkzeugen im Entwicklungsprozess ist ebenfalls oft mangelhaft. Insofern ist die Werkzeugfrage auch im agilen Umfeld sehr wichtig.

Funktionierende Software zählt mehr als umfassende Dokumentation

[IREB RE@Agile Primer] LE 1.3

Diese Darstellung führt immer wieder zu der Meinung, dass Dokumentation in agilen Projekten generell nicht befürwortet wird. Das ist eine falsche Interpretation, denn Dokumentation, die einen klaren Zweck und Nutzen für die Kunden hat, wird auch in agilen Methoden befürwortet. »Dokumentation« kann jegliche Art von Anforderungsspezifikation, Architekturdokumenten, Designvorgaben, Prozessdefinitionen, Benutzerdokumentation, Entwicklerkommentaren im Sourcecode etc. sein.

Leider wurden und werden aber in vielen Projekten immer wieder Dokumente erstellt, die keinen klaren Zweck oder Nutzen haben. Dies gilt es zu vermeiden.

Eine lauffähige, für die Kunden nützliche Software zu erstellen, ist natürlich wichtiger, als sich zu stark auf die Dokumentation zu fokussieren und vielleicht ein Produkt zu liefern, das nicht ausreichend funktioniert.

Eine interessante Erkenntnis ergibt sich, wenn man die Kosten der Erstellung einer funktionierenden Software inkl. Sourcecode im Vergleich zu den Dokumentationskosten inkl. Sourcecode-Kommentare in Abhängigkeit vom Dokumentationsgrad betrachtet. Dabei kommt man zu folgendem Ergebnis: Eine umfassende Dokumentation vor der Erstellung der ersten Codezeile macht aus Zeit- und Kostengründen keinen Sinn. Auf die Dokumentation komplett zu verzichten, ist aber ebenfalls keine gute Lösung. Die Kommunikationskosten und die Kosten für zusätzliche unnötige Iterationen werden sonst wegen vergessener Informationen, Spätfolgen durch fehlendes Verständnis für Umsetzungsentscheidungen und fehlende Nachvollziehbarkeit ebenfalls sehr hoch sein (siehe Abb. 1–3).

Abb. 1–3Kostenkurve in der Softwareentwicklung abhängig vom Dokumentationsgrad

Jede Dokumentation unterstützt bis zu einem gewissen Grad die Flexibilität und die Effizienz und bremst diese ab einem gewissen (übertriebenen) Grad.

Es ist daher im Sinne der Flexibilität und Effizienz bei jeder Dokumentation zu überlegen, was der für das jeweilige Projekt optimale Grad ist. Nachfolgend sind beispielhaft einige zentrale Dokumentationsarten angeführt, für die dies gut überlegt werden sollte:

Requirements

Risikoanalysen

Spikes

2

und Machbarkeitsanalysen

Architekturspezifikation

Codekommentare

Testspezifikation und Testdokumentation

Benutzerdokumentation

Prozessdefinition

Methodenbeschreibungen, Guidelines und Checklisten

Dokumentation, speziell Anforderungen, komplett wegzulassen, verursacht zusätzliche Kosten im Projekt! Den richtigen Grad an Dokumentation zu treffen, ist die Kunst guter agiler Projektabwicklung.

Zusammenarbeit mit Kunden zählt mehr als Vertragsverhandlung

Hier geht es um externe Kunden-Lieferanten-Verhältnisse, die typischerweise auf einem Vertrag – welcher Art auch immer – basieren. Die Interpretation des Agilen Manifests ist in diesem Kontext sehr stark von der jeweiligen Projektsituation abhängig. In Projekten, in denen die Kundschaft selbst nicht genau weiß, was sie will, muss die Zusammenarbeit mit ihr sehr intensiv sein. In Projekten, in denen schon ziemlich klar ist, was der Kunde benötigt und dies auch schon vorab gemeinsam definiert wurde, kann die Zusammenarbeit weniger intensiv sein.

Die Intensität der Zusammenarbeit wird auch von der Grundhaltung zwischen Kundschaft und Lieferant stark beeinflusst. Bei Kunden, die partnerschaftlich agieren und zu denen man als Lieferant aufgrund langjähriger Beziehungen großes Vertrauen hat, werden auch kaum intensive Vertragsverhandlungen nötig sein. Umgekehrt ist es genauso. Kundenorientierte Lieferanten werden im Sinne der Kundschaft denken und handeln. Ist dies jedoch nicht der Fall, so sind auch in agilen Projekten gute Verträge hinsichtlich der Risikominimierung und wechselseitigen Klarheit sehr wichtig. Wesentlich ist in allen Fällen, dass der Vertrag und die Spezifikation aufeinander abgestimmt sind (siehe auch Kap. 9).

Reagieren auf Veränderung zählt mehr als das Befolgen eines Plans

Änderungen sind die Normalität in Projekten. Wenn der Kundennutzen durch eine Änderung größer wird, ist eine Änderung auch zu befürworten. Es gibt jedoch Änderungen, die zwar von Kunden gewünscht werden, die aber aufgrund von fehlendem Wissen auf Kundenseite evtl. den Gesamtkundennutzen des Systems reduzieren würden. In solchen Fällen ist es besser, den Kunden die bisher gewählte Umsetzung und die Konsequenzen der Änderung zu erklären und den ursprünglichen Plan weiterzuverfolgen.

Beispiel:

Eine Kundin wünscht sich nach Sichtung des ersten Prototyps, der von der Entwicklung selbstständig mit einfachen Bedienelementen umgesetzt wurde, nun in einer Webmaske eine spezielle Drag-and-Drop-Funktionalität. Dies wäre jedoch nur sehr aufwendig mit den zur Verfügung stehenden Technologien umzusetzen. Möglicherweise würde dadurch der Teil ihrer Systembenutzer ausgeschlossen, der eine ältere Browserversion verwendet oder auf mobilen Geräten arbeitet. Die Änderung nicht umzusetzen ist in diesem Fall die bessere Alternative für die Kundin. Sie stellt in der Bedienung nur unwesentlich mehr Aufwand dar, spart jedoch die hohen Zusatzkosten der Implementierungsänderung und berücksichtigt außerdem alle potenziellen Benutzergruppen. Für die Kundschaft wäre die Änderung aus ihrer Sicht durchaus mit einem Nutzen verbunden. Auch für den Lieferanten, der durch die Zusatzanforderung mehr verrechnen könnte. Für die Kundin insgesamt und für den längerfristigen Nutzen aus dem System hätte es jedoch nachteilige Auswirkungen.

In allen Projekten sollen Änderungen systematisch analysiert und bewertet werden, bevor sie akzeptiert und in das Backlog eingefügt werden. Die Kundschaft sollte auch immer eine Rückmeldung erhalten, ob und warum die Änderung von den anderen Beteiligten (Entwicklung, IT-Betrieb, Marketing etc.) als nutzensteigernd oder nutzenverringernd eingeschätzt wird. Sie kann ja auch im nicht sinnvollen Fall die Änderung trotzdem durchführen lassen – es ist ja schließlich ihr Geld, das dann zusätzlich ausgegeben wird! Diese Tatsache sollte allen Beteiligten bewusst sein.

In der Praxis gibt es kaum Projekte, bei denen Zeit und Geld keine Rolle spielen und die Entwicklerinnen ohne Vorgaben einfach drauflos entwickeln oder Änderungen durchführen können. Es besteht daher in jedem Projekt die Notwendigkeit, zu Beginn zumindest eine grobe Planung und Spezifikation zu erstellen. Die Releaseplanung und das Product Backlog stellen genau solche Pläne dar (siehe Abschnitte 6.4.4 und 6.5.1). So kann man erkennen und nicht nur ahnen, ob bzw. wie weit vom ursprünglich vorgesehenen Ziel und Rahmen abgewichen wird.

Es gilt jedoch auch hier wieder das schon oben erwähnte Prinzip: Nur wenn die Kosten für die Erstellung und Pflege des Plans geringer sind als die Kosten, die sich durch eine unsystematische und schlecht abgestimmte Softwareentwicklung ohne Plan ergeben, sollte ein Plan erstellt und gewartet werden.

Dass sich Pläne ändern, ist ein Faktum. Gute Produkt- und Projektverantwortliche wissen dies und sehen in Änderungen auch nichts Negatives und schon gar kein Versagen ihrer planerischen Fähigkeiten.

Laufende Änderungen sind ein Naturgesetz in der Softwarewelt, das gute Produkt- und Projektverantwortliche akzeptieren und berücksichtigen.

Ein Grundsatz der Planung lautet: Entweder gut oder gar nicht! Wobei hier mit guter Planung nicht gemeint ist, dass das System vorab bis in die letzte Zeile Quellcode vorauszuplanen ist, sondern es geht hier darum, die Wegpunkte auf der Reise zum Ziel festzulegen, an denen man sich immer wieder orientieren kann. Wenn aber ein Plan erstellt wird, dann muss er auch bis zum Ende laufend gepflegt, angepasst und konsistent gehalten werden. Wenn Nachlässigkeit aufkommt und der Plan von den Beteiligten als nicht konsistent angesehen wird, dann ist er wertlos.

1.2.5Nutzen von RE im agilen Vorgehen

[IREB RE@Agile Primer] LE 1.4.1

Übergabeaufwände im Team werden reduziert

Das agile Team soll alle Fähigkeiten und Kompetenzen besitzen, die für die Erlangung der definierten Entwicklungsziele auf Basis der Kundenanforderungen notwendig sind. Dazu gehören neben den Entwicklungs- und Qualitätssicherungskompetenzen auch Fähigkeiten zur Durchführung von Requirements-Engineering-Aufgaben. Durch die direkte Kommunikation im agilen Team erfolgen große Teile des Requirements Engineering und das Beseitigen von Unklarheiten auf direkter Ebene zwischen den Teammitgliedern, wodurch Übergabeaufwände reduziert werden und es vermieden wird, im Voraus eine umfassende Spezifikation der Anforderungen zu erstellen.

Laufende Optimierung bestehender Anforderungen

Das iterativ inkrementelle Vorgehen im agilen Kontext mit seinen regelmäßigen Feedbackschleifen fördert die laufende Anpassung der Ideen und Anforderungen. Bei jeder Sprint-Planung oder jedem Refinement, bei jeder Sprint-Retrospektive und auch zwischendurch wird die Diskussion über die bestehenden Anforderungen durch die Kommunikation in den Iterationen gefördert. Dies kann z. B. nur als grobe Idee oder schon als detailliertere Ausarbeitung in Form von Artefakten stattfinden, wie z. B. einem Prozessmodell, einer User Story, einem Epic, einem Screendesign oder einer Ablaufbeschreibung (siehe auch

Kap. 3

). Dies führt einerseits zu einer passenden Detailliertheit der Requirements entsprechend dem jeweiligen Bedarf und andererseits auch zu besserer Qualität und Nutzen für die Kunden, da ihre Erwartungen mit jedem Inkrement abgeholt und überprüft werden und das weitere Vorgehen entsprechend angepasst werden kann.

Anforderungen reifen und werden validiert

In Scrum (siehe

Abschnitt 2.1.2

) werden Requirements regelmäßig in den Refinement-Meetings weiterentwickelt und durch die Beteiligten hinterfragt und überprüft. Um in das Backlog einer Iteration aufgenommen zu werden, müssen die Requirements den vorab in der Definition of Ready (siehe

Abschnitt 5.2

) festgelegten Qualitätskriterien entsprechen.

Sowohl im agilen Vorgehen als auch im Requirements Engineering stehen die Wünsche und Bedürfnisse der Stakeholder im Fokus. Das agile Vorgehen und dessen Prinzipien unterstützen, fördern und systematisieren die laufende Anpassung und Veränderung der Sichtweise der Stakeholder. Requirements Engineering ist kein einmaliger Prozess, sondern eine Aktivität, die sowohl im agilen als auch im nicht agilen Vorgehen kontinuierlich durchgeführt werden und dadurch diese verändernden Anforderungen und Bedürfnisse der Stakeholder erkennen und entsprechend abbilden soll.

Definition des initialen Product Backlog

In agilen Projekten muss zu Beginn ein initiales Product Backlog erstellt werden (siehe auch

Abschnitt 6.5.1

). Dies erfolgt oft intuitiv. Die Praxis des Requirements Engineering bietet aber ein gutes Set an Techniken und Methoden, um hier effektiver und effizienter vorzugehen und die Erstellung des initialen Backlogs zu erleichtern. Es geht dabei nicht um eine komplett vollständige Spezifikation, sondern um ein ausreichendes Verständnis für das umzusetzende System, den Kontext und die Wünsche der Stakeholder. Darauf basierend kann ein komplexer Sachverhalt (z. B. ein zu digitalisierender Geschäftsprozess) dann in verständliche Anforderungen aufgeteilt werden. Dies kann für jeden einzelnen Teil bzw. jede Anforderung im Backlog auch auf unterschiedlichen Abstraktions- und Spezifikationsebenen passieren (siehe

Abschnitte 3.2

bis

3.6

).

1.2.6Vorurteile und Probleme beim RE im agilen Umfeld

[IREB RE@Agile Primer] LE 1.4.2

Manchmal haben sich aufgrund der früher oft zu einseitigen Betrachtungen sowohl im Requirements Engineering als auch im agilen Umfeld einige Gedankenmuster und Vorurteile festgesetzt, die irreführend sind:

Requirements Engineering ist immer vorgelagert (upfront)