Patterns effektiv einsetzen

Patterns effektiv einsetzen
Anatomie erfolgreicher Projekte
Vortrag auf der OOP 2007
Matthias Bohlen <mbohlen@mbohlen.de>
Unabhängiger Software-Architekt und Berater

25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 2
Agenda
Erfolgreiche Projekte
Notwendiges Handwerkszeug
Patterns in Software und in Teams
Was können Sie tun?
Fragen und Antworten

Matthias Bohlen – das Profil
Unabhängiger Berater
Architektur, Software-Engineering
Modellgetriebene Software-Entwicklung, MDA
Objekt- und Komponententechnologien
Dienstleistungen:
Analyse, Design, Architektur
Project jump start
Technische Projektleitung
Therapie für Projekte in der Krise
Beratung
Schulung
Trainings
Coaching

Referenzen

Kunden
Kleine und große Unternehmen
Starten Softwareprojekte
mit neuen oder unbekannten Technologien
mit unklaren Methoden oder Prozessen
mit engen Terminvorgaben
mit sich schnell ändernden Anforderungen
manchmal ohne Architektur bzw. „Bauplan“
Insgesamt: hoher Beratungsbedarf

Die Expedition
Aufbruch ins Projekt – sind Sie richtig
ausgerüstet?

Aufbruch ins Ungewisse
Wenn Sie zu einer Wanderexpedition
aufbrechen, was packen Sie unbedingt ein?
Karte
Kompass
Sonnenbrille
Reserve-Kleidung
Essen & Wasser
Helm mit Lampe
Erste-Hilfe-Kit
Streichhölzer
Messer
Nur das unbedingt Nötige!
Mehr ergibt sich von selbst!

Dasselbe für Software…
Für ein Softwareprojekt gilt dasselbe!
Brechen Sie auf, das Nötige im Gepäck:
Vision
Geschäftsidee
Plan
Risikoliste
Problemliste
Architektur
Produktwachstum
Meilensteine
Change Requests
Benutzer-Support
Schreiben Sie Ihre eigene "Packliste"!
Mehr ergibt sich auch hier von selbst!

Sie sind nicht die Ersten!
Viele Projekte vor Ihnen haben schon
Erfahrung gesammelt
Lernen Sie aus diesen Projekten!
Verzichten Sie auf Fehler (es sei denn,
diese machen Ihnen Spaß)
Also: Lesen Sie Patterns!

Was tut ein Pattern?
Fasst Expertenwissen zusammen
Macht dieses verständlich
Löst wiederkehrende Probleme
Schafft Vokabular für Lösungen
Balanciert (widerstrebende) Kräfte aus
Arbeitet mit anderen Patterns zusammen

Was gibt es für Patterns?
Software Design (GoF)
Organisations-Patterns
Branchen-Patterns (Telekom, etc.)
Pädagogik-Patterns
und viele andere…

Was ist ein Pattern (1)?
Etwas
Seine Beschreibung
Beschreibung wie man "Etwas" erzeugt
Lösung eines wiederkehrenden Problems in
einem Kontext
Diese ominöse "Definition" nützt Ihnen nur,
wenn Sie schon wissen, was Patterns sind! ☺

Was ist ein Pattern (2)?
Beziehungen zwischen Komponenten eines
Systems, das eine Menge von
Anforderungen ins Gleichgewicht bringt
Eine Methode, komplexes Verhalten aus
einfachen Regeln zu erzeugen
Ein Weg, die Welt für Menschen
angenehmer zu machen (nicht nur für
Entwickler oder Lehrer…)
Klingt immer noch abstrakt, nicht wahr?

Elemente eines Patterns
Problem
Kontext / Umstände
Kräfte (in der Ausgangssituation)
Lösung
Anwendungsbeispiel
Konsequenzen und neuer Kontext

