Download - Der entspannte Architekt

Coach für effektive ProduktentwicklungMatthias BohlenDer entspannte ArchitektLean und Kanban in der Architekturarbeit

Matthias Bohlen+49 170 772 [email protected]://www.mbohlen.de@mbohlende

Donnerstag, 20. September 12

3 Vorträge

2Donnerstag, 20. September 12

Coach für effektive ProduktentwicklungMatthias Bohlen

Architekten sind beschäftigt

3

entwerfen

entscheiden

vereinfachen

implementieren

dokumentierenkommunizieren

schätzen

balancieren

beraten

verkaufen



Architektim

Parallelbetrieb


Foto: Casey Hussein Bisson

Muss das so sein odergeht das auch anders?


http://www.flickr.com/photos/maisonbisson/267746261/



Beispiel: Amazon neu entwerfen

6

Wie würden Sie Teams aufstellen, um Amazon.com neu zu bauen?

Und so, dass Ihre Architekten dabeinicht verrückt werden?


Form versus Struktur

7

Struktur stützt FormForm ermöglicht Verhalten


Form

"Essenz" der Strukturwahrnehmbar, interessantwertlieferndkonstant

8

Foto: Maik Maid


http://www.flickr.com/photos/frnetz/5175873526/

http://www.flickr.com/photos/frnetz/5175873526/

Struktur

notwendig für die Formwahrnehmbar, doch weniger interessantKosten erzeugendstabil

9

Foto: Ralph Aichinger


http://www.flickr.com/photos/sooperkuh/4568783387/

http://www.flickr.com/photos/sooperkuh/4568783387/

Verhalten

das, was in der Form passieren kanninteressantNutzen stiftendvariabel, flexibel

10Foto: Benjamin Thompson


http://www.flickr.com/photos/beija/4955027468/in/photostream/

http://www.flickr.com/photos/beija/4955027468/in/photostream/

11

Was das System ist Was das System tut

FormSubsysteme

Interfaces, APIsDomänenobjekte

Use CaseKontext

Methodenfreie Rollen

StrukturModulePaketeKlassen

Methodenreiche Rollen

Algorithmen

Form geht alle an!Form ändert sich seltener als Struktur!


11

Was das System ist Was das System tut

FormSubsysteme

Interfaces, APIsDomänenobjekte

Use CaseKontext

Methodenfreie Rollen

StrukturModulePaketeKlassen

Methodenreiche Rollen

Algorithmen

Form geht alle an!Form ändert sich seltener als Struktur!

Daher: Im Architekturteam die Form aufbauen,in den anderen Teams die Strukturen schaffen!



12

Lagerhaltung

+ Auswertungen+ Bestand+ Lieferanten+ Nachbestellung+ Wareneingang

Bestellung

+ Auswertungen+ Katalog+ Shop

Auslieferung

+ Auswertungen+ Transporteure+ Warenausgang

Zahlung

+ Auswertungen+ Dienstleister+ Mahnwesen+ Rechnungsausgang+ Zahlungseingang

Kundenverwaltung

+ Auswertungen+ Kunden

Schnittstellen

+ EmailAusgang

Subdomänen

Amazon-Subdomänen fachlich



Subdomäne "Lagerhaltung"

13

«Stamminformationen»Bestand

«Berichte»Auswertungen

«Geschaeft»Nachbestellung

«Geschaeft»Wareneingang

«ExterneAnbindung»Lieferanten rot

blau

grün



14

Subdomäne "Bestellung"


«Stamminformationen»Katalog

«Geschaeft»Shop

saphir

rubin

diamant



Subdomäne "Auslieferung"

15

«ExterneAnbindung»Transporteure


«Geschaeft»Warenausgang

gelb

cyan



User Stories

16

als ein... möchte ich... damit...

Kunde nach Waren stöbern

ich etwas bestellen kann

Kunde ein Buch bestellen

ich es lesen kann

CFO Amazon-Kunden bezahlen lassen

Amazon Geld verdient

Kunde eine alternative Lieferadresse angeben

ich es hierher zu mir in den Urlaub geliefert bekomme



Agile Architekturrunde:Gemeinsam sind wir Architekten !

