KenntnisstandWas ein Professional (Scrum) Developer

alles koumlnnen muss

Beginn 1540

Herbstcampus 2015 2

Scrum Team

bull The Scrum Team consists ofbull a Product Owner

bull the Development Team

bull and a Scrum Master

Quelle httpscrumguidesorgscrum-guidehtmlteam

Product Owner Dev Team

Scrum Master

Scrum Team

Herbstcampus 2015 2

Scrum Team

bull The Scrum Team consists ofbull a Product Owner

bull the Development Team

bull and a Scrum Master

Quelle httpscrumguidesorgscrum-guidehtmlteam

Product Owner Dev Team

Scrum Master

Scrum Team

Herbstcampus 2015 3

Scrum Team

bull The Scrum Team consists ofbull a Product Owner

bull the Development Team

bull and a Scrum Master

Quelle httpscrumguidesorgscrum-guidehtmlteam

Scrum Team

Scrum MasterDev Team

Product Owner

Herbstcampus 2015 4

Professional Scrum Developer (PSD) Program

Gegruumlndet 2009 von Microsoft und scrumorg

Mehr uumlber das PSD Program httpmsdnmicrosoftcomen-usvstudioff433643aspx

Basiert auf den Professional Scrum Developer (PSD)-

Kursunterlagen copy 2014 scrumorg

Herbstcampus 2015 5

Anna-Karenina-Prinzip

bdquoAlle gluumlcklichen Familien gleichen einander jede

ungluumlckliche Familie ist auf ihre eigene Weise ungluumlcklichldquo

-- Leo Tolstoi 187778

Herbstcampus 2015 6

Erfolgsfaktoren

Herbstcampus 2015 7

Beginnen wir mit dem schwierigstenhellip

Herbstcampus 2015 8

Welche Rolle spielt das Development Team

The Development Team consists of professionals who

do the work of delivering a potentially releasable

Increment of ldquoDonerdquo product at the end of each Sprint

--Scrum Guide July 2013

bull They are self-organizing

bull Development Teams are cross-functional

bull No titles for Development Team members

bull No sub-teams in the Development Team

bull Accountability belongs to the Development Team

Quelle httpscrumguidesorgscrum-guidehtmlteam-dev

Herbstcampus 2015 6

Erfolgsfaktoren

Herbstcampus 2015 7

Beginnen wir mit dem schwierigstenhellip

Herbstcampus 2015 8

Welche Rolle spielt das Development Team

The Development Team consists of professionals who

do the work of delivering a potentially releasable

Increment of ldquoDonerdquo product at the end of each Sprint

--Scrum Guide July 2013

bull They are self-organizing

bull Development Teams are cross-functional

bull No titles for Development Team members

bull No sub-teams in the Development Team

bull Accountability belongs to the Development Team

Quelle httpscrumguidesorgscrum-guidehtmlteam-dev

Herbstcampus 2015 7

Beginnen wir mit dem schwierigstenhellip

Herbstcampus 2015 8

Welche Rolle spielt das Development Team

The Development Team consists of professionals who

do the work of delivering a potentially releasable

Increment of ldquoDonerdquo product at the end of each Sprint

--Scrum Guide July 2013

bull They are self-organizing

bull Development Teams are cross-functional

bull No titles for Development Team members

bull No sub-teams in the Development Team

bull Accountability belongs to the Development Team

Quelle httpscrumguidesorgscrum-guidehtmlteam-dev

Herbstcampus 2015 8

Welche Rolle spielt das Development Team

The Development Team consists of professionals who

do the work of delivering a potentially releasable

Increment of ldquoDonerdquo product at the end of each Sprint

--Scrum Guide July 2013

bull They are self-organizing

bull Development Teams are cross-functional

bull No titles for Development Team members

bull No sub-teams in the Development Team

bull Accountability belongs to the Development Team

Quelle httpscrumguidesorgscrum-guidehtmlteam-dev

Herbstcampus 2015 9

Teams bestehen aus Menschen

bull Unterschiedliche Kulturen

bull Unterschiedliche Persoumlnlichkeiten

bull Unterschiedliche Arbeitsgeschwindigkeit

bull Menschen sind keine Maschinen

bull Menschen haben Gefuumlhle

bull Menschen haben schlechte Tage

Herbstcampus 2015 10

Dysfunctions of a Software Development Team

bull No collaboration

bull Donrsquot care rude

bull Alphas cowboys

bull Wonrsquot listen

bull Wonrsquot learn

bull Wonrsquot teach

bull Specialists

bull Slackers

bull Too many meetings

bull ldquoThatrsquos not my jobrdquo

bull ldquoIrsquom not a testerrdquo

bull ldquoIrsquom 80 donerdquo

bull ldquoIt compiled on my machinerdquo

bull ldquoI did my partrdquo

bull ldquoNothing is blocking merdquo

bull ldquoIt was your code that failedrdquo

bull ldquoI was on time you were earlyrdquo

bull ldquoYou just canrsquot implement my designrdquo

Herbstcampus 2015 11

Quiz What about Dieter

Dieter is your organizationrsquos only

SQL Server administrator He holds

all the passwords and all database

changes must go through him Hersquos

happy to help your team with its

database tasks but only for a few

days Hersquos very busy and important

He makes it clear that he doesnrsquot

work for you or your boss and his

help is just a courtesy

Herbstcampus 2015 12

(Bruce) Tuckman Model

bull In 1965 Bruce Tuckman identified four necessary

phases of group (team) development

Herbstcampus 2015 13

Some interesting Tactics

bull Use the Pomodoro Technique

bull Minimize eMail Distractions

bull Implement the Forgiveness Pattern

bull hellip

Herbstcampus 2015 15

Erfolgsfaktoren

Herbstcampus 2015 16

Scrum

Complementary Practices

Scrum

Pair

Programming

User

Stories

Planning

Poker

Relative

Estimation

Release

Planning

Information

Radiators

Just in Time

PlanningCollective

Ownership

Burndown

Charts

Test Driven

DevelopmentCI

Specification

by

Example

BDD

ATDD

Executable

Specifications

Design

Patterns

Reducing

Technical Debt

Build

Automation

Continuous

Deployment

Design for

Operations

Refactoring

Continuous

Delivery

Emergent

Architecture

Clean Code

Pair

Programming

People Practices

Engineering Practices

Scrum Guide

Herbstcampus 2015 17

Professional Scrum Developer-Knowhow

Development Practices

Product Backlog refinement

Relative (team) estimation

Burndowns and Cumulative Flow Charts

Emergent architecture

Continuous Integration (CI)

Test-Driven Development (TDD)

Test Smells

Acceptance testing

Clean coding

Pair Programming

Code Review

Overcoming dysfunction

Scrum

Plan Releases and Sprints

Create Sprint Backlog

Definition of Done

Conduct Sprint Reviews

Reflection in Retrospectives

Herbstcampus 2015 18

Herbstcampus 2015 19

Herbstcampus 2015 20

Big Design Up Front (BDUP)

bull Why Big Design Up Front Seems Goodbull Requirements are better understood

bull Thinking things out ahead of time saves headaches

bull Changes to specs are cheaper than changes to code

bull Bugs are cheaper to fix early

bull Why Big Design Up Front Isnrsquot Goodbull Requirements arenrsquot well known in the first place

bull Requirements change

bull Developers are not able to foresee all problems

bull Customers are not able to tell you what they want

There is no business value in architecture or design

Herbstcampus 2015 21

Where are you today

Waterfall Some DUF

Cowboy

EmergentBDUF

Herbstcampus 2015 22

What is Emergent Architecture

bull The opposite of Big Design Up Front

bull It allows architecture to emerge as you develop

bull Some architectural decisions will need to be made

before you write your first line of code

bull Technologies frameworks languages patterns practices

bull Most of these decisions will be hard to change later

Herbstcampus 2015 23

Gebrauchseignung (Fitness for Purpose)

bull Eine Loumlsung sollte fuumlr den geplanten Zweck geeignet sein

bull Beispiel fuumlr eine User Storybull Titel Alle Autos muumlssen in der Bahnstr 87 halten

bull Beschreibung Als Sicherheitsbeauftragter moumlchte ich dass alle

Autos vor dem Gebaumlude halten sodass keine Teilnehmer verletzt werden

bull Abnahmekriterien

bull Die Loumlsung sollte universell verstaumlndlich sein

bull 247 Verfuumlgbar sein

bull niedrige Betriebskosten haben

Herbstcampus 2015 24

Itrsquos all About Business Value

bull Every sprint should generates an increment of potentially-

shippable business value

bull Therefore

bull It is not ok to have an ldquoarchitecture sprintrdquo

bull It is not ok to have an ldquoinfrastructure sprintrdquo

bull There is no such thing as sprint 0

bull And while wersquore on the topic therersquos no such thing as ldquodone donerdquo

Herbstcampus 2015 25

Donrsquot Over-Architect the Product

bull Build at least one increment of business

functionality every sprint

bull Build enough of the architecture and design to

support that business functionality

bull Build adequate architecture and design to meet any

non-functional requirements

bull Solve todayrsquos problem today tomorrowrsquos

problem tomorrow

Herbstcampus 2015 26

Quizfrage

bull In sprint 3 you start implementing the customer

management component of the web site Yoursquove

committed to delivering basic add edit and view

functionality

bull But you know that in sprint 4 the product

owner is going to want the ability to delete

a customer

bull How should you consider this while

delivering the sprint 3 increment

Herbstcampus 2015 27

Was bedeutet fuumlr uns Qualitaumlt

bull Erfuumlllt es die Anforderungen

bull Erfuumlllt es die Erwartungen

bull Hat es einen Nutzen

bull Ist die Loumlsung fuumlr den Zweck geeignet

bull Sind erforderliche Qualitaumltsattribute eingehalten

Herbstcampus 2015 28

Development Definition of Done

Wann sind wir fertig

bull Explizite Definition of Done (DoD)

bull Konstante (Mindest-)Qualitaumlt

bull Basis fuumlr Schaumltzungen

bull Beeinflusst von unternehmensweiten Richtlinien

bull Messbar

bull Automatisiert

Herbstcampus 2015 29

Example A Simple Definition of Done

1 Coded

2 Acceptance criteria met

3 Tests pass

4 Checked-in

Herbstcampus 2015 30

Be Transparent

bull Everyone should be able to inspect hellipbull The teamrsquos Definition of Done (DoD)

bull The product backlog (user stories)

bull The sprint backlog (tasks)

bull The impediments

bull Deployments

bull Test results

bull Bugs

bull Everyone should adapt to these inspections

Herbstcampus 2015 31

What is Done

Fundamental

bull Code Analysis

bull Coded

bull Refactored

bull Code Reviewed

bull Unit Tested

bull Documented

bull Continuous Build

bull User Acceptance

Mature

bull Design Review

bull Design Refactored

bull Integration Tested

bull Regression Tested

bull Security Tested

bull LoadSoak Tested

bull Scalability Tested

bull Performance Tested

Herbstcampus 2015 32

Unit Tests ndash warum

bull Sicherheitsnetz

bull Weniger Bugs

bull Schoumlneres Design

bull Ermoumlglichen Refactoring

bull Fokus bleibt auf Done

bull Hilft eigentliche Absicht zu dokumentieren

bull Forciert Entwickler uumlber das Ziel nachzudenken

bull Umgehende Belohnung

bull Pruumlft auf die Existenz eines Bugs

Herbstcampus 2015 34

Nur Sauberer Code ist qualitativer Code

bull Sauberer Quellcode erfordert staumlndiges

schonungsloses saumlubern (Refactoring)

bull Niemand sonst wird Deinen Code aufraumlumenbull Kein Zimmer-Servicehellip

bull Broken-Windows-Theorie

Herbstcampus 2015 35

Refactoring

bull The process of improving your code after it has

been written by changing the internal structure of

the code without changing its external behaviorbull In other words improving your code without breaking your

unit tests

bull Refactoring should only be done to add business

value or to meet the teamrsquos definition of Done

Herbstcampus 2015 36

Erfolgsfaktoren

Herbstcampus 2015 37

Tool-Kenntnisse

Application Lifecycle Management (ALM) Tools

Development Environment

Configuration Management

Branching amp Merging

Continuous Integration (CI) Tools

Unit Testing

Measuring Code Quality

Refactoring Tools

Herbstcampus 2015 38

Zusammenfassung

Herbstcampus 2015 39

Professional Scrum Developer Glossary

bull ALM (Application Lifecycle Management)

bull ATDD (Acceptance Test-Driven Development)

bull BDD (Behavior-Driven Development)

bull Branching

bull Clean Code

bull Code Coverage

bull Collective Code Ownership

bull Continuous Delivery

bull Continuous Deployment

bull Continuous Integration (CI)

bull Cyclomatic Complexity

bull Cross-functional

bull Definition of Done

bull Developer

bull DevOps

bull Development Team

bull DRY (donrsquot repeat yourself)

bull Engineering Standards

bull Extreme Programming (XP)

bull Feature Toggle

bull Increment

bull Pair Programming

bull Refactoring

bull Scout Rule

bull Scrum Board

bull Scrum Guidetrade

bull Scrum Team

bull Self-organization

bull Specification by Example

bull TDD (Test-Driven Development)

bull Technical Debt

bull User Story

bull Unit Test

bull Velocity

Quelle httpwwwscrumorgResourcesPSD-Glossary

Herbstcampus 2015 10

Dysfunctions of a Software Development Team

bull No collaboration

bull Donrsquot care rude

bull Alphas cowboys

bull Wonrsquot listen

bull Wonrsquot learn

bull Wonrsquot teach

bull Specialists

bull Slackers

bull Too many meetings

bull ldquoThatrsquos not my jobrdquo

bull ldquoIrsquom not a testerrdquo

bull ldquoIrsquom 80 donerdquo

bull ldquoIt compiled on my machinerdquo

bull ldquoI did my partrdquo

bull ldquoNothing is blocking merdquo

bull ldquoIt was your code that failedrdquo

bull ldquoI was on time you were earlyrdquo

bull ldquoYou just canrsquot implement my designrdquo

Herbstcampus 2015 11

Quiz What about Dieter

Dieter is your organizationrsquos only

SQL Server administrator He holds

all the passwords and all database

changes must go through him Hersquos

happy to help your team with its

database tasks but only for a few

days Hersquos very busy and important

He makes it clear that he doesnrsquot

work for you or your boss and his

help is just a courtesy

Herbstcampus 2015 12

(Bruce) Tuckman Model

bull In 1965 Bruce Tuckman identified four necessary

phases of group (team) development

Herbstcampus 2015 13

Some interesting Tactics

bull Use the Pomodoro Technique

bull Minimize eMail Distractions

bull Implement the Forgiveness Pattern

bull hellip

Herbstcampus 2015 15

Erfolgsfaktoren

Herbstcampus 2015 16

Scrum

Complementary Practices

Scrum

Pair

Programming

User

Stories

Planning

Poker

Relative

Estimation

Release

Planning

Information

Radiators

Just in Time

PlanningCollective

Ownership

Burndown

Charts

Test Driven

DevelopmentCI

Specification

by

Example

BDD

ATDD

Executable

Specifications

Design

Patterns

Reducing

Technical Debt

Build

Automation

Continuous

Deployment

Design for

Operations

Refactoring

Continuous

Delivery

Emergent

Architecture

Clean Code

Pair

Programming

People Practices

Engineering Practices

Scrum Guide

Herbstcampus 2015 17

Professional Scrum Developer-Knowhow

Development Practices

Product Backlog refinement

Relative (team) estimation

Burndowns and Cumulative Flow Charts

Emergent architecture

Continuous Integration (CI)

Test-Driven Development (TDD)

Test Smells

Acceptance testing

Clean coding

Pair Programming

Code Review

Overcoming dysfunction

Scrum

Plan Releases and Sprints

Create Sprint Backlog

Definition of Done

Conduct Sprint Reviews

Reflection in Retrospectives

Herbstcampus 2015 18

Herbstcampus 2015 19

Herbstcampus 2015 20

Big Design Up Front (BDUP)

bull Why Big Design Up Front Seems Goodbull Requirements are better understood

bull Thinking things out ahead of time saves headaches

bull Changes to specs are cheaper than changes to code

bull Bugs are cheaper to fix early

bull Why Big Design Up Front Isnrsquot Goodbull Requirements arenrsquot well known in the first place

bull Requirements change

bull Developers are not able to foresee all problems

bull Customers are not able to tell you what they want

There is no business value in architecture or design

Herbstcampus 2015 21

Where are you today

Waterfall Some DUF

Cowboy

EmergentBDUF

Herbstcampus 2015 22

What is Emergent Architecture

bull The opposite of Big Design Up Front

bull It allows architecture to emerge as you develop

bull Some architectural decisions will need to be made

before you write your first line of code

bull Technologies frameworks languages patterns practices

bull Most of these decisions will be hard to change later

Herbstcampus 2015 23

Gebrauchseignung (Fitness for Purpose)

bull Eine Loumlsung sollte fuumlr den geplanten Zweck geeignet sein

bull Beispiel fuumlr eine User Storybull Titel Alle Autos muumlssen in der Bahnstr 87 halten

bull Beschreibung Als Sicherheitsbeauftragter moumlchte ich dass alle

Autos vor dem Gebaumlude halten sodass keine Teilnehmer verletzt werden

bull Abnahmekriterien

bull Die Loumlsung sollte universell verstaumlndlich sein

bull 247 Verfuumlgbar sein

bull niedrige Betriebskosten haben

Herbstcampus 2015 24

Itrsquos all About Business Value

bull Every sprint should generates an increment of potentially-

shippable business value

bull Therefore

bull It is not ok to have an ldquoarchitecture sprintrdquo

bull It is not ok to have an ldquoinfrastructure sprintrdquo

bull There is no such thing as sprint 0

bull And while wersquore on the topic therersquos no such thing as ldquodone donerdquo

Herbstcampus 2015 25

Donrsquot Over-Architect the Product

bull Build at least one increment of business

functionality every sprint

bull Build enough of the architecture and design to

support that business functionality

bull Build adequate architecture and design to meet any

non-functional requirements

bull Solve todayrsquos problem today tomorrowrsquos

problem tomorrow

Herbstcampus 2015 26

Quizfrage

bull In sprint 3 you start implementing the customer

management component of the web site Yoursquove

committed to delivering basic add edit and view

functionality

bull But you know that in sprint 4 the product

owner is going to want the ability to delete

a customer

bull How should you consider this while

delivering the sprint 3 increment

Herbstcampus 2015 27

Was bedeutet fuumlr uns Qualitaumlt

bull Erfuumlllt es die Anforderungen

bull Erfuumlllt es die Erwartungen

bull Hat es einen Nutzen

bull Ist die Loumlsung fuumlr den Zweck geeignet

