Konzeptionelle Integrität im Scrum Prozess - agil
Konzeptionelle Integrität im Scrum Prozess - agil
Konzeptionelle Integrität im Scrum Prozess - agil
Erfolgreiche ePaper selbst erstellen
Machen Sie aus Ihren PDF Publikationen ein blätterbares Flipbook mit unserer einzigartigen Google optimierten e-Paper Software.
<strong>Konzeptionelle</strong> Integrität<br />
<strong>im</strong> <strong>Scrum</strong> <strong>Prozess</strong><br />
Agile World 2012<br />
Ulf Schneider<br />
+49 163 2505164<br />
us@datenlabor.net<br />
www.alles<strong>agil</strong>.net<br />
Datenlabor GmbH<br />
Hillebrandstr. 6<br />
33102 Paderborn<br />
www.datenlabor.net
1<br />
<strong>Konzeptionelle</strong><br />
Integrität<br />
D A T E N L A B O R
Benutzer<br />
Ein konzeptionell integrer Entwurf ist<br />
- intuitiv verständlich,<br />
- längerfristig sinnvoll und klar.<br />
Entwickler<br />
Betreiber<br />
D A T E N L A B O R
D A T E N L A B O R<br />
Wie entsteht konzeptionelle Integrität
Problem<br />
Lösung<br />
D A T E N L A B O R
Vom Problem zur Lösung<br />
Problemraum<br />
Lösungsraum<br />
Zielsetzung Anforderungen Architektur Design Implementierung<br />
Überprüfung und<br />
Anpassung<br />
D A T E N L A B O R
Mut zur Vision und Demut dem Detail<br />
Vom Problem zur Lösung<br />
Problemraum<br />
Lösungsraum<br />
Zielsetzung<br />
Anforderungen Architektur Design Implementierung<br />
<strong>Konzeptionelle</strong> Integrität ist über alle Disziplinen herzustellen, aber besonders über die Architektur.<br />
Überprüfung und<br />
Anpassung<br />
D A T E N L A B O R
2<br />
Architektur<br />
und <strong>Scrum</strong><br />
D A T E N L A B O R
Softwareentwicklung als definierter <strong>Prozess</strong><br />
Problemraum<br />
Change<br />
Request<br />
Change<br />
Request<br />
Change<br />
Request<br />
Change<br />
Request<br />
Analyse<br />
Lösungsraum * * * *<br />
Architektur und<br />
Design Implementierung Test Auslieferung<br />
Inter-Domänen<br />
Kommunikation<br />
*<br />
Das<br />
Problem, oder das Verständnis des Problems ändert sich.<br />
D A T E N L A B O R
Deliver early and decide late!<br />
<strong>Scrum</strong> folgt einem empirischen <strong>Prozess</strong>modell<br />
Problemraum<br />
Lösungsraum<br />
Analyse<br />
Architektur<br />
Design<br />
Implementierung<br />
Test<br />
Auslieferung<br />
Analyse<br />
Architektur<br />
Design<br />
Implementierung<br />
Test<br />
Auslieferung<br />
Analyse<br />
Architektur<br />
Design<br />
Implementierung<br />
Test<br />
Auslieferung<br />
Analyse<br />
Architektur<br />
Design<br />
Implementierung<br />
Test<br />
Auslieferung<br />
Inter-Domänen<br />
Kommunikation<br />
D A T E N L A B O R
Wie werden <strong>im</strong> <strong>Scrum</strong><br />
die Architekturentscheidungen getroffen<br />
D A T E N L A B O R
Die Architektin hat das letzte Wort bei Architekturentscheidungen<br />
Analog dem Product Owner bei Geschäftsentscheidungen<br />
D A T E N L A B O R<br />
Vgl. F.P. Brooks, The Design of Design, Addison Wesley 2010, S. 79 ff.
Der Architekt führt Entscheidungen partizipativ herbei<br />
<br />
divergentes<br />
konvergentes<br />
✔<br />
Denken<br />
Denken<br />
emergenter<br />
Entscheidungsbedarf<br />
• der Teilnehmerkreis wird<br />
durch den Architekten<br />
eingeladen<br />
• der Architekt hat das<br />
letzte Wort<br />
Vgl. Sam Kaner, Facilitators Guide to Participatory Decision-Making, Jossey-Bass, 2007, S. 3-21<br />
D A T E N L A B O R
3<br />
Der<br />
Architekt <strong>im</strong> <strong>Scrum</strong><br />
D A T E N L A B O R
Eingliederung in das Projekt<br />
Ein <strong>Scrum</strong> Team<br />
ARC<br />
PO<br />
<strong>Scrum</strong> Team<br />
SM<br />
D A T E N L A B O R
Eingliederung in das Projekt<br />
Ein <strong>Scrum</strong> Team<br />
Mehrere <strong>Scrum</strong> Teams<br />
PO<br />
ARC<br />
ARC<br />
PO<br />
<strong>Scrum</strong> Team<br />
PO<br />
<strong>Scrum</strong> Team<br />
SM<br />
SM<br />
PO<br />
<strong>Scrum</strong> Team<br />
SM<br />
D A T E N L A B O R
Der Architekt gehört zum Projekt und<br />
stiftet dem Projekt Nutzen<br />
Der Architekt kann programmieren<br />
Der Architekt bildet aus<br />
D A T E N L A B O R
4<br />
Der<br />
Architekt in der Organisation<br />
D A T E N L A B O R
Keine Architektur durch Gremien<br />
Gremienarchitektur ist die Garantie für ein aufgeblähtes Produkt<br />
Vgl. F.P. Brooks, The Design of Design, Addison Wesley 2010, S. 71<br />
D A T E N L A B O R
Stattdessen: Ein Architekturgremium gibt unternehmensweite<br />
Architekturziele und Randbedingungen vor<br />
D A T E N L A B O R
Der Architekt entscheidet für sein Projekt unter<br />
Beachtung der Vorgaben<br />
D A T E N L A B O R
Große Projektorganisationen führen<br />
zu aufgeblähten Produkten.<br />
Hochleistungsorganisationen sind<br />
flach.<br />
Conway's Law<br />
Melvin Conway, 1968<br />
Any organization that designs a system<br />
will produce a design whose structure<br />
is a copy of the organization's<br />
communication structure.<br />
Vgl. http://www.melconway.com/Home/Conways_Law.html<br />
D A T E N L A B O R
5<br />
Einige<br />
Werkzeuge des Architekten<br />
D A T E N L A B O R
Architekturziele für das Projekt ermitteln<br />
Ziel: Erkennen, was wichtig ist<br />
Niemals ohne Festlegung und<br />
Abst<strong>im</strong>mung dieser Ziele beginnen.<br />
Interessenvertreter<br />
identifizieren<br />
Architekturziele<br />
ermitteln<br />
Architekturziele<br />
explizit machen, z.B.<br />
in der Produkt- oder<br />
Architekturvision *),<br />
und kommunizieren<br />
Der Architekt<br />
denkt sich die<br />
Architekturziele<br />
nicht selbst aus.<br />
• Erweiterbarkeit<br />
• Verfügbarkeit<br />
• Performance<br />
• Bedienbarkeit<br />
• Sicherheit<br />
• ...<br />
Architekturziele<br />
müssen bekannt<br />
und abgest<strong>im</strong>mt<br />
sein.<br />
*)<br />
http://alles<strong>agil</strong>.net/2012/01/01/der-erste-knopf/<br />
http://www.scrumalliance.org/articles/115-the-product-vision<br />
http://www.sigs-datacom.de/fileadmin/user_upload/zeitschriften/os/2011/04/pichler_roock_OS_04_11.pdf<br />
D A T E N L A B O R
Beispiele für verschiedene Architekturziele<br />
Repräsentation<br />
Villa La Rotonda, Quelle: Wik<strong>im</strong>edia<br />
Verteidigung<br />
Festung Hohensalzburg,<br />
Foto Andrew Bossi, Quelle: Wik<strong>im</strong>edia<br />
Mobilität<br />
Aquarell von Karl Bodmer, Quelle: Wik<strong>im</strong>edia<br />
D A T E N L A B O R
Systemkontext<br />
Ziel: Belastung und Schnittstellen des Systems erkennen<br />
Sachbearbeiter<br />
500<br />
Bestandssystem<br />
Spezialist<br />
0..10<br />
2 Fälle pro Tag<br />
Synchronisation<br />
330.000 einmal <strong>im</strong> Jahr<br />
300 bis 2000 Neugeschäft pro Tag<br />
20000 pro Jahr Abgang. E1<br />
http Web GUI<br />
E2<br />
330.000 an einem Tag <strong>im</strong> Jahr<br />
100 pro Tag<br />
Antwort auf<br />
Anfrage<br />
50 pro Tag<br />
A5<br />
JMS<br />
JMS<br />
System<br />
Bestand 2010:<br />
330.000<br />
JMS<br />
Konfig. + Logging<br />
Dateien<br />
JMS<br />
JMS<br />
JMS<br />
JMS<br />
Administrator<br />
0..10<br />
A1<br />
A2<br />
A3<br />
A4<br />
Ausgabe<br />
A1<br />
Ausgabe<br />
A2<br />
Ausgabe<br />
A3<br />
Ausgabe<br />
A4<br />
10.000 pro Jahr,<br />
an 12 Terminen<br />
10.000 pro Jahr,<br />
an 4 Terminen<br />
330.000 pro Jahr,<br />
an einem Termin<br />
330.000 pro Jahr,<br />
an einem Termin<br />
D A T E N L A B O R
Begrenzende Ressource<br />
Ziel: Die wesentliche Schwierigkeit aktiv behandeln<br />
NFA in die Fertigstellungskriterien<br />
(DoD) aufnehmen<br />
Begrenzende Ressource ermitteln und<br />
mit den Fertigstellungskriterien<br />
überprüfen<br />
Vgl. F.P. Brooks, The Design of Design, Addison Wesley 2010, S. 119 ff.<br />
D A T E N L A B O R
Komponentensicht<br />
Komponenten<br />
A<br />
B<br />
C<br />
Ziel: Innere Struktur des Systems<br />
mit seinen Komponenten sichtbar<br />
machen.<br />
E<br />
D<br />
D A T E N L A B O R
End-to-end Skeleton<br />
Ziel: Frühe, ganzheitliche Sicht und durchgehender Datenfluss<br />
Komponenten und ggf. <strong>Scrum</strong> Teams<br />
A<br />
B<br />
C<br />
Schnittstellen früh definieren (in der<br />
Hand des Architekten)<br />
Bei Bedarf Mocks in den<br />
Komponenten verwenden<br />
E<br />
D<br />
Vgl. F.P. Brooks, The Mythical Man Month (überarbeitete Ausgabe), Addison Wesley 1995, S. 267<br />
D A T E N L A B O R
Story-Board<br />
Ziel: Verständnis gemeinsam mit dem <strong>Scrum</strong> Team (bzw. den Team's) vertiefen<br />
User Story<br />
Aufgaben zur<br />
Umsetzung der Story<br />
Komponenten<br />
User Story in Aufgaben zergliedern<br />
Aufgaben visuell den Komponenten<br />
A<br />
B<br />
C<br />
zuordnen<br />
Fehlende Komponenten oder neu zu<br />
strukturierende Komponenten<br />
erkennen<br />
E<br />
D<br />
D A T E N L A B O R
Box-Bullet-Line (BBL)<br />
Ziel: Kommunikation für alle<br />
A<br />
1<br />
B<br />
2<br />
C<br />
3<br />
1. A sendet eine Nachricht an B<br />
2. C holt eine Nachricht von B ab<br />
3. C übermittelt eine Nachricht an A<br />
vgl. http://alles<strong>agil</strong>.net/2011/04/17/box-bullet-line-notation/<br />
D A T E N L A B O R
Architekturentscheidungen dokumentieren<br />
Ziel: bewusste und nachvollziehbare Architektur<br />
Dieses Modell haben wir Stefan Zörner zu verdanken! Vgl.: S. Zörner, Historisch gewachsen - Entscheidungen festhalten, in: Java Magazin 04/2009<br />
D A T E N L A B O R
Softwaresysteme werden nicht gebaut, sondern sie<br />
wachsen.<br />
Gute Architekturen werden von guten - kreativen -<br />
Architekten entworfen.<br />
D A T E N L A B O R
I<br />
❤<br />
Agile
Change language