17

Benutzer

Entwickler

Business

Domänen-

experte

Architekt

Fachbereich

Analyst

etc.

Designer

Programmierer

Tester

Kunde



Architekturentwicklung fraktal

18

gelb

cyan

Auslieferung

rot

blau

Lagerhaltung

grün

saphir

rubin

Bestellung

diamant

Top Level Architekturrunde

Zahlung

Kundenverwaltung

Schnittstellen




19

Mitgliederstammen aus allen Subdomänentreffen sich mehrmals pro Wochesprechen über Features des Systemsstellen fest, welchen Beitrag jede Subdomäne leisten mussdefinieren, welche Formabsprachen notwendig sind



Architekturentwicklung fraktal

20

gelb

cyan

Auslieferung

rot

blau

Lagerhaltung

grün

saphir

rubin

Bestellung

diamant


Zahlung

Kundenverwaltung

Schnittstellen

Spontane Architekturrunde auf Ebene jeder Subdomäne!



Architekturrunde pro Subdomäne

21

Mitgliederstammen aus einzelnen Entwicklungsteamsplus andere Stakeholdersprechen über domänen-interne Featuresdefinieren notwendige Form-Elemente pro Feature



User Story "Nach Waren stöbern"

22

Für Kunden: Stellen Sie Ihre eigenen Bilder ein.

Hier reinlesen und suchen

Hallo, Matthias Bohlen. Wir haben Empfehlungen für Sie. (Ausloggen)

Matthias' Amazon | Angebote | Wunschzettel | Gutscheine | Geschenke

Suche Bücher

Bücher Erweiterte Suche Stöbern Bestseller Neuheiten Hörbücher Englische Bücher Taschenbücher

IT-Unternehmensarchitektur: Von derGeschäftsstrategie zur optimalenIT-Unterstützung [Gebundene Ausgabe]Wolfgang Keller (Autor)

(3 Kundenrezensionen) (3)

Preis: EUR 49,90 kostenlose Lieferung. Siehe Details.

Alle Preisangaben inkl. MwSt.

Auf Lager.Verkauf und Versand durch Amazon.de. Geschenkverpackungverfügbar.

Nur noch 13 Stück auf Lager - jetzt bestellen.

Lieferung bis Dienstag, 4. September: Bestellen Sie innerhalb3 Stunden und 24 Minuten und wählen Sie Morning-Expressder Kasse. Siehe Details.

71 neu ab EUR 49,90 6 gebraucht ab EUR 35,60

KurzbeschreibungErscheinungstermin: 27. Februar 2012

Gegenstand von IT-Unternehmensarchitektur ist es, ein Portfolio an Software und IT-Infrastruktur so auszurichten,optimaler Nutzen für das anwendende Unternehmen entsteht. Durch den musterbasierten Ansatz, den dieses Buchmöglich, die IT-Unternehmensarchitektur für die Einsatzziele des Unternehmens zielgenau zu konfigurieren. Der LeZielmuster durch welche Managementprozessmuster unterstützt werden und wie er daraus die erforderliche Datenum Architekturaktivitäten zu unterstützen.

Die Kernprozesse der IT-Unternehmensarchitektur wie das Erarbeiten der IT-Strategie, das IT-PortfoliomanagemenIT-Planung, das Monitoring des Projektportfolios sowie die Projektbegleitung können so an den Bedarf des Unternewerden.

Darüber hinaus vermittelt das Buch notwendige Grundlagen zu den im Unternehmensumfeld wichtigen Themen CoIT-Sicherheit und IT-Risikomanagement. Dabei werden Frameworks für das IT-Management wie TOGAF oder COBIT

Auf diese Seite verlinken Dem Widget hinzufügen Dem aStore hinzufügen Veröffentlichen

Werbekostenrückerstattung Neuigkeiten Diskussionsforen Einstellungen

Alle Kategorien ansehen

Den Verlag informieren!Ich möchte dieses Buch auf demKindle lesen.

Sie haben keinen Kindle? Hier kaufenoder eine gratis Kindle Lese-Appherunterladen.

