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 Ih...
Inhaltsverzeichnis
1. Was bedeutet eigentlich Agil?
1. Werte, Prinzipien, Praktiken
2. Haltung/ Mindset
3. Komplexität und...
© HOOD GmbH
Werte
Prinzipien
Agiles Manifest
Agile Manifesto - Values
Individuals and Interactions over processes and tools
Working software over comprehensive documen...
Prinzipien des Agilen Manifests
1. Our highest priority is to satisfy the customer through early and continuous delivery o...
© 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
Systeme
Theorie X - der Mensch ist unwillig
Linda Rising
Theorie Y - der Mensch ist engagiert
Agiles Mindset/ Haltung
Command & Co...
kompliziert
kompliziert
System- und SW-Entwicklung ist komplex
Anforderungen
unbekanntbekannt
Technologie
bekannt unbekann...
Freiheitsgrade und Vorgaben – je nach Aufgabe
kompliziert
kompliziert
Anforderungen
unbekanntbekannt
Technologie
bekannt u...
So ist die Realität
14
Zu langsam
Geht bei uns nicht
So ist die Realität
15
Zeitdruck
Requirements -
Engineering
Requirements -
Engineering
Auftraggeber Auftragnehmer
?
Soft
ware
Die sieben Verschwendungen in
der Software-Entwicklung
• Halbfertige Arbeit
(Partially Done Work)
• Extra Features
• Wiede...
Verschwendung in phasenorientierten Vorgehen
18
Halbfertige
Arbeit
Übergaben
Fehler
Inhaltsverzeichnis
1. Was bedeutet eigentlich Agil?
1. Werte, Prinzipien, Praktiken
2. Haltung/ Mindset
3. Komplexität und...
Systems Engineering
Systems Engineering
HW
Engineering
Mechanical
Engineering
Electrical
Engineering
SW-
Engineering
Embed...
Was ist „Lean Systems Engineering“ ?
Systems
Engineering
Lean
Thinking
Lean
Systems
Engineering
Interdisziplinäre
Ingenieu...
Wann ist eine Aktivität wertvoll?
1. Eine Aktivität ist wertvoll, wenn…
 … der Kunde dafür zahlt, und
 … sie Information...
Requirements -
Engineering
Requirements -
Engineering
Auftraggeber Auftragnehmer
?
Soft
ware
1, 2 oder 3?
Kleine Schritte - Fangen Sie mit einem beherrschbaren kleinen Umfang
an
24
Starten Sie in der SW-
Entwicklung
Mit einer mö...
Weitere Synchronisationspunkte schaffen
25
Synchronisieren/
Integration
Starten Sie in der SW-
Entwicklung
Mit einer mögli...
Inhaltsverzeichnis
1. Was bedeutet eigentlich Agil?
1. Werte, Prinzipien, Praktiken
2. Haltung/ Mindset
3. Komplexität und...
Agil/ Scrum und Assessments (z.B. CMMI oder Spice)
• Reifegradmodelle zeigen auf,
was benötigt wird um einen
Reifegrad zu ...
Agil/ Scrum und Assessments (z.B. CMMI oder Spice)
CMMI SG1 Manage Requirements Agile/ Scrum
REQM SP1.1 Develop an underst...
Requirements -
Engineering
Requirements -
Engineering
Auftraggeber Auftragnehmer
?
Soft
ware
Lastenheft agil umsetzen
30
Architekturvision Produktvision
• Aufwandstreiber
identifizieren
• Architekturtreiber
identifi...
Lastenheft agil umsetzen
31
Architekturvision Produktvision
• Aufwandstreiber
identifizieren
• Architekturtreiber
identifi...
Sprint
Fokus auf Dokumentation
Implementierung Code
Designanforderungen Designdoku
Systemanforderungen Systemdoku
Kundenan...
Auf allen Ebenen:
• Motivation, Beweggründe
• Optionen,
Entscheidungen/
Trade-Offs
• grober Überblick
• Detailinformation
...
Inhaltsverzeichnis
1. Was bedeutet eigentlich Agil?
1. Werte, Prinzipien, Praktiken
2. Haltung/ Mindset
3. Komplexität und...
Requirements -
Engineering Testing
Soft
ware
Interdisziplinäre Teams - die Inseln müssen zusammenwachsen
Dokumentation
Dok...
36
Es ist eine Reise
Partnerschaftliche Zusammenarbeit
37
Vertrauen
Respekt
Offenheit
Fokus
und…
38
Mut
Agilität beginnt
im Kopf…!
Susanne.Muehlbauer@HOOD-Group.com
HOOD GmbH
Büro München
Keltenring 7
82041 Oberhaching
Germany
Tel: 0049 89 4512 53 0
www...
Agile-by-HOOD ist ein Angebot der HOOD GmbH.
HOOD konzentriert seine agilen Aktivitäten in Agile-by-HOOD
Agilität erleben:...
Upcoming SlideShare
Loading in …5
×

