Upload
others
View
1
Download
0
Embed Size (px)
Citation preview
Stefan Toth
Befehl von unten: Softwarearchitektur für dynamische Projekte
[…] „Ob man diese Entwickler schließlich Architekten nennt oder nicht, bleibt dem Projekt überlassen und sollte für die tatsächliche Arbeit wenig Auswirkungen haben.“
[…]
„Generell ist die Diskussion um einen Architekten als Rolle aber überbewertet“
Ich, Objektspektrum, 2009
Berater und Trainer bei oose in Hamburg
seit 06/2008
Artikel
Vorträge
Dies und das
u.a. in Java Magazin, ObjektSpektrum, BT-Magazin, dotnetpro, iX, HMD u.a. auf Jax, W-Jax, Seacon, OOP, SET@Jazoon, Eclipse.jar iSAQB Board Mitglied TOGAF 9 Certified (Level 2/2) AOGEA Mitglied
st_toth
Stefan Toth
Agenda
Die klassische Architektenrolle Anforderungen an die Person
Problemverschärfung Entwicklungen und Trends, die es schwerer machen
Konkrete Modelle Alternativen zum klassischen Architekten
Ausblick Rollenwahl, Praktiken und Zusammenfassung
definiert werden…
• Eigenschaften von Architekten
• Wissen das Architekten brauchen
• Aufgaben die Architekten wahrnehmen
Softwarearchitekten definiert
Eigenschaften und Wissen
und dann kommen die Aufgaben…
Architekturinformationen und Kontext bei einem Architekten gekapselt andere Entwickler agieren mit Scheuklappen
Es gibt jemanden der explizit für Architekturfragen verantwortlich ist Entwickler können annehmen es ist nicht ihr Problem
Alles was Entwickler machen kann die Architektur beeinflussen Entwickler haben die Macht alles kaputt zu machen
→
→
→
Nicht nur ein praktisches Problem…
Beschränkte Information (Kontext)
Kein Gewissen (jemand Anderes‘ Problem)
Macht alles kaputt zu machen
Immer eine schlechte Kombination…
Agenda
Die klassische Architektenrolle Anforderungen an die Person
Problemverschärfung Entwicklungen und Trends, die es schwerer machen
Konkrete Modelle Alternativen zum klassischen Architekten
Ausblick Rollenwahl, Praktiken und Zusammenfassung
Aufgabenvermischung
Analyst (RE)
Architekt Designer
Entwickler Build Engineer
Betrieb
Problem Lösung
Anforderungen: Stories/Tasks Build: Continuous Integration
Betrieb: Continuous Delivery, DevOps Architektur: ?
Mehrere: • Programmiersprachen • Persistenztechnologien • Plattformen • unterstützte Geräte • UI-Ansätze • …
Polyglotte Programmierung
Breites Technologie-Know-How…
VersionOne „State of Agile 2013“: 4048 Befragte IT-Mitarbeiter weltweit
Dynamik & Agilität
3% wollen agile Methoden künftig
NICHT einsetzen
oose „Projektmanagementstudie“: 2009 – 240 Projekte in Deutschland
Was ändert sich dadurch?
Nach eigener
Einschätzung agil
Eigenschaften: • Teams < 12 • Iterationen • >1x lauffähig • Kundenkontakt
• Erwartungen bezüglich Flexibilität • Weniger starre Projektaufstellung
evtl. Verteilung
• Höhere Transparenz • Verantwortungsstreuung
Was von „agil“ ankommt
neue Interpretation klassicher Rollenbilder… Entwickler bekommen mehr Möglichkeiten… (eigentlich cool)
Agenda
Die klassische Architektenrolle Anforderungen an die Person
Problemverschärfung Entwicklungen und Trends, die es schwerer machen
Konkrete Modelle Alternativen zum klassischen Architekten
Ausblick Rollenwahl, Praktiken und Zusammenfassung
Verteilung von
Aufgaben, (Wissen und Fähigkeiten)
Die Alternativen
Projektbeispiel 1
Größe: 26 Entwickler Teams: 3 Thema: Datenanalyse und -auswertung Art: Produktentwicklung Vorgehen: Scrum, 2-Wochen-Iterationen
Architekten-Ansatz: unterstützender Architekt (Architecture Owner) 2 „Architekten“ wechseln alle 2 Monate das Team (Springer)
Architecture Owner
Architekturentscheidungen
Werden gemeinsam getroffen:
1. Problem/Potential wird erkannt und zu AO getragen
2. Entscheidung wird vorbereitet (AO unterstützt) 3. Im Daily Scrum: Entscheidungsbedarf anmelden 4. Interessierte kommen zusammen: Vorstellung von Problem, vorgeschlagene Lösung und Alternativen. Abstimmung (Veto-Abfrage) 5. Umsetzung (AO unterstützt) 6. Jede zweite Iteration: Workshop mit Reflexion
Projektbeispiel 2
Größe: 52 Entwickler Teams: 6 Thema: Logistikanwendung Art: Projekt, Laufzeit ca. 3 Jahre Vorgehen: Iterativ, 6-Wochen-Iterationen
Architekten-Ansatz: Architekturagenten 9 Architekten mit unterschiedlichen Aufgabengebieten
Einzelne Verwantwortlichkeiten für
Architektur werden verteilt Etwa nach Schichten: UI-, Service-,
Backend-, Integrations-Architekten
Oder nach qualitativen Aspekten: Sicherheits-, Performance-, Skalierbarkeits-, Wartbarkeits-Marshalls
Architekturagenten
Architekturentscheidungen
Werden von Agenten getroffen: Teammitglieder haben ihre Rollenbezeichnungen behalten, können aber alle programmieren
Es gibt 9 „Architekten“ (Tiger-Team) mit Aufgabengebieten:
Die Agenten haben ein Auge auf „ihren“ Themenbereich
Übergreifende Jour-Fixes jede Woche (2 Stunden)
• Backend & Archivierung • Desktop-UI • Mobile
• Sicherheit • 4 Geschäftskomponenten
Projektbeispiel 3
Größe: 25 Entwickler Teams: 2-4 Teams Thema: Online-Community Art: Projekte, Laufzeiten 1-2 Jahre Vorgehen: Scrum,
Architekten-Ansatz: kein benannter Architekt Teams werden aus Entwicklerpool zusammengestellt
Teams können Anforderungen umsetzen und ausliefern (Analyse, Design, Entwicklung, Test, Deployment, …)
Es kann nicht jedes Teammitglied alles
Alle Teammitglieder entwickeln (es gibt keine „falschen“ Entwickler)
Zusätzliche Spezialfähigkeiten sind wünschenswert
Kein benannter Architekt
Architekturentscheidungen
Werden gemeinsam getroffen:
1. Architektonische Fragestellungen werden transparent gemacht: Qualitätsszenarien und technische Schulden 2. Priorisierung (Dringlichkeit) 3. „Pull“ durch Entwickler 4. Bewertungsworkshops jeden Freitag (60 Minuten)
Bei Problemen: Ad-hoc Workshops und interne Hackathons
Vermeidung des „Not-Invented-Here-Syndrom“
Breiteres Kontextwissen, garantierter Praxisbezug
Nutzung der Fähigkeiten / Übersicht der Gruppe
Vermeidung vom „Flaschenhals Architekt“
Unklare Zuständigkeiten
Hoher Kommunikationsdruck (Konsitenz und Integrität)
Kein benannter Architekt +/-
Agenda
Die klassische Architektenrolle Anforderungen an die Person
Problemverschärfung Entwicklungen und Trends, die es schwerer machen
Konkrete Modelle Alternativen zum klassischen Architekten
Ausblick Rollenwahl, Praktiken und Zusammenfassung
Die „richtige“ Rollenwahl
Informativer Arbeitsplatz Gemeinsame Entscheidung Wiederholte Reflexion Architekturcommunities
Architekturarbeit im Backlog Architekturprinzipien Ad-hoc Architekturtreffen Qualitative, automatisierte Tests
Konkrete Praktiken für Zusammenarbeit und Fokussierung
Kombinierbare Praktiken in Zeiten von Agile und Lean Autor: Stefan Toth Umfang: 240 Seiten Verlag: Carl Hanser Verlag Sprache: Deutsch ISBN-10: 3446436154 Datum: erscheint am 07. November 2013
Vorgehensmuster für Softwarearchitektur…
swamuster.de
28
29 Praktiken…
swamuster.de
Wir können (und sollten) uns nicht auf klassische Architekten verlassen
Es braucht Wege rasch zu reagieren und zu entscheiden
Softwarearchitektur wird zum Basisskill für Entwickler
Architekturpraktiken ersetzen die Rolle des
klassischen Architekten
Die Wahl des konkreten Rollenmodells hängt vom Projekt ab (Architektenfaktoren)
26
tl;dr
st_toth