Kontinuierliche Architektur im Rahmen grosser Agiler Projekte · Kontinuierliche Architektur im...

01.07.2014

1

Orientation in Objects GmbH

Weinheimer Str. 6868309 Mannheim

[email protected]:

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


Ihr Sprecher

3

Dirk M. Sohn

Trainer, Berater, Entwickler

SchwerpunkteSoftwareentwicklungsprozesse

Agile SoftwareentwicklungProjektmanagement


Ihr Sprecher

4

Falk Sippach

Trainer, Berater, Entwickler

SchwerpunkteArchitektur

Agile SoftwareentwicklungCodequalität

01.07.2014

3


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


Gliederung






6

01.07.2014

4


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


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


Agile Impulse ohne Architekten IScrum (1995)

• Gibt es einen übersichtlichen Arbeitsprozess für Softwareentwicklung in kleinen Teams?– Ken Schwaber: Scrum anwenden

9


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


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


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


Methoden mit ArchitektenRational Unified Prozess (1998)

• Wie würde man iterativ inkrementell anwendungsfallgetrieben und architekturzentriert Software entwickeln?– 3 Amigos: Mit RUP

13


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


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?“


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


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


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


Gliederung






19


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


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!


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


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


Program Level

24

Taktschlag

Wertgegenstände

Zuständigkeiten

01.07.2014

13


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


Neuer Taktschlag – PSI und ART

• (Arbeitet beim Portfolio Management mit – nachher)

26

01.07.2014

14


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


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


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


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


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


Program Level

32

Taktschlag

Wertgegenstände

Zuständigkeiten

Architektur später..

01.07.2014

17


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


Portfolio Level

34

Zuständigkeiten

Wertgegenstände

Architektur später..

01.07.2014

18


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


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


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


Gliederung






38

01.07.2014

20


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


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


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)


Architektur im SAFe Big Picture

42

01.07.2014

22


Architektur-Rollen in SAFe

• Team Ebene

• Programm-Ebene

• Portfolio-Ebene

43

+

+


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


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


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


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


Architectural Epic Kanban

48

01.07.2014

25


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


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


Program Backlog – Eingang und Priorisierung

51


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


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


Ausbalancieren Features and Architekturpiste (1)

54

01.07.2014

28


Ausbalancieren Features and Architekturpiste (2)

55


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


Gliederung






57


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


Architektur-Prinzip 1

59

Design emerges. Architecture is a collaboration.

1


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


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


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


Design emerges. Architecture is a collaboration.Collaboration

63

1



64

The bigger the system, the longer the runway.

2

01.07.2014

33


The bigger the system, the longer the runway

65

2



66

Build the simplest architecture that can possibly w ork.

3

01.07.2014

34


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


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


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



70

When in doubt, code, or model it out.

4

01.07.2014

36


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


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


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



74

They build it, they test it.

5

01.07.2014

38


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."



76

There is no monopoly on innovation.

6

01.07.2014

39


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


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



79

Implement architectural flow.

7


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


Gliederung






81


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


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


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


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


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


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



[email protected]

??

? ?

????

Fragen ?

01.07.2014

45



[email protected]

Vielen Dank für ihre Aufmerksamkeit !

Kontinuierliche Architektur im Rahmen grosser Agiler Projekte · Kontinuierliche Architektur im...

Documents

Transcript of Kontinuierliche Architektur im Rahmen grosser Agiler Projekte · Kontinuierliche Architektur im...