Patterns effektiv einsetzen

Patterns effektiv einsetzenAnatomie erfolgreicher Projekte

Vortrag auf der OOP 2007Matthias Bohlen <[email protected]>Unabhängiger Software-Architekt und Berater

25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 2

Agenda

Erfolgreiche ProjekteNotwendiges HandwerkszeugPatterns in Software und in TeamsWas können Sie tun?Fragen und Antworten


Matthias Bohlen – das Profil

Unabhängiger BeraterArchitektur, Software-EngineeringModellgetriebene Software-Entwicklung, MDAObjekt- 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 UnternehmenStarten Softwareprojekte

mit neuen oder unbekannten Technologienmit unklaren Methoden oder Prozessenmit engen Terminvorgabenmit sich schnell ändernden Anforderungenmanchmal 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?

KarteKompassSonnenbrilleReserve-Kleidung

Essen & WasserHelm mit LampeErste-Hilfe-KitStreichhölzerMesser

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:

VisionGeschäftsidee PlanRisikolisteProblemliste

ArchitekturProduktwachstumMeilensteineChange RequestsBenutzer-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 gesammeltLernen 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 zusammenMacht dieses verständlichLöst wiederkehrende ProblemeSchafft Vokabular für LösungenBalanciert (widerstrebende) Kräfte ausArbeitet mit anderen Patterns zusammen


Was gibt es für Patterns?

Software Design (GoF)Organisations-PatternsBranchen-Patterns (Telekom, etc.)Pädagogik-Patternsund viele andere…


Was ist ein Pattern (1)?

EtwasSeine BeschreibungBeschreibung wie man "Etwas" erzeugtLö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 bringtEine Methode, komplexes Verhalten aus einfachen Regeln zu erzeugenEin 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

ProblemKontext / UmständeKräfte (in der Ausgangssituation)LösungAnwendungsbeispielKonsequenzen und neuer Kontext


Beispiel: Verkehr

ProblemEntwerfen Sie eine Kreuzung zwischen zwei Landstraßen

KontextDänemark

Lösung: ?

KräfteWartungsarmLand ist billigStrom ist teuer zu transportierenVerkehr ist geringKeinen 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 FehlerGute Dokumen-tationLeichte Änderbarkeit

Viele FeaturesBenutzer-freundlichkeitSchnelle, robuste Software

Interessante ArbeitErforschen neuer GebieteStressarmes ArbeitenLeben zu Hause

Alles im Plan!Keine Über-raschungenErfolgreiches Projekt

Kurze Realisie-rungszeitGeringe 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 ErgebnisAlle 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 entstehenMachen 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 ZeitplanFalsche 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ößeu = Funktionsumfangt = Zeit bzw. Terminq = QualitätVier Parameter, die sich gegenseitig nicht-linear und zeitverzögert beeinflussen!

Alptraum des Projektmanagers!



Umfang beeinflusst ZeitJe mehr Features zu realisieren sind, desto mehr Zeit wird benötigtKoppelnde Größe: "Schlagzahl" des Teams

Zeit beeinflusst QualitätZu knapp gesetzte Zeit: Fehler und WorkaroundsZu großzügig gesetzte Zeit: "Goldene Lösungen", die teuer, komplex oder überflüssig sind



Qualität beeinflusst TeamgrößeGute Leute wollen gute Arbeit abliefernLeute werden kündigen, wenn die Qualität zu schlecht wird

Zeit beeinflusst TeamgrößeZeit zu knapp Entwickler gestresstLeute werden kündigen, wenn sie zu sehr gestresst werden



Qualität beeinflusst ZeitJe schlechter die Qualität, desto höher der Zusatzaufwand bei ÄnderungenWorkarounds machen das Entwicklerteam langsamerBei schlechter Qualität wird mehr Zeit benötigt


Pattern: ZeitplanAushandelnProblem

Aushandeln eines Zeitplans, dem alle zustimmen können

KontextSoftwareprojekt, das gerade startetThema verstandenUmfang ungefähr definiert

KräfteKunde: Schnell realisieren,geringe KostenBenutzer: Viele FeaturesEntwickler: Stressarmes, interessantes Arbeiten

Nach Jim Coplien: "SizeTheSchedule"