Beispiel: Verkehr
Problem
Entwerfen Sie eine
Kreuzung zwischen
zwei Landstraßen
Kontext
Dänemark
Lösung: ?
Kräfte
Wartungsarm
Land ist billig
Strom ist teuer zu
transportieren
Verkehr ist gering
Keinen unnötigen Halt
verursachen
Wie lautet dasselbe für die Schweiz
bei starkem Verkehr?

Was ein Pattern nicht ist!
Wenn es nur einen Weg gibt, etwas zu tun,
ist er kein Pattern (Kontext und Kräfte sind
wichtig!)
Wenn es die Kräfte nicht ins Gleichgewicht
bringt, ist es kein Pattern.
Wenn es keinen Expertenkonsens gibt,
dass die Lösung die beste ist, ist es kein
Pattern.

Na, ist ja ganz nett!
Aber was hat das mit einem Software-Projekt zu
tun?

Beteiligte und Interessen
Null Fehler
Gute
Dokumen-
tation
Leichte
Änderbarkeit
Viele Features
Benutzer-
freundlichkeit
Schnelle,
robuste
Software
Interessante
Arbeit
Erforschen
neuer Gebiete
Stressarmes
Arbeiten
Leben zu
Hause
Alles im Plan!
Keine Über-
raschungen
Erfolgreiches
Projekt
Kurze
Realisie-
rungszeit
Geringe
Kosten
Wartungs-
personal
BenutzerEntwicklerChefsKunden
Nach Steve McConnell: Rapid Development

Erfolgreiche Projekte
Wann ist ein Projekt erfolgreich?
Erfolg ist eine Kombination aus…
Das Projekt produziert ein werthaltiges Ergebnis
Alle Beteiligten sind zufrieden und möchten am
liebsten sofort zusammen das nächste Projekt
angehen!

Weg zum Erfolg
Balancieren Sie die Kräfte aus, die aus den
Interessen der Beteiligten entstehen
Machen Sie aus jedem Beteiligten einen
Gewinner!
Patterns beschreiben, wie das geht…

Part 1:
Projektmanagement
Erfolgreiche Projekte managen sich auf ganz
bestimmte Weise…

Projekte richtig aufsetzen
Die entscheidenden Fehler passieren am Anfang
eines Projektes bei der Definition
Zu eng gesetzter Zeitplan
Falsche Zahl von Leuten im Projekt
Warum ist das so schwierig?
Studieren wir die Grundlagen
Was kann man tun?
Zwei Patterns werden helfen

Projektdefinition: Kräfte (1)
Projektverlauf = f(s, u, t, q)
s = Teamgröße
u = Funktionsumfang
t = Zeit bzw. Termin
q = Qualität
Vier Parameter, die sich gegenseitig nicht-
linear und zeitverzögert beeinflussen!
Alptraum des Projektmanagers!

Umfang beeinflusst Zeit
Je mehr Features zu realisieren sind, desto mehr Zeit
wird benötigt
Koppelnde Größe: "Schlagzahl" des Teams
Zeit beeinflusst Qualität
Zu knapp gesetzte Zeit: Fehler und Workarounds
Zu großzügig gesetzte Zeit: "Goldene Lösungen", die
teuer, komplex oder überflüssig sind

Qualität beeinflusst Teamgröße
Gute Leute wollen gute Arbeit abliefern
Leute werden kündigen, wenn die Qualität zu
schlecht wird
Zeit beeinflusst Teamgröße
Zeit zu knapp Entwickler gestresst
Leute werden kündigen, wenn sie zu sehr
gestresst werden

Qualität beeinflusst Zeit
Je schlechter die Qualität, desto höher der
Zusatzaufwand bei Änderungen
Workarounds machen das Entwicklerteam
langsamer
Bei schlechter Qualität wird mehr Zeit benötigt

