Softwarearchitekten – die machtlosen Anführer

32
Matthias Bohlen Softwarearchitekten – die machtlosen Anführer Emergieren lassen statt schwitzen!

Transcript of Softwarearchitekten – die machtlosen Anführer

Page 1: Softwarearchitekten – die machtlosen Anführer

Matthias Bohlen

Softwarearchitekten – die machtlosen Anführer

Emergieren lassen statt schwitzen!

Page 2: Softwarearchitekten – die machtlosen Anführer

Neulich im Projekt

Starring:

Leiter der Abteilung ….... Ludwig AngererUse Case Analyst .......... Udo Carsten AmmannSoftware-Architekt …...... Stefan AndersCoach …………………… Matthias Bohlen

und viele Entwickler.

Page 3: Softwarearchitekten – die machtlosen Anführer

Ludwig Angerer: Leiter der Abteilung

Page 4: Softwarearchitekten – die machtlosen Anführer

Udo Carsten Ammann: Use Case Analyst

Page 5: Softwarearchitekten – die machtlosen Anführer

viele Entwickler…

Page 6: Softwarearchitekten – die machtlosen Anführer

Stefan Anders: Software-Architekt

Page 7: Softwarearchitekten – die machtlosen Anführer

Seinszustände eines ArchitektenPhase buddhistisch

absorbierend

dogmatisch

resignierend

pragmatisch

agnostisch

ignorant

nach Dr. Jürgen Lindund Alexander Knechtnaiv

Zeit

Page 8: Softwarearchitekten – die machtlosen Anführer

Der ursprüngliche WertstromUse Case

analysieren

SW-Architekturentwerfen

Komponentenentwickeln

SW integrierenund testen

Arbeitszeit

Wartezeit

1 Wo

1 Wo

3 Wo

1 Wo

1 Wo 1 Wo 1 Wo

3 Wo 2 Wo

normaler Weg

Abkürzung

Architekt Komponententeams QS-Teams

Page 9: Softwarearchitekten – die machtlosen Anführer

Der optimierte Wertstrom

Featurepaketgrob

analysieren und planen

Erstes Feature

auswählen. Problem

untersuchen. Entwerfen, codieren,

testen. Reviewdurch

Kunde. In Betrieb

nehmen.

Arbeitszeit

Wartezeit

1 Wo 4 Wo 4 Wo 4 Wo

Feature-Teams

Zweites Feature

auswählen. Problem

untersuchen. Entwerfen, codieren,

testen. Reviewdurch

Kunde. In Betrieb

nehmen.

Feature-Teams

Drittes Feature

auswählen. Problem

untersuchen. Entwerfen, codieren,

testen. Reviewdurch

Kunde. In Betrieb

nehmen.

1 Tag 1 Tag 1 Tag 1 Tag

Feature-Teams

Use Case Analyst, Architekt

Page 10: Softwarearchitekten – die machtlosen Anführer

Systemisches Denken

Ein Beispiel

Page 11: Softwarearchitekten – die machtlosen Anführer

Das Bier-SpielKunde Händler Großhändler

BrauereiNACHFRAGE ERFÜLLUNG

Fahrer kommt wöchentlich

Kunden bestellen 4 Kisten pro Woche

Händler bestellt 4 Kisten pro Woche und hält 12 Kisten am Lager

Großhändler liefert Bestellung nach 4 Wochen aus

Jeder achtet nur auf sich selbst!

“The Fifth Discipline”, Peter M. Senge, Century Business, 1990

Page 12: Softwarearchitekten – die machtlosen Anführer

Bier-Spiel, die 2.Der Spielleiter lässt die Nachfrage steigenJetzt sind es acht Kisten pro Woche

Was passiert jetzt?

Hinweis: Die Spieler wissen nicht, dass die Nachfrage bei acht Kisten stabil bleiben wird!

Page 13: Softwarearchitekten – die machtlosen Anführer

Das Bier-Spiel eskaliertHändler sehen Lager schwinden und bestellen

panisch nachBrauerei kommt auf TourenGroßhandel kommt endlich auch auf TourenIn Woche 24 hat Händler 90 Kisten am LagerAlle Händler hören auf zu bestellenDie Brauerei muss Kurzarbeit anmelden.