bull Sind erforderliche Qualitaumltsattribute eingehalten

Herbstcampus 2015 28

Development Definition of Done

Wann sind wir fertig

bull Explizite Definition of Done (DoD)

bull Konstante (Mindest-)Qualitaumlt

bull Basis fuumlr Schaumltzungen

bull Beeinflusst von unternehmensweiten Richtlinien

bull Messbar

bull Automatisiert

Herbstcampus 2015 29

Example A Simple Definition of Done

1 Coded

2 Acceptance criteria met

3 Tests pass

4 Checked-in

Herbstcampus 2015 30

Be Transparent

bull Everyone should be able to inspect hellipbull The teamrsquos Definition of Done (DoD)

bull The product backlog (user stories)

bull The sprint backlog (tasks)

bull The impediments

bull Deployments

bull Test results

bull Bugs

bull Everyone should adapt to these inspections

Herbstcampus 2015 31

What is Done

Fundamental

bull Code Analysis

bull Coded

bull Refactored

bull Code Reviewed

bull Unit Tested

bull Documented

bull Continuous Build

bull User Acceptance

Mature

bull Design Review

bull Design Refactored

bull Integration Tested

bull Regression Tested

bull Security Tested

bull LoadSoak Tested

bull Scalability Tested

bull Performance Tested

Herbstcampus 2015 32

Unit Tests ndash warum

bull Sicherheitsnetz

bull Weniger Bugs

bull Schoumlneres Design

bull Ermoumlglichen Refactoring

bull Fokus bleibt auf Done

bull Hilft eigentliche Absicht zu dokumentieren

bull Forciert Entwickler uumlber das Ziel nachzudenken

bull Umgehende Belohnung

bull Pruumlft auf die Existenz eines Bugs

Herbstcampus 2015 34

Nur Sauberer Code ist qualitativer Code

bull Sauberer Quellcode erfordert staumlndiges

schonungsloses saumlubern (Refactoring)

bull Niemand sonst wird Deinen Code aufraumlumenbull Kein Zimmer-Servicehellip

bull Broken-Windows-Theorie

Herbstcampus 2015 35

Refactoring

bull The process of improving your code after it has

been written by changing the internal structure of

the code without changing its external behaviorbull In other words improving your code without breaking your

unit tests

bull Refactoring should only be done to add business

value or to meet the teamrsquos definition of Done

Herbstcampus 2015 36

Erfolgsfaktoren

Herbstcampus 2015 37

Tool-Kenntnisse

Application Lifecycle Management (ALM) Tools

Development Environment

Configuration Management

Branching amp Merging

Continuous Integration (CI) Tools

Unit Testing

Measuring Code Quality

Refactoring Tools

Herbstcampus 2015 38

Zusammenfassung

Herbstcampus 2015 39

Professional Scrum Developer Glossary

bull ALM (Application Lifecycle Management)

bull ATDD (Acceptance Test-Driven Development)

bull BDD (Behavior-Driven Development)

bull Branching

bull Clean Code

bull Code Coverage

bull Collective Code Ownership

bull Continuous Delivery

bull Continuous Deployment

bull Continuous Integration (CI)

bull Cyclomatic Complexity

bull Cross-functional

bull Definition of Done

bull Developer

bull DevOps

bull Development Team

bull DRY (donrsquot repeat yourself)

bull Engineering Standards

bull Extreme Programming (XP)

bull Feature Toggle

bull Increment

bull Pair Programming

bull Refactoring

bull Scout Rule

bull Scrum Board

bull Scrum Guidetrade

bull Scrum Team

bull Self-organization

bull Specification by Example

bull TDD (Test-Driven Development)

bull Technical Debt

bull User Story

bull Unit Test

bull Velocity

Quelle httpwwwscrumorgResourcesPSD-Glossary

Herbstcampus 2015 11

Quiz What about Dieter

Dieter is your organizationrsquos only

SQL Server administrator He holds

all the passwords and all database

changes must go through him Hersquos

happy to help your team with its

database tasks but only for a few

days Hersquos very busy and important

He makes it clear that he doesnrsquot

work for you or your boss and his

help is just a courtesy

Herbstcampus 2015 12

(Bruce) Tuckman Model

bull In 1965 Bruce Tuckman identified four necessary

phases of group (team) development

Herbstcampus 2015 13

Some interesting Tactics

bull Use the Pomodoro Technique

bull Minimize eMail Distractions

bull Implement the Forgiveness Pattern

bull hellip

Herbstcampus 2015 15

Erfolgsfaktoren

Herbstcampus 2015 16

Scrum

Complementary Practices

Scrum

Pair

Programming

User

Stories

Planning

Poker

Relative

Estimation

Release

Planning

Information

Radiators

Just in Time

PlanningCollective

Ownership

Burndown

Charts

Test Driven

DevelopmentCI

Specification

by

Example

BDD

ATDD

Executable

Specifications

Design

Patterns

Reducing

Technical Debt

Build

Automation

Continuous

Deployment

Design for

Operations

Refactoring

Continuous

Delivery

Emergent

Architecture

Clean Code

Pair

Programming

People Practices

Engineering Practices

Scrum Guide

Herbstcampus 2015 17

Professional Scrum Developer-Knowhow

Development Practices

Product Backlog refinement

Relative (team) estimation

Burndowns and Cumulative Flow Charts

Emergent architecture

Continuous Integration (CI)

Test-Driven Development (TDD)

Test Smells

Acceptance testing

Clean coding

Pair Programming

Code Review

Overcoming dysfunction

Scrum

Plan Releases and Sprints

Create Sprint Backlog

Definition of Done

Conduct Sprint Reviews

Reflection in Retrospectives

Herbstcampus 2015 18

Herbstcampus 2015 19

Herbstcampus 2015 20

Big Design Up Front (BDUP)

bull Why Big Design Up Front Seems Goodbull Requirements are better understood

bull Thinking things out ahead of time saves headaches

bull Changes to specs are cheaper than changes to code

bull Bugs are cheaper to fix early

bull Why Big Design Up Front Isnrsquot Goodbull Requirements arenrsquot well known in the first place

bull Requirements change

bull Developers are not able to foresee all problems

bull Customers are not able to tell you what they want

There is no business value in architecture or design

Herbstcampus 2015 21

Where are you today

Waterfall Some DUF

Cowboy

EmergentBDUF

Herbstcampus 2015 22

What is Emergent Architecture

bull The opposite of Big Design Up Front

bull It allows architecture to emerge as you develop

bull Some architectural decisions will need to be made

before you write your first line of code

bull Technologies frameworks languages patterns practices

bull Most of these decisions will be hard to change later

Herbstcampus 2015 23

Gebrauchseignung (Fitness for Purpose)

bull Eine Loumlsung sollte fuumlr den geplanten Zweck geeignet sein

bull Beispiel fuumlr eine User Storybull Titel Alle Autos muumlssen in der Bahnstr 87 halten

bull Beschreibung Als Sicherheitsbeauftragter moumlchte ich dass alle

Autos vor dem Gebaumlude halten sodass keine Teilnehmer verletzt werden

bull Abnahmekriterien

bull Die Loumlsung sollte universell verstaumlndlich sein

bull 247 Verfuumlgbar sein

bull niedrige Betriebskosten haben

Herbstcampus 2015 24

Itrsquos all About Business Value

bull Every sprint should generates an increment of potentially-

shippable business value

bull Therefore

bull It is not ok to have an ldquoarchitecture sprintrdquo

bull It is not ok to have an ldquoinfrastructure sprintrdquo

bull There is no such thing as sprint 0

bull And while wersquore on the topic therersquos no such thing as ldquodone donerdquo

Herbstcampus 2015 25

Donrsquot Over-Architect the Product

bull Build at least one increment of business

functionality every sprint

bull Build enough of the architecture and design to

support that business functionality

bull Build adequate architecture and design to meet any

non-functional requirements

bull Solve todayrsquos problem today tomorrowrsquos

problem tomorrow

Herbstcampus 2015 26

Quizfrage

bull In sprint 3 you start implementing the customer

management component of the web site Yoursquove

committed to delivering basic add edit and view

functionality

bull But you know that in sprint 4 the product

owner is going to want the ability to delete

a customer

bull How should you consider this while

delivering the sprint 3 increment

Herbstcampus 2015 27

Was bedeutet fuumlr uns Qualitaumlt

bull Erfuumlllt es die Anforderungen

bull Erfuumlllt es die Erwartungen

bull Hat es einen Nutzen

bull Ist die Loumlsung fuumlr den Zweck geeignet

bull Sind erforderliche Qualitaumltsattribute eingehalten

Herbstcampus 2015 28

Development Definition of Done

Wann sind wir fertig

bull Explizite Definition of Done (DoD)

bull Konstante (Mindest-)Qualitaumlt

bull Basis fuumlr Schaumltzungen

bull Beeinflusst von unternehmensweiten Richtlinien

bull Messbar

bull Automatisiert

Herbstcampus 2015 29

Example A Simple Definition of Done

1 Coded

2 Acceptance criteria met

3 Tests pass

4 Checked-in

Herbstcampus 2015 30

Be Transparent

bull Everyone should be able to inspect hellipbull The teamrsquos Definition of Done (DoD)

bull The product backlog (user stories)

bull The sprint backlog (tasks)

bull The impediments

bull Deployments

bull Test results

bull Bugs

bull Everyone should adapt to these inspections

Herbstcampus 2015 31

What is Done

Fundamental

bull Code Analysis

bull Coded

bull Refactored

bull Code Reviewed

bull Unit Tested

bull Documented

bull Continuous Build

bull User Acceptance

Mature

bull Design Review

bull Design Refactored

bull Integration Tested

bull Regression Tested

bull Security Tested

bull LoadSoak Tested

bull Scalability Tested

bull Performance Tested

Herbstcampus 2015 32

Unit Tests ndash warum

bull Sicherheitsnetz

bull Weniger Bugs

bull Schoumlneres Design

bull Ermoumlglichen Refactoring

bull Fokus bleibt auf Done

bull Hilft eigentliche Absicht zu dokumentieren

bull Forciert Entwickler uumlber das Ziel nachzudenken

bull Umgehende Belohnung

bull Pruumlft auf die Existenz eines Bugs

Herbstcampus 2015 34

Nur Sauberer Code ist qualitativer Code

bull Sauberer Quellcode erfordert staumlndiges

schonungsloses saumlubern (Refactoring)

bull Niemand sonst wird Deinen Code aufraumlumenbull Kein Zimmer-Servicehellip

bull Broken-Windows-Theorie

Herbstcampus 2015 35

Refactoring

bull The process of improving your code after it has

been written by changing the internal structure of

the code without changing its external behaviorbull In other words improving your code without breaking your

unit tests

bull Refactoring should only be done to add business

value or to meet the teamrsquos definition of Done

Herbstcampus 2015 36

Erfolgsfaktoren

Herbstcampus 2015 37

Tool-Kenntnisse

Application Lifecycle Management (ALM) Tools

Development Environment

Configuration Management

Branching amp Merging

Continuous Integration (CI) Tools

Unit Testing

Measuring Code Quality

Refactoring Tools

Herbstcampus 2015 38

Zusammenfassung

Herbstcampus 2015 39

Professional Scrum Developer Glossary

bull ALM (Application Lifecycle Management)

bull ATDD (Acceptance Test-Driven Development)

bull BDD (Behavior-Driven Development)

bull Branching

bull Clean Code

bull Code Coverage

bull Collective Code Ownership

bull Continuous Delivery

bull Continuous Deployment

bull Continuous Integration (CI)

bull Cyclomatic Complexity

bull Cross-functional

bull Definition of Done

bull Developer

bull DevOps

bull Development Team

bull DRY (donrsquot repeat yourself)

bull Engineering Standards

bull Extreme Programming (XP)

bull Feature Toggle

bull Increment

bull Pair Programming

bull Refactoring

bull Scout Rule

bull Scrum Board

bull Scrum Guidetrade

bull Scrum Team

bull Self-organization

bull Specification by Example

bull TDD (Test-Driven Development)

bull Technical Debt

bull User Story

bull Unit Test

bull Velocity

Quelle httpwwwscrumorgResourcesPSD-Glossary

Herbstcampus 2015 12

(Bruce) Tuckman Model

bull In 1965 Bruce Tuckman identified four necessary

phases of group (team) development

Herbstcampus 2015 13

Some interesting Tactics

bull Use the Pomodoro Technique

bull Minimize eMail Distractions

bull Implement the Forgiveness Pattern

bull hellip

Herbstcampus 2015 15

Erfolgsfaktoren

Herbstcampus 2015 16

Scrum

Complementary Practices

Scrum

Pair

Programming

User

Stories

Planning

Poker

Relative

Estimation

Release

Planning

Information

Radiators

Just in Time

PlanningCollective

Ownership

Burndown

Charts

Test Driven

DevelopmentCI

Specification

by

Example

BDD

ATDD

Executable

Specifications

Design

Patterns

Reducing

Technical Debt

Build

Automation

Continuous

Deployment

Design for

Operations

Refactoring

Continuous

Delivery

Emergent

Architecture

Clean Code

Pair

Programming

People Practices

Engineering Practices

Scrum Guide

Herbstcampus 2015 17

Professional Scrum Developer-Knowhow

Development Practices

Product Backlog refinement

Relative (team) estimation

Burndowns and Cumulative Flow Charts

Emergent architecture

Continuous Integration (CI)

Test-Driven Development (TDD)

Test Smells

Acceptance testing

Clean coding

Pair Programming

Code Review

Overcoming dysfunction

Scrum

Plan Releases and Sprints

Create Sprint Backlog

Definition of Done

Conduct Sprint Reviews

Reflection in Retrospectives

Herbstcampus 2015 18

Herbstcampus 2015 19

Herbstcampus 2015 20

Big Design Up Front (BDUP)

bull Why Big Design Up Front Seems Goodbull Requirements are better understood

bull Thinking things out ahead of time saves headaches

bull Changes to specs are cheaper than changes to code

bull Bugs are cheaper to fix early

bull Why Big Design Up Front Isnrsquot Goodbull Requirements arenrsquot well known in the first place

bull Requirements change

bull Developers are not able to foresee all problems

bull Customers are not able to tell you what they want

There is no business value in architecture or design

Herbstcampus 2015 21

Where are you today

Waterfall Some DUF

Cowboy

EmergentBDUF

Herbstcampus 2015 22

What is Emergent Architecture

bull The opposite of Big Design Up Front

bull It allows architecture to emerge as you develop

bull Some architectural decisions will need to be made

before you write your first line of code

bull Technologies frameworks languages patterns practices

bull Most of these decisions will be hard to change later

Herbstcampus 2015 23

Gebrauchseignung (Fitness for Purpose)

bull Eine Loumlsung sollte fuumlr den geplanten Zweck geeignet sein

bull Beispiel fuumlr eine User Storybull Titel Alle Autos muumlssen in der Bahnstr 87 halten

bull Beschreibung Als Sicherheitsbeauftragter moumlchte ich dass alle

Autos vor dem Gebaumlude halten sodass keine Teilnehmer verletzt werden

bull Abnahmekriterien

bull Die Loumlsung sollte universell verstaumlndlich sein

bull 247 Verfuumlgbar sein

bull niedrige Betriebskosten haben

Herbstcampus 2015 24

Itrsquos all About Business Value

bull Every sprint should generates an increment of potentially-

shippable business value

bull Therefore

bull It is not ok to have an ldquoarchitecture sprintrdquo

bull It is not ok to have an ldquoinfrastructure sprintrdquo

bull There is no such thing as sprint 0

bull And while wersquore on the topic therersquos no such thing as ldquodone donerdquo

Herbstcampus 2015 25

Donrsquot Over-Architect the Product

bull Build at least one increment of business

functionality every sprint

bull Build enough of the architecture and design to

support that business functionality

bull Build adequate architecture and design to meet any

non-functional requirements

bull Solve todayrsquos problem today tomorrowrsquos

problem tomorrow

Herbstcampus 2015 26

Quizfrage

bull In sprint 3 you start implementing the customer

management component of the web site Yoursquove

committed to delivering basic add edit and view

functionality

bull But you know that in sprint 4 the product

owner is going to want the ability to delete

a customer

bull How should you consider this while

delivering the sprint 3 increment

Herbstcampus 2015 27

Was bedeutet fuumlr uns Qualitaumlt

bull Erfuumlllt es die Anforderungen

bull Erfuumlllt es die Erwartungen

bull Hat es einen Nutzen

bull Ist die Loumlsung fuumlr den Zweck geeignet

bull Sind erforderliche Qualitaumltsattribute eingehalten

Herbstcampus 2015 28

Development Definition of Done

Wann sind wir fertig

bull Explizite Definition of Done (DoD)

bull Konstante (Mindest-)Qualitaumlt

bull Basis fuumlr Schaumltzungen

bull Beeinflusst von unternehmensweiten Richtlinien

bull Messbar

bull Automatisiert

Herbstcampus 2015 29

Example A Simple Definition of Done

1 Coded

2 Acceptance criteria met

3 Tests pass

4 Checked-in

Herbstcampus 2015 30

Be Transparent

bull Everyone should be able to inspect hellipbull The teamrsquos Definition of Done (DoD)

bull The product backlog (user stories)

bull The sprint backlog (tasks)

bull The impediments

bull Deployments

bull Test results

bull Bugs

bull Everyone should adapt to these inspections

Herbstcampus 2015 31

What is Done

Fundamental

bull Code Analysis

bull Coded

bull Refactored

bull Code Reviewed

bull Unit Tested

bull Documented

bull Continuous Build

bull User Acceptance

Mature

bull Design Review

bull Design Refactored

bull Integration Tested

bull Regression Tested

bull Security Tested

bull LoadSoak Tested

bull Scalability Tested

bull Performance Tested

Herbstcampus 2015 32

Unit Tests ndash warum

bull Sicherheitsnetz

bull Weniger Bugs

bull Schoumlneres Design

bull Ermoumlglichen Refactoring

bull Fokus bleibt auf Done

bull Hilft eigentliche Absicht zu dokumentieren

bull Forciert Entwickler uumlber das Ziel nachzudenken

bull Umgehende Belohnung

bull Pruumlft auf die Existenz eines Bugs

Herbstcampus 2015 34

Nur Sauberer Code ist qualitativer Code

bull Sauberer Quellcode erfordert staumlndiges

schonungsloses saumlubern (Refactoring)

bull Niemand sonst wird Deinen Code aufraumlumenbull Kein Zimmer-Servicehellip

bull Broken-Windows-Theorie

Herbstcampus 2015 35

Refactoring

bull The process of improving your code after it has

been written by changing the internal structure of

the code without changing its external behaviorbull In other words improving your code without breaking your

unit tests

