Agilität im Systems Engineering – geht das?

1. Agilität im Systems Engineering – geht das? Susanne Mühlbauer REConf 2014

2. Agilität hat erstmal nichts mit dem Entwicklungsgegenstand zu tun

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

4. Was bedeutet „Agil“ für Sie? Eine weitere Vorgehens- weise Paradigmen- wechsel / Transition Wohin schlägt der Zeiger in Ihrer Organisation?

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. © HOOD GmbH Werte Prinzipien Agiles Manifest

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. 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. © HOOD GmbH Werte Prinzipien Agiles Manifest Bekannte Praktiken Praktiken Scrum, Kanban, XP, Crystal, … Ihre eigene...?

10. The new new development game 10 Harvard Business Review January-February 1986 1986 Systeme

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. kompliziert kompliziert System- und SW-Entwicklung ist komplex Anforderungen unbekanntbekannt Technologie bekannt unbekannt einfach Chaos komplex The Stacey Diagram, Ralph Stacey

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. So ist die Realität 14 Zu langsam Geht bei uns nicht

15. So ist die Realität 15 Zeitdruck

16. Requirements - Engineering Requirements - Engineering Auftraggeber Auftragnehmer ? Soft ware

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. Verschwendung in phasenorientierten Vorgehen 18 Halbfertige Arbeit Übergaben Fehler

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. 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. 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. Requirements - Engineering Requirements - Engineering Auftraggeber Auftragnehmer ? Soft ware 1, 2 oder 3?

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. 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

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. 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. Requirements - Engineering Requirements - Engineering Auftraggeber Auftragnehmer ? Soft ware

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. 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. 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. 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

35. Requirements - Engineering Testing Soft ware Interdisziplinäre Teams - die Inseln müssen zusammenwachsen Dokumentation Doku Integration Normen Architektur

36. 36 Es ist eine Reise

37. Partnerschaftliche Zusammenarbeit 37 Vertrauen Respekt Offenheit Fokus und…

38. 38 Mut

39. Agilität beginnt im Kopf…!

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. 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?

Du liest eine Vorschau.

Hier ansehen

Agilität im Systems Engineering – geht das?

Weitere Verwandte Inhalte

Diashows für Sie (20)

Ähnlich wie Agilität im Systems Engineering – geht das? (20)

Weitere von HOOD Group (14)

Aktuellste (20)