Gratis-Premiumversand für StudentenAls Student folgende Vorteile sichern: Gratis-Lieferungam nächsten Tag, ohne Mindestbestellwert.Außerdem: 20% erhöhter Eintauschwert bei Trade-In.

Jetzt anmelden

IT-Unternehmensarchitektur: Von der Geschäftsstrategie zur o... http://www.amazon.de/gp/product/3898647684/ref=s9_simh...



Bestand und Lieferzeit

23

Kunde möchte beides sehen"Stöbern"-Story (in Bestellung) muss...

das Lager nach dem Bestand fragendie Auslieferung nach der Lieferzeit fragenbeides ausgeben

Subdomänen-Leute nehmen den Gesprächsbedarf mit und gehen zur nächsten Anforderung über



Die Form der Subdomänen ändern

24

Subdomäne Komponente zuständiges Team

Bestellung Shop saphir

Lager Bestand rot

Auslieferung Warenausgang gelb

Vertreter aus saphir, rot und gelb diskutieren und beschließen die Schnittstellenerweiterungen.



Team rot und sein Shop

25

Mit den neuen Schnittstellen aus den Teams saphir und gelb...

...erweitert Team rot die Form der "Shop"-Komponente

«Geschaeft»Shop

«Geschaeft»Auslieferung::Warenausgang

«Stamminformationen»Lagerhaltung::Bestand

Lieferzeit abfragenBestand abfragen



In der nächsten Architekturrunde

26

Teams berichten über das realisierte Form-Inkrement

Andere Mitglieder der Runde geben Feedback

Die Form ist jetzt gutTeams realisieren und testen die Struktur

und dokumentieren die Änderungen.


Foto: Casey Hussein Bisson

Wie schaffen wir es, Form-Änderungen für 75 Leute

zu koordinieren, ohne dabei verrückt zu werden?




Coach für effektive ProduktentwicklungMatthias BohlenKanban in den Gärten des Kaiserpalastes von Tokio



Kanban in Deinem Portmonnaie

Signalvisuellbegrenzter Vorrat



Kanban in Deinem Portmonnaie

Signalvisuellbegrenzter Vorrat

29

Verflixt! Vergessen zu begrenzen!



Kanban (japanisch 看板)

Taiichi Ohno, Toyota, 1947:„Es müsste doch möglich sein, den Materialfluss in der Produktion nach dem Supermarkt-Prinzip zu organisieren, das heißt, ein Verbraucher entnimmt aus dem Regal eine Ware bestimmter Spezifikation und Menge; die Lücke wird bemerkt und wieder aufgefüllt“.



Einfache Grundideen

1. Arbeite gleichzeitig an so wenigen Aufgaben wie möglich!

2. Fange nur dann etwas Neues an, wenn etwas Existierendes fertig ist oder wenn Dir jemand "flussabwärts" die teilweise fertige Arbeit aus der Hand nimmt!



Warum Kanban?

Konfusion beseitigenKlarheit/Fokus erzeugenvoraussagbar liefern könnenKultur des Unternehmens verändernkontinuierliche Verbesserung fördernEngpässe, Warteschlangen, Varianz, Verschwendung sichtbar machen



Kanban in der SW-Entwicklung1. Visualisiere die Arbeit

2. Limitiere angefangene Arbeit (WIP)

3. Manage den Fluss

4. Mache Prozess-Richtlinien explizit

5. Implementiere Feedbackschleifen

6. Verbessert Euch in gemeinsamer Arbeit, entwickelt Euch weiter durch Experimente(benutzt Modelle und die wissenschaftliche Methode)

Kanban-Pionier seit 2004:David Anderson



© Henrik Kniberg, Crisp Stockholm

Kanban-BeispielTafel von 2 Teams benutzt(16 Leute insgesamt)



Warum WIP begrenzen?



Das Gesetz von Little (1961)

Wenn: L = Anzahl Kunden im Supermarkt λ = Ankunftsrate W = Wartezeit eines KundenDann: L = λW Beispiel: 5 = (10/h) * 0,5h



Das Gesetz von Little

37

Durchschnittlich gilt:

Work in Progress [Features]Zykluszeit = ---------------------------------