bull Refactoring should only be done to add business

value or to meet the teamrsquos definition of Done

Herbstcampus 2015 36

Erfolgsfaktoren

Herbstcampus 2015 37

Tool-Kenntnisse

Application Lifecycle Management (ALM) Tools

Development Environment

Configuration Management

Branching amp Merging

Continuous Integration (CI) Tools

Unit Testing

Measuring Code Quality

Refactoring Tools

Herbstcampus 2015 38

Zusammenfassung

Herbstcampus 2015 39

Professional Scrum Developer Glossary

bull ALM (Application Lifecycle Management)

bull ATDD (Acceptance Test-Driven Development)

bull BDD (Behavior-Driven Development)

bull Branching

bull Clean Code

bull Code Coverage

bull Collective Code Ownership

bull Continuous Delivery

bull Continuous Deployment

bull Continuous Integration (CI)

bull Cyclomatic Complexity

bull Cross-functional

bull Definition of Done

bull Developer

bull DevOps

bull Development Team

bull DRY (donrsquot repeat yourself)

bull Engineering Standards

bull Extreme Programming (XP)

bull Feature Toggle

bull Increment

bull Pair Programming

bull Refactoring

bull Scout Rule

bull Scrum Board

bull Scrum Guidetrade

bull Scrum Team

bull Self-organization

bull Specification by Example

bull TDD (Test-Driven Development)

bull Technical Debt

bull User Story

bull Unit Test

bull Velocity

Quelle httpwwwscrumorgResourcesPSD-Glossary

Herbstcampus 2015 13

Some interesting Tactics

bull Use the Pomodoro Technique

bull Minimize eMail Distractions

bull Implement the Forgiveness Pattern

bull hellip

Herbstcampus 2015 15

Erfolgsfaktoren

Herbstcampus 2015 16

Scrum

Complementary Practices

Scrum

Pair

Programming

User

Stories

Planning

Poker

Relative

Estimation

Release

Planning

Information

Radiators

Just in Time

PlanningCollective

Ownership

Burndown

Charts

Test Driven

DevelopmentCI

Specification

by

Example

BDD

ATDD

Executable

Specifications

Design

Patterns

Reducing

Technical Debt

Build

Automation

Continuous

Deployment

Design for

Operations

Refactoring

Continuous

Delivery

Emergent

Architecture

Clean Code

Pair

Programming

People Practices

Engineering Practices

Scrum Guide

Herbstcampus 2015 17

Professional Scrum Developer-Knowhow

Development Practices

Product Backlog refinement

Relative (team) estimation

Burndowns and Cumulative Flow Charts

Emergent architecture

Continuous Integration (CI)

Test-Driven Development (TDD)

Test Smells

Acceptance testing

Clean coding

Pair Programming

Code Review

Overcoming dysfunction

Scrum

Plan Releases and Sprints

Create Sprint Backlog

Definition of Done

Conduct Sprint Reviews

Reflection in Retrospectives

Herbstcampus 2015 18

Herbstcampus 2015 19

Herbstcampus 2015 20

Big Design Up Front (BDUP)

bull Why Big Design Up Front Seems Goodbull Requirements are better understood

bull Thinking things out ahead of time saves headaches

bull Changes to specs are cheaper than changes to code

bull Bugs are cheaper to fix early

bull Why Big Design Up Front Isnrsquot Goodbull Requirements arenrsquot well known in the first place

bull Requirements change

bull Developers are not able to foresee all problems

bull Customers are not able to tell you what they want

There is no business value in architecture or design

Herbstcampus 2015 21

Where are you today

Waterfall Some DUF

Cowboy

EmergentBDUF

Herbstcampus 2015 22

What is Emergent Architecture

bull The opposite of Big Design Up Front

bull It allows architecture to emerge as you develop

bull Some architectural decisions will need to be made

before you write your first line of code

bull Technologies frameworks languages patterns practices

bull Most of these decisions will be hard to change later

Herbstcampus 2015 23

Gebrauchseignung (Fitness for Purpose)

bull Eine Loumlsung sollte fuumlr den geplanten Zweck geeignet sein

bull Beispiel fuumlr eine User Storybull Titel Alle Autos muumlssen in der Bahnstr 87 halten

bull Beschreibung Als Sicherheitsbeauftragter moumlchte ich dass alle

Autos vor dem Gebaumlude halten sodass keine Teilnehmer verletzt werden

bull Abnahmekriterien

bull Die Loumlsung sollte universell verstaumlndlich sein

bull 247 Verfuumlgbar sein

bull niedrige Betriebskosten haben

Herbstcampus 2015 24

Itrsquos all About Business Value

bull Every sprint should generates an increment of potentially-

shippable business value

bull Therefore

bull It is not ok to have an ldquoarchitecture sprintrdquo

bull It is not ok to have an ldquoinfrastructure sprintrdquo

bull There is no such thing as sprint 0

bull And while wersquore on the topic therersquos no such thing as ldquodone donerdquo

Herbstcampus 2015 25

Donrsquot Over-Architect the Product

bull Build at least one increment of business

functionality every sprint

bull Build enough of the architecture and design to

support that business functionality

bull Build adequate architecture and design to meet any

non-functional requirements

bull Solve todayrsquos problem today tomorrowrsquos

problem tomorrow

Herbstcampus 2015 26

Quizfrage

bull In sprint 3 you start implementing the customer

management component of the web site Yoursquove

committed to delivering basic add edit and view

functionality

bull But you know that in sprint 4 the product

owner is going to want the ability to delete

a customer

bull How should you consider this while

delivering the sprint 3 increment

Herbstcampus 2015 27

Was bedeutet fuumlr uns Qualitaumlt

bull Erfuumlllt es die Anforderungen

bull Erfuumlllt es die Erwartungen

bull Hat es einen Nutzen

bull Ist die Loumlsung fuumlr den Zweck geeignet

bull Sind erforderliche Qualitaumltsattribute eingehalten

Herbstcampus 2015 28

Development Definition of Done

Wann sind wir fertig

bull Explizite Definition of Done (DoD)

bull Konstante (Mindest-)Qualitaumlt

bull Basis fuumlr Schaumltzungen

bull Beeinflusst von unternehmensweiten Richtlinien

bull Messbar

bull Automatisiert

Herbstcampus 2015 29

Example A Simple Definition of Done

1 Coded

2 Acceptance criteria met

3 Tests pass

4 Checked-in

Herbstcampus 2015 30

Be Transparent

bull Everyone should be able to inspect hellipbull The teamrsquos Definition of Done (DoD)

bull The product backlog (user stories)

bull The sprint backlog (tasks)

bull The impediments

bull Deployments

bull Test results

bull Bugs

bull Everyone should adapt to these inspections

Herbstcampus 2015 31

What is Done

Fundamental

bull Code Analysis

bull Coded

bull Refactored

bull Code Reviewed

bull Unit Tested

bull Documented

bull Continuous Build

bull User Acceptance

Mature

bull Design Review

bull Design Refactored

bull Integration Tested

bull Regression Tested

bull Security Tested

bull LoadSoak Tested

bull Scalability Tested

bull Performance Tested

Herbstcampus 2015 32

Unit Tests ndash warum

bull Sicherheitsnetz

bull Weniger Bugs

bull Schoumlneres Design

bull Ermoumlglichen Refactoring

bull Fokus bleibt auf Done

bull Hilft eigentliche Absicht zu dokumentieren

bull Forciert Entwickler uumlber das Ziel nachzudenken

bull Umgehende Belohnung

bull Pruumlft auf die Existenz eines Bugs

Herbstcampus 2015 34

Nur Sauberer Code ist qualitativer Code

bull Sauberer Quellcode erfordert staumlndiges

schonungsloses saumlubern (Refactoring)

bull Niemand sonst wird Deinen Code aufraumlumenbull Kein Zimmer-Servicehellip

bull Broken-Windows-Theorie

Herbstcampus 2015 35

Refactoring

bull The process of improving your code after it has

been written by changing the internal structure of

the code without changing its external behaviorbull In other words improving your code without breaking your

unit tests

bull Refactoring should only be done to add business

value or to meet the teamrsquos definition of Done

Herbstcampus 2015 36

Erfolgsfaktoren

Herbstcampus 2015 37

Tool-Kenntnisse

Application Lifecycle Management (ALM) Tools

Development Environment

Configuration Management

Branching amp Merging

Continuous Integration (CI) Tools

Unit Testing

Measuring Code Quality

Refactoring Tools

Herbstcampus 2015 38

Zusammenfassung

Herbstcampus 2015 39

Professional Scrum Developer Glossary

bull ALM (Application Lifecycle Management)

bull ATDD (Acceptance Test-Driven Development)

bull BDD (Behavior-Driven Development)

bull Branching

bull Clean Code

bull Code Coverage

bull Collective Code Ownership

bull Continuous Delivery

bull Continuous Deployment

bull Continuous Integration (CI)

bull Cyclomatic Complexity

bull Cross-functional

bull Definition of Done

bull Developer

bull DevOps

bull Development Team

bull DRY (donrsquot repeat yourself)

bull Engineering Standards

bull Extreme Programming (XP)

bull Feature Toggle

bull Increment

bull Pair Programming

bull Refactoring

bull Scout Rule

bull Scrum Board

bull Scrum Guidetrade

bull Scrum Team

bull Self-organization

bull Specification by Example

bull TDD (Test-Driven Development)

bull Technical Debt

bull User Story

bull Unit Test

bull Velocity

Quelle httpwwwscrumorgResourcesPSD-Glossary

Herbstcampus 2015 15

Erfolgsfaktoren

Herbstcampus 2015 16

Scrum

Complementary Practices

Scrum

Pair

Programming

User

Stories

Planning

Poker

Relative

Estimation

Release

Planning

Information

Radiators

Just in Time

PlanningCollective

Ownership

Burndown

Charts

Test Driven

DevelopmentCI

Specification

by

Example

BDD

ATDD

Executable

Specifications

Design

Patterns

Reducing

Technical Debt

Build

Automation

Continuous

Deployment

Design for

Operations

Refactoring

Continuous

Delivery

Emergent

Architecture

Clean Code

Pair

Programming

People Practices

Engineering Practices

Scrum Guide

Herbstcampus 2015 17

Professional Scrum Developer-Knowhow

Development Practices

Product Backlog refinement

Relative (team) estimation

Burndowns and Cumulative Flow Charts

Emergent architecture

Continuous Integration (CI)

Test-Driven Development (TDD)

Test Smells

Acceptance testing

Clean coding

Pair Programming

Code Review

Overcoming dysfunction

Scrum

Plan Releases and Sprints

Create Sprint Backlog

Definition of Done

Conduct Sprint Reviews

Reflection in Retrospectives

Herbstcampus 2015 18

Herbstcampus 2015 19

Herbstcampus 2015 20

Big Design Up Front (BDUP)

bull Why Big Design Up Front Seems Goodbull Requirements are better understood

bull Thinking things out ahead of time saves headaches

bull Changes to specs are cheaper than changes to code

bull Bugs are cheaper to fix early

bull Why Big Design Up Front Isnrsquot Goodbull Requirements arenrsquot well known in the first place

bull Requirements change

bull Developers are not able to foresee all problems

bull Customers are not able to tell you what they want

There is no business value in architecture or design

Herbstcampus 2015 21

Where are you today

Waterfall Some DUF

Cowboy

EmergentBDUF

Herbstcampus 2015 22

What is Emergent Architecture

bull The opposite of Big Design Up Front

bull It allows architecture to emerge as you develop

bull Some architectural decisions will need to be made

before you write your first line of code

bull Technologies frameworks languages patterns practices

bull Most of these decisions will be hard to change later

Herbstcampus 2015 23

Gebrauchseignung (Fitness for Purpose)

bull Eine Loumlsung sollte fuumlr den geplanten Zweck geeignet sein

bull Beispiel fuumlr eine User Storybull Titel Alle Autos muumlssen in der Bahnstr 87 halten

bull Beschreibung Als Sicherheitsbeauftragter moumlchte ich dass alle

Autos vor dem Gebaumlude halten sodass keine Teilnehmer verletzt werden

bull Abnahmekriterien

bull Die Loumlsung sollte universell verstaumlndlich sein

bull 247 Verfuumlgbar sein

bull niedrige Betriebskosten haben

Herbstcampus 2015 24

Itrsquos all About Business Value

bull Every sprint should generates an increment of potentially-

shippable business value

bull Therefore

bull It is not ok to have an ldquoarchitecture sprintrdquo

bull It is not ok to have an ldquoinfrastructure sprintrdquo

bull There is no such thing as sprint 0

bull And while wersquore on the topic therersquos no such thing as ldquodone donerdquo

Herbstcampus 2015 25

Donrsquot Over-Architect the Product

bull Build at least one increment of business

functionality every sprint

bull Build enough of the architecture and design to

support that business functionality

bull Build adequate architecture and design to meet any

non-functional requirements

bull Solve todayrsquos problem today tomorrowrsquos

problem tomorrow

Herbstcampus 2015 26

Quizfrage

bull In sprint 3 you start implementing the customer

management component of the web site Yoursquove

committed to delivering basic add edit and view

functionality

bull But you know that in sprint 4 the product

owner is going to want the ability to delete

a customer

bull How should you consider this while

delivering the sprint 3 increment

Herbstcampus 2015 27

Was bedeutet fuumlr uns Qualitaumlt

bull Erfuumlllt es die Anforderungen

bull Erfuumlllt es die Erwartungen

bull Hat es einen Nutzen

bull Ist die Loumlsung fuumlr den Zweck geeignet

bull Sind erforderliche Qualitaumltsattribute eingehalten

Herbstcampus 2015 28

Development Definition of Done

Wann sind wir fertig

bull Explizite Definition of Done (DoD)

bull Konstante (Mindest-)Qualitaumlt

bull Basis fuumlr Schaumltzungen

bull Beeinflusst von unternehmensweiten Richtlinien

bull Messbar

bull Automatisiert

Herbstcampus 2015 29

Example A Simple Definition of Done

1 Coded

2 Acceptance criteria met

3 Tests pass

4 Checked-in

Herbstcampus 2015 30

Be Transparent

bull Everyone should be able to inspect hellipbull The teamrsquos Definition of Done (DoD)

bull The product backlog (user stories)

bull The sprint backlog (tasks)

bull The impediments

bull Deployments

bull Test results

bull Bugs

bull Everyone should adapt to these inspections

Herbstcampus 2015 31

What is Done

Fundamental

bull Code Analysis

bull Coded

bull Refactored

bull Code Reviewed

bull Unit Tested

bull Documented

bull Continuous Build

bull User Acceptance

Mature

bull Design Review

bull Design Refactored

bull Integration Tested

bull Regression Tested

bull Security Tested

bull LoadSoak Tested

bull Scalability Tested

bull Performance Tested

Herbstcampus 2015 32

Unit Tests ndash warum

bull Sicherheitsnetz

bull Weniger Bugs

bull Schoumlneres Design

bull Ermoumlglichen Refactoring

bull Fokus bleibt auf Done

bull Hilft eigentliche Absicht zu dokumentieren

bull Forciert Entwickler uumlber das Ziel nachzudenken

bull Umgehende Belohnung

bull Pruumlft auf die Existenz eines Bugs

Herbstcampus 2015 34

Nur Sauberer Code ist qualitativer Code

bull Sauberer Quellcode erfordert staumlndiges

schonungsloses saumlubern (Refactoring)

bull Niemand sonst wird Deinen Code aufraumlumenbull Kein Zimmer-Servicehellip

bull Broken-Windows-Theorie

Herbstcampus 2015 35

Refactoring

bull The process of improving your code after it has

been written by changing the internal structure of

the code without changing its external behaviorbull In other words improving your code without breaking your

unit tests

bull Refactoring should only be done to add business

value or to meet the teamrsquos definition of Done

Herbstcampus 2015 36

Erfolgsfaktoren

Herbstcampus 2015 37

Tool-Kenntnisse

Application Lifecycle Management (ALM) Tools

Development Environment

Configuration Management

Branching amp Merging

Continuous Integration (CI) Tools

Unit Testing

Measuring Code Quality

Refactoring Tools

Herbstcampus 2015 38

Zusammenfassung

Herbstcampus 2015 39

Professional Scrum Developer Glossary

bull ALM (Application Lifecycle Management)

bull ATDD (Acceptance Test-Driven Development)

bull BDD (Behavior-Driven Development)

bull Branching

bull Clean Code

bull Code Coverage

bull Collective Code Ownership

bull Continuous Delivery

bull Continuous Deployment

bull Continuous Integration (CI)

bull Cyclomatic Complexity

bull Cross-functional

bull Definition of Done

bull Developer

bull DevOps

bull Development Team

bull DRY (donrsquot repeat yourself)

bull Engineering Standards

bull Extreme Programming (XP)

bull Feature Toggle

bull Increment

bull Pair Programming

bull Refactoring

bull Scout Rule

bull Scrum Board

bull Scrum Guidetrade

bull Scrum Team

bull Self-organization

bull Specification by Example

bull TDD (Test-Driven Development)

bull Technical Debt

bull User Story

bull Unit Test

bull Velocity

Quelle httpwwwscrumorgResourcesPSD-Glossary

Herbstcampus 2015 16

Scrum

Complementary Practices

Scrum

Pair

Programming

User

Stories

Planning

Poker

Relative

Estimation

Release

Planning

Information

Radiators

Just in Time

PlanningCollective

Ownership

Burndown

Charts

Test Driven

DevelopmentCI

Specification

by

Example

BDD

ATDD

Executable

Specifications

Design

Patterns

Reducing

Technical Debt

Build

Automation

Continuous

Deployment

Design for

Operations

Refactoring

Continuous

Delivery

Emergent

Architecture

Clean Code

Pair

Programming

People Practices

Engineering Practices

Scrum Guide

Herbstcampus 2015 17

Professional Scrum Developer-Knowhow

Development Practices

Product Backlog refinement

Relative (team) estimation

Burndowns and Cumulative Flow Charts

Emergent architecture

Continuous Integration (CI)

Test-Driven Development (TDD)

Test Smells

Acceptance testing

Clean coding

Pair Programming

Code Review

Overcoming dysfunction

Scrum

Plan Releases and Sprints

Create Sprint Backlog

Definition of Done

Conduct Sprint Reviews

Reflection in Retrospectives

Herbstcampus 2015 18

Herbstcampus 2015 19

Herbstcampus 2015 20

Big Design Up Front (BDUP)

bull Why Big Design Up Front Seems Goodbull Requirements are better understood

bull Thinking things out ahead of time saves headaches

bull Changes to specs are cheaper than changes to code

bull Bugs are cheaper to fix early

bull Why Big Design Up Front Isnrsquot Goodbull Requirements arenrsquot well known in the first place

bull Requirements change

