Upload
thomas-arends
View
58
Download
1
Embed Size (px)
Citation preview
Agile wurde nur entwickelt, weil man das V-Modell nicht verstanden hatEin Ketzerischer Vortrag um sich Feinde zu schaffen
VorabIch 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.
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
Agiler AnsatzA-SPICE© & ISO 26262
ASPICE © Grundlegende Anforderungen
Das ASPICE© Prozesshaus
Der Entwicklungsprozess
Traceability & Konsistenz
Zusammenfassung
▪ Klares V-Model
▪ Entwicklung beginnen von den Top Anforderungen
▪ Traceability und Konsistenz ist ein MUSS!
ISO 26262 Normative Anforderung
Prozesse in der ISO 26262
Das V-Model
Zusammenfassung
▪ Klares V-Model
▪ Entwicklung beginnen von den Top Anforderungen
▪ Traceability und Konsistenz ist ein MUSS!
Das Agile ManifestUnd ein paar ketzerische Kommentare
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
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
Grundlegende Ideen
Agile Software Entwicklung beschreibt ein Prinzipien
Bei dem Anforderungen und LösungenDurch 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“.
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.
Studienergebnisse AGILE So ganz scheint es nicht zu passen
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
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
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
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.
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.
Das Agile ManifestVergleiche aus dem normalen Leben
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.
Agile ManifestKonflikte zu normativen Anforderungen #1Menschen 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!
Agile ManifestKonflikte 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!
Agile ManifestKonflikte 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.
Agile ManifestKonflikte 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!
Agile ManifestKonflikte 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!
Agile ManifestKonflikte 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!
Agile ManifestKonflikte zu normativen Anforderungen #7Einhalten 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!
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
Wie löst man das Alles?Das Langzeitergebnis zählt
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 GesetzOrganisationen, 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
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 istAktivitä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.
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]
Lösungsansatz Methodenlose Entwicklung #2
Das machen, welches das Ergebnis bringt
6. Ausbildung Einfordern [Conway]BSP: 1-2 Std / TagDomä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
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
FinallyWas es so an Studien gibt
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
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
Conway's law
▪organizations which design systems ...
▪are constrained to produce designs whichare copies of the communicationstructures of these organizations
Back
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
Danke蔡荣耀Thomas ArendsRepräsentanz Deutscher MittelstandSchillerstr. 12/1,73249 WernauTel D - Mob | +49 176 42682164Tel D - FeN | +49 7153 750 9918Tel C - Mob | +86 159 50 153 049Skype# +49 176 [email protected]