Workshop Softwarearchitektur

2012-01-18, München / Senacor

Froh: Rollenspiel Softwarearchitektur - Teil 2

0. Zusammenfassung Teil 1

• „Spiel-Requirement“ Web-Platform für Entwickler-Profile
• Aufgabe der Mitspieler, als Architekten die Anforderungen vom Kunden (Froh) einzusammeln,
• insbesonder: Wie macht man das mit dem „Anforderungen einsammeln“

Prototyping tool: justproto.com

• Florian:
  • Vorteil gegenüber balsamiq: Bessere Kollaboration
  • Nachteil gegenüber balsamiq: „Zu viel UI“, zu lebensecht - weniger reduziert

0.1 Story von Froh zum Thema Prototyping

• Anwendungs-Prototyp zur UI-Bedienung in PPT
• Auch damit sieht man sehr schön, ob ein UI-Konzept „schön“/„bedienbar“ ist oder nicht
• (Maus-Wege, finden die Anwender die offensichtlichen Funktionen, …)

Florian:

• Hi-Fi-Prototyp mit UI-Mocks auf Papier, zum Einlegen in ein iPhone-Dummy aus Fimo

Erfahrung von Froh: Prototyp sehr früh machen; daraus entwickeln sich die Grund-(Bedien-)Konzepte Spätere Erweiterungen / später umgesetzte Features brauchen keinen so detaillierten Prototypen; da die Grundkonzepte bereits feststehen Der Prototyp ist greifbar, so daß alle Beteiligten (Entwickler + PO + …) den Entwurf verstehen

Requirements-Erfassung geht in Zyklen

• Anforderung einsammeln → Prototyp → mit Prototyp Anforderung diskutieren → Prototyp anpassen → …

Joe:

• Wie handhabt man in so einen Fall (Zyklen) den Kunden? D.h. welcher Zyklus ist der erste, der Geld kostet? Wie schätzen, anbieten?

Martin Bokämper:

• Diskussionsgrundlage bei „Kunde will etwas, von dem er nicht weiß was“:
  • Werkvertrag ablehnen mit „Teurer weil Risiko + Teurer weil höhere Margen“
  • ⇒ Dienstvertrag mit Zeitkontingenten, dazu Zusicherungen mit benannten Konditionen („unter der Voraussetzung, daß die XY-DB lesbar/schreibbar/… ist“)
• ⇒ Kunde hat eine Ausstiegsmöglichkeit - nächsten Block nicht bestellen
• ⇒ Lieferant hat eine Ausstiegsmöglichkeit - Kondition als nicht erfüllt deklarieren

1. Froh kommt mit formulierten Requirements / Management / Marketing / IT / …; wir sind die Architekten

• Requirements [aus dem 'Req'-Link] durchgehen
• 3-5 „Architekten“ mit der Planung betraut
• Offen: Platform, Architektur

Hakan: Alleinstellungsmerkmal aus Business Case, ⇒ Projekt „reell“

Joe/Froh: Budget ist „reichlich“, muß jedoch realistisch argumentiert werden

Martin: Lange Zeit, viele TODOs ⇒ viele Zyklen, was macht man gleich, was macht man später

• Zuerst nur eigen hosten, nicht für Fremdinstallation - das erst spät
• UI-Prototyp früh (3-6 Monate)
• ⇒ Roadmap für 2 Jahre

Roadmap-Beispiel:

• [1 Milestone pro Quartal]
• Deployment koordiniert an Kunden und eigene Server
• Zulieferer für eine Kundenkomponente liefert nicht pünktlich
• ⇒ Grundsätzliche Architekturänderung, die diese Kundenkomponente beseitigt…
• ⇒ Alle folgenden Punkte der Roadmap UND bereits umgesetzte Anteile müssen neu koordiniert werden

Hakan: Welche Sorte Personal steht zur Verfügung,

• Politik „in-house“ / „outsourced“? Beispielsituation: In-House, plus eigene Low-Cost-Abteilung beschäftigen
• ⇒ (Froh) Conway's Law: Architekturstruktur bildet Kommunikationsstruktur ab