bull Developers are not able to foresee all problems

bull Customers are not able to tell you what they want

There is no business value in architecture or design

Herbstcampus 2015 21

Where are you today

Waterfall Some DUF

Cowboy

EmergentBDUF

Herbstcampus 2015 22

What is Emergent Architecture

bull The opposite of Big Design Up Front

bull It allows architecture to emerge as you develop

bull Some architectural decisions will need to be made

before you write your first line of code

bull Technologies frameworks languages patterns practices

bull Most of these decisions will be hard to change later

Herbstcampus 2015 23

Gebrauchseignung (Fitness for Purpose)

bull Eine Loumlsung sollte fuumlr den geplanten Zweck geeignet sein

bull Beispiel fuumlr eine User Storybull Titel Alle Autos muumlssen in der Bahnstr 87 halten

bull Beschreibung Als Sicherheitsbeauftragter moumlchte ich dass alle

Autos vor dem Gebaumlude halten sodass keine Teilnehmer verletzt werden

bull Abnahmekriterien

bull Die Loumlsung sollte universell verstaumlndlich sein

bull 247 Verfuumlgbar sein

bull niedrige Betriebskosten haben

Herbstcampus 2015 24

Itrsquos all About Business Value

bull Every sprint should generates an increment of potentially-

shippable business value

bull Therefore

bull It is not ok to have an ldquoarchitecture sprintrdquo

bull It is not ok to have an ldquoinfrastructure sprintrdquo

bull There is no such thing as sprint 0

bull And while wersquore on the topic therersquos no such thing as ldquodone donerdquo

Herbstcampus 2015 25

Donrsquot Over-Architect the Product

bull Build at least one increment of business

functionality every sprint

bull Build enough of the architecture and design to

support that business functionality

bull Build adequate architecture and design to meet any

non-functional requirements

bull Solve todayrsquos problem today tomorrowrsquos

problem tomorrow

Herbstcampus 2015 26

Quizfrage

bull In sprint 3 you start implementing the customer

management component of the web site Yoursquove

committed to delivering basic add edit and view

functionality

bull But you know that in sprint 4 the product

owner is going to want the ability to delete

a customer

bull How should you consider this while

delivering the sprint 3 increment

Herbstcampus 2015 27

Was bedeutet fuumlr uns Qualitaumlt

bull Erfuumlllt es die Anforderungen

bull Erfuumlllt es die Erwartungen

bull Hat es einen Nutzen

bull Ist die Loumlsung fuumlr den Zweck geeignet

bull Sind erforderliche Qualitaumltsattribute eingehalten

Herbstcampus 2015 28

Development Definition of Done

Wann sind wir fertig

bull Explizite Definition of Done (DoD)

bull Konstante (Mindest-)Qualitaumlt

bull Basis fuumlr Schaumltzungen

bull Beeinflusst von unternehmensweiten Richtlinien

bull Messbar

bull Automatisiert

Herbstcampus 2015 29

Example A Simple Definition of Done

1 Coded

2 Acceptance criteria met

3 Tests pass

4 Checked-in

Herbstcampus 2015 30

Be Transparent

bull Everyone should be able to inspect hellipbull The teamrsquos Definition of Done (DoD)

bull The product backlog (user stories)

bull The sprint backlog (tasks)

bull The impediments

bull Deployments

bull Test results

bull Bugs

bull Everyone should adapt to these inspections

Herbstcampus 2015 31

What is Done

Fundamental

bull Code Analysis

bull Coded

bull Refactored

bull Code Reviewed

bull Unit Tested

bull Documented

bull Continuous Build

bull User Acceptance

Mature

bull Design Review

bull Design Refactored

bull Integration Tested

bull Regression Tested

bull Security Tested

bull LoadSoak Tested

bull Scalability Tested

bull Performance Tested

Herbstcampus 2015 32

Unit Tests ndash warum

bull Sicherheitsnetz

bull Weniger Bugs

bull Schoumlneres Design

bull Ermoumlglichen Refactoring

bull Fokus bleibt auf Done

bull Hilft eigentliche Absicht zu dokumentieren

bull Forciert Entwickler uumlber das Ziel nachzudenken

bull Umgehende Belohnung

bull Pruumlft auf die Existenz eines Bugs

Herbstcampus 2015 34

Nur Sauberer Code ist qualitativer Code

bull Sauberer Quellcode erfordert staumlndiges

schonungsloses saumlubern (Refactoring)

bull Niemand sonst wird Deinen Code aufraumlumenbull Kein Zimmer-Servicehellip

bull Broken-Windows-Theorie

Herbstcampus 2015 35

Refactoring

bull The process of improving your code after it has

been written by changing the internal structure of

the code without changing its external behaviorbull In other words improving your code without breaking your

unit tests

bull Refactoring should only be done to add business

value or to meet the teamrsquos definition of Done

Herbstcampus 2015 36

Erfolgsfaktoren

Herbstcampus 2015 37

Tool-Kenntnisse

Application Lifecycle Management (ALM) Tools

Development Environment

Configuration Management

Branching amp Merging

Continuous Integration (CI) Tools

Unit Testing

Measuring Code Quality

Refactoring Tools

Herbstcampus 2015 38

Zusammenfassung

Herbstcampus 2015 39

Professional Scrum Developer Glossary

bull ALM (Application Lifecycle Management)

bull ATDD (Acceptance Test-Driven Development)

bull BDD (Behavior-Driven Development)

bull Branching

bull Clean Code

bull Code Coverage

bull Collective Code Ownership

bull Continuous Delivery

bull Continuous Deployment

bull Continuous Integration (CI)

bull Cyclomatic Complexity

bull Cross-functional

bull Definition of Done

bull Developer

bull DevOps

bull Development Team

bull DRY (donrsquot repeat yourself)

bull Engineering Standards

bull Extreme Programming (XP)

bull Feature Toggle

bull Increment

bull Pair Programming

bull Refactoring

bull Scout Rule

bull Scrum Board

bull Scrum Guidetrade

bull Scrum Team

bull Self-organization

bull Specification by Example

bull TDD (Test-Driven Development)

bull Technical Debt

bull User Story

bull Unit Test

bull Velocity

Quelle httpwwwscrumorgResourcesPSD-Glossary

Herbstcampus 2015 17

Professional Scrum Developer-Knowhow

Development Practices

Product Backlog refinement

Relative (team) estimation

Burndowns and Cumulative Flow Charts

Emergent architecture

Continuous Integration (CI)

Test-Driven Development (TDD)

Test Smells

Acceptance testing

Clean coding

Pair Programming

Code Review

Overcoming dysfunction

Scrum

Plan Releases and Sprints

Create Sprint Backlog

Definition of Done

Conduct Sprint Reviews

Reflection in Retrospectives

Herbstcampus 2015 18

Herbstcampus 2015 19

Herbstcampus 2015 20

Big Design Up Front (BDUP)

bull Why Big Design Up Front Seems Goodbull Requirements are better understood

bull Thinking things out ahead of time saves headaches

bull Changes to specs are cheaper than changes to code

bull Bugs are cheaper to fix early

bull Why Big Design Up Front Isnrsquot Goodbull Requirements arenrsquot well known in the first place

bull Requirements change

bull Developers are not able to foresee all problems

bull Customers are not able to tell you what they want

There is no business value in architecture or design

Herbstcampus 2015 21

Where are you today

Waterfall Some DUF

Cowboy

EmergentBDUF

Herbstcampus 2015 22

What is Emergent Architecture

bull The opposite of Big Design Up Front

bull It allows architecture to emerge as you develop

bull Some architectural decisions will need to be made

before you write your first line of code

bull Technologies frameworks languages patterns practices

bull Most of these decisions will be hard to change later

Herbstcampus 2015 23

Gebrauchseignung (Fitness for Purpose)

bull Eine Loumlsung sollte fuumlr den geplanten Zweck geeignet sein

bull Beispiel fuumlr eine User Storybull Titel Alle Autos muumlssen in der Bahnstr 87 halten

bull Beschreibung Als Sicherheitsbeauftragter moumlchte ich dass alle

Autos vor dem Gebaumlude halten sodass keine Teilnehmer verletzt werden

bull Abnahmekriterien

bull Die Loumlsung sollte universell verstaumlndlich sein

bull 247 Verfuumlgbar sein

bull niedrige Betriebskosten haben

Herbstcampus 2015 24

Itrsquos all About Business Value

bull Every sprint should generates an increment of potentially-

shippable business value

bull Therefore

bull It is not ok to have an ldquoarchitecture sprintrdquo

bull It is not ok to have an ldquoinfrastructure sprintrdquo

bull There is no such thing as sprint 0

bull And while wersquore on the topic therersquos no such thing as ldquodone donerdquo

Herbstcampus 2015 25

Donrsquot Over-Architect the Product

bull Build at least one increment of business

functionality every sprint

bull Build enough of the architecture and design to

support that business functionality

bull Build adequate architecture and design to meet any

non-functional requirements

bull Solve todayrsquos problem today tomorrowrsquos

problem tomorrow

Herbstcampus 2015 26

Quizfrage

bull In sprint 3 you start implementing the customer

management component of the web site Yoursquove

committed to delivering basic add edit and view

functionality

bull But you know that in sprint 4 the product

owner is going to want the ability to delete

a customer

bull How should you consider this while

delivering the sprint 3 increment

Herbstcampus 2015 27

Was bedeutet fuumlr uns Qualitaumlt

bull Erfuumlllt es die Anforderungen

bull Erfuumlllt es die Erwartungen

bull Hat es einen Nutzen

bull Ist die Loumlsung fuumlr den Zweck geeignet

bull Sind erforderliche Qualitaumltsattribute eingehalten

Herbstcampus 2015 28

Development Definition of Done

Wann sind wir fertig

bull Explizite Definition of Done (DoD)

bull Konstante (Mindest-)Qualitaumlt

bull Basis fuumlr Schaumltzungen

bull Beeinflusst von unternehmensweiten Richtlinien

bull Messbar

bull Automatisiert

Herbstcampus 2015 29

Example A Simple Definition of Done

1 Coded

2 Acceptance criteria met

3 Tests pass

4 Checked-in

Herbstcampus 2015 30

Be Transparent

bull Everyone should be able to inspect hellipbull The teamrsquos Definition of Done (DoD)

bull The product backlog (user stories)

bull The sprint backlog (tasks)

bull The impediments

bull Deployments

bull Test results

bull Bugs

bull Everyone should adapt to these inspections

Herbstcampus 2015 31

What is Done

Fundamental

bull Code Analysis

bull Coded

bull Refactored

bull Code Reviewed

bull Unit Tested

bull Documented

bull Continuous Build

bull User Acceptance

Mature

bull Design Review

bull Design Refactored

bull Integration Tested

bull Regression Tested

bull Security Tested

bull LoadSoak Tested

bull Scalability Tested

bull Performance Tested

Herbstcampus 2015 32

Unit Tests ndash warum

bull Sicherheitsnetz

bull Weniger Bugs

bull Schoumlneres Design

bull Ermoumlglichen Refactoring

bull Fokus bleibt auf Done

bull Hilft eigentliche Absicht zu dokumentieren

bull Forciert Entwickler uumlber das Ziel nachzudenken

bull Umgehende Belohnung

bull Pruumlft auf die Existenz eines Bugs

Herbstcampus 2015 34

Nur Sauberer Code ist qualitativer Code

bull Sauberer Quellcode erfordert staumlndiges

schonungsloses saumlubern (Refactoring)

bull Niemand sonst wird Deinen Code aufraumlumenbull Kein Zimmer-Servicehellip

bull Broken-Windows-Theorie

Herbstcampus 2015 35

Refactoring

bull The process of improving your code after it has

been written by changing the internal structure of

the code without changing its external behaviorbull In other words improving your code without breaking your

unit tests

bull Refactoring should only be done to add business

value or to meet the teamrsquos definition of Done

Herbstcampus 2015 36

Erfolgsfaktoren

Herbstcampus 2015 37

Tool-Kenntnisse

Application Lifecycle Management (ALM) Tools

Development Environment

Configuration Management

Branching amp Merging

Continuous Integration (CI) Tools

Unit Testing

Measuring Code Quality

Refactoring Tools

Herbstcampus 2015 38

Zusammenfassung

Herbstcampus 2015 39

Professional Scrum Developer Glossary

bull ALM (Application Lifecycle Management)

bull ATDD (Acceptance Test-Driven Development)

bull BDD (Behavior-Driven Development)

bull Branching

bull Clean Code

bull Code Coverage

bull Collective Code Ownership

bull Continuous Delivery

bull Continuous Deployment

bull Continuous Integration (CI)

bull Cyclomatic Complexity

bull Cross-functional

bull Definition of Done

bull Developer

bull DevOps

bull Development Team

bull DRY (donrsquot repeat yourself)

bull Engineering Standards

bull Extreme Programming (XP)

bull Feature Toggle

bull Increment

bull Pair Programming

bull Refactoring

bull Scout Rule

bull Scrum Board

bull Scrum Guidetrade

bull Scrum Team

bull Self-organization

bull Specification by Example

bull TDD (Test-Driven Development)

bull Technical Debt

bull User Story

bull Unit Test

bull Velocity

Quelle httpwwwscrumorgResourcesPSD-Glossary

Herbstcampus 2015 18

Herbstcampus 2015 19

Herbstcampus 2015 20

Big Design Up Front (BDUP)

bull Why Big Design Up Front Seems Goodbull Requirements are better understood

bull Thinking things out ahead of time saves headaches

bull Changes to specs are cheaper than changes to code

bull Bugs are cheaper to fix early

bull Why Big Design Up Front Isnrsquot Goodbull Requirements arenrsquot well known in the first place

bull Requirements change

bull Developers are not able to foresee all problems

bull Customers are not able to tell you what they want

There is no business value in architecture or design

Herbstcampus 2015 21

Where are you today

Waterfall Some DUF

Cowboy

EmergentBDUF

Herbstcampus 2015 22

What is Emergent Architecture

bull The opposite of Big Design Up Front

bull It allows architecture to emerge as you develop

bull Some architectural decisions will need to be made

before you write your first line of code

bull Technologies frameworks languages patterns practices

bull Most of these decisions will be hard to change later

Herbstcampus 2015 23

Gebrauchseignung (Fitness for Purpose)

bull Eine Loumlsung sollte fuumlr den geplanten Zweck geeignet sein

bull Beispiel fuumlr eine User Storybull Titel Alle Autos muumlssen in der Bahnstr 87 halten

bull Beschreibung Als Sicherheitsbeauftragter moumlchte ich dass alle

Autos vor dem Gebaumlude halten sodass keine Teilnehmer verletzt werden

bull Abnahmekriterien

bull Die Loumlsung sollte universell verstaumlndlich sein

bull 247 Verfuumlgbar sein

bull niedrige Betriebskosten haben

Herbstcampus 2015 24

Itrsquos all About Business Value

bull Every sprint should generates an increment of potentially-

shippable business value

bull Therefore

bull It is not ok to have an ldquoarchitecture sprintrdquo

bull It is not ok to have an ldquoinfrastructure sprintrdquo

bull There is no such thing as sprint 0

bull And while wersquore on the topic therersquos no such thing as ldquodone donerdquo

Herbstcampus 2015 25

Donrsquot Over-Architect the Product

bull Build at least one increment of business

functionality every sprint

bull Build enough of the architecture and design to

support that business functionality

bull Build adequate architecture and design to meet any

non-functional requirements

bull Solve todayrsquos problem today tomorrowrsquos

problem tomorrow

Herbstcampus 2015 26

Quizfrage

bull In sprint 3 you start implementing the customer

management component of the web site Yoursquove

committed to delivering basic add edit and view

functionality

bull But you know that in sprint 4 the product

owner is going to want the ability to delete

a customer

bull How should you consider this while

delivering the sprint 3 increment

Herbstcampus 2015 27

Was bedeutet fuumlr uns Qualitaumlt

bull Erfuumlllt es die Anforderungen

bull Erfuumlllt es die Erwartungen

bull Hat es einen Nutzen

bull Ist die Loumlsung fuumlr den Zweck geeignet

bull Sind erforderliche Qualitaumltsattribute eingehalten

Herbstcampus 2015 28

Development Definition of Done

Wann sind wir fertig

bull Explizite Definition of Done (DoD)

bull Konstante (Mindest-)Qualitaumlt

bull Basis fuumlr Schaumltzungen

bull Beeinflusst von unternehmensweiten Richtlinien

bull Messbar

bull Automatisiert

Herbstcampus 2015 29

Example A Simple Definition of Done

1 Coded

2 Acceptance criteria met

3 Tests pass

4 Checked-in

Herbstcampus 2015 30

Be Transparent

bull Everyone should be able to inspect hellipbull The teamrsquos Definition of Done (DoD)

bull The product backlog (user stories)

bull The sprint backlog (tasks)

bull The impediments

bull Deployments

bull Test results

bull Bugs

bull Everyone should adapt to these inspections

Herbstcampus 2015 31

What is Done

Fundamental

bull Code Analysis

bull Coded

bull Refactored

bull Code Reviewed

bull Unit Tested

bull Documented

bull Continuous Build

bull User Acceptance

Mature

bull Design Review

bull Design Refactored

bull Integration Tested

bull Regression Tested

bull Security Tested

bull LoadSoak Tested

bull Scalability Tested

bull Performance Tested

Herbstcampus 2015 32

Unit Tests ndash warum

bull Sicherheitsnetz

bull Weniger Bugs

bull Schoumlneres Design

bull Ermoumlglichen Refactoring

bull Fokus bleibt auf Done

bull Hilft eigentliche Absicht zu dokumentieren

bull Forciert Entwickler uumlber das Ziel nachzudenken

bull Umgehende Belohnung

bull Pruumlft auf die Existenz eines Bugs

Herbstcampus 2015 34

Nur Sauberer Code ist qualitativer Code

bull Sauberer Quellcode erfordert staumlndiges

schonungsloses saumlubern (Refactoring)

bull Niemand sonst wird Deinen Code aufraumlumenbull Kein Zimmer-Servicehellip

bull Broken-Windows-Theorie

Herbstcampus 2015 35

Refactoring

bull The process of improving your code after it has

been written by changing the internal structure of

the code without changing its external behaviorbull In other words improving your code without breaking your

unit tests

bull Refactoring should only be done to add business

value or to meet the teamrsquos definition of Done

Herbstcampus 2015 36

Erfolgsfaktoren

Herbstcampus 2015 37

Tool-Kenntnisse

Application Lifecycle Management (ALM) Tools

Development Environment

Configuration Management

Branching amp Merging

Continuous Integration (CI) Tools

Unit Testing

Measuring Code Quality

Refactoring Tools

Herbstcampus 2015 38

Zusammenfassung