[Wochen] Durchsatz [Features pro Woche]



Konsequenzen von zuviel WIP

WIP steht im Zählerje mehr WIP, desto fetter und träger wird das System und desto länger wird die Zykluszeit

Damit kommt das Feedback späterund die Fehlerzahl nimmt zu.

Annahmen bleiben zu lange ungeprüft!



”One day in Kanban land”

Henrik Kniberg

http://blog.crisp.se/henrikkniberg/tags/kanban/





NextDev

Done

Backlog 32 In production :o)

Ongoing

Scenario 1 – one piece flow

B

C

A

D

E

F

G

H IJ L

KM



NextDev

Done


Ongoing


BC

A

D

E

F

G

H IJ L

KM



NextDev

Done


Ongoing


B

C A

D

E

F

G

H IJ L

KM



NextDev

Done


Ongoing

Scenario 1 – one piece flow.

B

C A

D

E

F

G

H IJ L

KM



NextDev

Done


Ongoing


B

C AD

E

F

G

H IJ L

KM



NextDev

Done


Ongoing


B

C ADE

FG

H IJ L

KM



NextDev

Done


Ongoing

Scenario 2 – Deployment problem

B

C

A

D

E

F

G

H IJ L

KM

PO



NextDev

Done


Ongoing


BC

A

D

E

F

G

H IJ L

KM

PO



NextDev

Done


Ongoing


B

C A

D

E

F

G

H IJ L

KM

PO



NextDev

Done


Ongoing


B

C A

D

F

G

H IJ L

KME

PO



NextDev

Done


Ongoing


B

C A

D

F

G

H IJ L

KM

!?

E

PO



NextDev

Done


Ongoing


B

C A

D

F

G

H IJ L

KME

PO



NextDev

Done


Ongoing


B

C

A

D

F

G

H IJ L

KME

PO



NextDev

Done


Ongoing


B

C

A

D

F

G

H IJ L

KM

E

PO



NextDev

Done


Ongoing


B

C

A

D

EF

G

H IJ L

KM

PO



NextDev

Done


Ongoing


B

C

A

D

EF

G

H IJ L

KM

!?PO



NextDev

Done


Ongoing


B

C

A

D

EF

G

H IJ L

KM

PO



NextDev

Done


Ongoing


B

A

D

EF

G

H IJ L

KM

C

PO



NextDev

Done


Ongoing


B

AD

EF

G

H IJ L

KM

C

PO



NextDev

Done


Ongoing


B

AD

E

FG

H IJ L

KM

C

PO



Das WIP-Limit optimieren

nach Henrik Kniberg




nach Henrik Kniberg

To do Doing Done

orem ipsum dolor sit amet, co nse ctetur

orem ipsum dolor

sit amet, co nse

ctetur

1

Zu geringes WIP-Limit

Zzzzzzzzz








nach Henrik Kniberg

To do Doing Done


orem ipsum dolor

sit amet, co nse

ctetur

1


Zzzzzzzzz





Leute warten




nach Henrik Kniberg

To do Doing Done


orem ipsum dolor

sit amet, co nse

ctetur

1


Zzzzzzzzz





Leute warten

Langsamer Fluss (end-to-end)




nach Henrik Kniberg

To do Doing Done


orem ipsum dolor

sit amet, co nse

ctetur

1


To do Doing

orem ipsum dolor

sit amet, co nse

ctetur

Done



orem ipsum dolor

sit amet, co nse

ctetur

5Zu hohes WIP-Limit

orem ipsum dolor sit amet, co nse ctetur orem ipsum dolor

sit amet, co nse ctetur


Zzzzzzzzz






Leute warten





nach Henrik Kniberg

To do Doing Done


orem ipsum dolor

sit amet, co nse

ctetur

1


To do Doing

orem ipsum dolor

sit amet, co nse

ctetur

Done



orem ipsum dolor

sit amet, co nse

ctetur

5Zu hohes WIP-Limit




Zzzzzzzzz






Leute warten


Leute warten nie




nach Henrik Kniberg

To do Doing Done


orem ipsum dolor

sit amet, co nse

ctetur

1


