Actually, that??™s not really
true. The essence of XP isn??™t its practices, but its approach to software development. [Beck 2004] describes XP
as including a philosophy of software development, a body of practices, a set of complementary principles,
and a community. Every experienced XP team will have its own way of practicing XP. As you master the art of
agile development, you will, too.
In Parts I and II of this book, I??™m going to perpetuate the little lie that there??™s just one way to do XP. It??™s a lot
easier to learn XP that way. As you learn, keep in mind that no practice is set in stone. You??™re always free to
experiment with changes. See ???The Road to Mastery??? in Chapter 2 and then turn to Part III for guidance.
There are a few differences between my approach to XP and what you??™ll find in other XP books. Most of the
differences are minor stylistic issues, but I??™ve also made a few important changes to XP??™s planning and
acceptance testing practices. I made these changes to address common problems I observed when working
with XP teams. Like XP itself, these changes are the result of several years of iterative refinement.
One of the problems I??™ve noticed with XP teams is that the on-site customers often have difficulty with release
planning.
Pages:
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69