Agiles Requirements- Engineering SEACON 2010 Marcus Winteroll oose GmbH
Marcus Winteroll Berater und Trainer bei oose Thematische Schwerpunkte Agiles Projektmanagement Requirements-Engineering Geschäftsprozessmodellierung Marcus.Winteroll@de
Agenda I. Agilität & Requirements-Engineering II. III. IV. Analyse in den agilen Ansätzen Benutzergeschichten extended version: Story-Maps Der Brückenschlag: Von den Story-Maps zu den klassischen RE-Methoden V. Inhaltliche Releaseplanung VI. Muss ich das jetzt alles machen?
Das Agile Manifest Menschen und Zusammenarbeit vor Prozessen und Werkzeugen Funktionierende Software vor umfassender Dokumentation Zusammenarbeit mit dem Kunden vor vertraglicher Verhandlung Reaktion auf Veränderung vor Einhaltung eines Plans http://www.agilemanifesto.org
Requirements-Engineering-Methoden und Agile Prinzipien Methoden des Requirements Engineering Genau definierter Prozess, um Anforderungen zu erheben unterstützt durch aufwändige RE-Werkzeuge Genaue Dokumentation der Anforderungen in Form eines Lastenhefts oder einer Software Requirement Specification (SRS) Lasten- und Pflichtenhefte als Teil des Vertrages Umgang mit Änderungen: Änderungsantrag, Änderungsprozess, CCB Agile Prinzipien Menschen und Zusammenarbeit vor Prozessen und Werkzeugen Funktionierende Software vor umfassender Dokumentation Zusammenarbeit mit dem Kunden vor vertraglicher Verhandlung Reaktion auf Veränderung vor Einhaltung eines Plans
Requirements-Engineering und Agile Ansätze: die gemeinsamen Ziele Verstehen, was der Kunde wirklich braucht. Mit den richtigen Leuten sprechen ( Stakeholderanalyse). Ziele verstehen ( Produktkarton). Menschen und Zusammenarbeit vor Prozessen und Werkzeugen Das richtige Produkt entwickeln. Anforderungen und Ziele abgleichen ( Verfolgbarkeit). Zusammenhänge verstehen ( Modellierungstechniken). Häufige Rückmeldungen vom Kunden. Funktionierende Software vor umfassender Dokumentation
Requirements-Engineering und Agile Ansätze: die gemeinsamen Ziele Ein gemeinsames Verständnis über die Anforderungen erzielen. Anforderungen gemeinsam mit dem Kunden erarbeiten ( Erhebungstechniken). Häufige Rückmeldungen vom Kunden. Zusammenarbeit mit dem Kunden vor vertraglicher Verhandlung Auf neue Erkenntnisse und ein sich veränderndes Umfeld reagieren. Neue Anforderungen aufnehmen. Vorhandene Anforderungen anpassen ( Auswirkungsanalyse). Reaktion auf Veränderung vor Einhaltung eines Plans
Requirements-Engineering hilft, Anforderungen richtig zu verstehen Analysetechniken dienen vor allem dazu, Anforderungen zu verstehen und darüber zu sprechen. Die Dokumentation ist in agilen Projekten nachrangig (aber häufig sinnvoll). Die Methoden der Anforderungsanalyse können helfen, komplexe Anforderungen zu durchdringen, z.b. mit Hilfe der UML; Anforderungen in ihrem Kontext zu verstehen, z.b. durch die Einbettung in die Geschäftsprozesse; gemeinsam mit dem Kunden über sinnvolle Abläufe nachzudenken, z.b. mit Hilfe von Anwendungsfällen und Aktivitätsdiagrammen; nach Anforderungen zu fischen, z.b. mit Befragungs-, Beobachtungs- und Kreativitätstechniken.
Agenda I. Agilität & Requirements-Engineering II. III. IV. Analyse in den agilen Ansätzen Benutzergeschichten extended version: Story-Maps Der Brückenschlag: Von den Story-Maps zu den klassischen RE-Methoden V. Inhaltliche Releaseplanung VI. Muss ich das jetzt alles machen?
Wozu Benutzergeschichten? Benutzergeschichten geben die Sicht des Nutzers wieder, rücken den Geschäftswert in den Vordergrund, sind einfach zu handhaben, sind keine Behälter, um Anforderungsdetails auf Halde zu legen. Rolf Kühnast/PIXELIO
Benutzergeschichten Story# <Titel> Als ein <Rolle> kann ich <Funktion>, um <Ziel> zu erreichen.
Benutzergeschichten Mitglied anlegen Als ein Back-Office-MA kann ich ein Mitglied anlegen, damit dieses Mitglied dann KFZs reservieren kann.
INVEST Anforderungen an Benutzergeschichten Independent: Können die repräsentierten Anforderungen unabhängig voneinander umgesetzt, getestet und ausgeliefert werden? Negotiable Die Benutzergeschichte ist nur ein Platzhalter für eine Anforderung. Die eigentlichen Inhalte werden in Gesprächen bestimmt. Valuable Lässt sich mit der repräsentierten Anforderung ein geschäftlicher Wert erreichen? Estimable Kann das Team den Aufwand für die Umsetzung schätzen? Small Die repräsentierte Anforderung ist innerhalb einer Iteration umsetzbar? Testable Lässt sich überprüfen, ob die Anforderung auch umgesetzt ist?
Dienen Benutzergeschichten der Analyse? Independent: Können die repräsentierten Anforderungen unabhängig voneinander umgesetzt, getestet und ausgeliefert Nur das werden? Versprechen einer Negotiable Analyse Die Benutzergeschichte ist nur ein Platzhalter für eine Anforderung. Die eigentlichen Inhalte werden in Gesprächen bestimmt. Valuable Diese Anforderungen sind Lässt sich mit der repräsentierten maßgeblich Anforderung für ein die geschäftlicher Größe Wert erreichen? einer Benutzergeschichte, Estimable werden aber durch Kann das Team den Aufwand für die Umsetzung schätzen? Planungsaspekte bestimmt, Small nicht durch Die repräsentierte Anforderung ist innerhalb einer Iteration umsetzbar? Anforderungsanalyse Testable Lässt sich überprüfen, ob die Anforderung auch umgesetzt ist?
Was Benutzergeschichten nicht leisten Die Benutzergeschichten mischen Analyse- und Planungsaspekte. Mit Benutzergeschichten ist es schwierig, den Kontext der übergeordneten Abläufe (Geschäftsprozesse) im Auge zu behalten. Benutzergeschichten geben kein Abstraktionsniveau vor. Benutzergeschichten fördern nicht den Blick aufs Ganze. Benutzergeschichten helfen nicht, komplexe Abläufe (gemeinsam mit dem Kunden) zu durchdringen. Benutzergeschichten unterstützen nicht dabei, die geforderte Unabhängigkeit zu gewährleisten. Benutzergeschichten unterstützen nicht dabei, Widerspruchsfreiheit zu gewährleisten. In Benutzergeschichten wird häufig Problembeschreibung und Lösung vermengt.
Agenda I. Agilität & Requirements-Engineering II. III. IV. Analyse in den agilen Ansätzen Benutzergeschichten extended version: Story-Maps Der Brückenschlag: Von den Story-Maps zu den klassischen RE-Methoden V. Inhaltliche Releaseplanung VI. Muss ich das jetzt alles machen?
Heiner Malchus/PIXELIO Agiles Requirements-Engineering Anforderungen brauchen Kontext Benutzergeschichten stellen einzelne Anforderungen dar. Um einen Gesamtüberblick zu erhalten, müssen diese in einen Kontext gestellt werden. Kontext im agilen Umfeld? Ein Backlog mischt Anforderungen über alle Abstraktionsstufen. Das Backlog enthält keine Kontextinformationen zu den einzelnen Anforderungen.
Jeff Patton Agiles Requirements-Engineering Story-Map Aufgabenbereiche (Activity) Zeit Wichtigkeit Tätigkeiten (Tasks)
Robert Marggraff/aboutpixel Agiles Requirements-Engineering Wie können Story-Maps helfen, die Anforderungen zu verstehen? Mit Story-Maps werden die einzelnen Anforderungen in ihren Kontext gestellt: z.b. Produktfeatures oder Geschäftsprozesse. Story-Maps ermöglichen einen Überblick, über die gesamten Anforderungen. Story-Maps ermöglichen, dass Kunden und Team-Mitglieder die Anforderungen gemeinsam entwickeln. Story-Maps sind einfach zu handhaben. Story-Maps geben nur einen groben Rahmen vor, der sehr flexibel auf die jeweiligen Bedürfnisses eines Projekts angepasst werden kann.
Was Story-Maps nicht leisten Da Story-Maps mit Benutzergeschichten arbeiten, bleiben auch einige Probleme: Die Benutzergeschichten mischen Analyse- und Planungsaspekte. Benutzergeschichten helfen nicht, komplexe Abläufe zu durchdringen. Benutzergeschichten geben kein Abstraktionsniveau vor. Benutzergeschichten unterstützen nicht dabei, die geforderte Unabhängigkeit zu gewährleisten. Benutzergeschichten unterstützen nicht dabei, Widerspruchsfreiheit zu gewährleisten. Volker Loschek/aboutpixel
Agenda I. Agilität & Requirements-Engineering II. III. IV. Analyse in den agilen Ansätzen Benutzergeschichten extended version: Story-Maps Der Brückenschlag: Von den Story-Maps zu den klassischen RE-Methoden V. Inhaltliche Releaseplanung VI. Muss ich das jetzt alles machen?
Story-Map Geschäftsprozesse, Pakete oder Produktfeatures Ungefähre zeitliche Reihenfolge Geschäftswert Anwendungsfälle
Was Anwendungsfälle leisten Anwendungsfälle dienen vor allem der Analyse. Anwendungsfälle bieten die Mittel, auch komplexe Abläufe zu verstehen. Mittels Systemanwendungsfällen wird ein bestimmtes Abstraktionsniveau vorgegeben. Systemanwendungsfälle unterstützen dabei, Abhängigkeiten zu erkennen. Systemanwendungsfälle unterstützen dabei, Widersprüche zu erkennen. Was Anwendungsfälle auch noch leisten: Sicht des Nutzers Geschäftswert wird betrachtet Anforderungsdetails werden nicht auf Halde gelegt
Was bringt die Kombination von Story-Maps mit Anwendungsfällen? Story-Maps helfen, den Blick aufs Ganze zu behalten: bei der Erhebung, beim Schneiden von Releases, bei der Umsetzung, bei der Qualitätssicherung. Story-Maps ermöglichen ein gemeinsames Erarbeiten der Anforderungen durch Kunden und Projektteam. Anwendungsfälle ermöglichen den Anschluss an sehr leistungsfähige Requirements- Engineering-Methoden.
Der Preis Systemanwendungsfälle sind analytisch sehr mächtig ihr Einsatz setzt daher methodische Fertigkeiten eines guten Analytikers voraus. Wem sollte die Analyse nicht überlassen werden? Dem Entwickler, ohne einschlägige Analysekenntnisse (aber gerne Entwickler mit!). Dem Kunden. Dieser bestimmt die Inhalte, jedoch sollte er bei der Analyse geführt werden.
Agenda I. Agilität & Requirements-Engineering II. III. IV. Analyse in den agilen Ansätzen Benutzergeschichten extended version: Story-Maps Der Brückenschlag: Von den Story-Maps zu den klassischen RE-Methoden V. Inhaltliche Releaseplanung VI. Muss ich das jetzt alles machen?
Wozu dienen Releases überhaupt? Durch Releases bekommt der Kunde bereits vor der endgültigen Fertigstellung des Produkts einen Mehrwert geliefert. Mit Hilfe von Releases werden Risiken vermindert, da das neue System schrittweise eingeführt, also ein Big-Bang verhindert wird. Erfahrungen aus dem produktiven Einsatz können bei der Entwicklung der folgenden Releases bereits berücksichtigt werden.
Um was geht es? Beim Schneiden der Releases müssen die Anforderungen zu sinnvollen Lieferungen zusammengestellt werden. Dabei sind folgende Aspekte zu berücksichtigen: Welche Anforderungen bringen den höchsten Geschäftswert? Welche Abhängigkeiten sind zu beachten? Welche Zusammenstellungen ergeben gemeinsam etwas sinnvolles Ganzes?
Aufgabenbereiche = Feature? Zweck Ungefähre zeitliche Reihenfolge Release 1 Geschäftswert Release 2 Release 3
Aufteilen von Tätigkeiten Notwendiges: Welche Teile einer Tätigkeit sind absolut unentbehrlich, damit das zughörige Feature seinen Zweck erfüllt? Es können ganze Ablaufschritte der Tätigkeiten weggelassen werden oder Schritte können in vereinfachter Form durchgeführt werden. Varianten: Gibt es zum Standard-Ablauf Varianten, auf die zunächst verzichtet werden kann? Komfort: Können Teile der Tätigkeit sehr einfach oder komfortabel durchgeführt werden? Reicht die einfache Variante zunächst aus?
Agenda I. Agilität & Requirements-Engineering II. III. IV. Analyse in den agilen Ansätzen Benutzergeschichten extended version: Story-Maps Der Brückenschlag: Von den Story-Maps zu den klassischen RE-Methoden V. Inhaltliche Releaseplanung VI. Muss ich das jetzt alles machen?
Zuviel oder zuwenig? Requirements-Engineering kostet Zeit und Geld wie lässt sich das rechtfertigen? Kann es dazu beitragen, zu besseren Ergebnissen zu kommen? schneller zu Ergebnissen zu kommen? kostengünstiger zu Ergebnissen zu kommen? Risiken zu verringern? Jede eingesetzte Requirements-Engineering-Technik sollte dahingehend hinterfragt werden, inwieweit sie zu diesen Zielen beiträgt.
Ziele Klassisch Wünsche und Ideen des Kunden Beschreibung der Anforderungen Entwicklung Rückkopplung mit Kunden Ziele Wünsche und Ideen des Kunden Entwicklung Produkt Rückkopplung mit Kunden Agil Kosten? Nutzen?
Agil mit Requirements-Engineering Kosten? Nutzen? Beschreibung der Anforderungen Ziele Wünsche und Ideen des Kunden Entwicklung Produkt Rückkopplung mit Kunden
Heuristiken zur Bestimmung des Requirements-Engineering-Bedarfs Kunde Hat der Kunde genaue Vorstellungen seiner Anforderungen? Wie viele Stakeholder sind beteiligt? Wie unterschiedlich sind die Meinungen der Stakeholder? Sind die Anforderungen des Kunden ausreichend klar, um sie umsetzen zu können? Verfügen die Anforderer über Abstraktionsvermögen?
Heuristiken zur Bestimmung des Requirements-Engineering-Bedarfs Team Hat das Team die Anforderungen ausreichend verstanden, um den Aufwand schätzen und die Risiken beurteilen zu können? Ist die Analyse und Umsetzung auf unterschiedliche Personen verteilt? Ist das Team mit der Fachlichkeit vertraut, z.b. interne Entwickler, oder ist die Fachlichkeit neu für das Team, z.b. Offshore-Entwicklung.
Heuristiken zur Bestimmung des Requirements-Engineering-Bedarfs Fachlichkeit Ist die Fachlichkeit einfach oder komplex? (Z.B. viele Varianten) Handelt es sich um ein fachlich innovatives Projekt? Gibt es externe Vorgaben, z.b. gesetzliche Vorgaben. Projektmanagement Wie hoch ist das Sicherheitsbedürfnis? (Risikomanagement) Sind mehrere Teams zu koordinieren? (Abhängigkeiten)
Heuristiken zur Bestimmung des Requirements-Engineering-Bedarfs Diese Fragen sind für die Anforderungen als Ganzes zu beantworten, um grundsätzlich festzulegen, wie weit analysiert werden soll, und für jede Anforderung, um festzulegen, ob für die konkrete Anforderung der zuvor festgelegte Rahmen ausgeschöpft werden soll. Hier wird nur der Analyseaspekt betrachtet, es geht also hier darum, Anforderungen zu verstehen. Von außen vorgegebene Dokumentationserfordernisse können ebenfalls einen Einfluss haben.
Resümee Die Welt der agilen Systementwicklung und einige leistungsfähige Techniken des Requirements-Engineering lassen sich sinnvoll verbinden. Was tatsächlich in einem Projekt an RE-Methoden sinnvoll eingesetzt werden kann, ist von vielen Faktoren abhängig und unter Kosten-Nutzen- Gesichtspunkten im Einzelfall zu entscheiden.
Vielen Dank! Ich freue mich auf Ihre Fragen???