Patterns effektiv einsetzen

313 Aufrufe

Veröffentlicht am

Jim Coplien hat mit seinen “Organizational Patterns” Erfolgsmuster für das Leben im Projektalltag festgehalten. Der Vortrag stellt Muster für wichtige Aufgabenbereiche im Projekt vor: Projektmanagement, Aufbau einer Projektorganisation, Konfigurationsmanagement, Teamkommunikation. Lernen Sie aus dem kondensierten Wissen, das in diesen Patterns steckt und verwenden Sie es in Ihrem eigenen Projekt.

Veröffentlicht in: Leadership & Management
0 Kommentare
0 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

Keine Downloads
Aufrufe
Aufrufe insgesamt
313
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
3
Aktionen
Geteilt
0
Downloads
1
Kommentare
0
Gefällt mir
0
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

Patterns effektiv einsetzen

  1. 1. Patterns effektiv einsetzen Anatomie erfolgreicher Projekte Vortrag auf der OOP 2007 Matthias Bohlen <mbohlen@mbohlen.de> Unabhängiger Software-Architekt und Berater
  2. 2. 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
  3. 3. 25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 3 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
  4. 4. 25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 4 Referenzen
  5. 5. 25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 5 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
  6. 6. Die Expedition Aufbruch ins Projekt – sind Sie richtig ausgerüstet?
  7. 7. 25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 7 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!
  8. 8. 25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 8 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!
  9. 9. 25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 9 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!
  10. 10. 25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 10 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
  11. 11. 25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 11 Was gibt es für Patterns? Software Design (GoF) Organisations-Patterns Branchen-Patterns (Telekom, etc.) Pädagogik-Patterns und viele andere…
  12. 12. 25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 12 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! ☺
  13. 13. 25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 13 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?
  14. 14. 25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 14 Elemente eines Patterns Problem Kontext / Umstände Kräfte (in der Ausgangssituation) Lösung Anwendungsbeispiel Konsequenzen und neuer Kontext
  15. 15. 25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 15 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?
  16. 16. 25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 16 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.
  17. 17. Na, ist ja ganz nett! Aber was hat das mit einem Software-Projekt zu tun?
  18. 18. 25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 18 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
  19. 19. 25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 19 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!
  20. 20. 25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 20 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…
  21. 21. Part 1: Projektmanagement Erfolgreiche Projekte managen sich auf ganz bestimmte Weise…
  22. 22. 25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 22 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
  23. 23. 25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 23 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!
  24. 24. 25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 24 Projektdefinition: Kräfte (3) 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
  25. 25. 25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 25 Projektdefinition: Kräfte (4) 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
  26. 26. 25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 26 Projektdefinition: Kräfte (5) 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
  27. 27. 25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 27 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"
  28. 28. 25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 28 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!
  29. 29. 25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 29 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
  30. 30. 25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 30 Pattern: TeamWachsenLassen Problem Ermitteln der richtigen Teamgröße Kontexte Softwareprojekt, das gerade startet Softwareprojekt, das 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"
  31. 31. 25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 31 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.
  32. 32. 25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 32 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!
  33. 33. 25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 33 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
  34. 34. 25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 34 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!
  35. 35. 25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 35 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
  36. 36. 25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 36 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?
  37. 37. 25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 37 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"
  38. 38. 25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 38 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!
  39. 39. 25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 39 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?
  40. 40. 25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 40 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
  41. 41. 25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 41 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
  42. 42. 25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 42 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
  43. 43. 25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 43 Sonstige Projektmanagement-Patterns AufgabeAufteilen bei Termin-Engpass eine Aufgabe in einen dringenden und einen weniger dringenden Teil aufteilen dringenden Teil vor dem Termin, den Rest danach erledigen
  44. 44. 25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 44 Sonstige Projektmanagement-Patterns 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
  45. 45. Part 2: Organisationsstile, organisches Wachstum Angepasste Organisationen funktionieren besser…
  46. 46. 25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 46 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.
  47. 47. 25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 47 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.)
  48. 48. 25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 48 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!
  49. 49. 25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 49 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!
  50. 50. 25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 50 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!
  51. 51. 25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 51 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!
  52. 52. 25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 52 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"
  53. 53. 25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 53 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"
  54. 54. 25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 54 Sonstige Organisationsstil-Patterns WenigeRollenSindMehr ProduzentenRollenSindWichtiger TeileUndHerrsche SchaffeKommunikationsPlätze VerschiebeVerantwortung etc.
  55. 55. Part 3: Menschen und Code Ein interessanter Zusammenhang…
  56. 56. 25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 56 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!
  57. 57. 25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 57 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"
  58. 58. 25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 58 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! ☺
  59. 59. 25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 59 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.
  60. 60. 25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 60 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"
  61. 61. 25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 61 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!
  62. 62. 25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 62 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!
  63. 63. 25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 63 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)
  64. 64. 25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 64 Sonstige Code-Patterns ArchitektSteuertProdukt SchließeSieAlleEin RauchgefüllterRaum VarianzHinterSchnittstelle PrivatesVersionieren LoseSchnittstellen etc…
  65. 65. 25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 65 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
  66. 66. 25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 66 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
  67. 67. 25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 67 Ende des Vortrags Danke für Ihre Aufmerksamkeit! FRAGEN ? Matthias Bohlen mbohlen@mbohlen.de Tel. 0170 / 772 8545

×