SlideShare ist ein Scribd-Unternehmen logo
1 von 46
Agile wurde nur
entwickelt, weil man das
V-Modell nicht verstanden
hat
Ein Ketzerischer Vortrag um sich Feinde zu schaffen
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.
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 Ansatz
A-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 Manifest
Und 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ö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“.
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 Manifest
Vergleiche 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 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!
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!
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.
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!
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!
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!
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!
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 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
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.
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 / 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
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
Finally
Was 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 which
are copies of the communication
structures 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 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

Weitere ähnliche Inhalte

Was ist angesagt?

Hypothesengetriebene agile Transitionen mit Sociocracy 3.0 (OOP-2017)
Hypothesengetriebene agile Transitionen mit Sociocracy 3.0 (OOP-2017)Hypothesengetriebene agile Transitionen mit Sociocracy 3.0 (OOP-2017)
Hypothesengetriebene agile Transitionen mit Sociocracy 3.0 (OOP-2017)Bernhard Bockelbrink
 
Anforderungen haben immer Schuld
Anforderungen haben immer SchuldAnforderungen haben immer Schuld
Anforderungen haben immer SchuldFrank Düsterbeck
 
Integration agiler und klassischer Vorgehensweisen (Embedded-Meets-Agile 18.2...
Integration agiler und klassischer Vorgehensweisen (Embedded-Meets-Agile 18.2...Integration agiler und klassischer Vorgehensweisen (Embedded-Meets-Agile 18.2...
Integration agiler und klassischer Vorgehensweisen (Embedded-Meets-Agile 18.2...Joachim Baumann
 
Schöner scheitern – Die beliebtesten Missverständnisse im agilen RE
Schöner scheitern – Die beliebtesten Missverständnisse im agilen RESchöner scheitern – Die beliebtesten Missverständnisse im agilen RE
Schöner scheitern – Die beliebtesten Missverständnisse im agilen REoose
 
E-Commerce vs Architektur CodeTalks.Commerce_2018
E-Commerce vs Architektur CodeTalks.Commerce_2018E-Commerce vs Architektur CodeTalks.Commerce_2018
E-Commerce vs Architektur CodeTalks.Commerce_2018Johann-Peter Hartmann
 
Erfahrungen mit agilen Festpreisen
Erfahrungen mit agilen FestpreisenErfahrungen mit agilen Festpreisen
Erfahrungen mit agilen FestpreisenJoachim Baumann
 
Markus Schranner: "Das Lean Startup Prinzip - Potentiale für NGOs und soziale...
Markus Schranner: "Das Lean Startup Prinzip - Potentiale für NGOs und soziale...Markus Schranner: "Das Lean Startup Prinzip - Potentiale für NGOs und soziale...
Markus Schranner: "Das Lean Startup Prinzip - Potentiale für NGOs und soziale...Socialbar
 
Keynote Highspeed Produktentwicklung - bis an die Grenzen des physikalisch Ma...
Keynote Highspeed Produktentwicklung - bis an die Grenzen des physikalisch Ma...Keynote Highspeed Produktentwicklung - bis an die Grenzen des physikalisch Ma...
Keynote Highspeed Produktentwicklung - bis an die Grenzen des physikalisch Ma...Frank Lange
 
Wozu Agilität? Klassisches Projektmanagement funktioniert doch auch sehr gut!
Wozu Agilität? Klassisches Projektmanagement funktioniert doch auch sehr gut!Wozu Agilität? Klassisches Projektmanagement funktioniert doch auch sehr gut!
Wozu Agilität? Klassisches Projektmanagement funktioniert doch auch sehr gut!Frank Lange
 
Ergebnisbericht der Studie Experten in agilen Produktentwicklungsprozessen
Ergebnisbericht der Studie Experten in agilen ProduktentwicklungsprozessenErgebnisbericht der Studie Experten in agilen Produktentwicklungsprozessen
Ergebnisbericht der Studie Experten in agilen ProduktentwicklungsprozessenProf. Dr. Eva-Maria Schön
 
2012-07 Lean Startup at #bcka by Calpano
2012-07 Lean Startup at #bcka by Calpano2012-07 Lean Startup at #bcka by Calpano
2012-07 Lean Startup at #bcka by CalpanoMax Völkel
 
23 Dinge, die Sie über Software Entwicklung in Teams wissen sollten
23 Dinge, die Sie über Software Entwicklung in Teams wissen sollten23 Dinge, die Sie über Software Entwicklung in Teams wissen sollten
23 Dinge, die Sie über Software Entwicklung in Teams wissen solltenStephan Schmidt
 

Was ist angesagt? (18)

Virtuelle projekte
Virtuelle projekteVirtuelle projekte
Virtuelle projekte
 
DevOps: Change Mindset before Toolset
DevOps: Change Mindset before ToolsetDevOps: Change Mindset before Toolset
DevOps: Change Mindset before Toolset
 
Hypothesengetriebene agile Transitionen mit Sociocracy 3.0 (OOP-2017)
Hypothesengetriebene agile Transitionen mit Sociocracy 3.0 (OOP-2017)Hypothesengetriebene agile Transitionen mit Sociocracy 3.0 (OOP-2017)
Hypothesengetriebene agile Transitionen mit Sociocracy 3.0 (OOP-2017)
 
Agile intro-90min (2007)
Agile intro-90min (2007)Agile intro-90min (2007)
Agile intro-90min (2007)
 
It Kaizen
It KaizenIt Kaizen
It Kaizen
 
Anforderungen haben immer Schuld
Anforderungen haben immer SchuldAnforderungen haben immer Schuld
Anforderungen haben immer Schuld
 
Integration agiler und klassischer Vorgehensweisen (Embedded-Meets-Agile 18.2...
Integration agiler und klassischer Vorgehensweisen (Embedded-Meets-Agile 18.2...Integration agiler und klassischer Vorgehensweisen (Embedded-Meets-Agile 18.2...
Integration agiler und klassischer Vorgehensweisen (Embedded-Meets-Agile 18.2...
 
Schöner scheitern – Die beliebtesten Missverständnisse im agilen RE
Schöner scheitern – Die beliebtesten Missverständnisse im agilen RESchöner scheitern – Die beliebtesten Missverständnisse im agilen RE
Schöner scheitern – Die beliebtesten Missverständnisse im agilen RE
 
OOP2017: Scrum statt Murcs - Agile Software-Entwicklung
OOP2017: Scrum statt Murcs - Agile Software-EntwicklungOOP2017: Scrum statt Murcs - Agile Software-Entwicklung
OOP2017: Scrum statt Murcs - Agile Software-Entwicklung
 
DWX2016: Der perfekte Mitarbeiter - vom T-Shape zum Team-Shape
DWX2016: Der perfekte Mitarbeiter - vom T-Shape zum Team-ShapeDWX2016: Der perfekte Mitarbeiter - vom T-Shape zum Team-Shape
DWX2016: Der perfekte Mitarbeiter - vom T-Shape zum Team-Shape
 
E-Commerce vs Architektur CodeTalks.Commerce_2018
E-Commerce vs Architektur CodeTalks.Commerce_2018E-Commerce vs Architektur CodeTalks.Commerce_2018
E-Commerce vs Architektur CodeTalks.Commerce_2018
 
Erfahrungen mit agilen Festpreisen
Erfahrungen mit agilen FestpreisenErfahrungen mit agilen Festpreisen
Erfahrungen mit agilen Festpreisen
 
Markus Schranner: "Das Lean Startup Prinzip - Potentiale für NGOs und soziale...
Markus Schranner: "Das Lean Startup Prinzip - Potentiale für NGOs und soziale...Markus Schranner: "Das Lean Startup Prinzip - Potentiale für NGOs und soziale...
Markus Schranner: "Das Lean Startup Prinzip - Potentiale für NGOs und soziale...
 
Keynote Highspeed Produktentwicklung - bis an die Grenzen des physikalisch Ma...
Keynote Highspeed Produktentwicklung - bis an die Grenzen des physikalisch Ma...Keynote Highspeed Produktentwicklung - bis an die Grenzen des physikalisch Ma...
Keynote Highspeed Produktentwicklung - bis an die Grenzen des physikalisch Ma...
 
Wozu Agilität? Klassisches Projektmanagement funktioniert doch auch sehr gut!
Wozu Agilität? Klassisches Projektmanagement funktioniert doch auch sehr gut!Wozu Agilität? Klassisches Projektmanagement funktioniert doch auch sehr gut!
Wozu Agilität? Klassisches Projektmanagement funktioniert doch auch sehr gut!
 
Ergebnisbericht der Studie Experten in agilen Produktentwicklungsprozessen
Ergebnisbericht der Studie Experten in agilen ProduktentwicklungsprozessenErgebnisbericht der Studie Experten in agilen Produktentwicklungsprozessen
Ergebnisbericht der Studie Experten in agilen Produktentwicklungsprozessen
 
2012-07 Lean Startup at #bcka by Calpano
2012-07 Lean Startup at #bcka by Calpano2012-07 Lean Startup at #bcka by Calpano
2012-07 Lean Startup at #bcka by Calpano
 
23 Dinge, die Sie über Software Entwicklung in Teams wissen sollten
23 Dinge, die Sie über Software Entwicklung in Teams wissen sollten23 Dinge, die Sie über Software Entwicklung in Teams wissen sollten
23 Dinge, die Sie über Software Entwicklung in Teams wissen sollten
 

Ähnlich wie Ketzerischer Vortrag zur Agilen Entwicklung

Agil in der Normativen Welt
Agil in der Normativen WeltAgil in der Normativen Welt
Agil in der Normativen WeltThomas Arends
 
Lean Startup: Wie sieht der Einsatz von MVPs in der deutschen Praxis aus?
Lean Startup: Wie sieht der Einsatz von MVPs in der deutschen Praxis aus?Lean Startup: Wie sieht der Einsatz von MVPs in der deutschen Praxis aus?
Lean Startup: Wie sieht der Einsatz von MVPs in der deutschen Praxis aus?Gregor Gross
 
Agile Methoden und die Theory of Constraints
Agile Methoden und die Theory of ConstraintsAgile Methoden und die Theory of Constraints
Agile Methoden und die Theory of ConstraintsFrank Lange
 
Agilität im Systems Engineering – geht das?
Agilität im Systems Engineering – geht das?Agilität im Systems Engineering – geht das?
Agilität im Systems Engineering – geht das?HOOD Group
 
AGILE BEYOND BUZZWORD BINGO (MAGAZIN)
AGILE BEYOND BUZZWORD BINGO (MAGAZIN)AGILE BEYOND BUZZWORD BINGO (MAGAZIN)
AGILE BEYOND BUZZWORD BINGO (MAGAZIN)Marc Wagner
 
eparo – IA und agile Softwareentwicklung verbinden (Vortrag IA-Konferenz 2009...
eparo – IA und agile Softwareentwicklung verbinden (Vortrag IA-Konferenz 2009...eparo – IA und agile Softwareentwicklung verbinden (Vortrag IA-Konferenz 2009...
eparo – IA und agile Softwareentwicklung verbinden (Vortrag IA-Konferenz 2009...eparo GmbH
 
Hurra wir werden agil - aber wie?
Hurra wir werden agil - aber wie?Hurra wir werden agil - aber wie?
Hurra wir werden agil - aber wie?Frank Düsterbeck
 
Lean und Agiles Management in der öffentlichen Verwaltung: die Zukunft?
Lean und Agiles Management in der öffentlichen Verwaltung: die Zukunft?Lean und Agiles Management in der öffentlichen Verwaltung: die Zukunft?
Lean und Agiles Management in der öffentlichen Verwaltung: die Zukunft?Learning Factory
 
Lean Startup und agile Methodiken – Hype oder Fortschritt ?
Lean Startup und agile Methodiken – Hype oder Fortschritt ?Lean Startup und agile Methodiken – Hype oder Fortschritt ?
Lean Startup und agile Methodiken – Hype oder Fortschritt ?Heico Koch
 
Projektmanagement in vernetzten Forschungsprojekten
Projektmanagement in vernetzten ForschungsprojektenProjektmanagement in vernetzten Forschungsprojekten
Projektmanagement in vernetzten ForschungsprojektenChristian Heise
 
OKR, Ziele und Zielsysteme im Agilen
OKR, Ziele und Zielsysteme im AgilenOKR, Ziele und Zielsysteme im Agilen
OKR, Ziele und Zielsysteme im AgilenBjörn Schotte
 
Selbstorganisation führt IT-Projekte zum Erfolg
Selbstorganisation führt IT-Projekte zum ErfolgSelbstorganisation führt IT-Projekte zum Erfolg
Selbstorganisation führt IT-Projekte zum ErfolgJürgen Marx
 
Agil vs. klassisch in der Geräteentwicklung - mit der richtigen Symbiose zum...
Agil vs. klassisch in der Geräteentwicklung - mit der richtigen Symbiose zum...Agil vs. klassisch in der Geräteentwicklung - mit der richtigen Symbiose zum...
Agil vs. klassisch in der Geräteentwicklung - mit der richtigen Symbiose zum...Marc Bless
 
FMK2015: Software Engineering Basics by Jan Rüdiger
FMK2015: Software Engineering Basics by Jan RüdigerFMK2015: Software Engineering Basics by Jan Rüdiger
FMK2015: Software Engineering Basics by Jan RüdigerVerein FM Konferenz
 
Baumgartner und Partner - BPM-Webinar - HR-Management in agilen Strukturen
Baumgartner und Partner  - BPM-Webinar  - HR-Management in agilen Strukturen Baumgartner und Partner  - BPM-Webinar  - HR-Management in agilen Strukturen
Baumgartner und Partner - BPM-Webinar - HR-Management in agilen Strukturen Friedrich, Dr. Fratschner
 
Baumgartner und partner bpm-webinar - hr-management in agilen strukturen
Baumgartner und partner    bpm-webinar  - hr-management in agilen strukturen Baumgartner und partner    bpm-webinar  - hr-management in agilen strukturen
Baumgartner und partner bpm-webinar - hr-management in agilen strukturen Friedrich, Dr. Fratschner
 
AgileAustriaConference2023_Brücken bauen: Wie Agilität und die ISO 9001 Hand ...
AgileAustriaConference2023_Brücken bauen: Wie Agilität und die ISO 9001 Hand ...AgileAustriaConference2023_Brücken bauen: Wie Agilität und die ISO 9001 Hand ...
AgileAustriaConference2023_Brücken bauen: Wie Agilität und die ISO 9001 Hand ...Agile Austria Conference
 

Ähnlich wie Ketzerischer Vortrag zur Agilen Entwicklung (20)

Agil in der Normativen Welt
Agil in der Normativen WeltAgil in der Normativen Welt
Agil in der Normativen Welt
 
Lean Startup: Wie sieht der Einsatz von MVPs in der deutschen Praxis aus?
Lean Startup: Wie sieht der Einsatz von MVPs in der deutschen Praxis aus?Lean Startup: Wie sieht der Einsatz von MVPs in der deutschen Praxis aus?
Lean Startup: Wie sieht der Einsatz von MVPs in der deutschen Praxis aus?
 
Agile Methoden und die Theory of Constraints
Agile Methoden und die Theory of ConstraintsAgile Methoden und die Theory of Constraints
Agile Methoden und die Theory of Constraints
 
Agilität im Systems Engineering – geht das?
Agilität im Systems Engineering – geht das?Agilität im Systems Engineering – geht das?
Agilität im Systems Engineering – geht das?
 
AGILE BEYOND BUZZWORD BINGO (MAGAZIN)
AGILE BEYOND BUZZWORD BINGO (MAGAZIN)AGILE BEYOND BUZZWORD BINGO (MAGAZIN)
AGILE BEYOND BUZZWORD BINGO (MAGAZIN)
 
eparo – IA und agile Softwareentwicklung verbinden (Vortrag IA-Konferenz 2009...
eparo – IA und agile Softwareentwicklung verbinden (Vortrag IA-Konferenz 2009...eparo – IA und agile Softwareentwicklung verbinden (Vortrag IA-Konferenz 2009...
eparo – IA und agile Softwareentwicklung verbinden (Vortrag IA-Konferenz 2009...
 
Hurra wir werden agil - aber wie?
Hurra wir werden agil - aber wie?Hurra wir werden agil - aber wie?
Hurra wir werden agil - aber wie?
 
Retail MeetUp #1 .pdf
Retail MeetUp #1 .pdfRetail MeetUp #1 .pdf
Retail MeetUp #1 .pdf
 
Lean und Agiles Management in der öffentlichen Verwaltung: die Zukunft?
Lean und Agiles Management in der öffentlichen Verwaltung: die Zukunft?Lean und Agiles Management in der öffentlichen Verwaltung: die Zukunft?
Lean und Agiles Management in der öffentlichen Verwaltung: die Zukunft?
 
Lean Startup und agile Methodiken – Hype oder Fortschritt ?
Lean Startup und agile Methodiken – Hype oder Fortschritt ?Lean Startup und agile Methodiken – Hype oder Fortschritt ?
Lean Startup und agile Methodiken – Hype oder Fortschritt ?
 
Projektmanagement in vernetzten Forschungsprojekten
Projektmanagement in vernetzten ForschungsprojektenProjektmanagement in vernetzten Forschungsprojekten
Projektmanagement in vernetzten Forschungsprojekten
 
OKR, Ziele und Zielsysteme im Agilen
OKR, Ziele und Zielsysteme im AgilenOKR, Ziele und Zielsysteme im Agilen
OKR, Ziele und Zielsysteme im Agilen
 
Das Pfadfinderprinzip in DevOps
Das Pfadfinderprinzip in DevOpsDas Pfadfinderprinzip in DevOps
Das Pfadfinderprinzip in DevOps
 
Selbstorganisation führt IT-Projekte zum Erfolg
Selbstorganisation führt IT-Projekte zum ErfolgSelbstorganisation führt IT-Projekte zum Erfolg
Selbstorganisation führt IT-Projekte zum Erfolg
 
Agil vs. klassisch in der Geräteentwicklung - mit der richtigen Symbiose zum...
Agil vs. klassisch in der Geräteentwicklung - mit der richtigen Symbiose zum...Agil vs. klassisch in der Geräteentwicklung - mit der richtigen Symbiose zum...
Agil vs. klassisch in der Geräteentwicklung - mit der richtigen Symbiose zum...
 
FMK2015: Software Engineering Basics by Jan Rüdiger
FMK2015: Software Engineering Basics by Jan RüdigerFMK2015: Software Engineering Basics by Jan Rüdiger
FMK2015: Software Engineering Basics by Jan Rüdiger
 
Baumgartner und Partner - BPM-Webinar - HR-Management in agilen Strukturen
Baumgartner und Partner  - BPM-Webinar  - HR-Management in agilen Strukturen Baumgartner und Partner  - BPM-Webinar  - HR-Management in agilen Strukturen
Baumgartner und Partner - BPM-Webinar - HR-Management in agilen Strukturen
 
Baumgartner und partner bpm-webinar - hr-management in agilen strukturen
Baumgartner und partner    bpm-webinar  - hr-management in agilen strukturen Baumgartner und partner    bpm-webinar  - hr-management in agilen strukturen
Baumgartner und partner bpm-webinar - hr-management in agilen strukturen
 
Über das U im UX
Über das U im UXÜber das U im UX
Über das U im UX
 
AgileAustriaConference2023_Brücken bauen: Wie Agilität und die ISO 9001 Hand ...
AgileAustriaConference2023_Brücken bauen: Wie Agilität und die ISO 9001 Hand ...AgileAustriaConference2023_Brücken bauen: Wie Agilität und die ISO 9001 Hand ...
AgileAustriaConference2023_Brücken bauen: Wie Agilität und die ISO 9001 Hand ...
 

Ketzerischer Vortrag zur Agilen Entwicklung

  • 1. Agile wurde nur entwickelt, weil man das V-Modell nicht verstanden hat Ein Ketzerischer Vortrag um sich Feinde zu schaffen
  • 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. 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
  • 9. Zusammenfassung ▪ Klares V-Model ▪ Entwicklung beginnen von den Top Anforderungen ▪ Traceability und Konsistenz ist ein MUSS!
  • 11. Prozesse in der ISO 26262
  • 13. Zusammenfassung ▪ Klares V-Model ▪ Entwicklung beginnen von den Top Anforderungen ▪ Traceability und Konsistenz ist ein MUSS!
  • 14. Das Agile Manifest Und ein paar ketzerische Kommentare
  • 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
  • 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. 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. Studienergebnisse AGILE So ganz scheint es nicht zu passen
  • 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. 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. 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. 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. 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. Das Agile Manifest Vergleiche aus dem normalen Leben
  • 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. 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. 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. 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. 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. 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. 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. 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. 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. Wie löst man das Alles? Das Langzeitergebnis zählt
  • 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. 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. 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. 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. 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. Finally Was es so an Studien gibt
  • 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. 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. Conway's law ▪organizations which design systems ... ▪are constrained to produce designs which are copies of the communication structures of these organizations Back
  • 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. 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

Hinweis der Redaktion

  1. Yep – wild es geht bei einem intelligenten Zusammenschluss
  2. Das Ergebnis dürfte real sein
  3. AUSREICHEND
  4. Ich erinnere mich an die Notwendigkeit mit ungeeigneten CPU‘s zu arbeite und ebenso K60 mit dem Z80 Kynernetik