Ketzerischer Vortrag zur Agilen Entwicklung

46
Agile wurde nur entwickelt, weil man das V-Modell nicht verstanden hat Ein Ketzerischer Vortrag um sich Feinde zu schaffen

Transcript of Ketzerischer Vortrag zur Agilen Entwicklung

Page 1: Ketzerischer Vortrag zur Agilen Entwicklung

Agile wurde nur entwickelt, weil man das V-Modell nicht verstanden hatEin Ketzerischer Vortrag um sich Feinde zu schaffen

Page 2: Ketzerischer Vortrag zur Agilen Entwicklung

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.

Page 3: Ketzerischer Vortrag zur Agilen Entwicklung

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

Page 4: Ketzerischer Vortrag zur Agilen Entwicklung

Agiler AnsatzA-SPICE© & ISO 26262

Page 5: Ketzerischer Vortrag zur Agilen Entwicklung

ASPICE © Grundlegende Anforderungen

Page 6: Ketzerischer Vortrag zur Agilen Entwicklung

Das ASPICE© Prozesshaus

Page 7: Ketzerischer Vortrag zur Agilen Entwicklung

Der Entwicklungsprozess

Page 8: Ketzerischer Vortrag zur Agilen Entwicklung

Traceability & Konsistenz

Page 9: Ketzerischer Vortrag zur Agilen Entwicklung

Zusammenfassung

▪ Klares V-Model

▪ Entwicklung beginnen von den Top Anforderungen

▪ Traceability und Konsistenz ist ein MUSS!

Page 10: Ketzerischer Vortrag zur Agilen Entwicklung

ISO 26262 Normative Anforderung

Page 11: Ketzerischer Vortrag zur Agilen Entwicklung

Prozesse in der ISO 26262

Page 12: Ketzerischer Vortrag zur Agilen Entwicklung

Das V-Model

Page 13: Ketzerischer Vortrag zur Agilen Entwicklung

Zusammenfassung

▪ Klares V-Model

▪ Entwicklung beginnen von den Top Anforderungen

▪ Traceability und Konsistenz ist ein MUSS!

Page 14: Ketzerischer Vortrag zur Agilen Entwicklung

Das Agile ManifestUnd ein paar ketzerische Kommentare

Page 15: Ketzerischer Vortrag zur Agilen Entwicklung

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

Page 16: Ketzerischer Vortrag zur Agilen Entwicklung

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

Page 17: Ketzerischer Vortrag zur Agilen Entwicklung

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“.

Page 18: Ketzerischer Vortrag zur Agilen Entwicklung

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.

Page 19: Ketzerischer Vortrag zur Agilen Entwicklung

Studienergebnisse AGILE So ganz scheint es nicht zu passen

Page 20: Ketzerischer Vortrag zur Agilen Entwicklung

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

Page 21: Ketzerischer Vortrag zur Agilen Entwicklung

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

Page 22: Ketzerischer Vortrag zur Agilen Entwicklung

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

Page 23: Ketzerischer Vortrag zur Agilen Entwicklung

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.

Page 24: Ketzerischer Vortrag zur Agilen Entwicklung

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.

Page 25: Ketzerischer Vortrag zur Agilen Entwicklung

Das Agile ManifestVergleiche aus dem normalen Leben

Page 26: Ketzerischer Vortrag zur Agilen Entwicklung

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.

Page 27: Ketzerischer Vortrag zur Agilen Entwicklung

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!

Page 28: Ketzerischer Vortrag zur Agilen Entwicklung

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!

Page 29: Ketzerischer Vortrag zur Agilen Entwicklung

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.

Page 30: Ketzerischer Vortrag zur Agilen Entwicklung

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!

Page 31: Ketzerischer Vortrag zur Agilen Entwicklung

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!

Page 32: Ketzerischer Vortrag zur Agilen Entwicklung

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!

Page 33: Ketzerischer Vortrag zur Agilen Entwicklung

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!

Page 34: Ketzerischer Vortrag zur Agilen Entwicklung

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

Page 35: Ketzerischer Vortrag zur Agilen Entwicklung

Wie löst man das Alles?Das Langzeitergebnis zählt

Page 36: Ketzerischer Vortrag zur Agilen Entwicklung

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

Page 37: Ketzerischer Vortrag zur Agilen Entwicklung

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.

Page 38: Ketzerischer Vortrag zur Agilen Entwicklung

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]

Page 39: Ketzerischer Vortrag zur Agilen Entwicklung

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

Page 40: Ketzerischer Vortrag zur Agilen Entwicklung

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

Page 41: Ketzerischer Vortrag zur Agilen Entwicklung

FinallyWas es so an Studien gibt

Page 42: Ketzerischer Vortrag zur Agilen Entwicklung

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

Page 43: Ketzerischer Vortrag zur Agilen Entwicklung

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

Page 44: Ketzerischer Vortrag zur Agilen Entwicklung

Conway's law

▪organizations which design systems ...

▪are constrained to produce designs whichare copies of the communicationstructures of these organizations

Back

Page 45: Ketzerischer Vortrag zur Agilen Entwicklung

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

Page 46: Ketzerischer Vortrag zur Agilen Entwicklung

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]