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:
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
Joe:
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
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“
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:
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