This document provides an overview of technical practices for Scrum software development. It discusses the importance of testing, including customer acceptance tests to validate functionality and programmer tests to prevent defects. Tests must be automated and integrated continuously to ensure the code works properly and progresses are accurately tracked. The document also emphasizes refactoring and continuous design improvement through each sprint to deliver working software while maintaining code quality.

1. Guide to Technical
Practices
Chet Hendrickson - chet@hendricksonxp.com
Ron Jeffries - ronjeffries@acm.org

2. There are two kinds of
Scrum
- XP and the kind that
doesn’t work

3. While we are building the product, we also
build defects
Defects are “Negative Features”
3

4. We cannot predict
how long defect repair will take
4

5. How can we avoid defects?
Best known way:
Test, extensively, as we go!
5

6. Customer tests show Product Owner
that the Product actually WORKS!
6

7. Programmer tests show that
the CODE actually works
and points to causes of defects!
7

8. Tests must be automated!
Why?
There’s no other way to keep up with demand.
8

9. Customer Tests
“Confirmation” from the 3c’s

10. Two Types of Tests
Through the GUI
Selenium
Mercury
Behind the GUI
Fitnesse
Cucumber

11. Fitnesse

12. Test Suite

13. Individual Test

14. YEA!!!

16. Not DONE Yet

17. Getting Close

18. Size in Kg
1000
900
800
700
600
500
400
300
200
100
0
Application
Test

19. Programmer Tests

20. Tools
xUnit
gTest
MS UnitTest

21. Assertions Added
Per Iterations
600
540
480
420
360
300
240
180
120
60
0
1
2
3
4
5
6
7
8
Iteration
9
10
11
12
13
14

22. How ELSE might our apparent progress be wrong?
22

23. Expected Velocity
Burn Up
300
270
240
User Stories Done
210
180
150
120
90
60
30
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14

24. Usual Velocity
150
135
120
105
User Stories Done
90
75
60
45
30
15
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14

25. Combined Burn Up
300
225
150
75
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14

26. What if the design is bad?
We get more defects and slow down over time.
The progress line lies.
26

27. We must start with a simple ...
and therefore insufficient ...
design
27

28. We need to wind up with a larger design ...
and it needs to be good!
28

29. We need a continually improving design.
How is that even possible?
29

30. How do we move from one good design ...
to the next good design?
30

31. Refactoring
Why?
There’s no other way to ship every Sprint
from the beginning
and keep the code base alive.
31

32. Continuous Integration
How else will you know?

33. Tools
Jenkins/Hudson
CruiseControl
TeamCity
Continuum
Microsoft Team Foundation Server

39. CSD Techniques:
The professional way to do
Scrum.
•
Potentially shippable “DONE” Software Every
Sprint
•
•
Automated Acceptance Tests (ATDD)
Test-Driven Development
•
•
•
Automated Programmer Tests
Refactoring
Continuous Integration
39

40. The Nature of Software
Development:
The only way we know today.
•
Potentially shippable “DONE” Software Every
Sprint
•
•
Automated Acceptance Tests (ATDD)
Test-Driven Development
•
•
•
Automated Programmer Tests
Refactoring
Continuous Integration
40