Extreme Programming Explained: Embrace Change / Edition 1by Kent Beck
Pub. Date: 10/08/1999
Publisher: Pearson Education
Extreme Programming (XP) was conceived and developed to address the specific needs of software development conducted by small teams in the face of vague and changing requirements. This new lightweight methodology challenges many conventional tenets, including the long-held assumption that the cost of changing a piece of software necessarily rises dramatically
Extreme Programming (XP) was conceived and developed to address the specific needs of software development conducted by small teams in the face of vague and changing requirements. This new lightweight methodology challenges many conventional tenets, including the long-held assumption that the cost of changing a piece of software necessarily rises dramatically over the course of time. XP recognizes that projects have to work to achieve this reduction in cost and exploit the savings once they have been earned.
Fundamentals of XP include:
- Distinguishing between the decisions to be made by business interests and those to be made by project stakeholders.
- Writing unit tests before programming and keeping all of the tests running at all times.
- Integrating and testing the whole systemseveral times a day.
- Producing all software in pairs, two programmers at one screen.
- Starting projects with a simple design that constantly evolves to add needed flexibility and remove unneeded complexity.
- Putting a minimal system into production quickly and growing it in whatever directions prove most valuable.
Why is XP so controversial? Some sacred cows don't make the cut in XP:
- Don't force team members to specialize and become analysts, architects, programmers, testers, and integratorsevery XP programmer participates in all of these critical activities every day.
- Don't conduct complete up-front analysis and designan XP project starts with a quick analysis of the entire system, and XP programmers continue to make analysis and design decisions throughout development.
- Develop infrastructure and frameworks as you develop your application, not up-frontdelivering business value is the heartbeat that drives XP projects.
- Don't write and maintain implementation documentationcommunication in XP projects occurs face-to-face, or through efficient tests and carefully written code.
You may love XP, or you may hate it, but Extreme Programming Explained will force you to take a fresh look at how you develop software.
Table of ContentsForeword by Erich Gamma.
I. THE PROBLEM.1. Risk: The Basic Problem.
2. A Development Episode.
3. Economics of Software Development.
4. Four Variables.
Focus on Scope.
5. Cost of Change.
6. Learning to Drive.
7. Four Values.
The Values in Practice.
8. Basic Principles.
9. Back to Basics.
II. THE SOLUTION.
10. Quick Overview.
11. How Could This Work?
12. Management Strategy.
13. Facilities Strategy.
14. Splitting Business and Technical Responsibility.
What to Do?
Choice of Technology.
What If It Is Hard?
15. Planning Strategy.
The Planning Game.
Planning in a Week.
16. Development Strategy.
17. Design Strategy.
The Simplest Thing that Could Possibly Work.
How Does Designing Through Refactoring Work?
What Is Simplest?
How Could This Work?
Role of Pictures in Design.
18. Testing Strategy.
Who Writes Tests?
19. Adopting XP.
21. Lifecycle of an Ideal XP Project.
Iterations to First Release.
22. Roles for People.
23. 20-80 Rule.
24. What Makes XP Hard.
25. When to Try XP.
26. XP at Work.
Time and Materials.