To do Doing

orem ipsum dolor

sit amet, co nse

ctetur

Done



orem ipsum dolor

sit amet, co nse

ctetur

5Zu hohes WIP-Limit




Zzzzzzzzz






Leute warten


Tasks warten oft

Leute warten nie




nach Henrik Kniberg

To do Doing Done


orem ipsum dolor

sit amet, co nse

ctetur

1


To do Doing

orem ipsum dolor

sit amet, co nse

ctetur

Done



orem ipsum dolor

sit amet, co nse

ctetur

5Zu hohes WIP-Limit




Zzzzzzzzz






Leute warten


Langsamer Fluss

Tasks warten oft

Leute warten nie




nach Henrik Kniberg

To do Doing Done


orem ipsum dolor

sit amet, co nse

ctetur

1


To do Doing

orem ipsum dolor

sit amet, co nse

ctetur

Done



orem ipsum dolor

sit amet, co nse

ctetur

5Zu hohes WIP-Limit




Zzzzzzzzz






Leute warten


Langsamer Fluss

Tasks warten oftKein Platz

hier...

Leute warten nie




nach Henrik Kniberg

To do Doing Done


orem ipsum dolor

sit amet, co nse

ctetur

1


To do Doing

orem ipsum dolor

sit amet, co nse

ctetur

Done



orem ipsum dolor

sit amet, co nse

ctetur

2Gerade richtiges WIP-Limit

To do Doing

orem ipsum dolor

sit amet, co nse

ctetur

Done



orem ipsum dolor

sit amet, co nse

ctetur

5Zu hohes WIP-Limit




Zzzzzzzzz








Leute warten


Langsamer Fluss


hier...

Leute warten nie




nach Henrik Kniberg

To do Doing Done


orem ipsum dolor

sit amet, co nse

ctetur

1


To do Doing

orem ipsum dolor

sit amet, co nse

ctetur

Done



orem ipsum dolor

sit amet, co nse

ctetur


To do Doing

orem ipsum dolor

sit amet, co nse

ctetur

Done



orem ipsum dolor

sit amet, co nse

ctetur

5Zu hohes WIP-Limit




Zzzzzzzzz








Leute warten


Tasks warten selten

Langsamer Fluss


hier...

Leute warten nie




nach Henrik Kniberg

To do Doing Done


orem ipsum dolor

sit amet, co nse

ctetur

1


To do Doing

orem ipsum dolor

sit amet, co nse

ctetur

Done



orem ipsum dolor

sit amet, co nse

ctetur


To do Doing

orem ipsum dolor

sit amet, co nse

ctetur

Done



orem ipsum dolor

sit amet, co nse

ctetur

5Zu hohes WIP-Limit




Zzzzzzzzz








Leute warten


Leute warten manchmal (Spielraum)

Tasks warten selten

Langsamer Fluss


hier...

Leute warten nie




nach Henrik Kniberg

To do Doing Done


orem ipsum dolor

sit amet, co nse

ctetur

1


To do Doing

orem ipsum dolor

sit amet, co nse

ctetur

Done



orem ipsum dolor

sit amet, co nse

ctetur


To do Doing

orem ipsum dolor

sit amet, co nse

ctetur

Done



orem ipsum dolor

sit amet, co nse

ctetur

5Zu hohes WIP-Limit




Zzzzzzzzz








Leute warten


Leute warten manchmal (Spielraum)

Schneller FlussTasks warten

seltenLangsamer

Fluss


hier...

Leute warten nie



Ein kanban pro Feature

55

Bestand undLieferzeit anzeigen

Subdomänen:

✓Bestellung (führend)

✓Lager✓Auslieferung

- Zahlung- Schnittstellen

Subdomänenankreuzen, um Abstimmbedarf festzustellen



Kanban Board (linke Hälfte)

56

IdeenIdeen Features NächsteFeatures

Form / ArchitekturForm / ArchitekturForm / Architektur

Neu zerlegen entwerfen zur Abstimmung fertig zumEntwickeln315

610



Kanban Board (rechte Hälfte)

57

EntwickelnEntwickelnEntwickeln Systemtest Akzeptanztest ProduktionSubdomäne unterwegs fertig zum