Herbstcampus 2015 39

Professional Scrum Developer Glossary

bull ALM (Application Lifecycle Management)

bull ATDD (Acceptance Test-Driven Development)

bull BDD (Behavior-Driven Development)

bull Branching

bull Clean Code

bull Code Coverage

bull Collective Code Ownership

bull Continuous Delivery

bull Continuous Deployment

bull Continuous Integration (CI)

bull Cyclomatic Complexity

bull Cross-functional

bull Definition of Done

bull Developer

bull DevOps

bull Development Team

bull DRY (donrsquot repeat yourself)

bull Engineering Standards

bull Extreme Programming (XP)

bull Feature Toggle

bull Increment

bull Pair Programming

bull Refactoring

bull Scout Rule

bull Scrum Board

bull Scrum Guidetrade

bull Scrum Team

bull Self-organization

bull Specification by Example

bull TDD (Test-Driven Development)

bull Technical Debt

bull User Story

bull Unit Test

bull Velocity

Quelle httpwwwscrumorgResourcesPSD-Glossary

Herbstcampus 2015 19

Herbstcampus 2015 20

Big Design Up Front (BDUP)

bull Why Big Design Up Front Seems Goodbull Requirements are better understood

bull Thinking things out ahead of time saves headaches

bull Changes to specs are cheaper than changes to code

bull Bugs are cheaper to fix early

bull Why Big Design Up Front Isnrsquot Goodbull Requirements arenrsquot well known in the first place

bull Requirements change

bull Developers are not able to foresee all problems

bull Customers are not able to tell you what they want

There is no business value in architecture or design

Herbstcampus 2015 21

Where are you today

Waterfall Some DUF

Cowboy

EmergentBDUF

Herbstcampus 2015 22

What is Emergent Architecture

bull The opposite of Big Design Up Front

bull It allows architecture to emerge as you develop

bull Some architectural decisions will need to be made

before you write your first line of code

bull Technologies frameworks languages patterns practices

bull Most of these decisions will be hard to change later

Herbstcampus 2015 23

Gebrauchseignung (Fitness for Purpose)

bull Eine Loumlsung sollte fuumlr den geplanten Zweck geeignet sein

bull Beispiel fuumlr eine User Storybull Titel Alle Autos muumlssen in der Bahnstr 87 halten

bull Beschreibung Als Sicherheitsbeauftragter moumlchte ich dass alle

Autos vor dem Gebaumlude halten sodass keine Teilnehmer verletzt werden

bull Abnahmekriterien

bull Die Loumlsung sollte universell verstaumlndlich sein

bull 247 Verfuumlgbar sein

bull niedrige Betriebskosten haben

Herbstcampus 2015 24

Itrsquos all About Business Value

bull Every sprint should generates an increment of potentially-

shippable business value

bull Therefore

bull It is not ok to have an ldquoarchitecture sprintrdquo

bull It is not ok to have an ldquoinfrastructure sprintrdquo

bull There is no such thing as sprint 0

bull And while wersquore on the topic therersquos no such thing as ldquodone donerdquo

Herbstcampus 2015 25

Donrsquot Over-Architect the Product

bull Build at least one increment of business

functionality every sprint

bull Build enough of the architecture and design to

support that business functionality

bull Build adequate architecture and design to meet any

non-functional requirements

bull Solve todayrsquos problem today tomorrowrsquos

problem tomorrow

Herbstcampus 2015 26

Quizfrage

bull In sprint 3 you start implementing the customer

management component of the web site Yoursquove

committed to delivering basic add edit and view

functionality

bull But you know that in sprint 4 the product

owner is going to want the ability to delete

a customer

bull How should you consider this while

delivering the sprint 3 increment

Herbstcampus 2015 27

Was bedeutet fuumlr uns Qualitaumlt

bull Erfuumlllt es die Anforderungen

bull Erfuumlllt es die Erwartungen

bull Hat es einen Nutzen

bull Ist die Loumlsung fuumlr den Zweck geeignet

bull Sind erforderliche Qualitaumltsattribute eingehalten

Herbstcampus 2015 28

Development Definition of Done

Wann sind wir fertig

bull Explizite Definition of Done (DoD)

bull Konstante (Mindest-)Qualitaumlt

bull Basis fuumlr Schaumltzungen

bull Beeinflusst von unternehmensweiten Richtlinien

bull Messbar

bull Automatisiert

Herbstcampus 2015 29

Example A Simple Definition of Done

1 Coded

2 Acceptance criteria met

3 Tests pass

4 Checked-in

Herbstcampus 2015 30

Be Transparent

bull Everyone should be able to inspect hellipbull The teamrsquos Definition of Done (DoD)

bull The product backlog (user stories)

bull The sprint backlog (tasks)

bull The impediments

bull Deployments

bull Test results

bull Bugs

bull Everyone should adapt to these inspections

Herbstcampus 2015 31

What is Done

Fundamental

bull Code Analysis

bull Coded

bull Refactored

bull Code Reviewed

bull Unit Tested

bull Documented

bull Continuous Build

bull User Acceptance

Mature

bull Design Review

bull Design Refactored

bull Integration Tested

bull Regression Tested

bull Security Tested

bull LoadSoak Tested

bull Scalability Tested

bull Performance Tested

Herbstcampus 2015 32

Unit Tests ndash warum

bull Sicherheitsnetz

bull Weniger Bugs

bull Schoumlneres Design

bull Ermoumlglichen Refactoring

bull Fokus bleibt auf Done

bull Hilft eigentliche Absicht zu dokumentieren

bull Forciert Entwickler uumlber das Ziel nachzudenken

bull Umgehende Belohnung

bull Pruumlft auf die Existenz eines Bugs

Herbstcampus 2015 34

Nur Sauberer Code ist qualitativer Code

bull Sauberer Quellcode erfordert staumlndiges

schonungsloses saumlubern (Refactoring)

bull Niemand sonst wird Deinen Code aufraumlumenbull Kein Zimmer-Servicehellip

bull Broken-Windows-Theorie

Herbstcampus 2015 35

Refactoring

bull The process of improving your code after it has

been written by changing the internal structure of

the code without changing its external behaviorbull In other words improving your code without breaking your

unit tests

bull Refactoring should only be done to add business

value or to meet the teamrsquos definition of Done

Herbstcampus 2015 36

Erfolgsfaktoren

Herbstcampus 2015 37

Tool-Kenntnisse

Application Lifecycle Management (ALM) Tools

Development Environment

Configuration Management

Branching amp Merging

Continuous Integration (CI) Tools

Unit Testing

Measuring Code Quality

Refactoring Tools

Herbstcampus 2015 38

Zusammenfassung

Herbstcampus 2015 39

Professional Scrum Developer Glossary

bull ALM (Application Lifecycle Management)

bull ATDD (Acceptance Test-Driven Development)

bull BDD (Behavior-Driven Development)

bull Branching

bull Clean Code

bull Code Coverage

bull Collective Code Ownership

bull Continuous Delivery

bull Continuous Deployment

bull Continuous Integration (CI)

bull Cyclomatic Complexity

bull Cross-functional

bull Definition of Done

bull Developer

bull DevOps

bull Development Team

bull DRY (donrsquot repeat yourself)

bull Engineering Standards

bull Extreme Programming (XP)

bull Feature Toggle

bull Increment

bull Pair Programming

bull Refactoring

bull Scout Rule

bull Scrum Board

bull Scrum Guidetrade

bull Scrum Team

bull Self-organization

bull Specification by Example

bull TDD (Test-Driven Development)

bull Technical Debt

bull User Story

bull Unit Test

bull Velocity

Quelle httpwwwscrumorgResourcesPSD-Glossary

Herbstcampus 2015 20

Big Design Up Front (BDUP)

bull Why Big Design Up Front Seems Goodbull Requirements are better understood

bull Thinking things out ahead of time saves headaches

bull Changes to specs are cheaper than changes to code

bull Bugs are cheaper to fix early

bull Why Big Design Up Front Isnrsquot Goodbull Requirements arenrsquot well known in the first place

bull Requirements change

bull Developers are not able to foresee all problems

bull Customers are not able to tell you what they want

There is no business value in architecture or design

Herbstcampus 2015 21

Where are you today

Waterfall Some DUF

Cowboy

EmergentBDUF

Herbstcampus 2015 22

What is Emergent Architecture

bull The opposite of Big Design Up Front

bull It allows architecture to emerge as you develop

bull Some architectural decisions will need to be made

before you write your first line of code

bull Technologies frameworks languages patterns practices

bull Most of these decisions will be hard to change later

Herbstcampus 2015 23

Gebrauchseignung (Fitness for Purpose)

bull Eine Loumlsung sollte fuumlr den geplanten Zweck geeignet sein

bull Beispiel fuumlr eine User Storybull Titel Alle Autos muumlssen in der Bahnstr 87 halten

bull Beschreibung Als Sicherheitsbeauftragter moumlchte ich dass alle

Autos vor dem Gebaumlude halten sodass keine Teilnehmer verletzt werden

bull Abnahmekriterien

bull Die Loumlsung sollte universell verstaumlndlich sein

bull 247 Verfuumlgbar sein

bull niedrige Betriebskosten haben

Herbstcampus 2015 24

Itrsquos all About Business Value

bull Every sprint should generates an increment of potentially-

shippable business value

bull Therefore

bull It is not ok to have an ldquoarchitecture sprintrdquo

bull It is not ok to have an ldquoinfrastructure sprintrdquo

bull There is no such thing as sprint 0

bull And while wersquore on the topic therersquos no such thing as ldquodone donerdquo

Herbstcampus 2015 25

Donrsquot Over-Architect the Product

bull Build at least one increment of business

functionality every sprint

bull Build enough of the architecture and design to

support that business functionality

bull Build adequate architecture and design to meet any

non-functional requirements

bull Solve todayrsquos problem today tomorrowrsquos

problem tomorrow

Herbstcampus 2015 26

Quizfrage

bull In sprint 3 you start implementing the customer

management component of the web site Yoursquove

committed to delivering basic add edit and view

functionality

bull But you know that in sprint 4 the product

owner is going to want the ability to delete

a customer

bull How should you consider this while

delivering the sprint 3 increment

Herbstcampus 2015 27

Was bedeutet fuumlr uns Qualitaumlt

bull Erfuumlllt es die Anforderungen

bull Erfuumlllt es die Erwartungen

bull Hat es einen Nutzen

bull Ist die Loumlsung fuumlr den Zweck geeignet

bull Sind erforderliche Qualitaumltsattribute eingehalten

Herbstcampus 2015 28

Development Definition of Done

Wann sind wir fertig

bull Explizite Definition of Done (DoD)

bull Konstante (Mindest-)Qualitaumlt

bull Basis fuumlr Schaumltzungen

bull Beeinflusst von unternehmensweiten Richtlinien

bull Messbar

bull Automatisiert

Herbstcampus 2015 29

Example A Simple Definition of Done

1 Coded

2 Acceptance criteria met

3 Tests pass

4 Checked-in

Herbstcampus 2015 30

Be Transparent

bull Everyone should be able to inspect hellipbull The teamrsquos Definition of Done (DoD)

bull The product backlog (user stories)

bull The sprint backlog (tasks)

bull The impediments

bull Deployments

bull Test results

bull Bugs

bull Everyone should adapt to these inspections

Herbstcampus 2015 31

What is Done

Fundamental

bull Code Analysis

bull Coded

bull Refactored

bull Code Reviewed

bull Unit Tested

bull Documented

bull Continuous Build

bull User Acceptance

Mature

bull Design Review

bull Design Refactored

bull Integration Tested

bull Regression Tested

bull Security Tested

bull LoadSoak Tested

bull Scalability Tested

bull Performance Tested

Herbstcampus 2015 32

Unit Tests ndash warum

bull Sicherheitsnetz

bull Weniger Bugs

bull Schoumlneres Design

bull Ermoumlglichen Refactoring

bull Fokus bleibt auf Done

bull Hilft eigentliche Absicht zu dokumentieren

bull Forciert Entwickler uumlber das Ziel nachzudenken

bull Umgehende Belohnung

bull Pruumlft auf die Existenz eines Bugs

Herbstcampus 2015 34

Nur Sauberer Code ist qualitativer Code

bull Sauberer Quellcode erfordert staumlndiges

schonungsloses saumlubern (Refactoring)

bull Niemand sonst wird Deinen Code aufraumlumenbull Kein Zimmer-Servicehellip

bull Broken-Windows-Theorie

Herbstcampus 2015 35

Refactoring

bull The process of improving your code after it has

been written by changing the internal structure of

the code without changing its external behaviorbull In other words improving your code without breaking your

unit tests

bull Refactoring should only be done to add business

value or to meet the teamrsquos definition of Done

Herbstcampus 2015 36

Erfolgsfaktoren

Herbstcampus 2015 37

Tool-Kenntnisse

Application Lifecycle Management (ALM) Tools

Development Environment

Configuration Management

Branching amp Merging

Continuous Integration (CI) Tools

Unit Testing

Measuring Code Quality

Refactoring Tools

Herbstcampus 2015 38

Zusammenfassung

Herbstcampus 2015 39

Professional Scrum Developer Glossary

bull ALM (Application Lifecycle Management)

bull ATDD (Acceptance Test-Driven Development)

bull BDD (Behavior-Driven Development)

bull Branching

bull Clean Code

bull Code Coverage

bull Collective Code Ownership

bull Continuous Delivery

bull Continuous Deployment

bull Continuous Integration (CI)

bull Cyclomatic Complexity

bull Cross-functional

bull Definition of Done

bull Developer

bull DevOps

bull Development Team

bull DRY (donrsquot repeat yourself)

bull Engineering Standards

bull Extreme Programming (XP)

bull Feature Toggle

bull Increment

bull Pair Programming

bull Refactoring

bull Scout Rule

bull Scrum Board

bull Scrum Guidetrade

bull Scrum Team

bull Self-organization

bull Specification by Example

bull TDD (Test-Driven Development)

bull Technical Debt

bull User Story

bull Unit Test

bull Velocity

Quelle httpwwwscrumorgResourcesPSD-Glossary

Herbstcampus 2015 21

Where are you today

Waterfall Some DUF

Cowboy

EmergentBDUF

Herbstcampus 2015 22

What is Emergent Architecture

bull The opposite of Big Design Up Front

bull It allows architecture to emerge as you develop

bull Some architectural decisions will need to be made

before you write your first line of code

bull Technologies frameworks languages patterns practices

bull Most of these decisions will be hard to change later

Herbstcampus 2015 23

Gebrauchseignung (Fitness for Purpose)

bull Eine Loumlsung sollte fuumlr den geplanten Zweck geeignet sein

bull Beispiel fuumlr eine User Storybull Titel Alle Autos muumlssen in der Bahnstr 87 halten

bull Beschreibung Als Sicherheitsbeauftragter moumlchte ich dass alle

Autos vor dem Gebaumlude halten sodass keine Teilnehmer verletzt werden

bull Abnahmekriterien

bull Die Loumlsung sollte universell verstaumlndlich sein

bull 247 Verfuumlgbar sein

bull niedrige Betriebskosten haben

Herbstcampus 2015 24

Itrsquos all About Business Value

bull Every sprint should generates an increment of potentially-

shippable business value

bull Therefore

bull It is not ok to have an ldquoarchitecture sprintrdquo

bull It is not ok to have an ldquoinfrastructure sprintrdquo

bull There is no such thing as sprint 0

bull And while wersquore on the topic therersquos no such thing as ldquodone donerdquo

Herbstcampus 2015 25

Donrsquot Over-Architect the Product

bull Build at least one increment of business

functionality every sprint

bull Build enough of the architecture and design to

support that business functionality

bull Build adequate architecture and design to meet any

non-functional requirements

bull Solve todayrsquos problem today tomorrowrsquos

problem tomorrow

Herbstcampus 2015 26

Quizfrage

bull In sprint 3 you start implementing the customer

management component of the web site Yoursquove

committed to delivering basic add edit and view

functionality

bull But you know that in sprint 4 the product

owner is going to want the ability to delete

a customer

bull How should you consider this while

delivering the sprint 3 increment

Herbstcampus 2015 27

Was bedeutet fuumlr uns Qualitaumlt

bull Erfuumlllt es die Anforderungen

bull Erfuumlllt es die Erwartungen

bull Hat es einen Nutzen

bull Ist die Loumlsung fuumlr den Zweck geeignet

bull Sind erforderliche Qualitaumltsattribute eingehalten

Herbstcampus 2015 28

Development Definition of Done

Wann sind wir fertig

bull Explizite Definition of Done (DoD)

bull Konstante (Mindest-)Qualitaumlt

bull Basis fuumlr Schaumltzungen

bull Beeinflusst von unternehmensweiten Richtlinien

bull Messbar

bull Automatisiert

Herbstcampus 2015 29

Example A Simple Definition of Done

1 Coded

2 Acceptance criteria met

3 Tests pass

4 Checked-in

Herbstcampus 2015 30

Be Transparent

bull Everyone should be able to inspect hellipbull The teamrsquos Definition of Done (DoD)

bull The product backlog (user stories)

bull The sprint backlog (tasks)

bull The impediments

bull Deployments

bull Test results

bull Bugs

bull Everyone should adapt to these inspections

Herbstcampus 2015 31

What is Done

Fundamental

bull Code Analysis

bull Coded

bull Refactored

bull Code Reviewed

bull Unit Tested

bull Documented

bull Continuous Build

bull User Acceptance

Mature

bull Design Review

bull Design Refactored

bull Integration Tested

bull Regression Tested

bull Security Tested

bull LoadSoak Tested

bull Scalability Tested

bull Performance Tested

Herbstcampus 2015 32

Unit Tests ndash warum

bull Sicherheitsnetz

bull Weniger Bugs

bull Schoumlneres Design

bull Ermoumlglichen Refactoring

bull Fokus bleibt auf Done

bull Hilft eigentliche Absicht zu dokumentieren

bull Forciert Entwickler uumlber das Ziel nachzudenken

bull Umgehende Belohnung

bull Pruumlft auf die Existenz eines Bugs

Herbstcampus 2015 34

Nur Sauberer Code ist qualitativer Code

bull Sauberer Quellcode erfordert staumlndiges

schonungsloses saumlubern (Refactoring)

bull Niemand sonst wird Deinen Code aufraumlumenbull Kein Zimmer-Servicehellip

bull Broken-Windows-Theorie

Herbstcampus 2015 35

Refactoring

bull The process of improving your code after it has

been written by changing the internal structure of

the code without changing its external behaviorbull In other words improving your code without breaking your

unit tests

bull Refactoring should only be done to add business

value or to meet the teamrsquos definition of Done

Herbstcampus 2015 36

Erfolgsfaktoren

Herbstcampus 2015 37

Tool-Kenntnisse