Das Spiel endet hier. Keine Gewinner.

Page 14: Softwarearchitekten – die machtlosen Anführer

Bier, isoliert betrachtetZwei Möglichkeiten:1) Die "Keine Strategie"-Strategie

Tue nichts besonderes, bestelle einfach so viel wie Du verkaufen kannst

2) Die "Folge den Richtlinien"-Strategie

Richtlinie 1: Merke Dir, wieviel Du bestellt hast und wieviel davon noch nicht eingetroffen ist

Richtlinie 2: Keine Panik! Das Schlimmste, was Du tun kannst, ist zuviel zu bestellen.

Peter M. Senge behauptet, dass 1) funktioniert, 2) aber besser sei.

Page 15: Softwarearchitekten – die machtlosen Anführer

Bier, systemisch betrachtetNeue Möglichkeiten, wenn man das Problem als

ein Problem des Systems, nicht als Problem der einzelnen Elemente betrachtet:

1) Alle Beteiligten teilen einander wöchentlich Daten über die Kundennachfrage mit.

2) Alle arbeiten daran, ihre Reaktionszeiten zu verkürzen.

Alle gewinnen dabei."Understanding your organization as a system", Vanguard Consulting Ltd., 2001

Page 16: Softwarearchitekten – die machtlosen Anführer

Systemisches DenkenEin System besteht aus

voneinander abhängigenund interagierenden Teilen,verbunden durch einenZweck.

Ein System entwickelt u.U. Eigenschaften, die keines seiner Elemente selbst besitzt.

Emergenz.

System

Page 17: Softwarearchitekten – die machtlosen Anführer

Beispiele für Emergenz• Menschenmassen bewegen sich wie Flüssigkeiten• Menschen bilden Sprachen aus Symbolen• Vogelschwärme weichen einem Feind aus• Internet: Netzkunst, Smart Mobs, Online-Spiele• Soldatentrupp bringt eine Brücke zum Einsturz• Windhose / Tornado• Conways Spiel des Lebens• Langtons Ameise

Page 18: Softwarearchitekten – die machtlosen Anführer

Systemisches Denken

Was bedeutet das für eine Entwicklungsorganisation?

Page 19: Softwarearchitekten – die machtlosen Anführer

Einstellung: Wir sind ein System!Unser Kunde gibt uns Anforderungen / ArbeitWir vernetzen uns als System und arbeiten so,

dass die Anforderungen des Kunden gut und vorhersagbar umgesetzt werden können

Wir benutzen Regeln und Feedback, um uns weiterzuentwickeln

Wir maximieren gemeinsam den Fluss, der Anforderungen in ausführbare Software verwandelt.

Page 20: Softwarearchitekten – die machtlosen Anführer

Das Projekt als System

Das Projekt ist ein hoch vernetztes, wissensverarbeitendesSystem mit mehreren Feedbackschleifen

Es zeigt selbstorganisierendes, intelligentes Schwarmverhalten, das über die Intelligenz des Einzelnen hinausgeht.

Grafik: David Anderson, "Kanban"

Page 21: Softwarearchitekten – die machtlosen Anführer

Selbstorganisation

Wie kommen wir dahin?

Page 22: Softwarearchitekten – die machtlosen Anführer

Es beginnt bei der Führung…

Worauf kommt es an?Einstellung zum Kunden

vertragsorientiert

auf das System einwirken

FührungsethikBudget managenLeute managen

intrinsischMotivationextrinsisch

orientiert an Zweck, Fähigkeit, Variation

MessgrößenKosten, Aktivität, Standards, Produktivität

integriert in die ArbeitEntscheidungengetrennt von der Arbeit

Nachfrage, Wert, FlussArbeitsverteilungfunktionale Spezialisierung

von außen nach innenPerspektivevon oben nach unten

Systemisch denkenKommandieren / Kontrollieren

"Understanding your organization as a system", Vanguard Consulting Ltd., 2001

Page 23: Softwarearchitekten – die machtlosen Anführer

Der Zyklus der Selbstorganisation

Regelverletzung Feedback

Starte hier! Regel Diskurs

