agilität im systems engineering – geht das?

Agilität im Systems Engineering – geht das?

Susanne Mühlbauer

REConf 2014

Agilität hat erstmal nichts mit dem Entwicklungsgegenstand zu tun

Agil zu sein, bedeutet für uns: Wir orientieren uns an den Werten und Prinzipien des agilen Manifests.

Was bedeutet „Agil“ für Sie?

Eine weitere

Vorgehens-

weise

Paradigmen-

wechsel /

Transition

Wohin schlägt der Zeiger in Ihrer Organisation?

Inhaltsverzeichnis

1. Was bedeutet eigentlich Agil?

1. Werte, Prinzipien, Praktiken

2. Haltung/ Mindset

3. Komplexität und Anforderungen

2. Systems Engineering

3. Beispiele

1. Agil/ Scrum und Assessments

2. Lastenheft und Traceability

4. Fazit

© HOOD GmbH Werte

Prinzipien

Agiles Manifest

Agile Manifesto - Values

Individuals and Interactions over processes and tools

Working software over comprehensive documentation

Customer Collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Prinzipien des Agilen Manifests

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

4. Business people and developers must work together daily throughout the project.

5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

7. Working software is the primary measure of progress.

8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

9. Continuous attention to technical excellence and good design enhances agility.

10. Simplicity--the art of maximizing the amount of work not done--is essential.

11. The best architectures, requirements, and designs emerge from self-organizing teams.

12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

© HOOD GmbH Werte

Prinzipien

Agiles Manifest Bekannte Praktiken

Praktiken

Scrum, Kanban,

XP, Crystal, … Ihre eigene...?

The new new development game

10

Harvard Business Review January-February 1986

1986

Syst

eme

Theorie X - der Mensch ist unwillig

Linda Rising

Theorie Y - der Mensch ist engagiert

Agiles Mindset/ Haltung

Command & Control Transparenz & Vertrauen

Kontrolle ist gut – Vertrauen ist besser

Ziel Begabung Scheitern Anstrengung

Douglas McGregor, 1969

kom

pliz

iert

kompliziert

System- und SW-Entwicklung ist komplex

Anforderungen

un

bek

ann

t b

ekan

nt

Technologie bekannt unbekannt

einfach

Chaos

komplex

The Stacey Diagram, Ralph Stacey

Freiheitsgrade und Vorgaben – je nach Aufgabe

kom

pliz

iert

kompliziert

Anforderungen

un

bek

ann

t b

ekan

nt

Technologie bekannt unbekannt

einfach

Chaos

komplex

The Stacey Diagram, Ralph Stacey

Chaos

„Gibt es hierfür eine Lösung?“

„Prototyping“

Einfache Aufgabe

„Lösung ist bekannt“

Anforderungsspezfikation

Anforderungen

Komplizierte Aufgabe

„Lösung kann mit Sorgfalt erarbeitet werden“

Anforderungsspezfikation

Zeitdruck

Komplexe Aufgabe

„Niemand kennt die Lösung“

„Agile“

So ist die Realität

14

Zu langsam

Geht bei uns nicht

So ist die Realität

15

Zeitdruck

Requirements -Engineering


Auftraggeber Auftragnehmer

?

Software

Die sieben Verschwendungen in der Software-Entwicklung

• Halbfertige Arbeit (Partially Done Work)

• Extra Features

• Wieder-Erlernen (Relearning)

• Übergaben (Handoffs)

• Ständiges Wechseln der Aufgaben (Task Switching)

• Verzögerung (Delays)

• Fehler (Defects)

(Lean SW Development, Poppendieck)

Die sieben Verschwendungen in der Software-Entwicklung

Verschwendung in phasenorientierten Vorgehen

18

Halbfertige Arbeit

Übergaben Fehler

Inhaltsverzeichnis



2. Haltung/ Mindset



3. Beispiele



4. Fazit

Systems Engineering

Systems Engineering

HW Engineering

Mechanical Engineering

Electrical Engineering

SW- Engineering

Embedded SW

Enterprise SW

