Arbeiten 4.0 - Agile Methoden und Prozesse: Ein Blick … · Rollen, Prozesse und Artefakte in Scrum. Rainer Telesko, Arbeiten 4.0 ... –Wiki-basierter Product und Sprint Backlog

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


Das agile Manifest

© https://agilesista.com/2014/09/26/the-agile-manifesto-updated/, Zugriff: 2018-04-17

https://agilesista.com/2014/09/26/the-agile-manifesto-updated/


Rollen, Prozesse und Artefakte in Scrum


Wasserfallmodell vs. Agile Methoden

© https://blog.presentationload.de/effizienter-arbeiten-mit-agilem-projektmanagement/, Zugriff: 2018-03-28

https://blog.presentationload.de/effizienter-arbeiten-mit-agilem-projektmanagement/


Missverständnisse über Agiles Vorgehen


Missverständnisse über Agiles Vorgehen

© https://coderanch.com/t/661968/engineering/opinion-year-scrum-experience, Zugriff: 2018-03-28

https://coderanch.com/t/661968/engineering/opinion-year-scrum-experience


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


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)


Requirements Engineering im agilen Kontext

© https://swissq.it/wp-content/uploads/2015/05/Trends-2015-RE-Schluesselergebnis-WP-1024x4791.jpeg, Zugriff: 2018-03-28

https://swissq.it/wp-content/uploads/2015/05/Trends-2015-RE-Schluesselergebnis-WP-1024x4791.jpeg


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)


Requirements Engineering klassisch vs. agil

© 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


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


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




Requirements Engineering agil (Idealfall)

© https://www.bbv.ch/images/bbv/pdf/downloads/system_event/2011_system_event_anforderungen.pdf, Zugriff: 2018-03-28



Prioritäten beim Requirements Engineering

Quelle: SwissQ: Trends & Benchmarks Report Schweiz Software Development, Agile – Requirements - Testing, 2017


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

https://www.heise.de/developer/artikel/Gedanken-ueber-agiles-Requirements-Engineering-948348.html


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“


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



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?




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?




Überblick Techniken zur Spezifikation von Requirements

Quelle: SwissQ: Trends & Benchmarks Report Schweiz Software Development, Agile – Requirements - Testing, 2017


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.


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


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++“)


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


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


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


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.


Und nun zu den Workshops ...

• E04 EG Workshop

• 204 2.OG Workshop

• 208 2.OG Workshop

Documents

Arbeiten 4.0 - Agile Methoden und Prozesse: Ein Blick … · Rollen, Prozesse und Artefakte in Scrum. Rainer Telesko, Arbeiten 4.0 ... –Wiki-basierter Product und Sprint Backlog