Workshop Softwarearchitektur 22.06.2011

Organisation

  • Treffen VI/2011: 12. Oktober 2011
  • Treffen V: NBG 31. Aug (wenn Michael wieder die Räume kriegt)
  • Treffen VI: offen
  • Thema: V (31. Aug) Florian High Performance (ca. 1h)
  • Guidelines: Wir wollen die Vorträge dokumentieren, Außenwirkung, Member-Bereich für confidential stuff.
  • Sinn auch: DRY, beim Nachbereiten lernt man auch noch mal selbst.

Inversion of Control

  • Spring im „Kleinen“, eher implizit nutzbar
  • OSGi im „Großen“, eher explizit nutzbar
  • Dependency Management im „modernen“ Sinne analog zu Shared Libraries in einer Distribution
  • Siehe Blog von flameeyes
  • „Konfiguration“ des IOC-Containers ⇔ Site-„Konfiguration“ von Komponentenparametern NICHT MISCHEN!
  • „85%-Frameworks“ - hier kann es sinnvoll sein, daß der Kunde Komponenten aus Eigenleistung in das Framework/Produkt einhängt.
  • Damit das funktioniert/„gut ist“, muß die Dokumentation dieser Schnittstelle WESENTLICH besser als typische Konfigurationsdokumentation sein.

Workshop

  • Rollenspiel: Froh „bestellt“ eine Web-Anwendung zum Profil-Management (analog GULP) bei einem Entwicklungsteam (restliche Teilnehmer)
  • 37 Signals (Basecamp): „selbstgewähltes“ Entwicklungsteam
  • Exkurs: „Gewaltfreie Kommunikation“ (Rosenberg?)
  • spezifisches Requirement A) „Jahre Erfahrung pro Fachgebiet im Profil erfassen“
  • Budget „vorhanden“ (Aufhänger: Planungsteam 4 Personen)
  • Wer macht was
    • Rollenverteilung beim Kunden ermitteln
    • Kommunikation zwischen Tech und non-Tech bei Requirements/im Projektverlauf aufrechterhalten
  • Klären: Produkt oder Projekt?
    • Nachsatz: „Wenn das Projekt fertig ist können wir es ja als Produkt verkaufen“ vermeiden
  • Unterschiedliche Vorstellungen innerhalb des Kunden klären
    • Assoziationen zunächst jeder für sich entwickeln, dann in der Runde konsolidieren (Hilfsmittel: Jeder schreibt seine auf)
    • wenn möglich unabhängig von der Organisationsstruktur
  • Ideen, die beim Kunden rumgeistern, zusammen mit Prioritäten/Gewichten erfassen/erzählen lassen
    • Zusammenhänge zwischen den Ideen verstehen
    • Ideen außerhalb der Umsetzungsdomäne identifizieren und „ablehnen“
      • Ideen sind: Rollen, Daten (DB-Felder), Funktionalitäten
    • ungeklärte Probleme dürfen *explizit* offen bleiben
  • „Zeichenphase“: Lösungsansätze/Prototypen entwickeln, vom Kunden beurteilen lassen
    • z.B. aus dem Blickwinkel unterschiedlicher Rollen
  • Zyklisch ab „Unterschiedliche Vorstellungen“ bzw. „Wer macht was“, bis der Prototyp genau genug als Implementierungsvorlage ist. Prototyp bekommt die Rolle eines Lastenhefts.
  • Flo: Tool „Balsamiq Mockups“ ⇒ Bleistiftoptik, analog Idee von Joel Spolsky: Unfertige Funktionen im UI „handschreiben“
  • Martin: „Vorteil“ von Komitee-Entscheidungen: Man hat genug Zeit das Zeug fertig zu machen, während der Entscheidungsprozess langwierig läuft
  • Funkionierendes Beispiel: „Dünner“ Prozess, in Templates nur das nötigste Ausfüllen
  • Froh: Confluence + ARC42-Template; Martin: Trac, Pläne durch Confluence zu ersetzen
  • Abstimmungs-Meetings: Wechselnde, kleine Gruppen zusammenstellen
  • Modell von Flo Dünkel ist eine Implementierung von Flo Sessers Konzept: Verschiedene Entwickler grob am Telefon z.B. 2 Tage vorher auf ein Thema „anspitzen“, dann in Gesprächsrunde konsolidieren
  • Froh: „Ich habe mir als Einzelgänger einen Job im stillen Kämmerchen ausgesucht und stelle nun im Leben fest, daß der Schwerpunkt auf Kommunizieren und Abstimmen liegt.“
  • Conway's Law: Die Systemarchitektur wird ein Abbild der Kommunikationsstruktur im Team.
  • Martin: Gibt es Strategien, mit angeordneter Kommunikationstrennung effizient/effektiv umzugehen?
    • → praktisch nur „Nebenkanäle“, Social Engineering
  • Plan für den nächsten Schritt: Architektur/Umsetzungsplan fur die oben erfassten Ideen/Prototypen
  • Interesse von Flo: Wie kommt man aus den Requirements zu einer Roadmap
  • Froh: „Growth Paper“; als „Gate“ des Konzernprozesses
  • Michi: Bei feststehendem Endtermin pragmatisch
    1. Klickdummy
    2. in schnellen Iterationen Features (nach Abhängigkeiten)
  • Froh: Vereinbarte Iterationen helfen, disjunkte Teams zu synchronisieren
  • WIE schreibt man die Ergebnisse der obigen Erfassung auf!?
  • ZIELGRUPPE/Zielperson der Dokumentation explizit aufzeigen!
  • Ein Dokument kann auch für viele Konsumenten vorgesehen sein - Beispiel FuncSpec (Martin)
  • Flo: Trac-Schema mit „Drill-Down“-Funktionalität (aus technischem Blickwinkel)
    • Obere Layer dienen auch als Input für Übersetzer/graphische Designer/usw.