Arbeiten 4.0 - Agile Methoden und Prozesse: Ein Blick auf die konkrete Umsetzung
Rainer Telesko, Fachhochschule Nordwestschweiz
Rainer Telesko, Arbeiten 4.0 – Agile Methoden und Prozesse 2
Inhalt
• Das Agile Manifest
• Klassisches vs. Agiles Vorgehen
• Fokus: Agiles Requirements Engineering (ARE)
• Entwicklungsstufen der Dokumentation
• Herausforderungen ARE
• Lösungansätze ARE
Rainer Telesko, Arbeiten 4.0 – Agile Methoden und Prozesse 3
Das agile Manifest
© https://agilesista.com/2014/09/26/the-agile-manifesto-updated/, Zugriff: 2018-04-17
Rainer Telesko, Arbeiten 4.0 – Agile Methoden und Prozesse 4
Rollen, Prozesse und Artefakte in Scrum
Rainer Telesko, Arbeiten 4.0 – Agile Methoden und Prozesse 5
Wasserfallmodell vs. Agile Methoden
© https://blog.presentationload.de/effizienter-arbeiten-mit-agilem-projektmanagement/, Zugriff: 2018-03-28
Rainer Telesko, Arbeiten 4.0 – Agile Methoden und Prozesse 7
Missverständnisse über Agiles Vorgehen
© https://coderanch.com/t/661968/engineering/opinion-year-scrum-experience, Zugriff: 2018-03-28
Rainer Telesko, Arbeiten 4.0 – Agile Methoden und Prozesse 8
Erfahrungen mit Scrum (1)
• Projekt A: Modellierungsplattform für IT-Service Management– Einsatz von Scrum im Projekt sinnvoll
– Scrum-Prozess und -Methoden gut gelebt
– Wiki-basierter Product und Sprint Backlog mit UML-/BPMN-Diagrammen
– Starker, autoritativer Product Owner
– Ziemliches Entwickler Know-How Gefälle im Team (Frontend vs. Backend)
– „Nicht jeder macht / kann alles“
– Guter Fokus auf «Definition of Done» in den Sprints
– Entwicklung von Hierarchien und Gruppenbildung im Team
– Grosse Fluktuation im Team mit entsprechenden Problemen
Rainer Telesko, Arbeiten 4.0 – Agile Methoden und Prozesse 9
Erfahrungen mit Scrum (2)
• Projekt B: Web App im Umfeld Social Media– Einsatz von Scrum im Projekt sinnvoll
– Excel-basierter Product- und Sprint Backlog (unzureichendes Stakeholdermanagement)
– Schwacher Product Owner
– Ziemliches Entwickler Know-How Gefälle im Team (Play Framework mit Java)
– Scrum Master nur fakultativ vorhanden
– Definition of Done oft nicht eingehalten (eigene Sprints ausschliesslich für das Testen)
– Kein durchdachtes Release Management
– Dokumentation fast ausschliesslich im Code (Probleme bei der Übergabe an andere Entwicklungsorganisation nach Projektende)
Rainer Telesko, Arbeiten 4.0 – Agile Methoden und Prozesse 10
Requirements Engineering im agilen Kontext
© https://swissq.it/wp-content/uploads/2015/05/Trends-2015-RE-Schluesselergebnis-WP-1024x4791.jpeg, Zugriff: 2018-03-28
Rainer Telesko, Arbeiten 4.0 – Agile Methoden und Prozesse 11
Requirements Engineering klassisch vs. agil
• Klassisches RE – Eigenes Berufsbild (Requirements Engineer / Business Analyst)
– Orientierung an IEEE / IREB Rahmenwerken (z.B. IREB: Erheben, Dokumentieren, Prüfen und Verwalten von Anforderungen)
– Fokus auf Vollständigkeit und Korrektheit der Anforderungen
• Agiles RE (ARE) – Arbeit im Team (Product Owner, Entwickler, Tester, …) statt eigenes
Berufsbild
– „Just in time“-Prinzip: Im Detaillierungsgrad, wie es gerade erforderlich ist („just barely good enough“)
– Orientierung am agilen Manifest (lauffähiger Code wichtiger als Dokumentation)
Rainer Telesko, Arbeiten 4.0 – Agile Methoden und Prozesse 12
Requirements Engineering klassisch vs. agil
© https://www.bbv.ch/images/bbv/pdf/downloads/system_event/2011_system_event_anforderungen.pdf, Zugriff: 2018-03-28
Rainer Telesko, Arbeiten 4.0 – Agile Methoden und Prozesse 13
Qualitätskriterien beim Requirements Engineering
• Anforderungsspezifikation(IREB Lehrplan V2.2)– Vollständigkeit
– Konsistenz
– Eindeutigkeit
– Modifizierbarkeit und Erweiterbarkeit
– Verfolgbarkeit (Traceability)
– Klare Struktur
• Anforderung (IEEE 29148-2011)– Abgestimmt
– Eindeutig
– Notwendig
– Konsistent
– Bewertet
– Prüfbar
– Realisierbar
– Verfolgbar
– Vollständig
– Verständlich
Rainer Telesko, Arbeiten 4.0 – Agile Methoden und Prozesse 14
Requirements Engineering klassisch
© https://www.bbv.ch/images/bbv/pdf/downloads/system_event/2011_system_event_anforderungen.pdf, Zugriff: 2018-03-28© https://www.bbv.ch/images/bbv/pdf/downloads/system_event/2011_system_event_anforderungen.pdf, Zugriff: 2018-03-28
Rainer Telesko, Arbeiten 4.0 – Agile Methoden und Prozesse 15
Requirements Engineering agil (Idealfall)
© https://www.bbv.ch/images/bbv/pdf/downloads/system_event/2011_system_event_anforderungen.pdf, Zugriff: 2018-03-28
Rainer Telesko, Arbeiten 4.0 – Agile Methoden und Prozesse 16
Prioritäten beim Requirements Engineering
Quelle: SwissQ: Trends & Benchmarks Report Schweiz Software Development, Agile – Requirements - Testing, 2017
Rainer Telesko, Arbeiten 4.0 – Agile Methoden und Prozesse 17
Dilemmasituation beim RE (B. Oesterreich)
• These 1– „Klassisches RE ist auf Perfektion konditioniert: Anforderungen möglichst
weitgehend verstehen und präzise beschreiben. Nichts steht beim Übergang zum agilen RE mehr im Weg als der Perfektionismus des RE. Insofern haben es erstklassige REler nicht leicht, agil zu werden!“
• These 2– „Agile Verfahren wie Scrum und XP basieren de facto auf Benutzer-
geschichten, Epen, Themen u.Ä. und damit auf einfachsten RE-Mitteln. Sie reichen zusammen mit grundlegenden Rückkopplungs- und Lern-mechanismen aus, um erfolgreich zu arbeiten. Nichts steht aber einem effizienten agilen RE mehr im Weg als die Nichtbeherrschung fort-geschrittener RE-Techniken. Insofern haben Scrum- und XPler es nicht leicht, erstklassig zu werden.“
© https://www.heise.de/developer/artikel/Gedanken-ueber-agiles-Requirements-Engineering-948348.html, Zugriff: 2018-03-29
Rainer Telesko, Arbeiten 4.0 – Agile Methoden und Prozesse 18
Definition - ARE
„In agile RE, the requirements are elicited, analyzed and specified in an ongoing and close collaboration with a customer or customer representative in order to achieve high reactivity to changes in the requirements and in the environment. Continuous requirements re-evaluation is vital for the success of the solution system, and the close collaboration with the customer or customer representative is the essential method of requirements and system validation.“
Quelle: Heikkilä VT, Damian D, Lassenius C, Paasivaara M (2015): A mapping study on requirements engineering in agile software development. In: 2015 41st Euromicro conference on software engineering and advanced applications, pp 199–207
Ziel: „Aktive Steuerung der Unvollkommenheit“
Rainer Telesko, Arbeiten 4.0 – Agile Methoden und Prozesse 19
Problemfelder beim ARE
• Zeitpunkt einer Anforderungserhebung / -beschreibung– Der Übergang vom Wasserfall zum Iterativen bedeutet, für jede einzelne
Anforderung zu entscheiden, wann sie dran kommt, wann der richtige Zeitpunkt für sie ist.
– Steuerung durch Business Value (Geschäftswert) einer Anforderung
• Verständistiefe– Wie detailliert muss eine Anforderung verstanden und beschrieben werden?
– Welche RE-Technik ist dann am besten geeignet?
– Steuerung durch Kernfragen
• Hypothese betreffend Techniken– RE-Techniken können prinzipiell im klassischen wie im agilen Umfeld
gleichermassen eingesetzt werden.© https://www.heise.de/developer/artikel/Gedanken-ueber-agiles-Requirements-Engineering-948348.html, Zugriff: 2018-03-29
Rainer Telesko, Arbeiten 4.0 – Agile Methoden und Prozesse 20
Steuerung der Verständnistiefe durch Kernfragen (1)
1.Wie vertraut sind die Beteiligten (Product Owner, Fachabteilung, Anforderungsanalytiker, Entwicklungsteam etc.) mit der fachlichen Domäne?
2.Wie homogen werden Geschäftsprozesse und Anwendungsfälle von verschiedenen Benutzern durchgeführt beziehungsweise bearbeitet?
3.Wie viele fachliche Varianten und Ausnahmen sind zu berücksichtigen beziehungsweise werden erwartet?
4.Wie neu oder verändert ist der Ablauf?
© https://www.heise.de/developer/artikel/Gedanken-ueber-agiles-Requirements-Engineering-948348.html, Zugriff: 2018-03-29
Rainer Telesko, Arbeiten 4.0 – Agile Methoden und Prozesse 21
Steuerung der Verständnistiefe durch Kernfragen (2)
5.Wie viele verschiedene Personen sind als Anforderungsgeber oder -beeinflusser zu berücksichtigen?
6.Wie hoch ist das Risiko, durch zu wenig RE wichtige Abhängig-keiten oder Details zu vergessen, die später Mehrkosten oder Verzögerungen verursachen?Merkregel (Glinz, Uni Zürich): Der Aufwand für das Requirements Engineering soll umgekehrt proportional zum Risiko sein, das man bereit ist, einzugehen.
7.Wie gravierend sind die Folgen, wenn wichtige fachliche Varianten oder Details vergessen werden?
© https://www.heise.de/developer/artikel/Gedanken-ueber-agiles-Requirements-Engineering-948348.html, Zugriff: 2018-03-29
Rainer Telesko, Arbeiten 4.0 – Agile Methoden und Prozesse 23
Überblick Techniken zur Spezifikation von Requirements
Quelle: SwissQ: Trends & Benchmarks Report Schweiz Software Development, Agile – Requirements - Testing, 2017
Rainer Telesko, Arbeiten 4.0 – Agile Methoden und Prozesse 24
Entwicklungsstufen einer Anforderungsdokumentation
• Stufe 1: User Story / Textschablone (nach den Sophisten)
• Stufe 2: User Story / Textschablone ++– User Story / Textschablone mit Name/Titel, Kurzbeschreibung,
Akzeptanzkriterien (nach B. Oesterreich)
– User Story mit ausgewählten Elementen einer Use Case Beschreibung ergänzen (Szenarien, ausgewählte UML-Diagramme wie Aktivitätsdiagramm oder Zustandsdiagramm) (nach T. Weilkiens)
• Stufe 3: Vollständige Use Case Beschreibung – inkl. Trigger, Eingaben, Ausgaben, Vor- und Nachbedingung als Systemzustände,
Ausnahmen
• Stufe 4: Zusätzliche (UML)-Diagramme– Sequenzdiagramm, Anforderungsdiagramm (SysML), Klassendiagramm etc.
Rainer Telesko, Arbeiten 4.0 – Agile Methoden und Prozesse 31
Herausforderungen beim ARE: wissenschaftliche Betrachtung
ID Herausforderung Charakterisierung
1 Minimale Anforderungsdokumentation
● Nachhaltigkeit und Wiederverwendung von agilenDokumentationen in (Folge-)projekten schwierig
● Problem Wissensmanagement bei Fluktuation
2 Ungenügende Berücksichtigung von NFA
● Fokus auf funktionale Anforderungen● Komplexe Querbeziehungen zu funktionalen
Anforderungen● Messung bei volatilen Anforderungen schwierig
3 Ungeeignete Software-Architektur
● Verändernde Anforderungen können die initiale Softwarearchitektur in Frage stellen
4 Ungenügende Verfügbarkeit des Kunden
● Häufig limitierte Ressourcen des Kunden für Spezifikation von Anforderungen und Review
5 Ungenaue Aufwandsschätzung
● Extensives Requirements Engineering notwendige Voraussetzung für Aufwandsschätzung
6 Kompatibilität mit Prozessaudits
● Prozessaudits (nach CMMI, SPICE etc.) fördern „Lücken“ rein agiler Prozesse und Methoden zutage
Rainer Telesko, Arbeiten 4.0 – Agile Methoden und Prozesse 32
Mögliche Lösungen für Herausforderungen beim ARE
ID Herausforderung Mögliche Lösungen
1 Minimale Anforderungsdokumentation Erweiterte Dokumentation (siehe Stufen 1 - 4 vorne), Prototyping, Test-driven Development (Red-Green-Refactor”-Zyklus)
2 Ungenügende Berücksichtigung von NFA User Stories für NFA, Modellierung von FA / NFA mit der SysML (Requirements Diagram), NORMATIC-Ansatz
3 Ungeeignete Software-Architektur Code Refactoring, Test-driven Development
4 Ungenügende Verfügbarkeit des Kunden Proxy Customer, dedizierter Requirements Engineer in Scrum
5 Ungenaue Aufwandsschätzung -
6 Kompatibilität mit Prozessaudits Anreicherung von Scrum mit weiteren agilen (z.B. XP) oder ad hoc Praktiken („Scrum++“)
Rainer Telesko, Arbeiten 4.0 – Agile Methoden und Prozesse 33
Audit nach CMMI ML2 Specific Goals (Web Development)
Legende: + erfüllt durch Scrum Praktiken* teilweise erfüllt durch Scrum Praktiken- nicht erfüllt durch Scrum Praktiken
C. J. Torrecilla Salinas: A Scrum-based approach to CMMI maturity level 2 in WebDevelopment environments, iiWAS Conference 2012
Rainer Telesko, Arbeiten 4.0 – Agile Methoden und Prozesse 34
Was beschreibt das Prozessgebiet PPQA?
• Der Zweck von PPQA ist, den Mitarbeitern und dem Management objektiven Einblick in Arbeitsabläufe und in Beziehung stehende Arbeitsergebnisse zu bieten.
• Tätigkeiten Durchgeführte Prozesse und Arbeitsergebnisse objektiv anhand anwendbarer
Prozessbeschreibungen, Verfahren, Normen und Standards bewerten Identifizierung und Dokumentation von Abweichungen Rückmeldungen an Projektmitarbeiter und Führungskräfte über die Ergebnisse der
Qualitätssicherungsaktivitäten Sicherstellen der Bearbeitung von Abweichungen
Rainer Telesko, Arbeiten 4.0 – Agile Methoden und Prozesse 35
Mögliche Scrum-Erweiterung für Prozessgebiet PPQA
C. J. Torrecilla Salinas: A Scrum-based approach to CMMI maturity level 2 in WebDevelopment environments, iiWAS Conference 2012
Rainer Telesko, Arbeiten 4.0 – Agile Methoden und Prozesse 36
Zusammenfassung
• ARE ist mittlerweile eine eigene (wissenschaftliche) Disziplin.
• Die Kernherausforderung ist, wie die RE Ansprüche einer Organisation mit dem agilen Paradigma in Einklang gebracht werden können („aktive Steuerung der Unvollkommenheit")
• RE-Techniken können prinzipiell im klassischen wie im agilen Umfeld gleichermassen eingesetzt werden.
• Im Zentrum der meisten Projekte steht dabei die notwendige Beschreibungstiefe einzelner Anforderungen.