Pattern: ZeitplanAushandeln
Problem
Aushandeln eines
Zeitplans, dem alle
zustimmen können
Kontext
Softwareprojekt, das
gerade startet
Thema verstanden
Umfang ungefähr
definiert
Kräfte
Kunde: Schnell
realisieren,
geringe Kosten
Benutzer: Viele Features
Entwickler: Stressarmes,
interessantes Arbeiten
Nach Jim Coplien: "SizeTheSchedule"

Lösung: ZeitplanAushandeln
Qualität q ganz hoch halten
Termin(e) t festsetzen
Teamgröße s als gegeben annehmen
Größe finden? Siehe nächstes Pattern!
Umfang u anpassen
Alle paar Wochen:
Verhältnis u,s,t überdenken!
Schlagzahl des Teams ist eine gute
Rechengrundlage für u-Anpassung!

ZeitplanAushandeln
Voraussetzungen
Vertrauensverhältnis zwischen Kunde und
Entwicklungsorganisation
Wichtigsten Teil des Umfangs in den ersten
Iterationen realisieren
Kunde wird Umfangsanpassung eher für
möglich halten als Vertröstung auf
imaginären Folgetermin

Pattern: TeamWachsenLassen
Problem
Ermitteln der richtigen
Teamgröße
Kontexte
gerade startet
schon eine Weile
unterwegs ist
Kräfte
Anforderungen und
Design anfangs unklar
Entwickler sitzen
herum, also wenig
Leute benötigt!
Viele Features in
kurzer Zeit mehr
Leute benötigt!
Nach Jim Coplien: "SizeTheOrganization"

Zu kleines Team
Kritische Masse wird nicht erreicht, die
zum Schreiben eines großen Systems
(> 25.000 LOC) notwendig ist
Projekt kommt nicht schnell genug voran.

Zu großes Team
Ein Team hat zwei Haupt-Aufgaben
Ergebnisse produzieren
Die Kraft zur Produktion der Ergebnisse steigt
linear mit der Mitgliederzahl
Kommunizieren
Der Aufwand für Kommunikation steigt quadratisch
mit der Mitgliederzahl
Effekt: Ab einer gewissen Größe kann das
Team nicht mehr effizient arbeiten!

Zu spätes Wachstum
Brooks: "Adding people to a late project
makes it later!"
Neue Leute müssen sich einarbeiten
verzögerte Steigerung der Arbeitskraft
Neue Leute beanspruchen erfahrene Leute
Produktivität sinkt vorübergehend ab! (siehe
nächstes Pattern)
Ein Projekt in Verzug gerät noch mehr in Verzug,
wenn Sie Leute hinzufügen!
Brooks, Frederick: The Mythical Man-Month

Lösung: TeamWachsenLassen
Starten Sie mit ein paar Experten
Domänenwissen und Analysemethodik
Architektur- und Designwissen
Wenige, exzellente "Prototyper"
Nutzen Sie danach das Wissen um die
voraussichtliche Projektgröße und planen
Sie sofort Wachstumsphasen mit ein!

Grenzen des Teamwachstums
V. A. Vyssotsky (Bell Telephone
Laboratories) schätzt, dass ein großes
Projekt ein Manpower-Wachstum von max.
30% pro Jahr halten kann – mehr stresst
und verhindert sogar den notwendigen
Aufbau informeller Strukturen und
Kommunikationswege!
Nach Frederick Brooks und Jim Coplien

Hilfe! Neue Leute!
Sie haben TeamWachsenLassen
erfolgreich angewendet.
Jetzt kommen die eingeplanten
neuen Leute!
Die Experten müssen die Novizen
anlernen und schaffen selbst nichts
mehr! Was tun?

Pattern: NovizenLehrer
Problem
Experten sollen
Novizen unterrichten
und trotzdem zum
Projekt beitragen
Kontext
Softwareteam, in
Wachstum und
Reorganisation
begriffen
Kräfte
Experten allein sind zu
wenig, um das System
zu entwickeln
Produktivitätszuwachs
durch neue Leute
erforderlich
Produktiv.-Minderung
durch Unterricht ist aber
schmerzhaft
Nach Jim Coplien: "DayCare"