Verhaltensänderung

Page 24: Softwarearchitekten – die machtlosen Anführer

Architekt gibt einfache RegelnBeispiel:Die S.O.L.I.D. Prinzipen für gutes Design

S ingle Responsibility Principle (SRP)Open/Closed Principle (OCP)L iskov Substitution Principle (LSP)I nterface Segregation Principle (ISP)Dependency Inversion Principle (DIP)

Robert "Uncle Bob" Martin: http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod

Page 25: Softwarearchitekten – die machtlosen Anführer

Teams organisieren sich selbstTeam 1 baut neues Feature einTeam 2 bemerkt, dass SRP verletzt istTeam 2 gibt Feedback an Team 1Team 1 diskutiert mit Team 2 darüberTeam 1 verändert sein VerhaltenTeam 2 schärft die Architekturdoku, weil die

Verantwortlichkeit der Komponente nicht klar genug beschrieben war

Page 26: Softwarearchitekten – die machtlosen Anführer

Architekt publiziert InformationenArchitekt erhebt Daten über

… Komponentenname und -verantwortlichkeit

… Abhängigkeiten

… Testabdeckung

… Komponentengröße und Komplexität

… Zahl der Schnittstellen

… usw.

Er bewertet und veröffentlicht diese Daten regelmäßig.

Page 27: Softwarearchitekten – die machtlosen Anführer

Teams publizieren ArchitekturTeams erzeugen oder verändern Komponenten

und dokumentieren das in der SW-ArchitekturTeams treffen sich wöchentlich zur

ArchitekturabstimmungDer Architektur-Junkie in jedem Team stellt sich

vor eine Webcam und präsentiert die neuesten Komponenten-Änderungen

Der Architekt filmt diese Präsentationen und stellt sie ins Wikiweb des Projektes

Page 28: Softwarearchitekten – die machtlosen Anführer

Architekt gibt weitere RegelnBeispiel: QUASAR als ArchitekturstilEs gibt vier Komponenten-Arten:Repräsentation, Anwendungsfachlichkeit,

Technologie und Neutrale Basiskomponenten

Architekt coacht, wie welche Komponenten-Art zu verwenden ist und welche Art von welcher anderen Art abhängig sein darf.

Teams wenden das auf eigene Komponenten an.

Page 29: Softwarearchitekten – die machtlosen Anführer

Architekt verändert seine RolleArchitekt ist jetzt nicht mehr der…

schwitzende Nachdokumentiererdogmatische PrinzipienreiterPolizist, der die Entwickler kontrolliert

Sondern er wird zum…Coach, der Management und Entwickler berät"Mann mit dem Ölkännchen", der die Reibung zwischen den Teams beseitigtFörderer der ganzen Entwicklungsorganisation

Page 30: Softwarearchitekten – die machtlosen Anführer

ZusammenfassungArchitektur allein zu machen ist mühevoll und

schmerzhaftLassen Sie es den Schwarm machenDenken Sie systemischStarten und fördern Sie den Zyklus der

SelbstorganisationNehmen Sie sich einen erfahrenen Coach für den

Anfang

Page 31: Softwarearchitekten – die machtlosen Anführer

Fragen?Gerne jetzt…

…oder später:Matthias [email protected]://www.mbohlen.de/+49 170 772 8545

Page 32: Softwarearchitekten – die machtlosen Anführer

Literatur und LinksMatthias Bohlen: „Emergente Architektur: Der machtlose

Architekt“, OBJEKTspektrum Nr. 3, Mai/Juni 2010Robert C. Martin: „Principles of object oriented design“

http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOodWikipedia: „Emergenz“ – http://de.wikipedia.org/wiki/EmergenzMike Rother, John Shook: „Learning to See – Value-stream

mapping to create value and eliminate muda“. Lean Enterprise Institute, 1999.

Mary und Tom Poppendieck: „Lean Software Development“, Addison Wesley 2003.

Fritz B. Simon: „Einführung in die systemische Organisationstheorie“. Carl-Auer Compact, 2007.

Fritz B. Simon: „Einführung in Systemtheorie und Konstruktivismus“, Carl-Auer Compact, 2008.