Agilität verspricht mehr Output in weniger Zeit. Und das bei höherer Qualität des Endproduktes. Der Grundsatz "Build Quality In" wird in der Agilen Softwareentwicklung GROSS geschrieben. So adressieren Frameworks wie Scrum vor allem die Effektivität mit ihren integrierten Aufforderungen zu Priorisierung, Planung und Prüfung des Produktes. Für die nötige Effizienz sorgen Engineering Practices wie Test Driven Development (TDD) und Pair Programming. Zu guter letzt bildet die Definition of Done die Klammer über die Qualitätssichernden Massnahmen.

1. agility
accelerates
...
Doppelter
Output
in
der
halben
Zeit
Wo
bleibt
die
Qualität?
SAQ
Jahresversammlung
8.
April
2014

2. hEp://www.management30.com
Mischa Ramseyer
Agile Executive Coach
@ramsyman

3. What
is
Quality?
?
10.04.14
SAQ
Jahresversammlung
3

4. ISO
9000
Definiton
of
Quality
“Quality is the degree to which a set of
inherent characteristics fulfills
requirements.“
The standard defines requirement as need
or expectation.
10.04.14
SAQ
Jahresversammlung
4

5. Philip
B.
Crosby‘s
DefiniRon
of
Quality
"Conformance to requirements“
The requirements may not fully represent
customer expectations;
Crosby treats this as a separate problem.
10.04.14
SAQ
Jahresversammlung
5

6. Joseph
Juran‘s
DefiniRon
of
Quality
"Fitness for use“
Fitness is defined by the customer
10.04.14
SAQ
Jahresversammlung
6

7. Peter
Drucker
defines
Quality
as
"Quality in a product or service is not
what the supplier puts in. It is what the
customer gets out and is willing to pay
for.“
10.04.14
SAQ
Jahresversammlung
7

8. American
Society
for
Quality
say‘s
A subjective term for which each person
has his or her own definition. In technical
usage, quality can have two meanings:
a. The characteristics of a product or
service that bear on its ability to satisfy
stated or implied needs;
b. A product or service free of
deficiencies.“
10.04.14
SAQ
Jahresversammlung
8

9. W.
Edwards
Deming
says
Concentrating on "the efficient production
of the quality that the market expects,“
and he linked quality and management:
"Costs go down and productivity goes up
as improvement of quality is accomplished
by better management of design,
engineering, testing and
by improvement of processes.“
10.04.14
SAQ
Jahresversammlung
9

10. DefiniRons
of
Quality
Quality
Fulfill
the
requirements
Fitness
for
use
Build
what
the
customer
is
willing
to
pay
for
No
Bugs
goes
up
by
empirically
improve
processes
10.04.14
SAQ
Jahresversammlung
10

11. Idea
What
is
Quality
about?
10.04.14
SAQ
Jahresversammlung
11
Idea
Idea
Idea
Product
Development
Do
the
Right
Thing!
Do
the
Thing
Right!
EffecRveness
Efficiency

12. What
is
more
important?
?
10.04.14
SAQ
Jahresversammlung
12

13. agility
accelerates
...
DO
THE
RIGHT
THING
10.04.14
SAQ
Jahresversammlung
13

14. The
„Cost
of
Complexity“
is
huge!
10.04.14
SAQ
Jahresversammlung
14

15. It‘s
all
about
secng
prioriRes!
10.04.14
SAQ
Jahresversammlung
15

16. Do
the
Right
Thing!
10.04.14
SAQ
Jahresversammlung
16
• Deliver
Business
Value
• in
the
right
order
• as
early
as
possible
• conRnuously
• Reduce
risk
• Collect
Customer
Feedback
as
early
as
possible
• Embrace
Change
• Release
when
good
enough
© pragmatic solutions gmbh 2009 - 2014

17. Good
enough
is
enough
to
Release!
10.04.14
SAQ
Jahresversammlung
17
Business
Value
Time
Feature
Good
Enough
Release
1.0
Faster Time to Market
and Lower Cost
means earlier ROI
80%
Business
Value
20%
Time
Release
1.x

18. Built-­‐in
Change
Management
10.04.14
SAQ
Jahresversammlung
18
Business
Value
Time
New Feature
identified during
development
Good
Enough
Release
1.0
Release
1.x
exchange

19. Idea
3
Rmes
as
EffecRve
10.04.14
SAQ
Jahresversammlung
19
Idea
Idea
Idea
Product
Development
Do
the
Right
Thing!
Do
the
Thing
Right!
EffecRveness
Efficiency
3x

20. agility
accelerates
...
DO
THE
THING
RIGHT
10.04.14
SAQ
Jahresversammlung
20

