01.07.2014
1
Orientation in Objects GmbH
Weinheimer Str. 6868309 Mannheim
Kontinuierliche Architektur im Rahmen grosser Agiler Projekte
1.0
Kontinuierliche Architektur im Rahmen großer Projek te© 2014 Orientation in Objects GmbH
Java, XML und Open Source seit 1998
) Competence Center)) Object Rangers )
• Schulungen , Coaching , Weiterbildungsberatung , Train & Solve-Programme
• Methoden , Standards und Tools für die Entwicklung von offenen, unternehmens-weiten Systemen
• Unterstützung laufenderJava Projekte
• Perfect Match• Rent-a-team• Coaching on the project• Inhouse Outsourcing
• Schlüsselfertige Realisierungvon Java Software
• Individualsoftware• Pilot- und Migrationsprojekte• Sanierung von Software• Software Wartung
) Software Factory )
2
01.07.2014
2
Kontinuierliche Architektur im Rahmen großer Projek te© 2014 Orientation in Objects GmbH
Ihr Sprecher
3
Dirk M. Sohn
Trainer, Berater, Entwickler
SchwerpunkteSoftwareentwicklungsprozesse
Agile SoftwareentwicklungProjektmanagement
Kontinuierliche Architektur im Rahmen großer Projek te© 2014 Orientation in Objects GmbH
Ihr Sprecher
4
Falk Sippach
Trainer, Berater, Entwickler
SchwerpunkteArchitektur
Agile SoftwareentwicklungCodequalität
01.07.2014
3
Kontinuierliche Architektur im Rahmen großer Projek te© 2014 Orientation in Objects GmbH
Gliederung
• Warum sind wir hier?
• Was ist das Big Picture von SAFe
• Wie geht es dem Architekten und der Architektur in SAFe
• Wie bin ich AGIL wenn ich ein Architekt bin?
• Was nehmen wir mit?
5
Kontinuierliche Architektur im Rahmen großer Projek te© 2014 Orientation in Objects GmbH
Gliederung
• Warum sind wir hier?
• Was ist das Big Picture von SAFe
• Wie geht es dem Architekten und der Architektur in SAFe
• Wie bin ich AGIL wenn ich ein Architekt bin?
• Was nehmen wir mit?
6
01.07.2014
4
Kontinuierliche Architektur im Rahmen großer Projek te© 2014 Orientation in Objects GmbH
Warum sind wir nicht hier?
• Nicht den Unterschied zwischen Projekt und Produktion diskutieren
– Eher Flow als Einmal-Projekt. Heißt Programm
• Keine Erfahrungsberichte geben, nur Orientierungshilfe
• Keine Definition von „Architektur“ leisten
• Keine lange Vorgeschichte erzählen
7
Kontinuierliche Architektur im Rahmen großer Projek te© 2014 Orientation in Objects GmbH
Warum sind wir hier?
Kontinuierliche Architektur im Rahmen großer Agiler Projekte
• Wie kann man bei großen Agilen Projekten in etwa vorgehen?– SAFe (Scaled Agile Framework)
8
„(Wie) bin ich Agil, wenn ich ein Architekt bin?“
„Wo wird eine solche beim reinen Scrum überflüssige Thematik (Architektur) notwendig?“
„ Welche Verantwortung trägt Architektur im Bilde des SAFe? “
„Welche Charaktere sind hierfür gefragt?“
01.07.2014
5
Kontinuierliche Architektur im Rahmen großer Projek te© 2014 Orientation in Objects GmbH
Agile Impulse ohne Architekten IScrum (1995)
• Gibt es einen übersichtlichen Arbeitsprozess für Softwareentwicklung in kleinen Teams?– Ken Schwaber: Scrum anwenden
9
Kontinuierliche Architektur im Rahmen großer Projek te© 2014 Orientation in Objects GmbH
Agile Impulse ohne Architekten IIExtreme Programming (1996)
• Was muss man als Entwickler aufschreiben um Kunden zu erklären, wie Softwareentwicklung mit maximaler Kundenzufriedenheit in kleinen Teams funktioniert?– Kent Beck: Extreme Programming machen
10
01.07.2014
6
Kontinuierliche Architektur im Rahmen großer Projek te© 2014 Orientation in Objects GmbH
Agile Impulse ohne Architekten IIIAgiles Manifest (2001)
• Worauf kommt es aus Sicht von uns 17 Experten bei Softwareentwicklung wirklich an?
Manifesto for Agile Software Development(Beck, Fowler, Cockburn, uvm,. 2001)
– Einzelpersonen und Interaktionen wichtiger alsProzesse und Werkzeuge
– Laufende Systeme wichtiger alsumfangreiche Dokumentation
– Zusammenarbeit mit dem Kunden wichtiger alsVertragsverhandlungen
– Fähigkeit auf Änderungen zu reagieren wichtiger als Verfolgen eines Plans
11
Kontinuierliche Architektur im Rahmen großer Projek te© 2014 Orientation in Objects GmbH
Agile Impulse ohne Architekten IVKANBAN (2007)
• Wie kann man auf einfache Art und Weise visualisieren und messen, wo Elemente in ihrem Ablaufe stehen und messen, wie lange sie für ihn brauchen?– Anderson: Kanban
12
01.07.2014
7
Kontinuierliche Architektur im Rahmen großer Projek te© 2014 Orientation in Objects GmbH
Methoden mit ArchitektenRational Unified Prozess (1998)
• Wie würde man iterativ inkrementell anwendungsfallgetrieben und architekturzentriert Software entwickeln?– 3 Amigos: Mit RUP
13
Kontinuierliche Architektur im Rahmen großer Projek te© 2014 Orientation in Objects GmbH
Methoden mit Architekten V-Modell XT Tailoring (2005)
• Agilität hat so viel Erfolg – kann das der Staat bei Softwareentwicklung nicht auch einsetzen?– iABG: V-Modell XT mit Agilem Durchführungsweg
Agil
01.07.2014
8
Kontinuierliche Architektur im Rahmen großer Projek te© 2014 Orientation in Objects GmbH
Definition „Übergewichtige Methoden“
• Prozessmodell: Es hat eine Tailoring Methode
• Es macht Sinn Prozess-Metamodelle zu vergleichen
15
http://ftp.uni-kl.de/pub/v-modell-xt/Release-1.1/Infomaterial/Prozessmodellintegration.pdf
VM XT AgilRollen 31 19
Produkte 107 56
Aktivitäten 101 56
„Braucht man Architekten nur bei übergewichtigen Methoden?“
Kontinuierliche Architektur im Rahmen großer Projek te© 2014 Orientation in Objects GmbH
Scaling Agility
• Wir suchen eine Orientierung beim „Skalieren von Scrum“– Wir wollen keine „übergewichten Prozesse“ top down einführen! – Wie könnten wir Scrum „nach oben“ vergrößern?
• Was machen wir, wenn 1 Scrum Team die Arbeit nicht leisten kann?– 2 Scrum Teams nehmen, 1 Product Owner reicht eventuell
• Was machen wir aber, wenn 3 Scrum Teams fast nicht reichen?– > 4 Scrum Teams nehmen ;-)– Scrum of Scrums Einführen– Mehr Product Owner einsetzen– Orthogonale Teams bilden– Ein Product Owner Board bilden– ….– Wie macht Ihr das?
16
„Das muss alles jeder selbst rausfinden?“
01.07.2014
9
Kontinuierliche Architektur im Rahmen großer Projek te© 2014 Orientation in Objects GmbH
Definition: „Skalieren“
• Annahmen für heute:• Programme: zwischen 5 und 10 „kleine Teams“ gemeins am
• Mehrere solcher Programme
• Kein End-2-End je Team möglich
• Unternehmensleitung angebunden
• Spezieller Blick• Wie funktionert das dann mit der Architektur?
17
Kontinuierliche Architektur im Rahmen großer Projek te© 2014 Orientation in Objects GmbH
Leichter wirds nicht…..
• Skalieren ist nie leicht:– http://tomdevos.be/scaling-agile-an-overview-of-frameworks/– Bspw. Disciplined Agile Delivery (Scott Ambler / IBM)
18
http://disciplinedagiledelivery.wordpress.com/
01.07.2014
10
Kontinuierliche Architektur im Rahmen großer Projek te© 2014 Orientation in Objects GmbH
Gliederung
• Warum sind wir hier?
• Was ist das Big Picture von SAFe
• Wie geht es dem Architekten und der Architektur in SAFe
• Wie bin ich AGIL wenn ich ein Architekt bin?
• Was nehmen wir mit?
19
Kontinuierliche Architektur im Rahmen großer Projek te© 2014 Orientation in Objects GmbH
Immerhin schön aufgeräumt gemalt:Scaled Agile Framework
20
All the material for SAFe isReproduced with permission of Leffingwell, LLC
01.07.2014
11
Kontinuierliche Architektur im Rahmen großer Projek te© 2014 Orientation in Objects GmbH
Team Level – Erster Blick
• 3 Level – fangen wir unten an, da kennen wir uns aus!
• Ist doch alles wie immer – hier arbeiten einige Scrum Teams mit Scrum Mastern und Product
Ownern parallel an ihren Backlogs?!
21
Kennen wir gut, Haken dran!
Ah, das ist XP,Haken dran!
Kontinuierliche Architektur im Rahmen großer Projek te© 2014 Orientation in Objects GmbH
Team Ebene
• „Scrum wie immer!“– agile ScrumTeams / 7 ± 2 Mitglieder / bauen und testen User Stories
• Mehrere Teams arbeiten parallel an der Realisierung umfassender Funktionalitäten– „Scrum of Scrums wie immer?“
• Forderungen an den „Product Owner“– Bestandteil des Teams, Co-Located– Gleichzeitig im „Team Product Management“
• Forderungen an den „Scrum Master“– Mitglied im „System Team“ für Release Planning– Verantwortet Metriken
22
Hups?War das nicht immer anders?
01.07.2014
12
Kontinuierliche Architektur im Rahmen großer Projek te© 2014 Orientation in Objects GmbH
Team Level – Zweiter Blick
• Team PSI Objectives? NFRs?
• Hier ist generell nicht alles wie immer!! Bitte alles genau lesen!
• Jetzt mal eine Ebene höher
23
Kontinuierliche Architektur im Rahmen großer Projek te© 2014 Orientation in Objects GmbH
Program Level
24
Taktschlag
Wertgegenstände
Zuständigkeiten
01.07.2014
13
Kontinuierliche Architektur im Rahmen großer Projek te© 2014 Orientation in Objects GmbH
Skalierung durch Program LevelWas kommt zu „Scrum“ und „XP“ dazu?
• Skalierung über Taktschlag:Zu Sprint / Sprint Backlog kommen zusätzlich– Potentially Shippable Increment / PSI Objectives / Agile Release Train
• Skalierung über Wertgegenstände / ArtefakteZu Backlog (= Program/Product Backlog) kommen zusätzlich– Vision/Roadmap, Features, Nonfunctional Requirements
• Skalierung über klare ZuständigkeitenZu Team, Scrum Master, Product Owner kommen zusätzlich– Product Management
• Skalierung über explizite Architekturzu „nix“ kommt zusätzlich– System Architect, Architectural Feature, Architectural Runway
25
Kontinuierliche Architektur im Rahmen großer Projek te© 2014 Orientation in Objects GmbH
Neuer Taktschlag – PSI und ART
• (Arbeitet beim Portfolio Management mit – nachher)
26
01.07.2014
14
Kontinuierliche Architektur im Rahmen großer Projek te© 2014 Orientation in Objects GmbH
Scaling AgilityFragen die SAFe beantworten kann – Antwort 1
• (1) Wie schaffen wir es, dass >5 Teams nach einem 2 Wochen Sprint gemeinsamen „Potentially Shippable Code“ produzieren?
• FAZIT: Das geht nicht, wir führen die PSIs (mehrere Sprint s werden geplant)Der starre Takt der Sprints wird fortgeführt (ART-K adenz)
27
Kontinuierliche Architektur im Rahmen großer Projek te© 2014 Orientation in Objects GmbH
Neue Zuständigkeit - Product ManagementDie Leitung der Product Owner
• Inputs sind Investment Strategy, Portfolio Backlog, ArchitecturalFeatures, Customer Value Stream Feedback, Team Inputs
• Product Management verantwortet Vision und Roadmap des Programs
• Output ist das Program Backlog und PSI objectives
28
01.07.2014
15
Kontinuierliche Architektur im Rahmen großer Projek te© 2014 Orientation in Objects GmbH
Scaling AgilityFragen die SAFe beantworten kann Antwort 2/3
• (2) Wie koordinieren sich die Product Owner?• Fazit:
In der neuen Rolle Product Management finden sich al le Product Owner bei einem Kollegen mit Gesamtverantwort ung wieder und haben Zuständigkeiten für ein team-überg reifendes „Program“
• (3) Wie kommuniziert man das Gesamtsystem?• Fazit:
Auf Program-Ebene werden Vision und Roadmap als Zieldokumente sowie NFRs und Program Backlog als Ein gaben in die Arbeitsplanung zur Verfügung gestellt.
29
Kontinuierliche Architektur im Rahmen großer Projek te© 2014 Orientation in Objects GmbH
Neue Wertgegenstände
• Vision / Roadmap schon erklärt
• Features – Hätte man auch schon EPIC genannt woanders– Müssen in ein PSI passen
• Stories (darunter) müssen in einen Sprint passen• Epics (darüber) müssen nirgends reinpassen
– Werden nicht zwingend von nur einem Team realisiert• Stories schon
– Können blau und rot sein (rote später, hier: ArchitekturFeatures sind „first class citizens“)
• Non functional Requirements (NFRs)– Alle Randbedingungen, die auf den Backlogs lasten– Standards, Zertifizierungen, Kompatibilitiäten, Dok.-anf.
Skalierbarkeit, Sicherheit, Testbarkeit, …..
30
01.07.2014
16
Kontinuierliche Architektur im Rahmen großer Projek te© 2014 Orientation in Objects GmbH
Scaling AgilityFragen die SAFe beantworten kann Antwort 4
– (4) Was macht man planerisch mit Funktionen die nicht in einen Sprint passen? Wo hält man Standards fest?
• Fazit
Features überspannen Sprints und Teams, müssen aber in genau ein PSI passen
Die NFRs werden in NFRs festgehalten
31
Kontinuierliche Architektur im Rahmen großer Projek te© 2014 Orientation in Objects GmbH
Program Level
32
Taktschlag
Wertgegenstände
Zuständigkeiten
Architektur später..
01.07.2014
17
Kontinuierliche Architektur im Rahmen großer Projek te© 2014 Orientation in Objects GmbH
Scaling AgilityEinige Fragen die SAFe beantworten kann
• (1) Wie schaffen wir es, dass >5 Teams nach jedem 2 Wochen Sprint gemeinsamen „Potentially Shippable Code“ produzieren?
• (2) Wie koordinieren sich die Product Owner?
• (3) Wie kommuniziert man das Gesamtsystem?
• (4) Was macht man mit Funktionen die nicht in einen Sprint passen? Wo hält man Standards fest?
• (5) Wie können wir die Unternehmensleitung anbinden?
• (6) Wie erhält man die technische „Fitness“ des Gesamtsystem?
• (7) Gibt es für all dies ein klares Bild an dem man sich reiben kann?
33
Kontinuierliche Architektur im Rahmen großer Projek te© 2014 Orientation in Objects GmbH
Portfolio Level
34
Zuständigkeiten
Wertgegenstände
Architektur später..
01.07.2014
18
Kontinuierliche Architektur im Rahmen großer Projek te© 2014 Orientation in Objects GmbH
Durchstich zum Geld durch Portfolio Level
• Skalierung über Taktschlag:Zu Sprint und Potentially Shippable Increment kommt– Erstmal nix mehr dazu ;-)
• Skalierung über WertgegenständeZu Backlog, Vision, Features, Stories und Nonfunctional Requirementskommen zusätzlich– Investment Themes und Epics
• Skalierung über klare ZuständigkeitenZu Team, Scrum Master, Product Owner, Product Management, kommen zusätzlich– Program Portfolio Management
• Skalierung über explizite Architekturzu System Architect, Architectural Feature, Architectural Runwaykommen zusätzlich– Enterprise Architect und Architectural Epics
35
Kontinuierliche Architektur im Rahmen großer Projek te© 2014 Orientation in Objects GmbH
Program Portfolio Management
• Muss sich um (mehrere) grosse Programm kümmern– Business Analyse / Aufdeckung von Wertschöpfung
• Value Stream Analyse – Definition der Wertschöfpungs einheit• Investment Themes bringen Mission und Budget für ART s• Dunbar‘s Number (größte Gruppe ~ 150 Mitglieder)
– Stämme, Kavallerien, Kirchen, Gore-Tex
– Portfolio Backlog Management• Aufbrechen aller Impulse in Epics (oder Subs)• Priorisierung der Epics• Zusammenarbeit mit dem übernehmenden Release Train
– Dezentralisierung wo möglich, bspw. Budgetvergabe an ARTs• Auslastungskontrolle (nicht zu viel) via WIP• KANBAN für Epics
– Kruschd• Statusreports, Finanzreports, Staffing, Infrastrukt ur,…..
36
01.07.2014
19
Kontinuierliche Architektur im Rahmen großer Projek te© 2014 Orientation in Objects GmbH
Scaling AgilityEinige Fragen die SAFe beantworten kann
• (1) Wie schaffen wir es, dass >5 Teams nach jedem 2 Wochen Sprint gemeinsamen „Potentially Shippable Code“ produzieren?
• (2) Wie koordinieren sich die Product Owner?
• (3) Wie kommuniziert man das Gesamtsystem?
• (4) Was macht man mit Funktionen die nicht in einen Sprint passen? Wo hält man Standards fest?
• (5) Wie können wir die Unternehmensleitung anbinden?
• (6) Wie erhält man die technische „Fitness“ des Gesamtsystem?
• (7) Gibt es für all dies ein klares Bild an dem man sich reiben kann?
37
Kontinuierliche Architektur im Rahmen großer Projek te© 2014 Orientation in Objects GmbH
Gliederung
• Warum sind wir hier?
• Was ist das Big Picture von SAFe
• Wie geht es dem Architekten und der Architektur in SAFe
• Wie bin ich AGIL wenn ich ein Architekt bin?
• Was nehmen wir mit?
38
01.07.2014
20
Kontinuierliche Architektur im Rahmen großer Projek te© 2014 Orientation in Objects GmbH
Agile Architekten?
• "Who needs an Architect?" (Fowler, 2003)
• Agile Methoden (Scrum, XP) kennen keinen Architekten
• das Team kümmert sich um die Architektur
• Implizite Architekturentwicklung: Design bildet sich heraus (emergent design)
• Schon gewußt? Scrum ist "murcS " rückwärts!
39
Kontinuierliche Architektur im Rahmen großer Projek te© 2014 Orientation in Objects GmbH
Braucht es wirklich keine Architekten mehr?
• Interessen aller Stakeholder vereinbaren (Kommunikation)
• Gesamtkosten (monetär und zeitlich) des Systems minimieren
• einzelne Teams, Produkte, Programme können gar nicht das Gesamtbild überschauen
• Auswirkungen unvorhersehbarer Ereignisse auf die Architektur
• Intentional Architecture : – Architektur-Entwicklung muss übergreifend gelenkt werden– Architektur-Vision/Strategie/Führung
40
"Architektur ist das Management von Komplexität und Änderbarkeit bei Erfüllung der geforderten Qualitätsmerkmale. " (Uwe Friedrichsen)
01.07.2014
21
Kontinuierliche Architektur im Rahmen großer Projek te© 2014 Orientation in Objects GmbH
Wo ist der Architekt in SAFe?
• Zur Erinnerung: – Programme mit ca. bis zu 150+ Personen– mehrere Teams von Teams (Program, Agile Release Train)
• das agile Team kümmert sich um das Design (im Kleinen )
• trotzdem explizite Architekten-Rollen notwendig (für das große Ganze)
41
„best requirements and designs emerge from self-organizing teams “ (Agiles Manifest)
Kontinuierliche Architektur im Rahmen großer Projek te© 2014 Orientation in Objects GmbH
Architektur im SAFe Big Picture
42
01.07.2014
22
Kontinuierliche Architektur im Rahmen großer Projek te© 2014 Orientation in Objects GmbH
Architektur-Rollen in SAFe
• Team Ebene
• Programm-Ebene
• Portfolio-Ebene
43
+
+
Kontinuierliche Architektur im Rahmen großer Projek te© 2014 Orientation in Objects GmbH
Enterprise Architekt
• Agiert unternehmensweit
• Ziel: ganzheitlichen High-Level Vision
• Enterprise Architekt oder CTO oder Architektur-Team
• Kommunikation (Stakeholder und System Architekten)
• Ermittlung Architectural Epics, Wartung Architekturpiste
• Empfehlungen für Entwicklung, Zulieferer, Schnittstellen, APIs, Hosting Strategien
• nimmt Ideen und Innovationen aus den agilen Teams an
44
01.07.2014
23
Kontinuierliche Architektur im Rahmen großer Projek te© 2014 Orientation in Objects GmbH
System Architekt
• Arbeitet in Programm-Ebene
• Zusammenarbeit mit Kunden, Stakeholdern, Produkt-Managern und –Ownern
• Unterstützung der agilen Teams bei der Implementierung
• Verständnis der Systemanforderungen und nicht-funktionalen Anforderungen
• Modellierung und Dokumentation
• Aufteilung der Epics in Features und Verteilung in Team-Backlogs
45
Kontinuierliche Architektur im Rahmen großer Projek te© 2014 Orientation in Objects GmbH
Abgrenzung zum klassischen Architekten
• Agilen Teams keine Design-Entscheidungen diktieren
• stattdessen Ratgeber (Mentor, Coach) und Moderator für die Teams und Product Owner
• Ziel : Design-Entscheidungen die das jetzige und zukünftige System unterstützen
46
01.07.2014
24
Kontinuierliche Architektur im Rahmen großer Projek te© 2014 Orientation in Objects GmbH
Architectural Epics
• große technische Vorhaben, Voraussetzung für weitere Entwicklung umfassender Lösungen
• zur Unterstützung der laufenden und zukünftigenUnternehmensbedürfnisse/Geschäftsinteressen
• erfordert regelmäßige Investitionsüberlegungen
• Überschneidungen:– umspannen meist mehrere Release-Zyklen (PSIs)– betreffen mehrere Produkte, Services, …– betreffen verschiedene Teams, Release Trains, Geschäftseinheiten und
sogar Außenstehende
47
Kontinuierliche Architektur im Rahmen großer Projek te© 2014 Orientation in Objects GmbH
Architectural Epic Kanban
48
01.07.2014
25
Kontinuierliche Architektur im Rahmen großer Projek te© 2014 Orientation in Objects GmbH
Umsetzung von Architektur Epics
• historisch : Architektur-Änderungen wurden in Branch ausgeführt und später in die Baseline gemerged
• agil : kontinuierliches Redesign des Systems (keine oder nur sehr kurzlebige Branches) => Inkrementelle Implementierung
• drei Strategien:
1. Bevorzugt: Große Epics, die sich inkrementell entwickeln lassen, über mehrere PSIs
2. Große Epics, die sich nicht komplett inkrementell implementieren lassen, aber in ein PSI passen
3. Epic ist sehr groß und kann nicht inkrementell und nicht in einem PSI implementiert werden
49
Kontinuierliche Architektur im Rahmen großer Projek te© 2014 Orientation in Objects GmbH
Aufteilen von Architectural Epics
1. Partition by subsystem or product.
2. System qualities incrementally.
3. Incremental functionality.
4. Build some scaffolding.
5. Major/minor effort.
6. Complex/Simple.
7. Variations in data.
8. Break out a spike.
50
01.07.2014
26
Kontinuierliche Architektur im Rahmen großer Projek te© 2014 Orientation in Objects GmbH
Program Backlog – Eingang und Priorisierung
51
Kontinuierliche Architektur im Rahmen großer Projek te© 2014 Orientation in Objects GmbH
Architectural Runway
• Runway = vorhandene technische Infrastruktur
• Release Trains verpflichten sich zur kontinuierlichen Weiterentwicklung
• Implementierung von Architektur Epics inkrementell in Haupt-Codelinie
52
01.07.2014
27
Kontinuierliche Architektur im Rahmen großer Projek te© 2014 Orientation in Objects GmbH
Architectural Feature
• technischer System Service, der Implementierung der nächsten Business Features erlaubt
• Verwaltung im Program Backlog
• System Architekt verantwortlich für Erkennung, Aufspaltung und Priorisierung (<= PSI-Grenzen)
53
Kontinuierliche Architektur im Rahmen großer Projek te© 2014 Orientation in Objects GmbH
Ausbalancieren Features and Architekturpiste (1)
54
01.07.2014
28
Kontinuierliche Architektur im Rahmen großer Projek te© 2014 Orientation in Objects GmbH
Ausbalancieren Features and Architekturpiste (2)
55
Kontinuierliche Architektur im Rahmen großer Projek te© 2014 Orientation in Objects GmbH
Quellen von Architectural Features
1. Resultat der Zerlegung von Business und Architecture Epics in Portfolio Ebene
2. Program Vision und Roadmap
3. NFRs als Resultat von Architectural Features
56
01.07.2014
29
Kontinuierliche Architektur im Rahmen großer Projek te© 2014 Orientation in Objects GmbH
Gliederung
• Warum sind wir hier?
• Was ist das Big Picture von SAFe
• Wie geht es dem Architekten und der Architektur in SAFe
• Wie bin ich AGIL wenn ich ein Architekt bin?
• Was nehmen wir mit?
57
Kontinuierliche Architektur im Rahmen großer Projek te© 2014 Orientation in Objects GmbH
Sieben Architektur-Prinzipien
1. Design emerges. Architecture is a collaboration.
2. The bigger the system, the longer the runway
3. Build the simplest architecture that can possibly work
4. When in doubt, code, or model it out
5. They build it, they test it
6. There is no monopoly on innovation
7. Implement architectural flow
58
01.07.2014
30
Kontinuierliche Architektur im Rahmen großer Projek te© 2014 Orientation in Objects GmbH
Architektur-Prinzip 1
59
Design emerges. Architecture is a collaboration.
1
Kontinuierliche Architektur im Rahmen großer Projek te© 2014 Orientation in Objects GmbH
Design emerges. Architecture is a collaboration.Problem vom Big Up-Front Design
• Hoffnung: einmal zu Beginn alle Anforderungen und Architekturziele für das zukünftige System abgedeckt
• viel Spekulation, Wirklichkeit sieht anders aus
• Änderungen der Anforderungen an der Tagesordnung
60
Design/Struktur zerbrechlich und schwer änderbar.
1"Wenn ein Projekt den Bach runter geht, dann nennt man das wohl Wasserfall."
01.07.2014
31
Kontinuierliche Architektur im Rahmen großer Projek te© 2014 Orientation in Objects GmbH
Design emerges. Architecture is a collaboration.Emergent Design
• statt Wasserfall und BUFD:
• evolutionärer Prozess des Findens und Erweiterns
• nur soviel wie nötig, um nächste Funktionalität zu implementieren
61
"best requirements and designs emerge from self-organizin gteams“ (Agiles Manifest)
1
Kontinuierliche Architektur im Rahmen großer Projek te© 2014 Orientation in Objects GmbH
Design emerges. Architecture is a collaboration.Intentional Architecture
• Emergent Design ungenügend bei der großen Komplexität von hoch skalierenden Entwicklungen
• Teams können nicht ohne weiteres Änderungen außerhalb ihres Bereichs erkennen und können nicht vollständig das gesamte System verstehen
• unvorhersehbare äußere Ereignisse/Einflüsse
• Redundanzen und Konflikte werden produziert
• gezielte, geplante Architektur-Initiativen zur Erhaltung/Verbesserung von Design, Performance und Benutzerfreundlichkeit
• teamübergreifend und team-synchronisierend
62
1
01.07.2014
32
Kontinuierliche Architektur im Rahmen großer Projek te© 2014 Orientation in Objects GmbH
Design emerges. Architecture is a collaboration.Collaboration
63
1
Kontinuierliche Architektur im Rahmen großer Projek te© 2014 Orientation in Objects GmbH
Architektur-Prinzip 2
64
The bigger the system, the longer the runway.
2
01.07.2014
33
Kontinuierliche Architektur im Rahmen großer Projek te© 2014 Orientation in Objects GmbH
The bigger the system, the longer the runway
65
2
Kontinuierliche Architektur im Rahmen großer Projek te© 2014 Orientation in Objects GmbH
Architektur-Prinzip 3
66
Build the simplest architecture that can possibly w ork.
3
01.07.2014
34
Kontinuierliche Architektur im Rahmen großer Projek te© 2014 Orientation in Objects GmbH
Build the simplest architecture that can possibly work – Zitate
67
"We welcome changing requirements even late in developeme nt. ..."(Agiles Manifest #2)
"If simplicity is good, we'll always leave the system with t he simplestdesign that supports its current functionality" (Kent Beck)
"Simplicity--the art of maximizing the amount of work not done--is essential." (Agiles Manifest #10)
"YAGNI, You Ain't Gonna Need It." (XP mantra)3
Kontinuierliche Architektur im Rahmen großer Projek te© 2014 Orientation in Objects GmbH
Build the simplest architecture that can possibly work – Empfehlungen
• Zur Beschreibung des Systems eine einfach, gewöhnliche Sprache verwenden
• Lösung so nah wie möglich an Problem-Domäne halten
• Kontinuierliches Refactoring
• Sicherstellen, dass Schnittstellen sauber ihre Absicht ausdrücken
• guten alten Design Prinzipien folgen
68
3
01.07.2014
35
Kontinuierliche Architektur im Rahmen großer Projek te© 2014 Orientation in Objects GmbH
Build the simplest architecture that can possibly work – Lösungen
• Domain Driven Design
• Design Patterns
• System Metaphor
• Vereinfachung des Designs
• Erleichterung der Kommunikation zwischen Teams
• gemeinsamer Code-Besitz (collective code ownership)
69
3
Kontinuierliche Architektur im Rahmen großer Projek te© 2014 Orientation in Objects GmbH
Architektur-Prinzip 4
70
When in doubt, code, or model it out.
4
01.07.2014
36
Kontinuierliche Architektur im Rahmen großer Projek te© 2014 Orientation in Objects GmbH
When in doubt, code, or model it outProblem
• Treffen guter Design-Entscheidungen ist eine Kunst
• selten Einigkeit zw. allen Team-Mitgliedern
• unnötiges Refactoring soll vermieden werden
71
4
Kontinuierliche Architektur im Rahmen großer Projek te© 2014 Orientation in Objects GmbH
When in doubt, code, or model it outLösung: Codieren
• einfach ausprobieren (kurze Durchstiche, Rapid Prototyping)
• durch kurze Iterationen gibt es schnelles Feedback
• transparent für Stakeholder (durch Stories und Demos)
• A/B-Tests durch Teams, Designer, Architekten oder sogar die Benutzer
72
4
01.07.2014
37
Kontinuierliche Architektur im Rahmen großer Projek te© 2014 Orientation in Objects GmbH
When in doubt, code, or model it outLösung: Modellieren
• wenn zu groß für Durchstich/Prototyp
• UML: – Domain Model– Use-case diagram– ...
73
4
Kontinuierliche Architektur im Rahmen großer Projek te© 2014 Orientation in Objects GmbH
Architektur-Prinzip 5
74
They build it, they test it.
5
01.07.2014
38
Kontinuierliche Architektur im Rahmen großer Projek te© 2014 Orientation in Objects GmbH
5
They build it, they test it
• was nicht getestet werden kann, wird als nicht funktionierend angesehen
• Aufbau einer automatisierten Test-Infrastruktur für immer wiederkehrende System-Tests notwendig
• Testen ist Verantwortung des Entwicklungsteam, nicht von externen Ressourcen
• Design for Testability
75
"If they design and build it, they have to test it too."
Kontinuierliche Architektur im Rahmen großer Projek te© 2014 Orientation in Objects GmbH
Architektur-Prinzip 6
76
There is no monopoly on innovation.
6
01.07.2014
39
Kontinuierliche Architektur im Rahmen großer Projek te© 2014 Orientation in Objects GmbH
There is no monopoly on innovation
• Architektur entsteht im Zusammenwirken von agilen Teams, Architekten und Stakeholdern
• begünstigt Innovationskultur, jeder darf Vorschläge machen:– System-Architekt– agile Teams– techisches Management
• Enterprise Architekt stellt sicher, daß innovative Ideen und Vorschläge der Team-Ebene in die Architekturpiste einfließen
• Einplanung ins Backlog als Redesign-Spikes oder Umsetzung in Hackathons (HIP-Sprint)
77
6
Kontinuierliche Architektur im Rahmen großer Projek te© 2014 Orientation in Objects GmbH
There is no monopoly on innovationInnovation in HIP-Sprint
• i – Standard Entwicklungs-Iteration
• h – einwöchige Hardening-Iteration
• k – Innovationssprint (Hackathon)
78
6
01.07.2014
40
Kontinuierliche Architektur im Rahmen großer Projek te© 2014 Orientation in Objects GmbH
Architektur-Prinzip 7
79
Implement architectural flow.
7
Kontinuierliche Architektur im Rahmen großer Projek te© 2014 Orientation in Objects GmbH
Implement architectural flow
• trotz agiler Prinzipien muss zusätzlich der Prozess von Architektur-Initiativen kontinuierlich verbessert werden
• Vermeidung von Verzögerungen und Mehraufwand
• Sichtbar machen und Optimierung von Architektur-Updates (Transparenz)
• Lösung:
80
7
01.07.2014
41
Kontinuierliche Architektur im Rahmen großer Projek te© 2014 Orientation in Objects GmbH
Gliederung
• Warum sind wir hier?
• Was ist das Big Picture von SAFe
• Wie geht es dem Architekten und der Architektur in SAFe
• Wie bin ich AGIL wenn ich ein Architekt bin?
• Was nehmen wir mit?
81
Kontinuierliche Architektur im Rahmen großer Projek te© 2014 Orientation in Objects GmbH
SAFe on one slide
• große Programme (50+ Personen)
• straffe Taktung der Release-Zyklen
• selbstorganisierte agile Teams
• Ausrichtung auf Gesamt-Unternehmenserfolg
• Programm-/Unternehmensweite unterstützende Rollen ("Architekten haben wieder eine Zukunft…")
82
01.07.2014
42
Kontinuierliche Architektur im Rahmen großer Projek te© 2014 Orientation in Objects GmbH
Architektur in SAFe: Was nehmen wir mit?
• Architektur ist ... „Zusammenspiel von Komponenten und ihrer Kommunkation ...“
• Architektur ist ... „Sich auf das zu konzentrieren, was man nicht mehr leicht losbekommt ...“
• Architektur im Sinne von SAFe ist ...– nicht BUFD, emergent Design durch Team– intentional (trotzdem übergreifende Vision/Strategie)– stetig in Weiterentwicklung (Architekturpiste)– sichtbar machen der Architektur-Aufgaben (Architektur Epic Kanban)
• Welche Charaktere sind hierfür gefragt?
83
Kontinuierliche Architektur im Rahmen großer Projek te© 2014 Orientation in Objects GmbH
Welche Charaktere sind hierfür gefragt?
Architekten sind:
• nicht mehr im Elfenbeinturm (emergent Design durch Teams)
• nicht mehr Diktatoren, stattdessen enge Zusammenarbeit mit Teams
• Ratgeber (Mentor, Coach) und Moderator für agile Teams und Product Owner
• proaktiv (Pflege der Architekturpiste)
• Annahme von Ideen und Innovationen von agilen Teams
84
01.07.2014
43
Kontinuierliche Architektur im Rahmen großer Projek te© 2014 Orientation in Objects GmbH
Alles epische / biblische ist 7 – oderwarum große Projekte auch Agil sein können
• 7 – oder die Zahl göttlicher Vollkommenheit– In 6 Tagen wurde die Welt erschaffen dann war Pause - seither ruhen wir am 7. Tag – 7 Töne hat die Oktave– Über 7 Brücken musst Du gehen, die führen aber nicht über die 7 Weltmeere– Immer nach 7 Tagen ist ein Mondviertel vergangen
• Die Frauen singen ein Lied davon, die Demeter-Bio-B auern auch– Menschen haben 7 jährige Lebensabschnitte, Ehen auch– 6 Richtige mit Zusatzzahl und man ist im 7. Himmel– 7 Schwaben packen ihre sieben Sachen und eilen mit Siebenmeilenstiefeln zu den 7
Hügeln von Rom und treffen 7 Zwerge und pflegen 7 freie Künste mit ihnen was Sieben Siegel zu den 7 Tugenden und 7 Todsünden öffnet woraufhin sich 7 auf einen Streich in 7 Geißlein verwandeln und das sind 7 Weltwunder.
– Die Wirtschaft kennt 7 magere und 7 fette Jahre– 1 + 2 + 3 + 4 + 5 + 6 + 7 = 28
• Scrum Teams haben eine ideale Größe von 7 +- 2 Mitgliedern
• Ein Scrum Sprint hat als Dauer meist ein Vielfaches von 7 Tagen
85
Kontinuierliche Architektur im Rahmen großer Projek te© 2014 Orientation in Objects GmbH
Selbstorganisation
• Kulturelle Veränderungen in Organisationen dauern 7 Jahre• Quelle: „Für Sie“
– http://www.fuersie.de/lifestyle/kultur/artikel/7-jahres-rhythmus/page/2
– Sollen wir solange auf Selbstorgansiation warten und die Augen vor allen Ideen verschließen, wenn wir Agil sein wollen?
– Falls nicht, dann wäre SAFe ein Tip zu Orientierung
• Ein Tip zum Schluss:– 365 / 7 hat einen Rest– Das Sonnen- (Buchhalter-) und das Mond- (Scrum-) Jahr passen nie!
86
01.07.2014
44
Kontinuierliche Architektur im Rahmen großer Projek te© 2014 Orientation in Objects GmbH
Links
• Das graphische Material des Vortrags zu SAFe ist reproduziert mit der freundlichen Erlaubnis von Leffingwell, LLC
• ScaledAgileFramework – frei für eigene Implementierunghttp://scaledagileframework.com/
• Kommerzielle Unterstützunghttp://www.scaledagile.com/
http://scaledagilepartners.com/
• Einige Alternativenhttp://disciplinedagiledelivery.wordpress.com/
87
Orientation in Objects GmbH
Weinheimer Str. 6868309 Mannheim
??
? ?
????
Fragen ?
01.07.2014
45
Orientation in Objects GmbH
Weinheimer Str. 6868309 Mannheim
Vielen Dank für ihre Aufmerksamkeit !