Systemtest

Lager

Bestellung

Auslieferung

Zahlung

Kunden

Schnittstellen

3015 15 12



Das Gesetz von Little

58

Durchschnittlich gilt:

Work in Progress [Features]Zykluszeit = ---------------------------------

[Wochen] Durchsatz [Features pro Woche]



Annahmen (1)

Jedes Entwicklerteam hat 5 PersonenZwei programmierende Paare

entwickeln gleichzeitig an je 1 Feature

Ein Kümmerer für die ArchitekturRolle kann rotieren, wenn möglich

Work in Progress = 2 FeaturesZykluszeit = 2 Wochen pro Featurealso Durchsatz = 1 Feature pro Woche



Annahmen (2)

Das ganze Kanbansystem (über beide Boards) soll mit einem Durchsatz von15 Features pro Woche "ticken"

Es gibt 15 Teams, also 15 Kümmereralso muss jeder Kümmerer

die Form von 1 Feature pro Wocheentwerfen, abstimmen, dokumentierenund den Code dazu reviewen



Annahmen (3)

Ein Kümmerer braucht pro Feature...1 Std. um Requirements zu verstehen1 Std. um Requirements aufzuschreiben8 Std. zum Entwerfen der Form10 Std. zur Abstimmung mit den anderen4 Std. für Code-Reviews und zur Dokumentation der Architektur

Das sind 24 Stunden pro WocheBleiben 16 Stunden Reservezeit



Der Wochenplan des "Kümmerers"

62

Montag Dienstag Mittwoch Donnerstag Freitag

09:00 - 09:30

09:30 - 12:00

12:00 - 13:00

13:00 - 15:00

15:00 - 16:00

16:00 - 17:00

Daily Scrum MeetingsDaily Scrum MeetingsDaily Scrum MeetingsDaily Scrum MeetingsDaily Scrum Meetings

Konzentrierte Entwurfsarbeitoder Code-Reviews





Mittagessen gehenMittagessen gehenMittagessen gehenMittagessen gehenMittagessen gehen

Meetings zur Abstimmung der FormMeetings zur Abstimmung der FormMeetings zur Abstimmung der FormMeetings zur Abstimmung der FormMeetings zur Abstimmung der Form

Requirements Architektur-DokumentationArchitektur-DokumentationArchitektur-DokumentationArchitektur-Dokumentation

Req.-Doku ReservezeitReservezeitReservezeitReservezeit



Annahmen (4)

Das Meeting der Kümmerer...dauert 2 Std. pro Tagstimmt 15 Form-Änderungen pro Woche abdas sind 3 pro Meetingbleibt pro Abstimmung eine halbe Stundeplus pro Meeting eine halbe Stunde Puffer

Jeder Kümmerer bringt pro Woche eine Form-Änderung zur Abstimmung



Im Form-Abstimmungs-Meeting

64

Bestand undLieferzeit anzeigen

Subdomänen:

✓Bestellung (führend)

✓Lager✓Auslieferung

- Zahlung- Schnittstellen

kanban mit mehreren Häkchen hatten vor dem Meeting echten Abstimmungs-bedarf und sollten sehr klar vorgestellt werden.

kanban mit nur einem Häkchen laufen schnell durch.



Annahmen (5)

65

Wenn mein Team sehr flexibel ist...dann rotieren wir die Rolle des Kümmerersdann komme ich nur alle 5 Wochen dranin den anderen 4 Wochen entwickle ich lauffähige Software!



Architektur besteht aus Form, Struktur und Stil

Architekten sollten Form + Stil schaffen und die Struktur den Entwicklern überlassen

Dann hat man als Architekt genug Zeit.

66

Zusammen-fassung



Literatur

David Anderson:"Kanban", Blue Hole Press 2010

James Coplien, Gertrud Bjornvig:"Lean Architecture", Wiley & Sons 2010



Mehr Info? Hier melden!

Matthias BohlenCoach für effektive Produktentwicklung

Telefon: +49 170 772 8545E-Mail: [email protected]: http://www.mbohlen.de/Twitter: @mbohlende