21. Do
the
Thing
Right!
Where
Defects
Originate
What
it
costs
to
fix
them
The Economics of Testing
The Relative Cost of Fixing Defects
One of the most well known facts about software defects is that the longer they go
undetected, the more expensive they are to fix. Although research differs on the exact
ratios, the general rule is 1:10:100.
The Relative Cost of Fixing
Defects
0
10
20
30
40
50
60
70
80
90
100
Req's Design Code Test Prod
The Relative Cost of Fixing
Defects
0
10
20
30
40
50
60
70
80
90
100
Req's Design Code Test Prod
10.04.14
SAQ
Jahresversammlung
21
definite economic impact of software testing. One economic impact is from the
fects. This is a very real and very tangible cost.
conomic impact is from the way we perform testing. It is possible to have very
vations and testing goals while testing in a very inefficient way.
tion, we will examine the economic impact of defects and ways to economize
Defects Originate
tand the dynamics and costs of defects, we need to know some things about
of the most commonly understood facts about defects is that most defects
Where Defects Originate
Code
7%
Other
10%
Req's
56%
Design
27%
Where Defects Originate
Code
7%
Other
10%
Req's
56%
Design
27%
James
MarRn
Study
1:10:100

22. How
would
you
handle
the
problem?
?
10.04.14
SAQ
Jahresversammlung
22

23. From
SpecificaRon
to
Discussion
10.04.14
SAQ
Jahresversammlung
23
As an
employee
I want
to
log
my
working
/me
so that
I
always
keep
track
of
my
daily
working
/me
User Story Template

24. Speak
the
same
language
• An
„Ubiquitous
Language“
is
needed
to
bridge
the
communicaRon
gap
• Use
Domain
Modeling
to
describe
the
Business
Domain
10.04.14
SAQ
Jahresversammlung
24
Timetracking
Domain
Model

25. Introducing
Acceptance
Criterias
Priority
As
a
[role]
I
can
[goal]
so
that
[reason]
EsAmaAon
10
Employee
log
my
working
Rme
I
always
keep
track
of
my
daily
working
Rme
2
10.04.14
SAQ
Jahresversammlung
25
Narrow
down
the
scope
of
the
Story
using
Acceptance
Criterias
• At
least
a
„How-­‐to-­‐demo-­‐Workflow“
• Add
them
to
the
Product
Backlog
Example
1. Fill
in
starRng-­‐,
lunch
&
end
Rme
in
natural
hours
&
minutes
2. Decimal
working
hours
will
be
displayed
&
saved
3. Displayed
working
hours
must
be
present
in
the
DB

26. Introducing
SpecificaRon
by
Example
10.04.14
SAQ
Jahresversammlung
26
Business
Rules
• Given
work
Rme
is
>
9h
Then
break
=
1
hour
• Given
work
Rme
is
>
7h
Then
break
=
30
min
• Given
work
Rme
is
>
5.5h
Then
break
=
15
min
Morn
In
Lunch
out
Lunch
In
Eve
Out
Time
9:00
12:00
13:00
17:05
7.08
8:00
12:00
13:00
17:00
8.00
8:00
-­‐
-­‐
17:01
8.02
7:30
12:00
13:00
17:00
8.50
...
...
...
...
...
Priority
As
a
[role]
I
can
[goal]
so
that
[reason]
EsAmaAon
10
Employee
log
my
working
Rme
I
always
keep
track
of
my
daily
working
Rme
2

27. Build
Executable
DocumentaRon
10.04.14
SAQ
Jahresversammlung
27
Scenario:
Log
Rme
Given
my
Rme
of
<arrival>
And
the
Rme
I
go
for
<lunch-­‐out>
And
the
Rme
I
return
from
<lunch-­‐in>
And
the
Rme
I
leave
in
the
<evening>
When I
entered
my
Rme
Then the
<total>
decimal
Rme
is
calculated
Examples:
| arrival | lunch-out | lunch-in | evening | total!
| 09:00 | 12:00 | 13:00 | 17:05 | 7.08!
| 08:00 | 12:00 | 13:00 | 18:00 | 9.00!
| 08:00 | - | - | 17:01 | 8.02!
| 07:30 | 12:00 | 13:00 | 17:00 | 8.50!
!
!
In terms of the
ubiquituous language

28. Address
Inner-­‐
&
Outer
Quality
10.04.14
SAQ
Jahresversammlung
28
Inner Quality is inside
the system

29. TDD
improves
inner
quality
10.04.14
SAQ
Jahresversammlung
29
RED GREEN
REFACTOR
Write a failing test Make it compile
Make it work
in production code
Make it nice
eliminate duplication
increase expressiveness
No production
code without a
test

30. TDD
is
NOT
an
opRon
10.04.14
SAQ
Jahresversammlung
30
Built
in
Regression
BeEer
Design
Fewer
Bugs
Faster
Development
RED GREEN
REFACTOR

31. What
is
Pair
Programming?
10.04.14
SAQ
Jahresversammlung
31
DriverNavigator