Lösung: ZeitplanAushandeln

Qualität q ganz hoch haltenTermin(e) t festsetzenTeamgröße s als gegeben annehmen

Größe finden? Siehe nächstes Pattern!

Umfang u anpassenAlle paar Wochen:

Verhältnis u,s,t überdenken!

Schlagzahl des Teams ist eine guteRechengrundlage für u-Anpassung!


ZeitplanAushandelnVoraussetzungen

Vertrauensverhältnis zwischen Kunde und EntwicklungsorganisationWichtigsten 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: TeamWachsenLassenProblem

Ermitteln der richtigen Teamgröße

KontexteSoftwareprojekt, das gerade startetSoftwareprojekt, das schon eine Weile unterwegs ist

KräfteAnforderungen und Design anfangs unklar

Entwickler sitzen herum, also wenigLeute benötigt!Viele Features in kurzer Zeit mehrLeute 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 istProjekt kommt nicht schnell genug voran.


Zu großes TeamEin Team hat zwei Haupt-Aufgaben

Ergebnisse produzierenDie Kraft zur Produktion der Ergebnisse steigt linear mit der Mitgliederzahl

KommunizierenDer Aufwand für Kommunikation steigt quadratischmit der Mitgliederzahl

Effekt: Ab einer gewissen Größe kann das Team nicht mehr effizient arbeiten!


Zu spätes WachstumBrooks: "Adding people to a late projectmakes it later!"

Neue Leute müssen sich einarbeitenverzö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: TeamWachsenLassenStarten Sie mit ein paar Experten

Domänenwissen und AnalysemethodikArchitektur- und DesignwissenWenige, 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 TelephoneLaboratories) 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 TeamWachsenLassenerfolgreich angewendet.Jetzt kommen die eingeplantenneuen Leute!Die Experten müssen die Novizen anlernen und schaffen selbst nichts mehr! Was tun?


Pattern: NovizenLehrerProblem

Experten sollen Novizen unterrichten und trotzdem zum Projekt beitragen

KontextSoftwareteam, in Wachstum und Reorganisation begriffen

KräfteExperten allein sind zu wenig, um das System zu entwickelnProduktivitätszuwachs durch neue Leute erforderlichProduktiv.-Minderungdurch Unterricht ist aber schmerzhaft

Nach Jim Coplien: "DayCare"


Lösung zu NovizenLehrer

Halten Sie die Novizen rausaus dem ExpertenteamStellen Sie einen Experten für die Novizen ab und lassen Sie die anderen in Ruhe das System weiterentwickelnDas ist besser als Experten und Novizen gleichmäßig zu mischen!


Woran liegt's?

Ein bisschen MathematikAnnahme: 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 Novizenjeder schafft n mit n<<1, z.B. n=1/10

Ein Experte abgestellt für die NovizenTeam-Performance nur nochTP = (X-1) + N*n

