• Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
490
On Slideshare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
Downloads
5
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Matthias BohlenSoftwarearchitekten – diemachtlosen AnführerEmergieren lassen statt schwitzen!
  • 2. Neulich im ProjektStarring:Leiter der Abteilung ….... Ludwig AngererUse Case Analyst .......... Udo Carsten AmmannSoftware-Architekt …...... Stefan AndersCoach …………………… Matthias Bohlenund viele Entwickler.
  • 3. Ludwig Angerer: Leiter der Abteilung
  • 4. Udo Carsten Ammann: Use Case Analyst
  • 5. viele Entwickler…
  • 6. Stefan Anders: Software-Architekt
  • 7. Seinszustände eines ArchitektenPhase buddhistisch agnostisch pragmatisch resignierend dogmatisch ignorant absorbierend nach Dr. Jürgen Lind naiv und Alexander Knecht Zeit
  • 8. Der ursprüngliche Wertstrom Use Case Abkürzung analysieren SW-Architektur Komponenten SW integrieren normaler Weg entwerfen entwickeln und testen Architekt Komponententeams QS- Teams 1 Wo 1 Wo 3 Wo 2 WoArbeitszeitWartezeit 1 Wo 3 Wo 1 Wo 1 Wo 1 Wo
  • 9. Der optimierte Wertstrom Erstes Zweites Drittes Feature Feature Feature auswählen. auswählen. auswählen. Problem Problem Problem untersuchen. untersuchen. untersuchen. Featurepaket Entwerfen, Entwerfen, Entwerfen, grob codieren, codieren, codieren, analysieren und testen. testen. testen. planen Review Review Review durch durch durch Kunde. In Kunde. In Kunde. In Use Case Analyst, Betrieb Betrieb Betrieb Architekt nehmen. nehmen. nehmen. Feature- Feature- Feature- Teams Teams Teams 1 Wo 4 Wo 4 Wo 4 WoArbeitszeitWartezeit 1 Tag 1 Tag 1 Tag 1 Tag
  • 10. Systemisches Denken Ein Beispiel
  • 11. Das Bier-Spiel Kunde Händler Großhändler Brauerei NACHFRAGE ERFÜLLUNGFahrer kommt wöchentlichKunden bestellen 4 Kisten pro WocheHändler bestellt 4 Kisten pro Woche und hält 12 Kisten am LagerGroßhändler liefert Bestellung nach 4 Wochen ausJeder achtet nur auf sich selbst!“The Fifth Discipline”, Peter M. Senge, Century Business, 1990
  • 12. Bier-Spiel, die 2.Der Spielleiter lässt die Nachfrage steigenJetzt sind es acht Kisten pro WocheWas passiert jetzt?Hinweis: Die Spieler wissen nicht, dass die Nachfrage bei acht Kisten stabil bleiben wird!
  • 13. 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.
  • 14. Bier, isoliert betrachtetZwei Möglichkeiten:1) Die "Keine Strategie"-Strategie Tue nichts besonderes, bestelle einfach so viel wie Du verkaufen kannst2) 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.
  • 15. 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
  • 16. Systemisches DenkenEin System besteht aus voneinander abhängigen und interagierenden Teilen, verbunden durch einen System Zweck.Ein System entwickelt u.U. Eigenschaften, die keines seiner Elemente selbst besitzt. Emergenz.
  • 17. 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
  • 18. Systemisches DenkenWas bedeutet das für eineEntwicklungsorganisation?
  • 19. 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önnenWir benutzen Regeln und Feedback, um uns weiterzuentwickelnWir maximieren gemeinsam den Fluss, der Anforderungen in ausführbare Software verwandelt.
  • 20. Das Projekt als SystemDas Projekt ist ein hoch vernetztes, wissensverarbeitendesSystem mit mehreren FeedbackschleifenEs zeigt selbstorganisierendes, intelligentes Schwarmverhalten,das über die Intelligenz des Einzelnen hinausgeht.Grafik: David Anderson, "Kanban"
  • 21. SelbstorganisationWie kommen wir dahin?
  • 22. Es beginnt bei der Führung…Kommandieren / Systemisch denkenKontrollierenvon oben nach unten Perspektive von außen nach innenfunktionale Arbeitsverteilung Nachfrage, Wert, FlussSpezialisierunggetrennt von der Arbeit Entscheidungen integriert in die ArbeitKosten, Aktivität, Messgrößen orientiert an Zweck,Standards, Produktivität Fähigkeit, Variationextrinsisch Motivation intrinsischBudget managen Führungsethik auf das SystemLeute managen einwirkenvertragsorientiert Einstellung zum Worauf kommt es an? Kunden"Understanding your organization as a system", Vanguard Consulting Ltd., 2001
  • 23. Der Zyklus der Selbstorganisation Regelverletzung FeedbackStarte hier! Regel Diskurs Verhaltensänderung
  • 24. Architekt gibt einfache RegelnBeispiel:Die S.O.L.I.D. Prinzipen für gutes DesignS ingle Responsibility Principle (SRP)Open/Closed Principle (OCP)L iskov Substitution Principle (LSP)I nterface Segregation Principle (ISP)D ependency Inversion Principle (DIP)Robert "Uncle Bob" Martin:http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod
  • 25. 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
  • 26. 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.
  • 27. 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-ÄnderungenDer Architekt filmt diese Präsentationen und stellt sie ins Wikiweb des Projektes
  • 28. Architekt gibt weitere RegelnBeispiel: QUASAR als ArchitekturstilEs gibt vier Komponenten-Arten:Repräsentation, Anwendungsfachlichkeit, Technologie und Neutrale BasiskomponentenArchitekt 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.
  • 29. Architekt verändert seine Rolle Architekt ist jetzt nicht mehr der… schwitzende Nachdokumentierer dogmatische Prinzipienreiter Polizist, 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 beseitigt Förderer der ganzen Entwicklungsorganisation
  • 30. 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
  • 31. Fragen?Gerne jetzt……oder später:Matthias Bohlenmbohlen@mbohlen.dehttp://www.mbohlen.de/+49 170 772 8545
  • 32. 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.