Lösung zu NovizenLehrer
Halten Sie die Novizen raus
aus dem Expertenteam
Stellen Sie einen Experten für die Novizen
ab und lassen Sie die anderen in Ruhe das
System weiterentwickeln
Das ist besser als Experten und Novizen
gleichmäßig zu mischen!

Woran liegt's?
Ein bisschen Mathematik
Annahme: Ein Experte hat normalerweise eine
Performance von 1.
Unterrichtet er einen Novizen, so fällt seine
Produktivität auf ½, bei zwei Novizen auf 1/3,
bei dreien auf ¼, bei m auf 1/(m+1).
Wie sieht also die Team-Performance aus,
wenn Novizen hereinkommen?

Experten getrennt von Novizen
X Experten
schaffen normalerweise X*1 = X
N Novizen
jeder schafft n mit n<<1, z.B. n=1/10
Ein Experte abgestellt für die Novizen
Team-Performance nur noch
TP = (X-1) + N*n
Beispiel: X=5, N=10, n=0,1
TP = (5-1)+10*0,1 = 5

Experten gemischt mit Nov.
Die Performance jedes Experten geht
zurück auf 1/(m+1), wobei m die Anzahl
der Novizen pro Experte ist
also m = N / X
Team-Performance ist also jetzt
TP = X / ( N/X + 1 ) + N*n
Beispiel: X=5, N=10, n=0,1
TP = 5 / (2+1) + 10*0,1 = 2,7

Sonstige Projektmanagement-Patterns
BenannteStabileBasen
Entwickler kann Baseline selbst wählen, z.b. den
Nightly Build oder das letzte ausführlich
getestete Build
PrivateWelt
Entwickler arbeitet in eigener Umgebung
holt sich Änderungen der Kollegen explizit herein

AufgabeAufteilen
bei Termin-Engpass eine Aufgabe in einen
dringenden und einen weniger dringenden Teil
aufteilen
dringenden Teil vor dem Termin, den Rest
danach erledigen

TeamProAufgabe
In den besten Projekten kommen Krisen und
sonstige Ablenkungen vor
Gründen Sie ein Sub-Team, das sich um die
Krise kümmert
Lassen Sie das Haupt-Team ungehindert
weiterarbeiten
Viele weitere Patterns von Jim Coplien:
http://www.easycomp.org/cgi-bin/OrgPatterns?BookOutline

Part 2:
Organisationsstile,
organisches Wachstum
Angepasste Organisationen funktionieren
besser…

Pattern: HolistischeVielfalt
Problem
Entwicklung eines
Subsystems benötigt
viele Skills, jedoch sind
Leute meist spezialisiert
Kontext
Softwareprojekt
Stark disjunktes Wissen
bei den beteiligten
Menschen
Kräfte
Ein Einzelner hat nicht alle
Skills, die benötigt werden,
z.B. GUI-Design,
Persistenz, Security, usw.
Um ein fachlich und
technisch korrektes
Subsystem zu schreiben,
benötigt man jedoch alle
diese Skills.
Lösung: Formen Sie ein Team aus mehreren
Spezialisten. Geben Sie dem Team
Verantwortung für das fachliche
Subsystem.

Pattern: SubsystemProSkill
Problem
Software soll über
längere Zeit wartbar
bleiben, selbst wenn sich
die Teamzusammen-
setzung ändert
Kontext
Lang laufendes Projekt
Disjunkte Skills bei den
beteiligten Menschen
Fluktuation im Team
Kräfte
Fluktuation bringt Varianz
Varianz kann Inkonsistenz
im Code nach sich ziehen
Neue Leute brauchen klar
lesbaren Code, der ihre
eigenes Vokabular
verwendet
Neue Leute müssen die
Philosophie des alten Codes
verstehen bzw. ablesen
können
Lösung: Trennen Sie Subsysteme nach den Skills
der Mannschaft (GUI, Domänenmodell,
Persistenz, Datenbankzugriff, usw.)