32. Pair
Programming
10.04.14
SAQ
Jahresversammlung
32
Faster,
but
more
Effort
BeEer
Code
&
Design
Half
of
Bugs
Knowledge
spread

33. Double
pack!
10.04.14
SAQ
Jahresversammlung
33
RED GREEN
REFACTOR

34. Build
Quality
In
10.04.14
SAQ
Jahresversammlung
34
Test
Refactor
Code
Test
Refactor
Code
Test
Refactor
Code
Select a User
Story
Identify
Acceptance
Criterias
Implement
Acceptance
test(s)
Failing
Acceptance
Test
Passing
Acceptance
Test
Refactor
Acceptance
Test
Customer
Acceptance
Behaviour
Driven Development
Test Driven
Development

35. Check
against
Requirements
FuncAonal
Check
if
the
System
works
as
required
• Unit
Test
• IntegraRon
Test
• Regression
Test
• User
Acceptance
Test
NON-­‐FuncAonal
Check
if
the
System
operates
as
intended
• Technical
TesRng
• Build
• Deployment
• Load,
Stress
&
Performance
• Security
&
PenetraRon
• Usability
10.04.14
SAQ
Jahresversammlung
35

36. Checking
vs.
TesRng
Checking
• Automated
• Expected
Result
• Developer-­‐Mindset
• Developer
Know-­‐how
• Basis
for
TesRng
10.04.14
SAQ
Jahresversammlung
36
TesAng
• Manual
• Exploratory
• User-­‐Mindset
• Business
Know-­‐how
• On
Top
of
Checks

37. Test
AutomaRon
is
NOT
an
opRon!
10.04.14
SAQ
Jahresversammlung
37
• Business
Scenarios
UI
• Business
FuncRonality
Services
• Inner
Quality
Unit

38. Checks
&
Tests
10.04.14
SAQ
Jahresversammlung
Unit
Tests
Single
Unit
Mock
Objects
Coded
TDD
Refactoring
IntegraRon
Test
Check
Test
Environment
MulRple
Units
Prepared
„Real“
Data
Coded
&
Configured
Expected
Output
Regression
Test
Replay
Unit-­‐
/
IntegraRon-­‐Tests
Don‘t
break
something
else
System
Tests
Manual
Exploratory
User
Mindset
Acceptance
NON-­‐funcRonal
Usability
Performance
Security
38

39. ConRnuous
IntegraRon
is
NOT
an
opRon
10.04.14
SAQ
Jahresversammlung
39
Build
Test
Deploy
Publish
reports

40. Idea
3
Rmes
as
Efficient
10.04.14
SAQ
Jahresversammlung
40
Idea
Idea
Idea
Product
Development
Do
the
Right
Thing!
Do
the
Thing
Right!
EffecRveness
Efficiency
3x

41. agility
accelerates
...
CONCLUSION
10.04.14
SAQ
Jahresversammlung
41

42. Idea
Build
Quality
In:
Boost
ProducRvity
10.04.14
SAQ
Jahresversammlung
42
Idea
Idea
Idea
Product
Development
Do
the
Right
Thing!
Do
the
Thing
Right!
EffecRveness
Efficiency
3 x 3 = 9

43. Do
the
Right
Thing
Do
the
Thing
Right
EffecRveness
Efficiency
Delivery
Products
Services
©
2012
-­‐
2014
pragmaRc
soluRons
gmbh
The
AdpaRve
PragmaRc
OrganisaRon

44. Network
&
Empowerment
Do
the
Right
Thing
Do
the
Thing
Right
OrganisaRon
EffecRveness
Efficiency
Culture
Context
&
Constraints
Delivery
Products
Services
©
2012
-­‐
2014
pragmaRc
soluRons
gmbh
The
AdpaRve
PragmaRc
OrganisaRon

45. Network
&
Empowerment
Do
the
Right
Thing
Do
the
Thing
Right
Strategy
OrganisaRon
EffecRveness
Efficiency
Culture
Context
&
Constraints
Delivery
Products
Services
©
2012
-­‐
2014
pragmaRc
soluRons
gmbh
The
AdpaRve
PragmaRc
OrganisaRon
ConRnuous
Improvement
&
InnovaRon

46. Mehr
zu
den
Herausforderungen
im
Management
des
21.
Jahrhunderts
10.04.14
SAQ
Jahresversammlung
46
25./26.
April
2014
hEp://zuerich.pm-­‐camp.org

47. 10.04.14
SAQ
Jahresversammlung
47

48. slideshare.net/pragmaticsolutions
info@pragmatic-­‐solutions.ch
@ramsyman
and/or
@pragsol
facebook.com/PragmaticSolutionsGmbh
plus.google.com/b/100642162720912501942
www.pragmaRc-­‐soluRons.ch
10.04.14
SAQ
Jahresversammlung
48