Application Lifecycle Management (ALM) Tools

Development Environment

Configuration Management

Branching amp Merging

Continuous Integration (CI) Tools

Unit Testing

Measuring Code Quality

Refactoring Tools

Herbstcampus 2015 38

Zusammenfassung

Herbstcampus 2015 39

Professional Scrum Developer Glossary

bull ALM (Application Lifecycle Management)

bull ATDD (Acceptance Test-Driven Development)

bull BDD (Behavior-Driven Development)

bull Branching

bull Clean Code

bull Code Coverage

bull Collective Code Ownership

bull Continuous Delivery

bull Continuous Deployment

bull Continuous Integration (CI)

bull Cyclomatic Complexity

bull Cross-functional

bull Definition of Done

bull Developer

bull DevOps

bull Development Team

bull DRY (donrsquot repeat yourself)

bull Engineering Standards

bull Extreme Programming (XP)

bull Feature Toggle

bull Increment

bull Pair Programming

bull Refactoring

bull Scout Rule

bull Scrum Board

bull Scrum Guidetrade

bull Scrum Team

bull Self-organization

bull Specification by Example

bull TDD (Test-Driven Development)

bull Technical Debt

bull User Story

bull Unit Test

bull Velocity

Quelle httpwwwscrumorgResourcesPSD-Glossary

Herbstcampus 2015 22

What is Emergent Architecture

bull The opposite of Big Design Up Front

bull It allows architecture to emerge as you develop

bull Some architectural decisions will need to be made

before you write your first line of code

bull Technologies frameworks languages patterns practices

bull Most of these decisions will be hard to change later

Herbstcampus 2015 23

Gebrauchseignung (Fitness for Purpose)

bull Eine Loumlsung sollte fuumlr den geplanten Zweck geeignet sein

bull Beispiel fuumlr eine User Storybull Titel Alle Autos muumlssen in der Bahnstr 87 halten

bull Beschreibung Als Sicherheitsbeauftragter moumlchte ich dass alle

Autos vor dem Gebaumlude halten sodass keine Teilnehmer verletzt werden

bull Abnahmekriterien

bull Die Loumlsung sollte universell verstaumlndlich sein

bull 247 Verfuumlgbar sein

bull niedrige Betriebskosten haben

Herbstcampus 2015 24

Itrsquos all About Business Value

bull Every sprint should generates an increment of potentially-

shippable business value

bull Therefore

bull It is not ok to have an ldquoarchitecture sprintrdquo

bull It is not ok to have an ldquoinfrastructure sprintrdquo

bull There is no such thing as sprint 0

bull And while wersquore on the topic therersquos no such thing as ldquodone donerdquo

Herbstcampus 2015 25

Donrsquot Over-Architect the Product

bull Build at least one increment of business

functionality every sprint

bull Build enough of the architecture and design to

support that business functionality

bull Build adequate architecture and design to meet any

non-functional requirements

bull Solve todayrsquos problem today tomorrowrsquos

problem tomorrow

Herbstcampus 2015 26

Quizfrage

bull In sprint 3 you start implementing the customer

management component of the web site Yoursquove

committed to delivering basic add edit and view

functionality

bull But you know that in sprint 4 the product

owner is going to want the ability to delete

a customer

bull How should you consider this while

delivering the sprint 3 increment

Herbstcampus 2015 27

Was bedeutet fuumlr uns Qualitaumlt

bull Erfuumlllt es die Anforderungen

bull Erfuumlllt es die Erwartungen

bull Hat es einen Nutzen

bull Ist die Loumlsung fuumlr den Zweck geeignet

bull Sind erforderliche Qualitaumltsattribute eingehalten

Herbstcampus 2015 28

Development Definition of Done

Wann sind wir fertig

bull Explizite Definition of Done (DoD)

bull Konstante (Mindest-)Qualitaumlt

bull Basis fuumlr Schaumltzungen

bull Beeinflusst von unternehmensweiten Richtlinien

bull Messbar

bull Automatisiert

Herbstcampus 2015 29

Example A Simple Definition of Done

1 Coded

2 Acceptance criteria met

3 Tests pass

4 Checked-in

Herbstcampus 2015 30

Be Transparent

bull Everyone should be able to inspect hellipbull The teamrsquos Definition of Done (DoD)

bull The product backlog (user stories)

bull The sprint backlog (tasks)

bull The impediments

bull Deployments

bull Test results

bull Bugs

bull Everyone should adapt to these inspections

Herbstcampus 2015 31

What is Done

Fundamental

bull Code Analysis

bull Coded

bull Refactored

bull Code Reviewed

bull Unit Tested

bull Documented

bull Continuous Build

bull User Acceptance

Mature

bull Design Review

bull Design Refactored

bull Integration Tested

bull Regression Tested

bull Security Tested

bull LoadSoak Tested

bull Scalability Tested

bull Performance Tested

Herbstcampus 2015 32

Unit Tests ndash warum

bull Sicherheitsnetz

bull Weniger Bugs

bull Schoumlneres Design

bull Ermoumlglichen Refactoring

bull Fokus bleibt auf Done

bull Hilft eigentliche Absicht zu dokumentieren

bull Forciert Entwickler uumlber das Ziel nachzudenken

bull Umgehende Belohnung

bull Pruumlft auf die Existenz eines Bugs

Herbstcampus 2015 34

Nur Sauberer Code ist qualitativer Code

bull Sauberer Quellcode erfordert staumlndiges

schonungsloses saumlubern (Refactoring)

bull Niemand sonst wird Deinen Code aufraumlumenbull Kein Zimmer-Servicehellip

bull Broken-Windows-Theorie

Herbstcampus 2015 35

Refactoring

bull The process of improving your code after it has

been written by changing the internal structure of

the code without changing its external behaviorbull In other words improving your code without breaking your

unit tests

bull Refactoring should only be done to add business

value or to meet the teamrsquos definition of Done

Herbstcampus 2015 36

Erfolgsfaktoren

Herbstcampus 2015 37

Tool-Kenntnisse

Application Lifecycle Management (ALM) Tools

Development Environment

Configuration Management

Branching amp Merging

Continuous Integration (CI) Tools

Unit Testing

Measuring Code Quality

Refactoring Tools

Herbstcampus 2015 38

Zusammenfassung

Herbstcampus 2015 39

Professional Scrum Developer Glossary

bull ALM (Application Lifecycle Management)

bull ATDD (Acceptance Test-Driven Development)

bull BDD (Behavior-Driven Development)

bull Branching

bull Clean Code

bull Code Coverage

bull Collective Code Ownership

bull Continuous Delivery

bull Continuous Deployment

bull Continuous Integration (CI)

bull Cyclomatic Complexity

bull Cross-functional

bull Definition of Done

bull Developer

bull DevOps

bull Development Team

bull DRY (donrsquot repeat yourself)

bull Engineering Standards

bull Extreme Programming (XP)

bull Feature Toggle

bull Increment

bull Pair Programming

bull Refactoring

bull Scout Rule

bull Scrum Board

bull Scrum Guidetrade

bull Scrum Team

bull Self-organization

bull Specification by Example

bull TDD (Test-Driven Development)

bull Technical Debt

bull User Story

bull Unit Test

bull Velocity

Quelle httpwwwscrumorgResourcesPSD-Glossary

Herbstcampus 2015 23

Gebrauchseignung (Fitness for Purpose)

bull Eine Loumlsung sollte fuumlr den geplanten Zweck geeignet sein

bull Beispiel fuumlr eine User Storybull Titel Alle Autos muumlssen in der Bahnstr 87 halten

bull Beschreibung Als Sicherheitsbeauftragter moumlchte ich dass alle

Autos vor dem Gebaumlude halten sodass keine Teilnehmer verletzt werden

bull Abnahmekriterien

bull Die Loumlsung sollte universell verstaumlndlich sein

bull 247 Verfuumlgbar sein

bull niedrige Betriebskosten haben

Herbstcampus 2015 24

Itrsquos all About Business Value

bull Every sprint should generates an increment of potentially-

shippable business value

bull Therefore

bull It is not ok to have an ldquoarchitecture sprintrdquo

bull It is not ok to have an ldquoinfrastructure sprintrdquo

bull There is no such thing as sprint 0

bull And while wersquore on the topic therersquos no such thing as ldquodone donerdquo

Herbstcampus 2015 25

Donrsquot Over-Architect the Product

bull Build at least one increment of business

functionality every sprint

bull Build enough of the architecture and design to

support that business functionality

bull Build adequate architecture and design to meet any

non-functional requirements

bull Solve todayrsquos problem today tomorrowrsquos

problem tomorrow

Herbstcampus 2015 26

Quizfrage

bull In sprint 3 you start implementing the customer

management component of the web site Yoursquove

committed to delivering basic add edit and view

functionality

bull But you know that in sprint 4 the product

owner is going to want the ability to delete

a customer

bull How should you consider this while

delivering the sprint 3 increment

Herbstcampus 2015 27

Was bedeutet fuumlr uns Qualitaumlt

bull Erfuumlllt es die Anforderungen

bull Erfuumlllt es die Erwartungen

bull Hat es einen Nutzen

bull Ist die Loumlsung fuumlr den Zweck geeignet

bull Sind erforderliche Qualitaumltsattribute eingehalten

Herbstcampus 2015 28

Development Definition of Done

Wann sind wir fertig

bull Explizite Definition of Done (DoD)

bull Konstante (Mindest-)Qualitaumlt

bull Basis fuumlr Schaumltzungen

bull Beeinflusst von unternehmensweiten Richtlinien

bull Messbar

bull Automatisiert

Herbstcampus 2015 29

Example A Simple Definition of Done

1 Coded

2 Acceptance criteria met

3 Tests pass

4 Checked-in

Herbstcampus 2015 30

Be Transparent

bull Everyone should be able to inspect hellipbull The teamrsquos Definition of Done (DoD)

bull The product backlog (user stories)

bull The sprint backlog (tasks)

bull The impediments

bull Deployments

bull Test results

bull Bugs

bull Everyone should adapt to these inspections

Herbstcampus 2015 31

What is Done

Fundamental

bull Code Analysis

bull Coded

bull Refactored

bull Code Reviewed

bull Unit Tested

bull Documented

bull Continuous Build

bull User Acceptance

Mature

bull Design Review

bull Design Refactored

bull Integration Tested

bull Regression Tested

bull Security Tested

bull LoadSoak Tested

bull Scalability Tested

bull Performance Tested

Herbstcampus 2015 32

Unit Tests ndash warum

bull Sicherheitsnetz

bull Weniger Bugs

bull Schoumlneres Design

bull Ermoumlglichen Refactoring

bull Fokus bleibt auf Done

bull Hilft eigentliche Absicht zu dokumentieren

bull Forciert Entwickler uumlber das Ziel nachzudenken

bull Umgehende Belohnung

bull Pruumlft auf die Existenz eines Bugs

Herbstcampus 2015 34

Nur Sauberer Code ist qualitativer Code

bull Sauberer Quellcode erfordert staumlndiges

schonungsloses saumlubern (Refactoring)

bull Niemand sonst wird Deinen Code aufraumlumenbull Kein Zimmer-Servicehellip

bull Broken-Windows-Theorie

Herbstcampus 2015 35

Refactoring

bull The process of improving your code after it has

been written by changing the internal structure of

the code without changing its external behaviorbull In other words improving your code without breaking your

unit tests

bull Refactoring should only be done to add business

value or to meet the teamrsquos definition of Done

Herbstcampus 2015 36

Erfolgsfaktoren

Herbstcampus 2015 37

Tool-Kenntnisse

Application Lifecycle Management (ALM) Tools

Development Environment

Configuration Management

Branching amp Merging

Continuous Integration (CI) Tools

Unit Testing

Measuring Code Quality

Refactoring Tools

Herbstcampus 2015 38

Zusammenfassung

Herbstcampus 2015 39

Professional Scrum Developer Glossary

bull ALM (Application Lifecycle Management)

bull ATDD (Acceptance Test-Driven Development)

bull BDD (Behavior-Driven Development)

bull Branching

bull Clean Code

bull Code Coverage

bull Collective Code Ownership

bull Continuous Delivery

bull Continuous Deployment

bull Continuous Integration (CI)

bull Cyclomatic Complexity

bull Cross-functional

bull Definition of Done

bull Developer

bull DevOps

bull Development Team

bull DRY (donrsquot repeat yourself)

bull Engineering Standards

bull Extreme Programming (XP)

bull Feature Toggle

bull Increment

bull Pair Programming

bull Refactoring

bull Scout Rule

bull Scrum Board

bull Scrum Guidetrade

bull Scrum Team

bull Self-organization

bull Specification by Example

bull TDD (Test-Driven Development)

bull Technical Debt

bull User Story

bull Unit Test

bull Velocity

Quelle httpwwwscrumorgResourcesPSD-Glossary

Herbstcampus 2015 24

Itrsquos all About Business Value

bull Every sprint should generates an increment of potentially-

shippable business value

bull Therefore

bull It is not ok to have an ldquoarchitecture sprintrdquo

bull It is not ok to have an ldquoinfrastructure sprintrdquo

bull There is no such thing as sprint 0

bull And while wersquore on the topic therersquos no such thing as ldquodone donerdquo

Herbstcampus 2015 25

Donrsquot Over-Architect the Product

bull Build at least one increment of business

functionality every sprint

bull Build enough of the architecture and design to

support that business functionality

bull Build adequate architecture and design to meet any

non-functional requirements

bull Solve todayrsquos problem today tomorrowrsquos

problem tomorrow

Herbstcampus 2015 26

Quizfrage

bull In sprint 3 you start implementing the customer

management component of the web site Yoursquove

committed to delivering basic add edit and view

functionality

bull But you know that in sprint 4 the product

owner is going to want the ability to delete

a customer

bull How should you consider this while

delivering the sprint 3 increment

Herbstcampus 2015 27

Was bedeutet fuumlr uns Qualitaumlt

bull Erfuumlllt es die Anforderungen

bull Erfuumlllt es die Erwartungen

bull Hat es einen Nutzen

bull Ist die Loumlsung fuumlr den Zweck geeignet

bull Sind erforderliche Qualitaumltsattribute eingehalten

Herbstcampus 2015 28

Development Definition of Done

Wann sind wir fertig

bull Explizite Definition of Done (DoD)

bull Konstante (Mindest-)Qualitaumlt

bull Basis fuumlr Schaumltzungen

bull Beeinflusst von unternehmensweiten Richtlinien

bull Messbar

bull Automatisiert

Herbstcampus 2015 29

Example A Simple Definition of Done

1 Coded

2 Acceptance criteria met

3 Tests pass

4 Checked-in

Herbstcampus 2015 30

Be Transparent

bull Everyone should be able to inspect hellipbull The teamrsquos Definition of Done (DoD)

bull The product backlog (user stories)

bull The sprint backlog (tasks)

bull The impediments

bull Deployments

bull Test results

bull Bugs

bull Everyone should adapt to these inspections

Herbstcampus 2015 31

What is Done

Fundamental

bull Code Analysis

bull Coded

bull Refactored

bull Code Reviewed

bull Unit Tested

bull Documented

bull Continuous Build

bull User Acceptance

Mature

bull Design Review

bull Design Refactored

bull Integration Tested

bull Regression Tested

bull Security Tested

bull LoadSoak Tested

bull Scalability Tested

bull Performance Tested

Herbstcampus 2015 32

Unit Tests ndash warum

bull Sicherheitsnetz

bull Weniger Bugs

bull Schoumlneres Design

bull Ermoumlglichen Refactoring

bull Fokus bleibt auf Done

bull Hilft eigentliche Absicht zu dokumentieren

bull Forciert Entwickler uumlber das Ziel nachzudenken

bull Umgehende Belohnung

bull Pruumlft auf die Existenz eines Bugs

Herbstcampus 2015 34

Nur Sauberer Code ist qualitativer Code

bull Sauberer Quellcode erfordert staumlndiges

schonungsloses saumlubern (Refactoring)

bull Niemand sonst wird Deinen Code aufraumlumenbull Kein Zimmer-Servicehellip

bull Broken-Windows-Theorie

Herbstcampus 2015 35

Refactoring

bull The process of improving your code after it has

been written by changing the internal structure of

the code without changing its external behaviorbull In other words improving your code without breaking your

unit tests

bull Refactoring should only be done to add business

value or to meet the teamrsquos definition of Done

Herbstcampus 2015 36

Erfolgsfaktoren

Herbstcampus 2015 37

Tool-Kenntnisse

Application Lifecycle Management (ALM) Tools

Development Environment

Configuration Management

Branching amp Merging

Continuous Integration (CI) Tools

Unit Testing

Measuring Code Quality

Refactoring Tools

Herbstcampus 2015 38

Zusammenfassung

Herbstcampus 2015 39

Professional Scrum Developer Glossary

bull ALM (Application Lifecycle Management)

bull ATDD (Acceptance Test-Driven Development)

bull BDD (Behavior-Driven Development)

bull Branching

bull Clean Code

bull Code Coverage

bull Collective Code Ownership

bull Continuous Delivery

bull Continuous Deployment

bull Continuous Integration (CI)

bull Cyclomatic Complexity

bull Cross-functional

bull Definition of Done

bull Developer

bull DevOps

bull Development Team

bull DRY (donrsquot repeat yourself)

bull Engineering Standards

bull Extreme Programming (XP)

bull Feature Toggle

bull Increment

bull Pair Programming

bull Refactoring

bull Scout Rule

bull Scrum Board

bull Scrum Guidetrade

bull Scrum Team

bull Self-organization

bull Specification by Example

bull TDD (Test-Driven Development)

bull Technical Debt

bull User Story

bull Unit Test

bull Velocity

Quelle httpwwwscrumorgResourcesPSD-Glossary

Herbstcampus 2015 25

Donrsquot Over-Architect the Product

bull Build at least one increment of business

functionality every sprint

bull Build enough of the architecture and design to

support that business functionality

bull Build adequate architecture and design to meet any

non-functional requirements

bull Solve todayrsquos problem today tomorrowrsquos

problem tomorrow

Herbstcampus 2015 26

Quizfrage

bull In sprint 3 you start implementing the customer

management component of the web site Yoursquove

committed to delivering basic add edit and view

functionality

bull But you know that in sprint 4 the product

owner is going to want the ability to delete

a customer

bull How should you consider this while

delivering the sprint 3 increment

Herbstcampus 2015 27

Was bedeutet fuumlr uns Qualitaumlt

bull Erfuumlllt es die Anforderungen

bull Erfuumlllt es die Erwartungen

bull Hat es einen Nutzen

bull Ist die Loumlsung fuumlr den Zweck geeignet

bull Sind erforderliche Qualitaumltsattribute eingehalten

Herbstcampus 2015 28