Na, welches von beiden denn nun?
HolistischeVielfalt oder SubsystemProSkill?
Antwort: Nehmen Sie beide!
Wenn Sie SubsystemProSkill weglassen…
…bekommen Sie eine wilde Mischung aus GUI,
Domänenmodell, Persistenz, Remoting, usw. im
selben Code!
Wenn Sie HolistischeVielfalt weglassen…
…bekommen Sie ein Zimmer mit GUI-Leuten, eins
mit Domänenmodellierern, eins mit Persistenz-
Spezialisten usw. und entsprechend wenig
Kommunikation!

Pattern: Conway's Law
Problem
Organisation finden,
deren Kommunikations-
wege die Architektur des
Produktes unterstützen
Kontext
Reiferes Softwareprojekt
Entwicklerteam
Architekturteam
Reife, mitwachsende
Architektur
Kräfte
Softwarestruktur ändert
sich innerhalb der
Projektlaufzeit
Alte Teamstrukturen
existieren weiter
Mismatch verursacht
Reibung im Projekt
Lösung: Passen Sie die Organisation an!

Organisation versus Produkt
Die Struktur des Produkts definiert die
Struktur der Kommunikationswege in den
Teams
Passen Sie deshalb bei sich ändernder
Produktarchitektur die Struktur Ihrer
Projektorganisation an!
Das wird Reibungsverluste minimieren!

Pattern: OrganisationUndOrt
Problem
Kommunikationswege
finden oder anpassen,
wenn Teile des
Projektes an
verschiedenen Orten
arbeiten
Kontext
Softwareprojekt mit
verteilten Teams
Kräfte
Kommunikation über
Ortsgrenzen hinweg ist
schwieriger als direkte
Kommunikation
Trotzdem notwendig, da
gemeinsames Produkt zu
erstellen
Overhead minimieren
Lösung: Passen Sie architektonische und
geographische Grenzen aneinander an!

Produkt und Geographie (1)
Es hat keinen Sinn, zusammenhängende
Teile des Produktes an getrennten Orten
zu entwickeln (umgekehrt ist das kein
Problem!)
Der Kommunikationsaufwand wird Sie
auffressen, deshalb wird die
Kommunikation nicht stattfinden, und das
Produkt wird leiden!
Nach Jim Coplien:
"OrganizationFollowsLocation"

Produkt und Geographie (2)
Wenn zwei Teams T1 und T2 an
verschiedenen Orten am selben
Teilprodukt P arbeiten, dann…
spalten Sie P in P1 und P2, schaffen dazwischen
eine Schnittstelle und lassen P1 durch T1 und P2
durch T2 entwickeln oder
lassen Sie ein Team umziehen, so dass es am
selben Ort wie das andere Team sitzt!
Nach Jim Coplien:
"OrganizationFollowsLocation"

Sonstige Organisationsstil-Patterns
WenigeRollenSindMehr
ProduzentenRollenSindWichtiger
TeileUndHerrsche
SchaffeKommunikationsPlätze
VerschiebeVerantwortung
etc.

Part 3:
Menschen und Code
Ein interessanter Zusammenhang…

Pattern: ArchitektImplementiert
Problem
Dem Architekten
Realitätsbezug und
Autorität verschaffen
Kontext
Softwareprojekt
Architekten und
Entwickler als explizite
Rollen ausgeprägt
Kräfte
Entwickler treffen
Einzelentscheidungen
pro Subsystem
Anerkannte,
übergeordnete,
strategische, technische
Sicht und Leitung
erforderlich
Möglicher Konflikt
Lösung: Lassen Sie den Architekten
teilweise mitentwickeln!