Beispiel: X=5, N=10, n=0,1TP = (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 jetztTP = X / ( N/X + 1 ) + N*n

Beispiel: X=5, N=10, n=0,1TP = 5 / (2+1) + 10*0,1 = 2,7


Sonstige Projektmanagement-Patterns

BenannteStabileBasenEntwickler kann Baseline selbst wählen, z.b. den Nightly Build oder das letzte ausführlich getestete Build

PrivateWeltEntwickler arbeitet in eigener Umgebungholt sich Änderungen der Kollegen explizit herein



AufgabeAufteilenbei Termin-Engpass eine Aufgabe in einen dringenden und einen weniger dringenden Teil aufteilendringenden Teil vor dem Termin, den Rest danach erledigen



TeamProAufgabeIn den besten Projekten kommen Krisen und sonstige Ablenkungen vorGründen Sie ein Sub-Team, das sich um die Krise kümmertLassen 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: HolistischeVielfaltProblem

Entwicklung eines Subsystems benötigt viele Skills, jedoch sind Leute meist spezialisiert

KontextSoftwareprojektStark disjunktes Wissen bei den beteiligten Menschen

KräfteEin 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 mehrerenSpezialisten. Geben Sie dem Team Verantwortung für das fachliche Subsystem.


Pattern: SubsystemProSkillProblem

Software soll über längere Zeit wartbar bleiben, selbst wenn sich die Teamzusammen-setzung ändert

KontextLang laufendes ProjektDisjunkte Skills bei den beteiligten MenschenFluktuation im Team

KräfteFluktuation bringt VarianzVarianz kann Inkonsistenz im Code nach sich ziehenNeue Leute brauchen klar lesbaren Code, der ihre eigenes Vokabular verwendetNeue Leute müssen die Philosophie des alten Codes verstehen bzw. ablesen können

Lösung: Trennen Sie Subsysteme nach den Skillsder 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 LawProblem

Organisation finden, deren Kommunikations-wege die Architektur des Produktes unterstützen

KontextReiferes SoftwareprojektEntwicklerteamArchitekturteamReife, mitwachsendeArchitektur

KräfteSoftwarestruktur ändert sich innerhalb der ProjektlaufzeitAlte Teamstrukturen existieren weiterMismatch 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 TeamsPassen Sie deshalb bei sich ändernder Produktarchitektur die Struktur Ihrer Projektorganisation an!Das wird Reibungsverluste minimieren!


Pattern: OrganisationUndOrtProblem

Kommunikationswege finden oder anpassen, wenn Teile des Projektes an verschiedenen Orten arbeiten

KontextSoftwareprojekt mit verteilten Teams

KräfteKommunikation über Ortsgrenzen hinweg ist schwieriger als direkte KommunikationTrotzdem notwendig, da gemeinsames Produkt zu erstellenOverhead minimieren

Lösung: Passen Sie architektonische und geographische Grenzen aneinander an!


Produkt und Geographie (1)Es hat keinen Sinn, zusammenhängendeTeile 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 selbenTeilprodukt P arbeiten, dann…

spalten Sie P in P1 und P2, schaffen dazwischen eine Schnittstelle und lassen P1 durch T1 und P2 durch T2 entwickeln oderlassen Sie ein Team umziehen, so dass es am selben Ort wie das andere Team sitzt!

Nach Jim Coplien: "OrganizationFollowsLocation"


Sonstige Organisationsstil-Patterns

WenigeRollenSindMehrProduzentenRollenSindWichtigerTeileUndHerrscheSchaffeKommunikationsPlätzeVerschiebeVerantwortungetc.

Part 3:Menschen und Code

Ein interessanter Zusammenhang…


Pattern: ArchitektImplementiertProblem

Dem Architekten Realitätsbezug und Autorität verschaffen

KontextSoftwareprojektArchitekten und Entwickler als explizite Rollen ausgeprägt

KräfteEntwickler treffen Einzelentscheidungen pro SubsystemAnerkannte, übergeordnete, strategische, technische Sicht und Leitung erforderlichMöglicher Konflikt

Lösung: Lassen Sie den Architektenteilweise 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 Kleinenimplementieren, testen, kommunizierenwerden 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 jedochnicht auf den kritischen Pfad! ☺


Pattern: CodeBesitzProblem

Integrität bereits geschriebenen Codes bewahren

KontextSoftwareprojektStark disjunktesWissen im Entwicklerteam

KräfteGedanken 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 AnwendungFeatures benutzen jedoch dieselben ArchitekturkomponentenDaher 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)

KontraindikationEntwickler 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 "CollectiveOwnership": 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 permanentFeature-Verantwortung bezieht sich auf eine Funktion der Anwendung und ist temporär!(so lange, bis das Feature realisiert ist)


Sonstige Code-PatternsArchitektSteuertProduktSchließeSieAlleEinRauchgefüllterRaumVarianzHinterSchnittstellePrivatesVersionierenLoseSchnittstellenetc…


Zusammenfassung

Patterns sind kondensiertes ErfahrungswissenPatterns haben einen Kontext, in dem sie angewendet werden sollenPatterns bieten eine anerkannte Lösung für eine häufig auftretende AufgabenstellungPatterns 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 StarkeAnmelden?Email an: [email protected]

Buch „Organizational Patterns of Agile Software Development“Autor: James CoplienISBN: 0-13-146740-9


Ende des Vortrags

Danke für Ihre Aufmerksamkeit!

FRAGEN ?

Matthias Bohlen [email protected]

Tel. 0170 / 772 8545

mailto:[email protected]

Leadership & Management

Patterns effektiv einsetzen