Development Definition of Done

Wann sind wir fertig

bull Explizite Definition of Done (DoD)

bull Konstante (Mindest-)Qualitaumlt

bull Basis fuumlr Schaumltzungen

bull Beeinflusst von unternehmensweiten Richtlinien

bull Messbar

bull Automatisiert

Herbstcampus 2015 29

Example A Simple Definition of Done

1 Coded

2 Acceptance criteria met

3 Tests pass

4 Checked-in

Herbstcampus 2015 30

Be Transparent

bull Everyone should be able to inspect hellipbull The teamrsquos Definition of Done (DoD)

bull The product backlog (user stories)

bull The sprint backlog (tasks)

bull The impediments

bull Deployments

bull Test results

bull Bugs

bull Everyone should adapt to these inspections

Herbstcampus 2015 31

What is Done

Fundamental

bull Code Analysis

bull Coded

bull Refactored

bull Code Reviewed

bull Unit Tested

bull Documented

bull Continuous Build

bull User Acceptance

Mature

bull Design Review

bull Design Refactored

bull Integration Tested

bull Regression Tested

bull Security Tested

bull LoadSoak Tested

bull Scalability Tested

bull Performance Tested

Herbstcampus 2015 32

Unit Tests ndash warum

bull Sicherheitsnetz

bull Weniger Bugs

bull Schoumlneres Design

bull Ermoumlglichen Refactoring

bull Fokus bleibt auf Done

bull Hilft eigentliche Absicht zu dokumentieren

bull Forciert Entwickler uumlber das Ziel nachzudenken

bull Umgehende Belohnung

bull Pruumlft auf die Existenz eines Bugs

Herbstcampus 2015 34

Nur Sauberer Code ist qualitativer Code

bull Sauberer Quellcode erfordert staumlndiges

schonungsloses saumlubern (Refactoring)

bull Niemand sonst wird Deinen Code aufraumlumenbull Kein Zimmer-Servicehellip

bull Broken-Windows-Theorie

Herbstcampus 2015 35

Refactoring

bull The process of improving your code after it has

been written by changing the internal structure of

the code without changing its external behaviorbull In other words improving your code without breaking your

unit tests

bull Refactoring should only be done to add business

value or to meet the teamrsquos definition of Done

Herbstcampus 2015 36

Erfolgsfaktoren

Herbstcampus 2015 37

Tool-Kenntnisse

Application Lifecycle Management (ALM) Tools

Development Environment

Configuration Management

Branching amp Merging

Continuous Integration (CI) Tools

Unit Testing

Measuring Code Quality

Refactoring Tools

Herbstcampus 2015 38

Zusammenfassung

Herbstcampus 2015 39

Professional Scrum Developer Glossary

bull ALM (Application Lifecycle Management)

bull ATDD (Acceptance Test-Driven Development)

bull BDD (Behavior-Driven Development)

bull Branching

bull Clean Code

bull Code Coverage

bull Collective Code Ownership

bull Continuous Delivery

bull Continuous Deployment

bull Continuous Integration (CI)

bull Cyclomatic Complexity

bull Cross-functional

bull Definition of Done

bull Developer

bull DevOps

bull Development Team

bull DRY (donrsquot repeat yourself)

bull Engineering Standards

bull Extreme Programming (XP)

bull Feature Toggle

bull Increment

bull Pair Programming

bull Refactoring

bull Scout Rule

bull Scrum Board

bull Scrum Guidetrade

bull Scrum Team

bull Self-organization

bull Specification by Example

bull TDD (Test-Driven Development)

bull Technical Debt

bull User Story

bull Unit Test

bull Velocity

Quelle httpwwwscrumorgResourcesPSD-Glossary

Herbstcampus 2015 26

Quizfrage

bull In sprint 3 you start implementing the customer

management component of the web site Yoursquove

committed to delivering basic add edit and view

functionality

bull But you know that in sprint 4 the product

owner is going to want the ability to delete

a customer

bull How should you consider this while

delivering the sprint 3 increment

Herbstcampus 2015 27

Was bedeutet fuumlr uns Qualitaumlt

bull Erfuumlllt es die Anforderungen

bull Erfuumlllt es die Erwartungen

bull Hat es einen Nutzen

bull Ist die Loumlsung fuumlr den Zweck geeignet

bull Sind erforderliche Qualitaumltsattribute eingehalten

Herbstcampus 2015 28

Development Definition of Done

Wann sind wir fertig

bull Explizite Definition of Done (DoD)

bull Konstante (Mindest-)Qualitaumlt

bull Basis fuumlr Schaumltzungen

bull Beeinflusst von unternehmensweiten Richtlinien

bull Messbar

bull Automatisiert

Herbstcampus 2015 29

Example A Simple Definition of Done

1 Coded

2 Acceptance criteria met

3 Tests pass

4 Checked-in

Herbstcampus 2015 30

Be Transparent

bull Everyone should be able to inspect hellipbull The teamrsquos Definition of Done (DoD)

bull The product backlog (user stories)

bull The sprint backlog (tasks)

bull The impediments

bull Deployments

bull Test results

bull Bugs

bull Everyone should adapt to these inspections

Herbstcampus 2015 31

What is Done

Fundamental

bull Code Analysis

bull Coded

bull Refactored

bull Code Reviewed

bull Unit Tested

bull Documented

bull Continuous Build

bull User Acceptance

Mature

bull Design Review

bull Design Refactored

bull Integration Tested

bull Regression Tested

bull Security Tested

bull LoadSoak Tested

bull Scalability Tested

bull Performance Tested

Herbstcampus 2015 32

Unit Tests ndash warum

bull Sicherheitsnetz

bull Weniger Bugs

bull Schoumlneres Design

bull Ermoumlglichen Refactoring

bull Fokus bleibt auf Done

bull Hilft eigentliche Absicht zu dokumentieren

bull Forciert Entwickler uumlber das Ziel nachzudenken

bull Umgehende Belohnung

bull Pruumlft auf die Existenz eines Bugs

Herbstcampus 2015 34

Nur Sauberer Code ist qualitativer Code

bull Sauberer Quellcode erfordert staumlndiges

schonungsloses saumlubern (Refactoring)

bull Niemand sonst wird Deinen Code aufraumlumenbull Kein Zimmer-Servicehellip

bull Broken-Windows-Theorie

Herbstcampus 2015 35

Refactoring

bull The process of improving your code after it has

been written by changing the internal structure of

the code without changing its external behaviorbull In other words improving your code without breaking your

unit tests

bull Refactoring should only be done to add business

value or to meet the teamrsquos definition of Done

Herbstcampus 2015 36

Erfolgsfaktoren

Herbstcampus 2015 37

Tool-Kenntnisse

Application Lifecycle Management (ALM) Tools

Development Environment

Configuration Management

Branching amp Merging

Continuous Integration (CI) Tools

Unit Testing

Measuring Code Quality

Refactoring Tools

Herbstcampus 2015 38

Zusammenfassung

Herbstcampus 2015 39

Professional Scrum Developer Glossary

bull ALM (Application Lifecycle Management)

bull ATDD (Acceptance Test-Driven Development)

bull BDD (Behavior-Driven Development)

bull Branching

bull Clean Code

bull Code Coverage

bull Collective Code Ownership

bull Continuous Delivery

bull Continuous Deployment

bull Continuous Integration (CI)

bull Cyclomatic Complexity

bull Cross-functional

bull Definition of Done

bull Developer

bull DevOps

bull Development Team

bull DRY (donrsquot repeat yourself)

bull Engineering Standards

bull Extreme Programming (XP)

bull Feature Toggle

bull Increment

bull Pair Programming

bull Refactoring

bull Scout Rule

bull Scrum Board

bull Scrum Guidetrade

bull Scrum Team

bull Self-organization

bull Specification by Example

bull TDD (Test-Driven Development)

bull Technical Debt

bull User Story

bull Unit Test

bull Velocity

Quelle httpwwwscrumorgResourcesPSD-Glossary

Herbstcampus 2015 27

Was bedeutet fuumlr uns Qualitaumlt

bull Erfuumlllt es die Anforderungen

bull Erfuumlllt es die Erwartungen

bull Hat es einen Nutzen

bull Ist die Loumlsung fuumlr den Zweck geeignet

bull Sind erforderliche Qualitaumltsattribute eingehalten

Herbstcampus 2015 28

Development Definition of Done

Wann sind wir fertig

bull Explizite Definition of Done (DoD)

bull Konstante (Mindest-)Qualitaumlt

bull Basis fuumlr Schaumltzungen

bull Beeinflusst von unternehmensweiten Richtlinien

bull Messbar

bull Automatisiert

Herbstcampus 2015 29

Example A Simple Definition of Done

1 Coded

2 Acceptance criteria met

3 Tests pass

4 Checked-in

Herbstcampus 2015 30

Be Transparent

bull Everyone should be able to inspect hellipbull The teamrsquos Definition of Done (DoD)

bull The product backlog (user stories)

bull The sprint backlog (tasks)

bull The impediments

bull Deployments

bull Test results

bull Bugs

bull Everyone should adapt to these inspections

Herbstcampus 2015 31

What is Done

Fundamental

bull Code Analysis

bull Coded

bull Refactored

bull Code Reviewed

bull Unit Tested

bull Documented

bull Continuous Build

bull User Acceptance

Mature

bull Design Review

bull Design Refactored

bull Integration Tested

bull Regression Tested

bull Security Tested

bull LoadSoak Tested

bull Scalability Tested

bull Performance Tested

Herbstcampus 2015 32

Unit Tests ndash warum

bull Sicherheitsnetz

bull Weniger Bugs

bull Schoumlneres Design

bull Ermoumlglichen Refactoring

bull Fokus bleibt auf Done

bull Hilft eigentliche Absicht zu dokumentieren

bull Forciert Entwickler uumlber das Ziel nachzudenken

bull Umgehende Belohnung

bull Pruumlft auf die Existenz eines Bugs

Herbstcampus 2015 34

Nur Sauberer Code ist qualitativer Code

bull Sauberer Quellcode erfordert staumlndiges

schonungsloses saumlubern (Refactoring)

bull Niemand sonst wird Deinen Code aufraumlumenbull Kein Zimmer-Servicehellip

bull Broken-Windows-Theorie

Herbstcampus 2015 35

Refactoring

bull The process of improving your code after it has

been written by changing the internal structure of

the code without changing its external behaviorbull In other words improving your code without breaking your

unit tests

bull Refactoring should only be done to add business

value or to meet the teamrsquos definition of Done

Herbstcampus 2015 36

Erfolgsfaktoren

Herbstcampus 2015 37

Tool-Kenntnisse

Application Lifecycle Management (ALM) Tools

Development Environment

Configuration Management

Branching amp Merging

Continuous Integration (CI) Tools

Unit Testing

Measuring Code Quality

Refactoring Tools

Herbstcampus 2015 38

Zusammenfassung

Herbstcampus 2015 39

Professional Scrum Developer Glossary

bull ALM (Application Lifecycle Management)

bull ATDD (Acceptance Test-Driven Development)

bull BDD (Behavior-Driven Development)

bull Branching

bull Clean Code

bull Code Coverage

bull Collective Code Ownership

bull Continuous Delivery

bull Continuous Deployment

bull Continuous Integration (CI)

bull Cyclomatic Complexity

bull Cross-functional

bull Definition of Done

bull Developer

bull DevOps

bull Development Team

bull DRY (donrsquot repeat yourself)

bull Engineering Standards

bull Extreme Programming (XP)

bull Feature Toggle

bull Increment

bull Pair Programming

bull Refactoring

bull Scout Rule

bull Scrum Board

bull Scrum Guidetrade

bull Scrum Team

bull Self-organization

bull Specification by Example

bull TDD (Test-Driven Development)

bull Technical Debt

bull User Story

bull Unit Test

bull Velocity

Quelle httpwwwscrumorgResourcesPSD-Glossary

Herbstcampus 2015 28

Development Definition of Done

Wann sind wir fertig

bull Explizite Definition of Done (DoD)

bull Konstante (Mindest-)Qualitaumlt

bull Basis fuumlr Schaumltzungen

bull Beeinflusst von unternehmensweiten Richtlinien

bull Messbar

bull Automatisiert

Herbstcampus 2015 29

Example A Simple Definition of Done

1 Coded

2 Acceptance criteria met

3 Tests pass

4 Checked-in

Herbstcampus 2015 30

Be Transparent

bull Everyone should be able to inspect hellipbull The teamrsquos Definition of Done (DoD)

bull The product backlog (user stories)

bull The sprint backlog (tasks)

bull The impediments

bull Deployments

bull Test results

bull Bugs

bull Everyone should adapt to these inspections

Herbstcampus 2015 31

What is Done

Fundamental

bull Code Analysis

bull Coded

bull Refactored

bull Code Reviewed

bull Unit Tested

bull Documented

bull Continuous Build

bull User Acceptance

Mature

bull Design Review

bull Design Refactored

bull Integration Tested

bull Regression Tested

bull Security Tested

bull LoadSoak Tested

bull Scalability Tested

bull Performance Tested

Herbstcampus 2015 32

Unit Tests ndash warum

bull Sicherheitsnetz

bull Weniger Bugs

bull Schoumlneres Design

bull Ermoumlglichen Refactoring

bull Fokus bleibt auf Done

bull Hilft eigentliche Absicht zu dokumentieren

bull Forciert Entwickler uumlber das Ziel nachzudenken

bull Umgehende Belohnung

bull Pruumlft auf die Existenz eines Bugs

Herbstcampus 2015 34

Nur Sauberer Code ist qualitativer Code

bull Sauberer Quellcode erfordert staumlndiges

schonungsloses saumlubern (Refactoring)

bull Niemand sonst wird Deinen Code aufraumlumenbull Kein Zimmer-Servicehellip

bull Broken-Windows-Theorie

Herbstcampus 2015 35

Refactoring

bull The process of improving your code after it has

been written by changing the internal structure of

the code without changing its external behaviorbull In other words improving your code without breaking your

unit tests

bull Refactoring should only be done to add business

value or to meet the teamrsquos definition of Done

Herbstcampus 2015 36

Erfolgsfaktoren

Herbstcampus 2015 37

Tool-Kenntnisse

Application Lifecycle Management (ALM) Tools

Development Environment

Configuration Management

Branching amp Merging

Continuous Integration (CI) Tools

Unit Testing

Measuring Code Quality

Refactoring Tools

Herbstcampus 2015 38

Zusammenfassung

Herbstcampus 2015 39

Professional Scrum Developer Glossary

bull ALM (Application Lifecycle Management)

bull ATDD (Acceptance Test-Driven Development)

bull BDD (Behavior-Driven Development)

bull Branching

bull Clean Code

bull Code Coverage

bull Collective Code Ownership

bull Continuous Delivery

bull Continuous Deployment

bull Continuous Integration (CI)

bull Cyclomatic Complexity

bull Cross-functional

bull Definition of Done

bull Developer

bull DevOps

bull Development Team

bull DRY (donrsquot repeat yourself)

bull Engineering Standards

bull Extreme Programming (XP)

bull Feature Toggle

bull Increment

bull Pair Programming

bull Refactoring

bull Scout Rule

bull Scrum Board

bull Scrum Guidetrade

bull Scrum Team

bull Self-organization

bull Specification by Example

bull TDD (Test-Driven Development)

bull Technical Debt

bull User Story

bull Unit Test

bull Velocity

Quelle httpwwwscrumorgResourcesPSD-Glossary

Herbstcampus 2015 29

Example A Simple Definition of Done

1 Coded

2 Acceptance criteria met

3 Tests pass

4 Checked-in

Herbstcampus 2015 30

Be Transparent

bull Everyone should be able to inspect hellipbull The teamrsquos Definition of Done (DoD)

bull The product backlog (user stories)

bull The sprint backlog (tasks)

bull The impediments

bull Deployments

bull Test results

bull Bugs

bull Everyone should adapt to these inspections

Herbstcampus 2015 31

What is Done

Fundamental

bull Code Analysis

bull Coded

bull Refactored

bull Code Reviewed

bull Unit Tested

bull Documented

bull Continuous Build

bull User Acceptance

Mature

bull Design Review

bull Design Refactored

bull Integration Tested

bull Regression Tested

bull Security Tested

bull LoadSoak Tested

bull Scalability Tested

bull Performance Tested

Herbstcampus 2015 32

Unit Tests ndash warum

bull Sicherheitsnetz

bull Weniger Bugs

bull Schoumlneres Design

bull Ermoumlglichen Refactoring

bull Fokus bleibt auf Done

bull Hilft eigentliche Absicht zu dokumentieren

bull Forciert Entwickler uumlber das Ziel nachzudenken

bull Umgehende Belohnung

bull Pruumlft auf die Existenz eines Bugs

Herbstcampus 2015 34

Nur Sauberer Code ist qualitativer Code

bull Sauberer Quellcode erfordert staumlndiges

schonungsloses saumlubern (Refactoring)

bull Niemand sonst wird Deinen Code aufraumlumenbull Kein Zimmer-Servicehellip

bull Broken-Windows-Theorie

Herbstcampus 2015 35

Refactoring

bull The process of improving your code after it has

been written by changing the internal structure of

the code without changing its external behaviorbull In other words improving your code without breaking your

unit tests

bull Refactoring should only be done to add business

value or to meet the teamrsquos definition of Done

Herbstcampus 2015 36

Erfolgsfaktoren

Herbstcampus 2015 37

Tool-Kenntnisse

Application Lifecycle Management (ALM) Tools

Development Environment

Configuration Management

Branching amp Merging

Continuous Integration (CI) Tools

Unit Testing

Measuring Code Quality

Refactoring Tools

Herbstcampus 2015 38

Zusammenfassung

Herbstcampus 2015 39

Professional Scrum Developer Glossary

bull ALM (Application Lifecycle Management)

bull ATDD (Acceptance Test-Driven Development)

bull BDD (Behavior-Driven Development)

bull Branching

bull Clean Code

bull Code Coverage

bull Collective Code Ownership

bull Continuous Delivery

bull Continuous Deployment

bull Continuous Integration (CI)

bull Cyclomatic Complexity

bull Cross-functional

bull Definition of Done

bull Developer

bull DevOps

bull Development Team

bull DRY (donrsquot repeat yourself)

bull Engineering Standards

bull Extreme Programming (XP)

bull Feature Toggle

bull Increment

bull Pair Programming

bull Refactoring

bull Scout Rule

bull Scrum Board

bull Scrum Guidetrade

bull Scrum Team

bull Self-organization

bull Specification by Example

bull TDD (Test-Driven Development)

bull Technical Debt

bull User Story

bull Unit Test

bull Velocity

Quelle httpwwwscrumorgResourcesPSD-Glossary

Herbstcampus 2015 30

Be Transparent