ArchitektImplementiert (1)
Architekten…
designen, beraten, kommunizieren,
koordinieren, führen (ja, tatsächlich!)
brauchen jedoch auch tiefes Wissen über
Komponentenbeziehungen, Protokolle, APIs,
Performance, etc.
dürfen nicht im Elfenbeinturm entwerfen
Nach Jim Coplien:
"ArchitectAlsoImplements"

ArchitektImplementiert (2)
Entwickler…
entwerfen im Kleinen
implementieren, testen, kommunizieren
werden den Architekten nicht unbedingt
respektieren, wenn er sie nicht versteht oder
"über den Wolken schwebt"
Deshalb: Lassen Sie den Architekten
teilweise Code schreiben!
Achtung: Lassen Sie den Architekten jedoch
nicht auf den kritischen Pfad! ☺

Pattern: CodeBesitz
Problem
Integrität bereits
geschriebenen Codes
bewahren
Kontext
Softwareprojekt
Stark disjunktes
Wissen im
Entwicklerteam
Kräfte
Gedanken hinter dem
Code stehen nicht im
Code (Code basiert z.B.
auf kompliziertem
Framework)
Codepflege verlangt
informierten Entwickler
Lösung: Definieren Sie "Besitzer"
pro Codemodul.

CodeBesitz (1)
Entwickler arbeiten an getrennten Features
der Anwendung
Features benutzen jedoch dieselben
Architekturkomponenten
Daher werden Entwickler dazu tendieren,
dieselben Komponenten modifizieren zu
wollen
Nach Jim Coplien: "CodeOwnership"

CodeBesitz (2)
Gefahr:
Viele Köche verderben den Brei!
Modul wird u.U. inkonsistent
Bei einfachem Code und geteiltem Wissen im
Entwicklerteam
kein Problem!
Bei kompliziertem Code und individuellem, nicht
geteiltem Hintergrundwissen
besser nur ein Koch pro Modul!

CodeBesitz (3)
Kontraindikation
Entwickler ist so stolz auf seinen Code, dass er
ihn so toll schreibt, dass nur noch er selbst ihn
versteht
XP verlangt deshalb aus guten Grund "Collective
Ownership": Wenn ich heute eine zu
komplizierte Stelle einbaue, hast Du sie morgen
schon rausfaktorisiert!

CodeBesitz (4)
Achtung: CodeBesitz nicht mit Feature-
Verantwortung verwechseln!
CodeBesitz bezieht sich auf ein Modul und ist
permanent
Feature-Verantwortung bezieht sich auf eine
Funktion der Anwendung und ist temporär!
(so lange, bis das Feature realisiert ist)

Sonstige Code-Patterns
ArchitektSteuertProdukt
SchließeSieAlleEin
RauchgefüllterRaum
VarianzHinterSchnittstelle
PrivatesVersionieren
LoseSchnittstellen
etc…

Zusammenfassung
Patterns sind kondensiertes Erfahrungswissen
Patterns haben einen Kontext, in dem sie
angewendet werden sollen
Patterns bieten eine anerkannte Lösung für
eine häufig auftretende Aufgabenstellung
Patterns haben manchmal
Kontraindikationen, so dass sie in einer
bestimmten Situation nicht angewendet
werden sollten

Mehr über Patterns erfahren?
Workshop "Patterns effektiv einsetzen"
zusammen mit Dr. Gernot Starke
Anmelden?
Email an: mbohlen@mbohlen.de
Buch „Organizational Patterns of Agile
Software Development“
Autor: James Coplien
ISBN: 0-13-146740-9

Ende des Vortrags
Danke für Ihre
Aufmerksamkeit!
FRAGEN ?
Matthias Bohlen
mbohlen@mbohlen.de
Tel. 0170 / 772 8545

Patterns effektiv einsetzen

Weitere ähnliche Inhalte

Was ist angesagt?

Andere mochten auch

Mehr von Matthias Bohlen

Patterns effektiv einsetzen