23-mal heruntergeladen
Hochgeladen vonHOOD Group
Agilität im Systems Engineering – geht das?
Das Dokument behandelt die Implementierung agiler Methoden im Systems Engineering und definiert Agilität basierend auf den Werten und Prinzipien des agilen Manifests. Es werden anschauliche Praktiken vorgestellt, die die Zusammenarbeit in interdisziplinären Teams fördern und auf die Vermeidung von Verschwendung abzielen. Zudem wird betont, wie wichtig es ist, sich an sich ändernde Anforderungen anzupassen und kontinuierlich wertvolle Ergebnisse zu liefern.
Weitere ähnliche Inhalte
Ähnlich wie Agilität im Systems Engineering – geht das?
Agilität im Systems Engineering – geht das?
- 1. Agilität im SystemsEngineering – geht das? Susanne Mühlbauer REConf 2014
- 2. Agilität hat erstmal nichtsmit 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 bedeuteteigentlich 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.
- 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 AgilenManifests 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 AgilesManifest Bekannte Praktiken Praktiken Scrum, Kanban, XP, Crystal, … Ihre eigene...?
- 10. The new newdevelopment 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-Entwicklungist 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 dieRealität 14 Zu langsam Geht bei uns nicht
- 15. So ist dieRealität 15 Zeitdruck
- 16. Requirements - Engineering Requirements - Engineering AuftraggeberAuftragnehmer ? Soft ware
- 17. Die sieben Verschwendungenin 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 phasenorientiertenVorgehen 18 Halbfertige Arbeit Übergaben Fehler
- 19. Inhaltsverzeichnis 1. Was bedeuteteigentlich 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. 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 „LeanSystems 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 eineAktivitä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 AuftraggeberAuftragnehmer ? 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 StartenSie 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. Inhaltsverzeichnis 1. Was bedeuteteigentlich 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. Agil/ Scrum undAssessments (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 undAssessments (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 AuftraggeberAuftragnehmer ? Soft ware
- 30. Lastenheft agil umsetzen 30 ArchitekturvisionProduktvision • 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 ArchitekturvisionProduktvision • 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 ImplementierungCode 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
- 34. Inhaltsverzeichnis 1. Was bedeuteteigentlich 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. Requirements - Engineering Testing Soft ware InterdisziplinäreTeams - die Inseln müssen zusammenwachsen Dokumentation Doku Integration Normen Architektur
- 36. 36 Es ist eineReise
- 37.
- 38.
- 39.
- 40. Susanne.Muehlbauer@HOOD-Group.com HOOD GmbH Büro München Keltenring7 82041 Oberhaching Germany Tel: 0049 89 4512 53 0 www.Agile-by-HOOD.com Susanne Mühlbauer Agile Coach
- 41. Agile-by-HOOD ist einAngebot 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.