• Viele Schnittstellen zum Gesamtsystem

• Interdisziplinäre Themen • Ausschuss ist teuer • Integrationstests sind teuer • Simulation/ simulierbare Systeme

und Komponenten ermöglichen laufende (Integrations-) Tests

Was ist „Lean Systems Engineering“ ?

Systems Engineering

Lean Thinking

Lean Systems

Engineering

Interdisziplinäre Ingenieurstätigkeit in komplexen Entwicklungsprojekten

Schaffen von Wert Vermeiden von Verschwendung

Basierend auf: http://www.lean-systems-engineering.org/downloads-products/lean-enablers-for-managing-engineering-programs/

Wann ist eine Aktivität wertvoll?

1. Eine Aktivität ist wertvoll, wenn…

… der Kunde dafür zahlt, und

… sie Information/Material umwandelt bzw. Unklarheiten minimiert, und

… sie gleich beim ersten Mal einen definierten Nutzen bringt

2. Eine Aktivität ist nicht wertvoll, aber notwendig, wenn…

… sie aktuell keinen Wert erzeugt, aber

… sie erforderlich ist (z.B. aus juristischen Gründen)

3. Eine Aktivität ist Verschwendung (Waste), wenn sie…

… keinen Wert für Kunden erzeugt, und nicht notwendig ist

Basierend auf: http://www.lean-systems-engineering.org/downloads-products/lean-enablers-for-managing-engineering-programs/




?

Software

1, 2 oder 3?

Kleine Schritte - Fangen Sie mit einem beherrschbaren kleinen Umfang an

24

Starten Sie in der SW-Entwicklung

Mit einer möglichst stabilen HW-Komponente

Nutzen Sie Simulation

Suchen Sie ein Projekt/ Umfeld, in dem folgendes möglich scheint

Ein interdisziplinäres Team

Verständnisvolle Schnittstellenpartner

Integrieren Sie so oft wie möglich

Weitere Synchronisationspunkte schaffen

25

Syn

chro

nis

iere

n/

Inte

grat

ion

Starten Sie in der SW-Entwicklung

Mit einer möglichst stabilen HW-Komponente

Nutzen Sie Simulation

Kleine Schritte: Fangen Sie mit einem beherrschbaren kleinen Umfang an

Inhaltsverzeichnis



2. Haltung/ Mindset



3. Beispiele



4. Fazit

Agil/ Scrum und Assessments (z.B. CMMI oder Spice)

• Reifegradmodelle zeigen auf, was benötigt wird um einen Reifegrad zu erfüllen

• Sie schreiben nicht das „Wie“ vor

• Assessoren brauchen ggf. eine Übersetzung

• Es hilft, Assessoren früh einzubinden

Agil/ Scrum und Assessments (z.B. CMMI oder Spice)

CMMI SG1 Manage Requirements Agile/ Scrum

REQM SP1.1 Develop an understanding with the requirements providers on the meaning of the requirements

Product Owner Conversation, User Story Backlog Refinement Session Product Backlog Items in Status “Ready” Planning Event

REQM SP1.2 Obtain commitment to requirements from project participants

Backlog Refinement Session Product Backlog Items in Status “Ready” Planning Event

REQM SP1.3 Manage changes to requirements as they evolve during the project

Product Backlog, Embrace Change Review Event

REQM SP1.4 Maintain Bidirectional Traceability of Requirements

User Story ID, Commit Messages Definition of “Done”

REQM SP1.5 Ensure that project plans and work products remain aligned with requirements

Architektur- und Produktvision Release Burndown Daily Standup Product Backlog Review Event

Wenn notwendig, integrieren Sie die Informationen in

vorgegebene Templates




?

Software

Lastenheft agil umsetzen

30

Architekturvision Produktvision

• Aufwandstreiber identifizieren

• Architekturtreiber identifizieren

• Schnittstellen identifizieren

• Key Features identifizieren • Key Features priorisieren

Initiales Backlog

Feature 1

Feature 2

Feature 3

Feature …

Lastenheft agil umsetzen

31