2. Situation: Nach einigen Wochen: „Wie schaut's aus“

• Hakan: High-Level Überblick/Plan/Roadmap
• (Martin, aus Entwicklersicht):
  • - Architektur-Gerippe:
    • - ** Viele Instanzen: Multi-VM vs. Multi-DB vs. Mandantenschlüssel?: → Multi-VM
    • - Sprache: Java, Python, Rails
    • - OS: Linux, Windows
  • - Unabdingbare technische Umgebung, Projektsetup:
    • - VCS
    • - Tracker
    • - CI → Test, Demo
  • - Produktive Prototypen haben und „nah halten“ (näher als eigene Operations, eigenes Hosting)
  • - Anfang QA:
    • - Manuelle Tests
    • - Automatisierte Tests
  • - UI (weil das früh jemand haben wird)
  • - SmartPhone-App
  • - QA: Performance-Tests
  • - …
  • - Installierbare Version für Fremdhoster

3. Detailentscheidung „Wie die Instanzen verteilen“ (**)

• Martin: 2 Core-Techniker diskutieren am Whiteboard; einigen sich auf ein Ergebnis
• Dabei produzieren sie eine Wiki-Page: Kritische Argumente, Alternativen
• Froh: Doku sogar extrem kurz in tabellarischer Form
• Sprache: 0. Präferenz der Core-Techs, 1. verfügbare Entwickler, 2. verfügbare Toolkits (Python, Rails)
• Betriebssystem: Hier wg. Kosten und VM-Instanzen: Win-Lizenz pro PSP-Instanz nicht wirtschaftlich

Martin / Froh: Testverfahren

• Winzige Feature-Spec
• Entwickler setzt Feature um, stellt Feature auf „Ready for Test“
• ⇒ Tests gegen diese Features werden (entworfen und) durchgeführt
• Feature-Tests auf dedizierten Beta-Builds

Ggf. auch Listen mit „known bad“, was nicht zu testen ist

Erfahrungen von Florian:

• Tests zeitnah an der Entwicklung machen
• Durch bewußtes Pairing läßt sich innerhalb von 6 Monaten ein balanciertes Team schaffen

von Froh:

• Entwickler testen erstmal selbst
• System ist noch so volatil, daß immer wieder kein lauffähiges System vorliegt
• 6-9 Entwickler, SCRUM ⇒ 1 Tag Stabilisierung
• ⇒ zu kurz, Testplan bereits 1 Woche vor Sprint-Ende festlegen
• Hohes Testaufkommen, manueller Systemtest ähnlicher Aufwand wie ein Sprint

Florian / Froh: Tests machen Spaß mit kleinen (= schnell entwickelten/testbaren) Funktionseinheiten Begrenzung des größtmöglichen einzelnen Tasks auf 25% der Produktivität des Sprints (reduziert von 50%)

SCRUM: Positionen mit unbekanntem Aufwand: Froh / Florian unabhängig voneinander: „Evaluation Story“ / „Konzept-Ticket“

Wichtiges Fazit: Kommunikation zwischen Entwickler und Test treibt das vorhandensein eines Prozesses, um diese Kommunikation zu strukturieren

Froh: Es kristallisiert sich ein stark strukturiertes Testschema heraus - Während der Entwicklung Unit-Tests - Manuelle Feature- und Systemtest am Ende von Sprints

Martin: Automatisierter Gesamt-System-Test wichtig / hilfreich Backend wird an seiner UI-Schnittstelle sehr umfassend getestet Durchaus erheblicher Aufwand, sehr hilfreicher Effekt Simulator externer Systeme vorhanden/nötig ⇒ finden von Seiteneffekten, Abhängigkeiten, …

Testbeispiel: Neustart der DB im laufenden Betrieb

Froh: ARC42

Seit 2009 neue Erfahrung: Ein Prozess (hier: SCRUM) kann nützlich/hilfreich/unterstützend sein Cross-Functional Teams; bewußt „unbequeme“ Tasks + 'Mentor' Flo: Idee: „Schlechterer“ Entwickler soll Code vom „besseren“ reviewen