Agilität im Systems Engineering – geht das?

1,548 views

Published on

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.
Agilität beginnt im Kopf…!

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,548
On SlideShare
0
From Embeds
0
Number of Embeds
8
Actions
Shares
0
Downloads
16
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Agilität im Systems Engineering – geht das?

  1. 1. Agilität im Systems Engineering – geht das? Susanne Mühlbauer REConf 2014
  2. 2. Agilität hat erstmal nichts mit dem Entwicklungsgegenstand zu tun
  3. 3. Agil zu sein, bedeutet für uns: Wir orientieren uns an den Werten und Prinzipien des agilen Manifests.
  4. 4. Was bedeutet „Agil“ für Sie? Eine weitere Vorgehens- weise Paradigmen- wechsel / Transition Wohin schlägt der Zeiger in Ihrer Organisation?
  5. 5. 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
  6. 6. © HOOD GmbH Werte Prinzipien Agiles Manifest
  7. 7. 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:
  8. 8. 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.
  9. 9. © HOOD GmbH Werte Prinzipien Agiles Manifest Bekannte Praktiken Praktiken Scrum, Kanban, XP, Crystal, … Ihre eigene...?
  10. 10. The new new development game 10 Harvard Business Review January-February 1986 1986 Systeme
  11. 11. 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 ZielBegabung Scheitern Anstrengung Douglas McGregor, 1969
  12. 12. kompliziert kompliziert System- und SW-Entwicklung ist komplex Anforderungen unbekanntbekannt Technologie bekannt unbekannt einfach Chaos komplex The Stacey Diagram, Ralph Stacey
  13. 13. Freiheitsgrade und Vorgaben – je nach Aufgabe kompliziert kompliziert Anforderungen unbekanntbekannt 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“
  14. 14. So ist die Realität 14 Zu langsam Geht bei uns nicht
  15. 15. So ist die Realität 15 Zeitdruck
  16. 16. Requirements - Engineering Requirements - Engineering Auftraggeber Auftragnehmer ? Soft ware
  17. 17. 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
  18. 18. Verschwendung in phasenorientierten Vorgehen 18 Halbfertige Arbeit Übergaben Fehler
  19. 19. 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
  20. 20. 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
  21. 21. 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/
  22. 22. 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/
  23. 23. Requirements - Engineering Requirements - Engineering Auftraggeber Auftragnehmer ? Soft ware 1, 2 oder 3?
  24. 24. 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
  25. 25. Weitere Synchronisationspunkte schaffen 25 Synchronisieren/ Integration 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
  26. 26. 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
  27. 27. 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
  28. 28. 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
  29. 29. Requirements - Engineering Requirements - Engineering Auftraggeber Auftragnehmer ? Soft ware
  30. 30. 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 …
  31. 31. 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 Bearbeitungsreihenfolge Funktionalität und Architektur Funktionalität und Architektur Umsetzung starten Weiter ausdetaillieren und dabei erworbenes Wissen einarbeiten
  32. 32. Sprint Fokus auf Dokumentation Implementierung Code Designanforderungen Designdoku Systemanforderungen Systemdoku Kundenanforderungen fachliche DokuWarum/ Ziel Was Wie Stakeholder/ Leser/ Autor User Story Sprint Planning Produkt-/ System- Dokumentation Traceability Traceability
  33. 33. 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
  34. 34. 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
  35. 35. Requirements - Engineering Testing Soft ware Interdisziplinäre Teams - die Inseln müssen zusammenwachsen Dokumentation Doku Integration Normen Architektur
  36. 36. 36 Es ist eine Reise
  37. 37. Partnerschaftliche Zusammenarbeit 37 Vertrauen Respekt Offenheit Fokus und…
  38. 38. 38 Mut
  39. 39. Agilität beginnt im Kopf…!
  40. 40. Susanne.Muehlbauer@HOOD-Group.com 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
  41. 41. 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.

×