Architekturvision Produktvision

• Aufwandstreiber identifizieren

• Architekturtreiber identifizieren

• Schnittstellen identifizieren

• Key Features identifizieren • Key Features priorisieren

Initiales Backlog

Feature 1

Feature 2

Feature 3

Feature 1

Be

arb

eitu

ngs

reih

enfo

lge

Funktionalität und Architektur Funktionalität

und Architektur

Umsetzung starten

Weiter ausdetaillieren und dabei erworbenes

Wissen einarbeiten

Sprint

Fokus auf Dokumentation

Implementierung Code

Designanforderungen Designdoku

Systemanforderungen Systemdoku

Kundenanforderungen fachliche Doku Warum/ Ziel

Was

Wie

Stakeholder/ Leser/ Autor

User Story

Sprint Planning

Produkt-/ System-

Dokumentation

Traceability

Traceability

Auf allen Ebenen: • Motivation, Beweggründe • Optionen,

Entscheidungen/ Trade-Offs

• grober Überblick • Detailinformation

• Benutzerhandbuch • Fachliche Architektur • Szenarien/ fachliche

Use Cases • Testfälle, z.B. User

Acceptance Tests • Nachweise • …

Siehe auch Agile Testing Quadrant, Lisa Crispin

• Designprinzipien • Schichtenmodell • Frameworks • Coding Guidelines • Branching-/ Merging

Konzept • …

• Technische Architektur • Schnittstellen • Nicht-funktionale

Anforderungen • Testfälle, z.B. funktionale

Tests, Performance Tests • Nachweise • …

• Code • Inline-Doku • Testfälle, z.B. Unit Tests • Modelle –> Reverse

Engineering • …

Nachhaltige Artefakte

Unterschiedliche Stakeholder/ Leser/

Autor

Langfristig relevantes Wissen

Sofort nutzbares Wissen

Fokus auf Wert und Vermeidung von Verschwendung

Inhaltsverzeichnis



2. Haltung/ Mindset



3. Beispiele



4. Fazit

Requirements -Engineering Testing

Software

Interdisziplinäre Teams - die Inseln müssen zusammenwachsen

Dokumentation

Doku

Integration Normen Architektur

36

Es ist eine Reise

Partnerschaftliche Zusammenarbeit

37

Vertrauen Respekt Offenheit Fokus und…

38

Mut

Tsitsikama, Südafrika 210 m

Agilität beginnt im Kopf…!

[email protected]

HOOD GmbH Büro München Keltenring 7 82041 Oberhaching Germany

Tel: 0049 89 4512 53 0 www.Agile-by-HOOD.com

Susanne Mühlbauer Agile Coach

Agile-by-HOOD ist ein Angebot der HOOD GmbH. HOOD konzentriert seine agilen Aktivitäten in Agile-by-HOOD Agilität erleben: Jeden Tag gemeinsam einen Mehrwert schaffen. Ein Umdenken beginnt, neue Ideen sind gesät und und ein mutiger Schritt ist gewagt. Seit mehr als 25 Jahren berät und unterstützt HOOD erfolgreich seine Kunden bei der Entwicklung komplexer Software und Systeme durch Requirements Engineering-Prinzipien. Mit der Marke Agile-by-HOOD bündelt HOOD das Angebot im agilen Umfeld und macht somit einen weiteren konsequenten Schritt zur zielgerichteten Unterstützung von Organisationen, die entweder bereits agil arbeiten oder sich vorgenommen haben, in Zukunft ihre Entwicklung auf Scrum, Kanban oder ähnliche Vorgehensweisen umzustellen. HOOD kann dabei auf langjährige Erfahrungen im Agile Coaching und fundierte Expertise im Requirements Engineering zurückgreifen, um große Unternehmen beim Umstieg von klassischer auf agile Vorgehensweise zu begleiten. Das Thema agil-skaliert ist uns ein besonderes Anliegen - wir verstehen auch die Entwicklung komplexer Produkte und Systeme mit vielen Teams und großen Organisationen.

agilität im systems engineering – geht das?

Technology