Scrum für Embedded-Software: Gut – aber aus anderen Gründen, als Ihr Manager glaubt
•
3 likes•1,450 views
Agile Entwicklung, das hat was von Leichtigkeit, und agile Entwicklung trägt tatsächlich dazu bei, bessere Ergebnisse früher zu erzielen. Es gilt aber auch: Der Prozess ist stikter, als Sie das heute leben. Scrum ist strikter gegenüber Management, und erfordert einen funktionierenden Integrations- und Testprozess. Vor allem in Embedded Systemen. Mehr zum Thema auf http://www.elektrobit.com/consulting Agil klingt innovativ, fluffig, ebenso Scrum mit seinen User Stories, dem Zusammenarbeiten. Das agilenPrinzip, Änderungen willkommen zu heißen, lässt das höhere Management in Entwicklungsorganisationen und deren Kunden in freudiger Schnappatmung erzittern. Verheißt dies doch die Möglichkeit, ohne sauer dreinblickende Projektmanager auch zwischendrin mal das Ruder rumzureißen, und das ganze auch noch mit dem Segen des Agilen Manifests und mit einem Framework namens Scrum. Wessen Organisation agil entwickelt, der freut sich, innovative Methoden zu verwenden, mit schlanken Prozessen und kaum Overhead, und vor allem gleich damit starten zu können. Echt jetzt? Wenn Ihre Organisation mit Scrum wirklich erfolgreich sein will, dann ist das kein Zuckerschlecken. Der Prozess ist mit hoher Wahrscheinlichkeit deutlich stikter, als Sie das heute leben. Scrum ist strikter gegenüber dem Management außerhalb des Teams, und Scrum ist strikter und zu Beginn der Einführung anstrengender als Ihr heutiger Integrations- und Testprozess. Vor allem in Embedded Systemen. Der erste agile Wert sagt „Individuals and interactions over processes and tools.“ Und um eben im täglichen Arbeiten den Menschen und Interaktionen eine höhere Bedeutung einräumen zu können, ist es so wichtig, dass Prozess und Tools vorhanden sind, funktionieren und ganz natürlich benutzt werden. Scrum, Kanban und andere agile Methoden erlauben den Menschen in Organisationen, streßfreier hervorragende Qualität zu liefern, erlauben internen und externen Kunden, früher werthaltige Lösungen zu bekommen, und machen aufs große Ganze gesehen der eigenen Organisation bessere Planung. In diesem Vortrag sehen Sie, was Sie zum Agilen Entwickeln mit Scrum lieber nicht sehen wollten, und wie Sie endlich einen Nutzen fürs Projekt, fürs Unternehmen, für den Kunden und für die Mitarbeiter aus Scrum ziehen können.
Recommended
Recommended
More Related Content
Similar to Scrum für Embedded-Software: Gut – aber aus anderen Gründen, als Ihr Manager glaubt
Similar to Scrum für Embedded-Software: Gut – aber aus anderen Gründen, als Ihr Manager glaubt (20)
More from Joachim Schlosser
More from Joachim Schlosser (11)
Recently uploaded
Recently uploaded (20)
Scrum für Embedded-Software: Gut – aber aus anderen Gründen, als Ihr Manager glaubt
- 1. 5. 12. 2017 Dr. Joachim Schlosser Scrum für Embedded-Software Gut – aber aus anderen Gründen, als Ihr Manager glaubt
- 2. 2© Elektrobit (EB) 2017 Photo: www.joachimschlosser.de, License CC-BY-SA Mindset Scrum for Embedded Software Engineering The Foundation
- 3. 3© Elektrobit (EB) 2017 Mindset is key Processes and tools Practices Principles Values Mindset Mindset • High impact • Hard to measure Processes and tools • Low impact • Easy to measure Principles • Medium impact • Able to evaluate Scrum for Embedded Software Engineering
- 4. 4© Elektrobit (EB) 2017 Agile Manifesto Scrum for Embedded Software Engineering What does “over” really mean? Individuals and interactions Working software comprehensive documentation Customer collaboration contract negotiation Responding to change following a plan processes and toolsover over over over
- 5. 6© Elektrobit (EB) 2017 Agile Manifesto Scrum for Embedded Software Engineering What does “over” really mean? Individuals and interactions Working software comprehensive documentation Customer collaboration contract negotiation Responding to change following a plan processes and tools
- 6. 7© Elektrobit (EB) 2017 Photo: Bernisches Historisches Museum, License CC0 Albert Einstein zugeschrieben Planung ersetzt Zufall durch Irrtum. Scrum for Embedded Software Engineering
- 7. 8© Elektrobit (EB) 2017 Scrum for Embedded Software Engineering The objective of your agile approach
- 8. 9© Elektrobit (EB) 2017 Scrum for Embedded Software Engineering Incremental experimental introduction
- 9. 10© Elektrobit (EB) 2017 DevOps Scrum for Embedded Software Engineering Continuous Integration as Enabler Individuals and interactions Working software comprehensive documentation Customer collaboration contract negotiation Responding to change following a plan processes and tools
- 10. 11© Elektrobit (EB) 2017 Test from day one using automated infrastructure.
- 11. 12© Elektrobit (EB) 2017 BMW Werk Leipzig, License CC-BY-SA Lean and Agile Scrum for Embedded Software Engineering Adaptive and Efficient
- 12. 13© Elektrobit (EB) 2017 LEAN Principles fit very well with Agile Scrum for Embedded Software Engineering Applied to Embedded Software DevelopmentGenericLEAN Principle FLOW … PO CM QMDev. Arch. SM TAKT PULL ZERO DEFECTS • Cross-functional team • Co-location • Deliver working software frequently • Self-organizing teams pull from backlog • Definition of done • Simplicity is essential Agile Element / Principle Define Develop Test Demonstrate and evaluate Priority backlog 1 2 3 4 5
- 13. 14© Elektrobit (EB) 2017 As concert halls for orchestras, the build infrastructure is the room where the music plays Photo: Maria Oik on Flickr, License CC-BY.
- 14. 15© Elektrobit (EB) 2017 Server/Cluster/Cloud Infrastructure VersionControl TicketSystem MultiLayerBuildServer SandboxSystem StaticCodeAnalysis CodeCoverage Collaboration TestAutomation AutomatedReporting A Continuous Integration Stack (simplified) Scrum for Embedded Software Engineering
- 15. 17© Elektrobit (EB) 2017 All Logos are trademarks of their owners. Tool Examples (no endorsement) Scrum for Embedded Software Engineering (many, depending on your software)
- 16. 18© Elektrobit (EB) 2017 Automated tests are easier to scale. Image Sources: torkildr on Flickr, License CC-BY-SA
- 17. 19© Elektrobit (EB) 2017 Embedded Hardware Scrum for Embedded Software Engineering Integration Implementation Design Test&Verification Constraints Requirements Environment Models Mechanical Control Algorithms Electrical Supervisory Logic Test System Structured Text VHDL, VerilogC, C++ MCU DSP FPGA ASIC PLC Aus: Schlosser, Joachim: Frühe Verifikation von Regelungssystemen mit Model-Based Design. in: ESE Kongress 2011
- 18. 20© Elektrobit (EB) 2017 Scrum for Embedded Software Engineering Model Driven Development Adoption Grid Modeling&SimulationAdoption Requirements Based V&V (connecting to & testing against requirements) Virtual Verification & Validation (using formal tools & methods) System Validation (applying formal tools and methods to hardware) Fully Leveraged Model Based Design System Simulation (varying levels of plant models) Closed-Loop Simulation (using controller & plant models) Hardware-in-the- Loop (generating code for the plant model) Simulation Based Development (targeting production hardware) Algorithm Modeling (no plant models) Graphical Specs (expressing the controller algorithms graphically) Rapid Prototyping (generating code for the control algorithms for testing) Graphical Programming (generating code for the control algorithms for production) Simulation Real-Time Testing Production Code Generation Adoption Aus: Schlosser, Joachim: Frühe Verifikation von Regelungssystemen mit Model-Based Design. in: ESE Kongress 2011
- 19. 21© Elektrobit (EB) 2017 A Love Story Manager and Scrum Introduction Scrum for Embedded Software Engineering Photo: www.joachimschlosser.de, License CC-BY-SA
- 20. 22© Elektrobit (EB) 2017 Agile Introduction = Adaptive Introduction Scrum for Embedded Software Engineering Continuous Integration as Enabler Individuals and interactions Working software comprehensive documentation Customer collaboration contract negotiation Responding to change following a plan processes and tools
- 21. 23© Elektrobit (EB) 2017 Transition Approach Scrum for Embedded Software Engineering Target area Incremental results Transition start Change iteration Decision area Iterative minimization of the target area Start where you are Teams Flow OrganizationTeams Flow Flow A D A P T A D A P T A D A P T A D A P T A D A P T A D A P T
- 22. 24© Elektrobit (EB) 2017 Photo: www.joachimschlosser.de, License CC-BY-SA Scrum for Embedded Software Engineering Manager, stay out.
- 23. 25© Elektrobit (EB) 2017 Scrum for Embedded Software Engineering Deliver! www.elektrobit.com/consulting
Editor's Notes
- Version: February 16th, 2017
- The introduction of a speci c process model should never be the objective of a transition. Introducing a process model can only be one step towards achieving an overall objective such as shorter installation cycles and therefore better market opportunities. Constantly remind yourself of the actual objectives. Continuously communicate these goals to make sure that you reach every employee. Focus on few but clear objectives. This means visualize your objectives and publish them in the organization so that the objectives are always kept in view [COV13] and the right decisions are made. Give the employees the opportunity to provide feedback on the practices used. This reality check from innovation [MOR14] gives you different views. It provides you with a clearer picture of where you are on the path to achieving your objectives.
- In a study conducted by McKinsey (see [KINS]), only 30 percent of organizations achieve their initial change targets. Dogmatically adhering to a scaled agile process model results in a 70-percent probability of not attaining these targets. Incrementally introducing a scaled agile process model supports us in minimizing this risk. Lean Change Management [LIT14] can help incrementally introduce changes with small experiments and establish them on a small scale before their company-wide rollout (see Figure 3). The experiments are supported by one or more experts for agile processes, which allow the team to learn the iterative approach from them. If the experiment was successful, not only the expert but also the pilot team should support the further rollout. The diagrammatic representation in Figure 4 shows how a designated target area can be reached using an iterative approach. It is important to build a team of experienced persons from your company and experts who drive the scaling process. If you want to make sure that the scaling has top priority, this team’s only task should be to introduce and support these experiments. What ts here is the Shu-Ha-Ri model, an Asian martial arts concept applied to software development by Alistair Cockburn [COC06]. Shu-Ha-Ri also translates as learn-break-create (see Box 1). This suggests that the teams’ transition from the Shu to the Ha phase gives a new and different impetus from theory and practice. This does not necessarily mean that these practices are from the process model you have chosen. However, your theoretical model will be modi ed to a greater or lesser extent at the latest when the teams reach the Ri phase and go their own way. Make sure to check whether these modi cations are still in line with your objectives or whether you need to adjust your plan.
- Eines ist allen drei Bereichen – Forschung, Lehre, Unternehmertum – gemein: Die Wertschöpfung kommt aus dem jeweiligen Anwendungsbereich, nicht daraus, dass sich jeder wieder alles an Tool-Infrastruktur selber zusammenstrickt. Wie ein Konzertsaal für Orchester, so ist MATLAB Teil der wissenschaftlichen Infrastruktur von akademischen Organisationen. In diesem Konzertsaal musizieren die verschiedenen Instrumentalisten dann gemeinsam – jeder mit seinem Instrument, aber alle profitieren vom Klangbild, das der Konzertsaal daraus formt. Unabhängig davon, ob Sie gerade noch lernen, ob Sie forschen, ob Sie lehren oder ob Sie gründen oder entwickeln – das MATLAB Ökosystem ist die vertrauenswürdige Umgebung für alle Phasen der Entdeckung und Innovation. Es geht um Wissen und Fähigkeiten. Und darum, beides auf die Straße zu bekommen.
- Funktionstests Rapid Control Prototyping Robustheitstests Hardware-in-the-Loop-Tests viele fangen leider sofort damit an RCP/HIL: For every budget and application, there is the right system, e.g. xPC from Speedgoat
- The stages can be expanded over several Change iterations that need to be supported by a team that has the authority and the responsibility to support the transition and set goals for the transition.