Guide to Technical
Practices
Chet Hendrickson - chet@hendricksonxp.com
Ron Jeffries - ronjeffries@acm.org
There are two kinds of
Scrum
- XP and the kind that
doesn’t work
While we are building the product, we also
build defects
Defects are “Negative Features”
3
We cannot predict
how long defect repair will take
4
How can we avoid defects?
Best known way:
Test, extensively, as we go!
5
Customer tests show Product Owner
that the Product actually WORKS!
6
Programmer tests show that
the CODE actually works
and points to causes of defects!
7
Tests must be automated!
Why?
There’s no other way to keep up with demand.

8
Customer Tests
“Confirmation” from the 3c’s
Two Types of Tests
Through the GUI
Selenium
Mercury
Behind the GUI
Fitnesse
Cucumber
Fitnesse
Test Suite
Individual Test
YEA!!!
Not DONE Yet
Getting Close
Size in Kg
1000

900

800

700

600

500

400

300

200

100

0

Application

Test
Programmer Tests
Tools

xUnit
gTest
MS UnitTest
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

1...
How ELSE might our apparent progress be wrong?
22
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
...
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...
Combined Burn Up
300

225

150

75

0

1

2

3

4

5

6

7

8

9

10

11

12

13

14
What if the design is bad?
We get more defects and slow down over time.
The progress line lies.
26
We must start with a simple ...
and therefore insufficient ...
design
27
We need to wind up with a larger design ...
and it needs to be good!
28
We need a continually improving design.
How is that even possible?
29
How do we move from one good design ...
to the next good design?
30
Refactoring
Why?
There’s no other way to ship every Sprint
from the beginning
and keep the code base alive.

31
Continuous Integration
How else will you know?
Tools
Jenkins/Hudson
CruiseControl
TeamCity
Continuum
Microsoft Team Foundation Server
CSD Techniques:
The professional way to do
Scrum.

•

Potentially shippable “DONE” Software Every
Sprint

•
•

Automated A...
The Nature of Software
Development:
The only way we know today.

•

Potentially shippable “DONE” Software Every
Sprint

•
...
Mon 1130 acacia_d_chethendricksonronjeffries
Mon 1130 acacia_d_chethendricksonronjeffries
Mon 1130 acacia_d_chethendricksonronjeffries
Mon 1130 acacia_d_chethendricksonronjeffries
Mon 1130 acacia_d_chethendricksonronjeffries
Mon 1130 acacia_d_chethendricksonronjeffries
Upcoming SlideShare
Loading in …5
×

Mon 1130 acacia_d_chethendricksonronjeffries

79
-1

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
79
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
3
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Mon 1130 acacia_d_chethendricksonronjeffries

  1. 1. Guide to Technical Practices Chet Hendrickson - chet@hendricksonxp.com Ron Jeffries - ronjeffries@acm.org
  2. 2. There are two kinds of Scrum - XP and the kind that doesn’t work
  3. 3. While we are building the product, we also build defects Defects are “Negative Features” 3
  4. 4. We cannot predict how long defect repair will take 4
  5. 5. How can we avoid defects? Best known way: Test, extensively, as we go! 5
  6. 6. Customer tests show Product Owner that the Product actually WORKS! 6
  7. 7. Programmer tests show that the CODE actually works and points to causes of defects! 7
  8. 8. Tests must be automated! Why? There’s no other way to keep up with demand. 8
  9. 9. Customer Tests “Confirmation” from the 3c’s
  10. 10. Two Types of Tests Through the GUI Selenium Mercury Behind the GUI Fitnesse Cucumber
  11. 11. Fitnesse
  12. 12. Test Suite
  13. 13. Individual Test
  14. 14. YEA!!!
  15. 15. Not DONE Yet
  16. 16. Getting Close
  17. 17. Size in Kg 1000 900 800 700 600 500 400 300 200 100 0 Application Test
  18. 18. Programmer Tests
  19. 19. Tools xUnit gTest MS UnitTest
  20. 20. 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
  21. 21. How ELSE might our apparent progress be wrong? 22
  22. 22. 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
  23. 23. 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
  24. 24. Combined Burn Up 300 225 150 75 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14
  25. 25. What if the design is bad? We get more defects and slow down over time. The progress line lies. 26
  26. 26. We must start with a simple ... and therefore insufficient ... design 27
  27. 27. We need to wind up with a larger design ... and it needs to be good! 28
  28. 28. We need a continually improving design. How is that even possible? 29
  29. 29. How do we move from one good design ... to the next good design? 30
  30. 30. Refactoring Why? There’s no other way to ship every Sprint from the beginning and keep the code base alive. 31
  31. 31. Continuous Integration How else will you know?
  32. 32. Tools Jenkins/Hudson CruiseControl TeamCity Continuum Microsoft Team Foundation Server
  33. 33. 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
  34. 34. 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
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×