Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Ketzerischer Vortrag zur Agilen Entwicklung

71 views

Published on

Agile wurde nur entwickelt weil man das V-Modell nicht verstanden hat.
Vortrag um sich Feinde zu machen.

Youtube Video dazu hier https://youtu.be/W8TpeWBctKQ

Published in: Business
  • Be the first to comment

  • Be the first to like this

Ketzerischer Vortrag zur Agilen Entwicklung

  1. 1. Agile wurde nur entwickelt, weil man das V-Modell nicht verstanden hat Ein Ketzerischer Vortrag um sich Feinde zu schaffen
  2. 2. Vorab Ich glaube nicht – ich schaue! Warum ich das sage? Methodenwahl hat fanatische Ausmaße angenommen. Es MUSS GENAU SO!!!  ich hab Recht !!! Basierend auf einer Studie „Capers Jones & Associates LLC.“ wurden 10 Methoden in Bezug auf verschiedene Standard Metriken inklusive • Function points, • Defect removal efficiency (DRE), • Cost of Quality (COQ), und • Total Cost of Ownership (TCO) Untersucht um diese Methoden zu vergleichen. Das Ergebnis ist: In general selecting a software development methodology has more in common with joining a cult than it does with making a technical decision. UND No single method appears to be a universal panacea that can be successful on every size and kind of software application.
  3. 3. Agile in normativem Umfeld am Beispiel der Automobilindustrie • Grundlegende Forderungen ASPICE© • Grundlegende Forderungen ISO 26262 • Das Agile Manifest • Schritt für Schritt Die Widersprüche zur Norm. • Die Lösung
  4. 4. Agiler Ansatz A-SPICE© & ISO 26262
  5. 5. ASPICE © Grundlegende Anforderungen
  6. 6. Das ASPICE© Prozesshaus
  7. 7. Der Entwicklungsprozess
  8. 8. Traceability & Konsistenz
  9. 9. Zusammenfassung ▪ Klares V-Model ▪ Entwicklung beginnen von den Top Anforderungen ▪ Traceability und Konsistenz ist ein MUSS!
  10. 10. ISO 26262 Normative Anforderung
  11. 11. Prozesse in der ISO 26262
  12. 12. Das V-Model
  13. 13. Zusammenfassung ▪ Klares V-Model ▪ Entwicklung beginnen von den Top Anforderungen ▪ Traceability und Konsistenz ist ein MUSS!
  14. 14. Das Agile Manifest Und ein paar ketzerische Kommentare
  15. 15. Das Originale Manifest http://agilemanifesto.org/ ▪ Individuals and interactions over processes and tools ▪ Working software over comprehensive documentation ▪ Customer collaboration over contract negotiation ▪ Responding to change over following a plan
  16. 16. Ein bisschen Verwirrung https://www.agilealliance.org/agile101/12- principles-behind-the-agile-manifesto/ http://agilemanifesto.org/principles.html http://www.automotive-spin.it/uploads/8/8W_mueller.pdf
  17. 17. Grundlegende Ideen Agile Software Entwicklung beschreibt ein Prinzipien Bei dem Anforderungen und Lösungen Durch gemeinsame Anstrengung Sich selbst organisierender Teams gelöst werden Inhaltliches Zitat Prof. Dr. G. Dueck aus seinem Buch: „Schwarmdumm – so blöd sind wir nur gemeinsam“ Hier führt Professor Dueck aus das die Schwarmintelligenz im Endeffekt nur dann existiert wenn‘s wirklich frei zusammen arbeitende Leute sind. Schwarmaktionen, sich selbst organisierende Systeme, gibt es nur in Freiheit. Nicht in einer Firma unter „Zwang“.
  18. 18. Grundlegende Ideen Dazu kommen 2 Ausführungen. Ganz kurzer Exkurs in die Biologie. Selbstorganisation führt maximal zu einem losen Einzellerverbund. Alle höher organisierten Organismen egal ob Pflanzen, Tiere oder was auch immer folgen einem hierarchischen System“. Und die Kollegen von der Engineering Abteilung der Biologie hatten ein paar mehr Jahre Zeit um etwas zu entwickeln. Da könnte man sich ja mal etwas von ab gucken. Schwarmtheorie Tatsache ist dass Menschen typischerweise, auf dem niedrigsten Niveau dass es überhaupt zu erreichen gibt, eine Übereinstimmung machen.
  19. 19. Studienergebnisse AGILE So ganz scheint es nicht zu passen
  20. 20. Studie der Fa. Kugler Maag Einstimmige Ansicht der Befragten: Nach agilen Methoden und Prinzipien "blind" wie "durch das Buch beschrieben “ hätte zum Scheitern geführt Deshalb machen die Befragten “Kirschen Pflücken" und implementieren solche agile Praktiken, die für sie nützlich sind
  21. 21. Studie der Fa. Kugler Maag Einstimmige Ansicht der Befragten: Wichtige Bedenken in Bezug auf Agile: ▪ Agile skaliert nicht (Trotz LESS & SAFE*) ▪ Mangel an Vorausplanung und (Siehe u.a. ASPICE MAN.3 und respektive Level 2) ▪ Managementwiderstand ▪ Das größte Problem:, agile Elemente in eine nicht agile Umgebung zu bringen, die Fähigkeit, die Organisationskultur, die Projektkomplexität und die Kundenzusammenarbeit zu verändern *Diese Aussage habe ich zugefügt nach mehreren Gesprächen mit Entwicklern bei deutschen Automotive OEM‘s und Tier 1 Zulieferen Quelle: http://www.kuglermaag.de/fileadmin/05_CONTENT_PDF/2-22_agile-automotive_survey-2015.pdf
  22. 22. Kurze Zusammenfassung ▪ Project Manager scheinen sehr intelligent zu reagieren. ▪ Sie machen das was notwendig ist so dass das gewünschte Ergebnis erreicht wird. ▪ Sie nahmen/nehmen das (egal woher es kommt) was Ihnen hilft besser zu werden. ▪ Es scheint unlösbare Wiedersprüche zu geben
  23. 23. Weitere Studienresultate Weitere Studienresultate, welche in dem angegebenen Dokument (Kugler Maag) zu finden sind. • Low Performer und High Performer haben Probleme in solchen Projekten. • Low Performer mit der Transparenz. • High Performer verlieren ihren Heldenstatus.
  24. 24. Gleichmacherei ▪ Ich persönlich habe kein Problem damit das Low Performer auffallen und sich unwohl fühlen. ▪ Ich habe aber ein großes Problem damit, wenn die Highperformer nicht weiterhin exzellent genutzt werden. Sie werden gehen. ▪ Jeder der nicht das Gefühl hat das seine Beiträge wertgeschätzt werden ▪ Wird knötterig ▪ Arbeitet gegen diese Menschen welche ihn nicht wertschätzen oder wendet sich von diesen ab. ▪ Auf lange Sicht wird er die Firma nicht mehr unterstützen, und selbst wenn es bloß darauf hinausläuft dass er nicht mehr vollen Einsatz zeigt.
  25. 25. Das Agile Manifest Vergleiche aus dem normalen Leben
  26. 26. Agile Befürwortet ▪ Adaptive Planung ▪ Evolutionäre Entwicklung ▪ Möglichst frühe Lieferung ▪ Kontinuierliche Verbesserung ▪ Befürwortet schnelle und flexible Antwort auf Änderung Das ist die tägliche Arbeit im Automobilsektor Das möchte jeder, aber keiner möchte sich verändern Auch das möchte jeder haben Das ist etwas, was jeder möchte. Dem steht jedoch die Grundeinstellung entgegen: „Das hamma immer schon so gemacht“ Auch hier der gleiche Satz wie oben: Jeder möchte Veränderung aber keiner möchte sich ändern.
  27. 27. Agile Manifest Konflikte zu normativen Anforderungen #1 Menschen und Interaktionen sind wichtiger als Prozesse und Werkzeug Wer nicht verstanden hat wie wichtig Menschen sind, gehört auf keine einzige Führungsposition. Wenn nicht verstanden hat wie wichtig Prozesse sind um erfolgreich zum Ergebnis zu kommen, gehört auch auf keine Führungsposition. Ein Widerspruch existiert erst mal nicht! Die Wichtigkeit der Menschen ist jedoch seit langem durch das Gesetz von Conway bekannt. Das ist kein agiles Alleinstellungsmerkmal. Funktionierende Software hat Vorrang vor umfassender Dokumentation. Software hat, genauso wie jedes andere Bauelement das anhand von Anforderungen entwickelt wird, zu funktionieren wie in den Anforderungen festgelegt. Die Menge der notwendigen Dokumentation ist in normativen Vorgaben festgelegt.  Definition of Done Ein Versagen ausreichend zu dokumentieren führt grundsätzlich zu weiteren Fehlern und ist von daher, da Fehlerkorrektur mit die teuerste Projekteigenschaft ist, wenn irgend möglich, zu vermeiden. Ein Widerspruch existiert erst mal nicht!
  28. 28. Agile Manifest Konflikte zu normativen Anforderungen #2 Zusammenarbeit mit dem Kunden hat Vorrang vor Vertragsverhandlungen Das ist etwas, was das Management anpassen muss. Ein Widerspruch existiert erst mal nicht! Wer jedoch genau hinschaut und sich die größten Fehler anschaut die im Projektgeschäft immer wieder gemacht werden, wird feststellen das ein sinnvoller Vertrag der Schlüssel Faktor für eine erfolgreiche Zusammenarbeit ist. Reagieren auf eine Änderung hat Vorrang vor den geplanten Schritten Das führt typischerweise innerhalb einer normalen Firma zu dem was die Mitarbeiter so hassen: Zum Chaos Management. Die sofortige Reaktion auf größere Änderungen ist typischerweise in komplexen Systemen nicht durchsetzbar. Wer sich durch Änderung Management aus dem Plan heraus werfen lässt, wird typischerweise nie am Ziel ankommen. Ein Widerspruch existiert erst mal nicht!
  29. 29. Agile Manifest Konflikte zu normativen Anforderungen #3 Reagieren auf eine Änderung hat Vorrang vor den geplanten Schritten Es gibt eine normative Anforderung zum Änderungsmanagement. Die Änderungsanfrage wird sich angeschaut, bewertet, die Einflussanalyse durchgeführt und dann wird die Änderung genehmigt und verplant oder verworfen. Ein Widerspruch existiert erst mal nicht! Grundlegend ist die Reaktion auf eine Änderung vorab zu überlegen. Die Änderung Management und Projektmanagementprozesse müssen aufeinander abgestimmt sein und miteinander interagieren.
  30. 30. Agile Manifest Konflikte zu normativen Anforderungen #4 Zufriedenstellung des Kunden durch frühe und kontinuierliche Auslieferung von wertvoller Software Widerspricht der Notwendigkeit eine Sicherheitsarchitektur zu haben, sowie der Modularität vs. Schnittstellen Die Zufriedenstellung des Kunden bezieht sich nicht darauf, dass der Kunde nun ein Wunschkonzert bekommt. Die Erstellung einer Sicherheitsarchitektur oder eines ähnlich komplexen Systems, bedarf einer gewissen Zeit. Natürlich kann man auch das modular entwickeln, aber gerade größere Systeme benötigen ein wenig Zeit und Gehirnschmalz von erfahrenen Architekten. Wenn man sich diese nicht nimmt wird es im Nachhinein immer sehr sehr schwer genau das was man nicht möchte. Ein Widerspruch existiert erst mal nicht!
  31. 31. Agile Manifest Konflikte zu normativen Anforderungen #5 Agile Prozesse nutzen Veränderungen (selbst spät in der Entwicklung) zum Wettbewerbsvorteil. Das ist eine reine Behauptung und jeder der in einem Unternehmen arbeitet wird versuchen Veränderungen zum Wettbewerbsvorteil einzusetzen. Das kann durch jeden intelligenten und gesteuerten Prozess abgebildet werden. Das ist kein Alleinstellungsmerkmal von agil. Ein Widerspruch existiert erst mal nicht! Nahezu tägliche Zusammenarbeit von Fachexperten und Entwicklern während des Projektes (Bsp.: Gemeinsamer Code-Besitz (Collective Code Ownership)) O. k., wer es nicht schafft die Kollegen eines Projektes zur Zusammenarbeit zu bekommen und damit signifikant gegen jegliche Art von normalen Erkenntnissen und ebenso dem Gesetz von Conway widerspricht, der sollte auch keine Projekte leiten Ein Widerspruch existiert erst mal nicht!
  32. 32. Agile Manifest Konflikte zu normativen Anforderungen #6 Bereitstellung des Umfeldes und der Unterstützung, welche von motivierten Individuen für die Aufgabenerfüllung benötigt wird Das ist eher ein Dauerthema, die Bereitstellung einer Umgebung in der man arbeiten kann ist leider immer noch viel zu selten anzutreffen. Wird aber nicht durch die Agilität verbessert. Ein Widerspruch existiert erst mal nicht! Informationsübertragung nach Möglichkeit im Gespräch von Angesicht zu Angesicht Es ist normativ nicht verboten Informationen von Angesicht zu Angesicht zu übertragen, diese müssen jedoch dokumentiert werden. Hier ist Dokumentation über Podcast, Mitschnitte etc. erlaubt! Es ist erlaubt diese Dokumentation als Aufzeichnung mitzuführen. Ein Widerspruch existiert erst mal nicht!
  33. 33. Agile Manifest Konflikte zu normativen Anforderungen #7 Einhalten eines gleichmäßigen Arbeitstempos von Auftraggebern, Entwicklern und Benutzern für eine nachhaltige Entwicklung Das ist keine Besonderheit der Agilität. Kanban/Kaizen und andere Methoden zeigen, dass eine gleichmäßige Auslastung von maximal 80 % ideal ist. Ein Widerspruch existiert erst mal nicht! Ständiges Augenmerk auf technische Exzellenz und gutes Design Das ist an sich die Idee eines jeden guten Technikers. Diese wird jedoch oftmals durch Management Entscheidungen über den Haufen geworfen. Ein Widerspruch existiert erst mal nicht! Einfachheit ist essenziell (KISS-Prinzip) Das lässt sich in komplexen Systemen kaum noch abbilden.(Alles was man verstanden hat ist einfach) Ein Widerspruch existiert erst mal nicht! Selbstorganisation der Teams bei Planung und Umsetzung Die Kollegen bei der Planung und Umsetzung einzubinden ist Standard eines jeden guten Projektmanagers. Ein Widerspruch existiert erst mal nicht! Selbstreflexion der Teams über das eigene Verhalten zur Anpassung im Hinblick auf Effizienzsteigerung Das setzt voraus, dass es innerhalb der Firma eine etablierte Fehler Mentalität gibt und eine etablierte Fehlerkultur. Ein Widerspruch existiert erst mal nicht!
  34. 34. Zusammenfassung ▪ So schlimm war es doch gar nicht, es gibt jedoch einige Punkte, die de facto im Normativen Umfeld nicht durchsetzbar sind. ▪ Die Widersprüche zu den normativen Anforderungen sind hauptsächlich genau die seitens der Projektleiter als Probleme in der Studie identifizierten Punkte. ▪ Wenn man genau hinschaut gibt es keinen direkten Widerspruch weder zu irgendeiner Norm, noch zu irgend einer Methode. ▪ Es gibt keinen Widerspruch zum V Modell! ▪ DAS WAS IN DER AGILITÄT GEFORDERT WIRD,IST ETWAS WAS AN SICH GESUNDER MENSCHENVERSTAND IST! ▪ Ich komme zurück zu meiner ursprünglichen Aussage: Agilität ist nur entwickelt worden weil man das V Modell nicht verstanden hat. Ich habe nicht gesagt wer es nicht verstanden hat.... Aber ich denke es ist jetzt etwas klarer
  35. 35. Wie löst man das Alles? Das Langzeitergebnis zählt
  36. 36. Die Lösungsidee „methodenfreie Entwicklung“ Machen Sie was langfristig das gewünschte Resultat bringt 1. Ergebnis definieren/ Zieldefinition (muss vorhanden sein) [Wer definiert] (Zeit, Aufwand, Qualität ….) 2. Entpolitisieren Meinungen entfernen  Prozesse / Ergebnisse [Kennzahlen] Weder ist das V-Modell, noch die Agile Methode richtig, das Ergebnis bestimmt den Weg  auf die Kompetenz der Mitarbeiter setzen 3. Conway Gesetz Organisationen, die Systeme entwerfen, […] sind auf Entwürfe festgelegt, welche die Kommunikationsstrukturen dieser Organisationen abbilden. (Bitte keine Religionskriege) Ausbildung untereinander  Stärkere Kommunikation der Teams untereinander  Ausbildung 4. Theorie der Abhängigkeiten (TOC [Theory of constraints]) Engpass finden und auslasten (Bedingung  Kennzahlen) 5. EKS (Engpass orientierte Strategie) Konzentration auf die Kompetenzen  Lösungen hinzukaufen
  37. 37. Grundlegende Probleme jeglicher Entwicklung ▪ Gewisse Arbeitsprodukte müssen erstellt werden BEVOR weitere Entwicklung stattfinden kann. ▪ (Architektur vor coding) ▪ Schnittstellen zwischen den Modulen müssen sauber definiert sein (Grob anfangen  verfeinern und downsizen, gerade bei neuen Systemen) (Widerspruch Einkauf – möglichst Billig) ▪ Skalierung der Teams Die ideale Größe des Teams herauszufinden hat sehr viel mit den Kompetenzen zu tun, welche in Ihrem Unternehmen vorhanden sind. Ein Team größer als zehn Mitarbeiter ist jedoch unabhängig von den Kompetenzen nicht managebar. ▪ Missverständnis was AGILE wirklich ist Aktivität bedeutet nicht auf jeden Kundenwunsch einzugehen. Agile ist eine Aktion mit gesundem Menschenverstand zu entwickeln. Wenn Projektleiter oder das Management Jasager zum Kunden sind, wird es in einer jeglichen Entwicklung schwer.
  38. 38. Lösungsansatz Methodenlose Entwicklung #1 Das machen, welches das Ergebnis bringt 1. Überdimensioniert beginnen 2. Downsizing, wenn überhaupt im C/ D Muster (widerspricht dem Wunsch des Einkaufs) 3. Prio 1 Themen zuerst (Priorisierungsproblematik) ▪ Wird typischerweise in der Agilität über den Systemarchitekt festgelgt 4. In der Vorentwicklung (A & B Muster) MEHR investieren um dort die Lösungen zu finden 5. Kommunikation Einfordern [Meeting Support Record ASPICE] [Conway]
  39. 39. Lösungsansatz Methodenlose Entwicklung #2 Das machen, welches das Ergebnis bringt 6. Ausbildung Einfordern [Conway] BSP: 1-2 Std / Tag Domänen untereinander  Probleme kommen auf lösen 7. Statische Anforderungen der Norm (Mental) ausgliedern und als Teil der „Definition of Done“ beifügen 8. Das Team selbst die beste Methode finden lassen. 9. Aufwändige Aktionen im Team in Themenkomplexen entwickeln – Bsp. Requirements & Architektur 10. Aufwändig planen – PUFFER realistisch einschätzen
  40. 40. PIM.3* und SUP.9** ASPICE© In Kombination mit ISO 26262 • Exzellenter PIM.3*  Generisch • Lessons Learned umsetzen nicht nur aufschreiben  • SUP.9 inklusive • 08-29 Improvement plan • 07-03 Personnel performance measure • 14-02 Corrective action register *Prozess Verbesserung ** Korrektur | Fehlerbehandlung
  41. 41. Finally Was es so an Studien gibt
  42. 42. Fehler Barry Boehm und Victor Basili ▪ Softwarefehler, die erst spät im Lebenszyklus einer Software – also z. B. nach der Auslieferung – gefunden werden, verursachen bis zu 100-mal mehr Kosten als solche, die frühzeitig entdeckt werden. Dies spricht für den konsequenten Einsatz von Techniken zur Fehlervermeidung, insbesondere auch in den frühen Phasen eines Projektes. ▪ 40 bis 50 Prozent des Gesamtaufwandes eines Softwareprojekts entstehen durch eigentlich vermeidbare Nacharbeit. Eine deutlicheReduktion dieses Aufwandes kann vor allem durch Verbesserungen in den Bereichen Entwicklungsprozess, Softwarearchitektur und Risikomanagement erreicht werden. ▪ 80 % der vermeidbaren Nacharbeit werden von nur 20 % der Fehler verursacht. Fehlermanagement kann helfen, die kritischen Bereiche einer Anwendung zu identifizieren. Diese können dann einem Refactoring unterzogen werden. ▪ 80 % der Fehler treten in nur 20 % der Module oder Komponenten auf. Über die Hälfte aller Module und Komponenten ist fehlerfrei. Dieser Tatsache sollte man z. B. durch automatisierte Codeanalysen Rechnung tragen. Diese Analysen geben schon früh im Lebenszyklus eines Projektes wertvolle Hinweise auf potenziell fehleranfällige Module. ▪ 90 % aller Ausfälle eines Systems werden von nur 10 % der Fehler verursacht. Es ist offensichtlich, dass der komplette Stillstand eines produktiven Systems zu den schwerwiegendsten Fehlerszenarien gehört. Jeder einzelne frühzeitig identifizierte oder vermiedene Fehler aus diesen kritischen 10 % rechtfertigt schon für sich die Maßnahmen zur Fehlervermeidung in einem Projekt Zurück
  43. 43. Optimierungspotential ▪ 40 bis 50 Prozent des Gesamtaufwandes eines Softwareprojekts entstehen durch eigentlich vermeidbare Nacharbeit. Eine deutliche Reduktion dieses Aufwandes kann vor allem durch Verbesserungen in den Bereichen Entwicklungsprozess, Softwarearchitektur und Risikomanagement erreicht werden ▪  Selbst mit zusätzlichem Aufwand zur Vermeidung lassen sich MINDESTENS > 20% der Entwicklungskosten sparen ▪ 100 Mann Projekt auf 3 Jahre = >10 Millionen Einsparung ▪ 25 Mann Projekt auf 3 Jahre = > 2,5 Mio Einsparung ▪ Pro Person auf 3 Jahre 125.000 Zurück
  44. 44. Conway's law ▪organizations which design systems ... ▪are constrained to produce designs which are copies of the communication structures of these organizations Back
  45. 45. Die grundlegende Idee einer jeden Veränderung ▪ Benutzen Sie jegliche Norm. ▪ Benutzen Sie jegliche Methode. ▪ Benutzen Sie jegliches Werkzeug. ▪ Benutzen Sie was auch immer. ▪ Um besser zu werden
  46. 46. Danke 蔡荣耀Thomas Arends Repräsentanz Deutscher Mittelstand Schillerstr. 12/1, 73249 Wernau Tel D - Mob | +49 176 42682164 Tel D - FeN | +49 7153 750 9918 Tel C - Mob | +86 159 50 153 049 Skype# +49 176 42682164 ta@deutscher-mittestand.com

×