Dies ist eine alte Version des Dokuments!
Workshop Softwarearchitektur
2012-01-18, München / Senacor
Froh: Rollenspiel Softwarearchitektur - Teil 2
0. Zusammenfassung Teil 1
Prototyping tool: justproto.com
0.1 Story von Froh zum Thema Prototyping
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:
1. Froh kommt mit formulierten Requirements / Management / Marketing / IT / …; wir sind die Architekten
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:
Hakan: Welche Sorte Personal steht zur Verfügung,
2. Situation: Nach einigen Wochen: „Wie schaut's aus“
3. Detailentscheidung „Wie die Instanzen verteilen“ (**)
Martin / Froh: Testverfahren
Ggf. auch Listen mit „known bad“, was nicht zu testen ist
Erfahrungen von Florian:
von Froh:
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