Iterativ

Inkrementell

Build Management

Distributed Version Control

Dependency Management

Workplace Setup & IDE

Release Management

Continuous Integration

Feature Branches

Release Process (Version, Notes,

Migration)

Test

TDD

Mocks & Stubs

ATDD

Qualität

Design

Statische Code-Analyse

Metriken

Architektur &Documentation

Agile Architektur

Ausreichende Dokumentation

BuildManagement

Distributed Version Control

DependencyManagement

WorkplaceSetup & IDE

Release Management

ContinuousIntegration

Feature Branches

Release Process(Version, Notes,

Migration)

Test

TDD

Mocks & Stubs

ATDD

Qualität

Design

Statische Code-Analyse

Metriken

Architektur &Documentation

Agile Architektur

Ausreichende Dokumentation

RCS CVS Subversion Mercurial

Lokal Zentralisiert Verteilt

Change SetsRevisions

BuildManagement

Distributed Version Control

DependencyManagement

WorkplaceSetup & IDE

Release Management

ContinuousIntegration

Feature Branches

Release Process(Version, Notes,

Migration)

Test

TDD

Mocks & Stubs

ATDD

Qualität

Design

Statische Code-Analyse

Metriken

Architektur &Documentation

Agile Architektur

Ausreichende Dokumentation

BuildManagement

Distributed Version Control

DependencyManagement

WorkplaceSetup & IDE

Release Management

ContinuousIntegration

Feature Branches

Release Process(Version, Notes,

Migration)

Test

TDD

Mocks & Stubs

ATDD

Qualität

Design

Statische Code-Analyse

Metriken

Architektur &Documentation

Agile Architektur

Ausreichende Dokumentation

Pro (Branch Per Story) Kontra (Arbeit auf dem “Trunk”)

Unfertige Stories sind ein Problem:• Rollback?• Dunkelauslieferung?

(„Passiert schon nichts“)

Per Scrum-Definition gibt es keine unfertigen Stories => Team Commitment

Bonus Problem: Was passiert, wenn die erste, angefangene Story nicht beendet ist, aber alle anderen?

s.o.

Einfache Branches und Merges mit einem verteilten VCS (Mercurial, Git)

Merging tut weh.

Continuous Integration:• Stories müssen feinkörnig sein• Alternative: CI für jeden Branch

Jeder Commit wird sofort integriert und getestet.

BuildManagement

Distributed Version Control

DependencyManagement

WorkplaceSetup & IDE

Release Management

ContinuousIntegration

Feature Branches

Release Process(Version, Notes,

Migration)

Test

TDD

Mocks & Stubs

ATDD

Qualität

Design

Statische Code-Analyse

Metriken

Architektur &Documentation

Agile Architektur

Ausreichende Dokumentation

BuildManagement

Distributed Version Control

DependencyManagement

WorkplaceSetup & IDE

Release Management

ContinuousIntegration

Feature Branches

Release Process(Version, Notes,

Migration)

Test

TDD

Mocks & Stubs

ATDD

Qualität

Design

Statische Code-Analyse

Metriken

Architektur &Documentation

Agile Architektur

Ausreichende Dokumentation

Red

GreenRefactor

Test

schreiben

Die einfachste

Lösung umsetzen

Design

verbessern

Class

under

Test

Service A Service B

depends on

Mock

Service A

Mock

Service B

Service A IF Service B IF

Class

under

Test

Service A Service B

depends on

Mock

Service B

Contract

Test

Service A IF

Service A

Alternative

Impl.

*** Keyword ***

Verhalten

[Arguments] ${Produkt} ${Feld} ${Wert} ${Fehler} ${Ort}

Es existiert eine Produktseite für ${Produkt}

Wenn im Feld ${Feld} der Wert ${Wert} eingegeben wird

Dann wird der ${Fehler} angezeigt

Und der ${Fehler} befindet sich bei ${Ort}

Und der ${Fehler} hat den Style Rechenblock_Fehler_Text

Und das Feld ${Feld} ist als Validierungsfehler markiert

| *Test Case* | | *Risiken* | *Feld* | *Wert* | *Fehler* | *Ort* |