bull Everyone should be able to inspect hellipbull The teamrsquos Definition of Done (DoD)

bull The product backlog (user stories)

bull The sprint backlog (tasks)

bull The impediments

bull Deployments

bull Test results

bull Bugs

bull Everyone should adapt to these inspections

Herbstcampus 2015 31

What is Done

Fundamental

bull Code Analysis

bull Coded

bull Refactored

bull Code Reviewed

bull Unit Tested

bull Documented

bull Continuous Build

bull User Acceptance

Mature

bull Design Review

bull Design Refactored

bull Integration Tested

bull Regression Tested

bull Security Tested

bull LoadSoak Tested

bull Scalability Tested

bull Performance Tested

Herbstcampus 2015 32

Unit Tests ndash warum

bull Sicherheitsnetz

bull Weniger Bugs

bull Schoumlneres Design

bull Ermoumlglichen Refactoring

bull Fokus bleibt auf Done

bull Hilft eigentliche Absicht zu dokumentieren

bull Forciert Entwickler uumlber das Ziel nachzudenken

bull Umgehende Belohnung

bull Pruumlft auf die Existenz eines Bugs

Herbstcampus 2015 34

Nur Sauberer Code ist qualitativer Code

bull Sauberer Quellcode erfordert staumlndiges

schonungsloses saumlubern (Refactoring)

bull Niemand sonst wird Deinen Code aufraumlumenbull Kein Zimmer-Servicehellip

bull Broken-Windows-Theorie

Herbstcampus 2015 35

Refactoring

bull The process of improving your code after it has

been written by changing the internal structure of

the code without changing its external behaviorbull In other words improving your code without breaking your

unit tests

bull Refactoring should only be done to add business

value or to meet the teamrsquos definition of Done

Herbstcampus 2015 36

Erfolgsfaktoren

Herbstcampus 2015 37

Tool-Kenntnisse

Application Lifecycle Management (ALM) Tools

Development Environment

Configuration Management

Branching amp Merging

Continuous Integration (CI) Tools

Unit Testing

Measuring Code Quality

Refactoring Tools

Herbstcampus 2015 38

Zusammenfassung

Herbstcampus 2015 39

Professional Scrum Developer Glossary

bull ALM (Application Lifecycle Management)

bull ATDD (Acceptance Test-Driven Development)

bull BDD (Behavior-Driven Development)

bull Branching

bull Clean Code

bull Code Coverage

bull Collective Code Ownership

bull Continuous Delivery

bull Continuous Deployment

bull Continuous Integration (CI)

bull Cyclomatic Complexity

bull Cross-functional

bull Definition of Done

bull Developer

bull DevOps

bull Development Team

bull DRY (donrsquot repeat yourself)

bull Engineering Standards

bull Extreme Programming (XP)

bull Feature Toggle

bull Increment

bull Pair Programming

bull Refactoring

bull Scout Rule

bull Scrum Board

bull Scrum Guidetrade

bull Scrum Team

bull Self-organization

bull Specification by Example

bull TDD (Test-Driven Development)

bull Technical Debt

bull User Story

bull Unit Test

bull Velocity

Quelle httpwwwscrumorgResourcesPSD-Glossary

Herbstcampus 2015 31

What is Done

Fundamental

bull Code Analysis

bull Coded

bull Refactored

bull Code Reviewed

bull Unit Tested

bull Documented

bull Continuous Build

bull User Acceptance

Mature

bull Design Review

bull Design Refactored

bull Integration Tested

bull Regression Tested

bull Security Tested

bull LoadSoak Tested

bull Scalability Tested

bull Performance Tested

Herbstcampus 2015 32

Unit Tests ndash warum

bull Sicherheitsnetz

bull Weniger Bugs

bull Schoumlneres Design

bull Ermoumlglichen Refactoring

bull Fokus bleibt auf Done

bull Hilft eigentliche Absicht zu dokumentieren

bull Forciert Entwickler uumlber das Ziel nachzudenken

bull Umgehende Belohnung

bull Pruumlft auf die Existenz eines Bugs

Herbstcampus 2015 34

Nur Sauberer Code ist qualitativer Code

bull Sauberer Quellcode erfordert staumlndiges

schonungsloses saumlubern (Refactoring)

bull Niemand sonst wird Deinen Code aufraumlumenbull Kein Zimmer-Servicehellip

bull Broken-Windows-Theorie

Herbstcampus 2015 35

Refactoring

bull The process of improving your code after it has

been written by changing the internal structure of

the code without changing its external behaviorbull In other words improving your code without breaking your

unit tests

bull Refactoring should only be done to add business

value or to meet the teamrsquos definition of Done

Herbstcampus 2015 36

Erfolgsfaktoren

Herbstcampus 2015 37

Tool-Kenntnisse

Application Lifecycle Management (ALM) Tools

Development Environment

Configuration Management

Branching amp Merging

Continuous Integration (CI) Tools

Unit Testing

Measuring Code Quality

Refactoring Tools

Herbstcampus 2015 38

Zusammenfassung

Herbstcampus 2015 39

Professional Scrum Developer Glossary

bull ALM (Application Lifecycle Management)

bull ATDD (Acceptance Test-Driven Development)

bull BDD (Behavior-Driven Development)

bull Branching

bull Clean Code

bull Code Coverage

bull Collective Code Ownership

bull Continuous Delivery

bull Continuous Deployment

bull Continuous Integration (CI)

bull Cyclomatic Complexity

bull Cross-functional

bull Definition of Done

bull Developer

bull DevOps

bull Development Team

bull DRY (donrsquot repeat yourself)

bull Engineering Standards

bull Extreme Programming (XP)

bull Feature Toggle

bull Increment

bull Pair Programming

bull Refactoring

bull Scout Rule

bull Scrum Board

bull Scrum Guidetrade

bull Scrum Team

bull Self-organization

bull Specification by Example

bull TDD (Test-Driven Development)

bull Technical Debt

bull User Story

bull Unit Test

bull Velocity

Quelle httpwwwscrumorgResourcesPSD-Glossary

Herbstcampus 2015 32

Unit Tests ndash warum

bull Sicherheitsnetz

bull Weniger Bugs

bull Schoumlneres Design

bull Ermoumlglichen Refactoring

bull Fokus bleibt auf Done

bull Hilft eigentliche Absicht zu dokumentieren

bull Forciert Entwickler uumlber das Ziel nachzudenken

bull Umgehende Belohnung

bull Pruumlft auf die Existenz eines Bugs

Herbstcampus 2015 34

Nur Sauberer Code ist qualitativer Code

bull Sauberer Quellcode erfordert staumlndiges

schonungsloses saumlubern (Refactoring)

bull Niemand sonst wird Deinen Code aufraumlumenbull Kein Zimmer-Servicehellip

bull Broken-Windows-Theorie

Herbstcampus 2015 35

Refactoring

bull The process of improving your code after it has

been written by changing the internal structure of

the code without changing its external behaviorbull In other words improving your code without breaking your

unit tests

bull Refactoring should only be done to add business

value or to meet the teamrsquos definition of Done

Herbstcampus 2015 36

Erfolgsfaktoren

Herbstcampus 2015 37

Tool-Kenntnisse

Application Lifecycle Management (ALM) Tools

Development Environment

Configuration Management

Branching amp Merging

Continuous Integration (CI) Tools

Unit Testing

Measuring Code Quality

Refactoring Tools

Herbstcampus 2015 38

Zusammenfassung

Herbstcampus 2015 39

Professional Scrum Developer Glossary

bull ALM (Application Lifecycle Management)

bull ATDD (Acceptance Test-Driven Development)

bull BDD (Behavior-Driven Development)

bull Branching

bull Clean Code

bull Code Coverage

bull Collective Code Ownership

bull Continuous Delivery

bull Continuous Deployment

bull Continuous Integration (CI)

bull Cyclomatic Complexity

bull Cross-functional

bull Definition of Done

bull Developer

bull DevOps

bull Development Team

bull DRY (donrsquot repeat yourself)

bull Engineering Standards

bull Extreme Programming (XP)

bull Feature Toggle

bull Increment

bull Pair Programming

bull Refactoring

bull Scout Rule

bull Scrum Board

bull Scrum Guidetrade

bull Scrum Team

bull Self-organization

bull Specification by Example

bull TDD (Test-Driven Development)

bull Technical Debt

bull User Story

bull Unit Test

bull Velocity

Quelle httpwwwscrumorgResourcesPSD-Glossary

Herbstcampus 2015 34

Nur Sauberer Code ist qualitativer Code

bull Sauberer Quellcode erfordert staumlndiges

schonungsloses saumlubern (Refactoring)

bull Niemand sonst wird Deinen Code aufraumlumenbull Kein Zimmer-Servicehellip

bull Broken-Windows-Theorie

Herbstcampus 2015 35

Refactoring

bull The process of improving your code after it has

been written by changing the internal structure of

the code without changing its external behaviorbull In other words improving your code without breaking your

unit tests

bull Refactoring should only be done to add business

value or to meet the teamrsquos definition of Done

Herbstcampus 2015 36

Erfolgsfaktoren

Herbstcampus 2015 37

Tool-Kenntnisse

Application Lifecycle Management (ALM) Tools

Development Environment

Configuration Management

Branching amp Merging

Continuous Integration (CI) Tools

Unit Testing

Measuring Code Quality

Refactoring Tools

Herbstcampus 2015 38

Zusammenfassung

Herbstcampus 2015 39

Professional Scrum Developer Glossary

bull ALM (Application Lifecycle Management)

bull ATDD (Acceptance Test-Driven Development)

bull BDD (Behavior-Driven Development)

bull Branching

bull Clean Code

bull Code Coverage

bull Collective Code Ownership

bull Continuous Delivery

bull Continuous Deployment

bull Continuous Integration (CI)

bull Cyclomatic Complexity

bull Cross-functional

bull Definition of Done

bull Developer

bull DevOps

bull Development Team

bull DRY (donrsquot repeat yourself)

bull Engineering Standards

bull Extreme Programming (XP)

bull Feature Toggle

bull Increment

bull Pair Programming

bull Refactoring

bull Scout Rule

bull Scrum Board

bull Scrum Guidetrade

bull Scrum Team

bull Self-organization

bull Specification by Example

bull TDD (Test-Driven Development)

bull Technical Debt

bull User Story

bull Unit Test

bull Velocity

Quelle httpwwwscrumorgResourcesPSD-Glossary

Herbstcampus 2015 35

Refactoring

bull The process of improving your code after it has

been written by changing the internal structure of

the code without changing its external behaviorbull In other words improving your code without breaking your

unit tests

bull Refactoring should only be done to add business

value or to meet the teamrsquos definition of Done

Herbstcampus 2015 36

Erfolgsfaktoren

Herbstcampus 2015 37

Tool-Kenntnisse

Application Lifecycle Management (ALM) Tools

Development Environment

Configuration Management

Branching amp Merging

Continuous Integration (CI) Tools

Unit Testing

Measuring Code Quality

Refactoring Tools

Herbstcampus 2015 38

Zusammenfassung

Herbstcampus 2015 39

Professional Scrum Developer Glossary

bull ALM (Application Lifecycle Management)

bull ATDD (Acceptance Test-Driven Development)

bull BDD (Behavior-Driven Development)

bull Branching

bull Clean Code

bull Code Coverage

bull Collective Code Ownership

bull Continuous Delivery

bull Continuous Deployment

bull Continuous Integration (CI)

bull Cyclomatic Complexity

bull Cross-functional

bull Definition of Done

bull Developer

bull DevOps

bull Development Team

bull DRY (donrsquot repeat yourself)

bull Engineering Standards

bull Extreme Programming (XP)

bull Feature Toggle

bull Increment

bull Pair Programming

bull Refactoring

bull Scout Rule

bull Scrum Board

bull Scrum Guidetrade

bull Scrum Team

bull Self-organization

bull Specification by Example

bull TDD (Test-Driven Development)

bull Technical Debt

bull User Story

bull Unit Test

bull Velocity

Quelle httpwwwscrumorgResourcesPSD-Glossary

Herbstcampus 2015 36

Erfolgsfaktoren

Herbstcampus 2015 37

Tool-Kenntnisse

Application Lifecycle Management (ALM) Tools

Development Environment

Configuration Management

Branching amp Merging

Continuous Integration (CI) Tools

Unit Testing

Measuring Code Quality

Refactoring Tools

Herbstcampus 2015 38

Zusammenfassung

Herbstcampus 2015 39

Professional Scrum Developer Glossary

bull ALM (Application Lifecycle Management)

bull ATDD (Acceptance Test-Driven Development)

bull BDD (Behavior-Driven Development)

bull Branching

bull Clean Code

bull Code Coverage

bull Collective Code Ownership

bull Continuous Delivery

bull Continuous Deployment

bull Continuous Integration (CI)

bull Cyclomatic Complexity

bull Cross-functional

bull Definition of Done

bull Developer

bull DevOps

bull Development Team

bull DRY (donrsquot repeat yourself)

bull Engineering Standards

bull Extreme Programming (XP)

bull Feature Toggle

bull Increment

bull Pair Programming

bull Refactoring

bull Scout Rule

bull Scrum Board

bull Scrum Guidetrade

bull Scrum Team

bull Self-organization

bull Specification by Example

bull TDD (Test-Driven Development)

bull Technical Debt

bull User Story

bull Unit Test

bull Velocity

Quelle httpwwwscrumorgResourcesPSD-Glossary

Herbstcampus 2015 37

Tool-Kenntnisse

Application Lifecycle Management (ALM) Tools

Development Environment

Configuration Management

Branching amp Merging

Continuous Integration (CI) Tools

Unit Testing

Measuring Code Quality

Refactoring Tools

Herbstcampus 2015 38

Zusammenfassung

Herbstcampus 2015 39

Professional Scrum Developer Glossary

bull ALM (Application Lifecycle Management)

bull ATDD (Acceptance Test-Driven Development)

bull BDD (Behavior-Driven Development)

bull Branching

bull Clean Code

bull Code Coverage

bull Collective Code Ownership

bull Continuous Delivery

bull Continuous Deployment

bull Continuous Integration (CI)

bull Cyclomatic Complexity

bull Cross-functional

bull Definition of Done

bull Developer

bull DevOps

bull Development Team

bull DRY (donrsquot repeat yourself)

bull Engineering Standards

bull Extreme Programming (XP)

bull Feature Toggle

bull Increment

bull Pair Programming

bull Refactoring

bull Scout Rule

bull Scrum Board

bull Scrum Guidetrade

bull Scrum Team

bull Self-organization

bull Specification by Example

bull TDD (Test-Driven Development)

bull Technical Debt

bull User Story

bull Unit Test

bull Velocity

Quelle httpwwwscrumorgResourcesPSD-Glossary

Herbstcampus 2015 38

Zusammenfassung

Herbstcampus 2015 39

Professional Scrum Developer Glossary

bull ALM (Application Lifecycle Management)

bull ATDD (Acceptance Test-Driven Development)

bull BDD (Behavior-Driven Development)

bull Branching

bull Clean Code

bull Code Coverage

bull Collective Code Ownership

bull Continuous Delivery

bull Continuous Deployment

bull Continuous Integration (CI)

bull Cyclomatic Complexity

bull Cross-functional

bull Definition of Done

bull Developer

bull DevOps

bull Development Team

bull DRY (donrsquot repeat yourself)

bull Engineering Standards

bull Extreme Programming (XP)

bull Feature Toggle

bull Increment

bull Pair Programming

bull Refactoring

bull Scout Rule

bull Scrum Board

bull Scrum Guidetrade

bull Scrum Team

bull Self-organization

bull Specification by Example

bull TDD (Test-Driven Development)

bull Technical Debt

bull User Story

bull Unit Test

bull Velocity

Quelle httpwwwscrumorgResourcesPSD-Glossary

Herbstcampus 2015 39

Professional Scrum Developer Glossary

bull ALM (Application Lifecycle Management)

bull ATDD (Acceptance Test-Driven Development)

bull BDD (Behavior-Driven Development)

bull Branching

bull Clean Code

bull Code Coverage

bull Collective Code Ownership

bull Continuous Delivery

bull Continuous Deployment

bull Continuous Integration (CI)

bull Cyclomatic Complexity

bull Cross-functional

bull Definition of Done

bull Developer

bull DevOps

bull Development Team

bull DRY (donrsquot repeat yourself)

bull Engineering Standards

bull Extreme Programming (XP)

bull Feature Toggle

bull Increment

bull Pair Programming

bull Refactoring

bull Scout Rule

bull Scrum Board

bull Scrum Guidetrade

bull Scrum Team

bull Self-organization

bull Specification by Example

bull TDD (Test-Driven Development)

bull Technical Debt

bull User Story

bull Unit Test

bull Velocity

Quelle httpwwwscrumorgResourcesPSD-Glossary

Herbstcampus 2015 40

Weitere Informationen

bull Scrum Guide - das offizielle Regelwerk zu Scrum

bull Scrum Open Assessment - Kostenfreie Online-Pruumlfung

(30 Fragen) zu Scrum-Themen

bull Developer Open Assessment - Kostenfreie Online-

Pruumlfung (30 Fragen) zu Scrum Developer-Themen

bull PSD Course Topics - Themenliste aus dem PSD-Kurs

bull PSD Subject Areas - Themen die jeder PSD kennen sollte

bull PSD Glossary - Glossar zu den wichtigsten Begriffen

bull Professional Scrum Developer auf scrumorg - The

Home of Scrum

Herbstcampus 2015 41

Buchempfehlungen zu Scrum

bull Software in 30 Days How Agile Managers Beat

the Odds Delight Their Customers And Leave

Competitors In the DustVon den Erfindern von Scrum Zielgruppe Entscheider

bull Visual Studio Team Foundation Server 2012

Adopting Agile Software Practices From Backlog

to Continuous FeedbackVom Product Owner von Visual Studio Zielgruppe jeder

bull Professional Scrum Development with Microsoft

Visual Studio 2012Empfohlen fuumlr alle Scrum-Teammitglieder

Herbstcampus 2015 42

Danke fuumlr Ihre Aufmerksamkeit

Im Anschluss oder per E-Mail an

nenolojeteamsystemprode

Herbstcampus 2015 43

Uumlber Neno Loje

bull Neno unterstuumltzt Unternehmen und Teams moderner und agiler zu werden

bull Seine Schwerpunkte sind Scrum TFS und DevOps

bull Auch die Einfuumlhrung des Team Foundation Servers ndash von der

Entscheidung uumlber die Migration bis zur individuellen Anpassung

bull Besonders stolz ist er auf den Professional Scrum Developer-Kurs dem

Ausbildungsprogramm fuumlr Scrum-Teammitglieder

bull Neno ist seit 2010 Referent beim Herbstcampus