| 1 | Verhalten | Haftpflicht | Geburtsdatum | ABC | Bitte geben Sie das Geburtsdatum im Format TT.MM.JJJJ an. | Hauptrechenblock |

| 2 | Verhalten | Haftpflicht | Fassungsvermögen | ABC | ABC ist keine Zahl | Risikorechenblock |

| 3 | Verhalten | ... | ... | ... | ... | ... |

| 4 | Verhalten | ... | ... | ... | ... | ... |

| . | Verhalten | ... | ... | ... | ... | ... |

BuildManagement

Distributed Version Control

DependencyManagement

WorkplaceSetup & IDE

Release Management

ContinuousIntegration

Feature Branches

Release Process(Version, Notes,

Migration)

Test

TDD

Mocks & Stubs

ATDD

Qualität

Design

Statische Code-Analyse

Metriken

Architektur &Documentation

Agile Architektur

Ausreichende Dokumentation

BuildManagement

Distributed Version Control

DependencyManagement

WorkplaceSetup & IDE

Release Management

ContinuousIntegration

Feature Branches

Release Process(Version, Notes,

Migration)

Test

TDD

Mocks & Stubs

ATDD

Qualität

Design

Statische Code-Analyse

Metriken

Architektur &Documentation

Agile Architektur

Ausreichende Dokumentation

Design

GoF

SOLID

Clean Code

...

BuildManagement

Distributed Version Control

DependencyManagement

WorkplaceSetup & IDE

Release Management

ContinuousIntegration

Feature Branches

Release Process(Version, Notes,

Migration)

Test

TDD

Mocks & Stubs

ATDD

Qualität

Design

Statische Code-Analyse

Metriken

Architektur &Documentation

Agile Architektur

Ausreichende Dokumentation

BuildManagement

Distributed Version Control

DependencyManagement

WorkplaceSetup & IDE

Release Management

ContinuousIntegration

Feature Branches

Release Process(Version, Notes,

Migration)

Test

TDD

Mocks & Stubs

ATDD

Qualität

Design

Statische Code-Analyse

Metriken

Architektur &Documentation

Agile Architektur

Ausreichende Dokumentation

0

0,1

0,2

0,3

0,4

0,5

0,6

0,7

0,8

0,9

1

0 5 10

Architektur Funktionalität

BuildManagement

Distributed Version Control

DependencyManagement

WorkplaceSetup & IDE

Release Management

ContinuousIntegration

Feature Branches

Release Process(Version, Notes,

Migration)

Test

TDD

Mocks & Stubs

ATDD

Qualität

Design

Statische Code-Analyse

Metriken

Architektur &Documentation

Agile Architektur

Ausreichende Dokumentation

http://www.scrum.org/

Montag Dienstag Mittwoch Donnerstag Freitag

Scrum Overview Sprint 2: Build Management

Ziele:• Version Control• Dependency

Mgmt

Sprint 4: TDD

Ziele:• TDD• Mocking• Coverage

Sprint 6: ATDD

Ziele:• Test Framework• Executable

Specs

Sprint 8:Documentation & ArchitectureZiele:• Agile Arch.• System Doc.

Sprint 1: Scrum Flow

Ziele:• Practice the

Flow• Setup Dev-Env

Sprint 3: Release Mgmt

Ziele:• Branching• CI• Deployment

Sprint 5: Design & Refactoring

Ziele:• SOLID• Refactoring in

TDD

Sprint 7: Code Quality

Ziele:• Metrics• Clean Code• Javadocs

Roundup & FAQ

Auf dem Weg zurZertifizierung

Aktivität Dauer Beschreibung

Einführung 60’ Präsentation und Einführung in die neuen und relevanten Werkzeuge und Praktiken

Sprint Planning I 15’ Product Owner stellt das Backlog vor. Teams verpflichten sich auf neue Funktionen

Sprint Planning II 15’ Jedes Team plant den Sprint

Pause 15’

The Sprint 100’ Teams arbeiten selbstorganisiert an den Aufgaben. 5’ Scrum alle 20’

Sprint Review 20’ Zwei Teams stellen die Ergebnisse vor

Sprint Retrospective 15’ Kurze Teamretrospektive zum nachregeln