Résumé
Even as the popularity of Extreme Programming (XP) grows,
many programmers and developers are still looking for
practical advice on getting started. They are finding
themselves in search of a roadmap which points them down
paths clear of obstacles and other diversions to initiating
the XP ideology.
1. The Courage to Begin.
2. Introducing XP.
3. Taming the Resistance.
4. Manager Resistance.
6. Having the Right Attitude.
7. The Bare Essentials.
8. Exception Handling.
9. Can We Talk?
10. Planning Roles and Reality.
11. Project Planning.
12. Iteration Planning.
13. Write the Tests, Run the Tests.
14. Stop the Maverick.
15. Making It Right.
16. Pulling It Together.
18. Designing the Simple.
19. It's Everybody's Job.
20. Where's the Customer?
21. Knowing When You're Done.
22. Don't Get Distracted by the Code.
23. Overtime Is Not the Answer.
24. Painting a Thousand Words.
25. Looking for Guidance.
26. Keeping Score.
27. Selling XP.
28. XP and Startups.
29. Scaling XP.
30. The Next Best Thing to Being There.
31. Measuring XP.
32. Where to Next?
Index.
Extreme Programming Applied is a pragmatic guide to getting started with Extreme Programming. It helps programmers and project managers take their first steps toward applying the XP discipline. This book is not a tutorial; it uses real-world experience to educate readers about applying XP to their organizations. The authors offer advice on implementing XP in your organization, illustrating key points with stories from pioneers who have successfully introduced XP.
XP is a significant departure from traditional software development methods, ushering in a change for both developers and business people. It is an agile methodology, which enables highly productive teams to produce quality software from rapidly changing or unclear requirements. XP is disciplined software craftsmanship, elevating best practices in software analysis, design, testing, implementation and project management to a new level. Extreme Programming Applied helps readers begin using the principles behind this revolutionary concept.
Developing software is a challenge. Using XP can help you over the hills and through the valleys, increasing your chances for creating reliable, flexible software on a routine basis. Extreme Programming Applied is the guide you need for getting on your way.
Table of Contents
List of Pioneer Stories.
Foreword.
Preface.
Acknowledgments.
Introduction: Playing to Win!
0. BEFORE YOU START.
0. XP Distilled.The Planning Game.
Testing.
Pair Programming.
Refactoring.
Simple Design.
Collective Code Ownership.
Continuous Integration.
On-Site Customer.
Small Releases.
40-Hour Week.
Coding Standards.
System Metaphor.
The Practices Work Together.
Testing.
Pair Programming.
Refactoring.
Simple Design.
Collective Code Ownership.
Continuous Integration.
On-Site Customer.
Small Releases.
40-Hour Week.
Coding Standards.
System Metaphor.
The Practices Work Together.
I. THE RIGHT MINDSET.
1. The Courage to Begin.
The Organizational
Imperative.
Your Role.
Your Role.
2. Introducing XP.
Bring a Friend.
Find a Target.
Assemble the Right Tools.
Driving Spikes.
It's All Right to Feel Awkward.
Find a Target.
Assemble the Right Tools.
Driving Spikes.
The Lone Wolf.
A Single Pair.
A Small Team.
A Small Team with a Lead Developer.
A Single Pair.
A Small Team.
A Small Team with a Lead Developer.
It's All Right to Feel Awkward.
3. Taming the Resistance.
Where Resistance Comes
From.
The Result That Matters.
What Not to Do.
The Result That Matters.
What Not to Do.
4. Manager Resistance.
The Manager Perspective on
Winning.
XP Is Too New to Trust.
XP Is Simplistic.
Pair Programming Is Too Expensive.
I Can't Afford a Full-Time, On-Site Customer.
XP Is Too Informal.
Be Wary of “XP-Lite” .
5.Developer Resistance.
Developers Are Different.
The Developer Perspective on Winning.
XP Is Too Simplistic.
I Won't Like Pair Programming.
XP Is Weird.
XP Doesn't Give Us Enough Information.
XP Is Too New to Trust.
XP Is Simplistic.
Pair Programming Is Too Expensive.
I Can't Afford a Full-Time, On-Site Customer.
XP Is Too Informal.
Be Wary of “XP-Lite” .
5.Developer Resistance.
Developers Are Different.
The Developer Perspective on Winning.
XP Is Too Simplistic.
I Won't Like Pair Programming.
XP Is Weird.
XP Doesn't Give Us Enough Information.
6. Having the Right Attitude.
Honesty and Trust.
Humility.
Sweet Freedom.
Humility.
Sweet Freedom.
II. First Things First.
7. The Bare Essentials.
The First Step.
The XP Essentials.
Remember the XP Values.
The XP Essentials.
Remember the XP Values.
Think Simply.
Get Feedback Early and Often.
Communicate.
Be Courageous.
Get Feedback Early and Often.
Communicate.
Be Courageous.
8. Exception Handling.
Handling XP Exceptions
Like Code Exceptions.
An Odd Number of Developers.
The Customer Won't Write Stories.
The Customer Won't Write Acceptance Tests.
Management Sets Unrealistic Schedules.
Management Doesn't Like Your Estimates.
Management Won't Let You Pair.
The Cost of Tea in China Doubles.
An Odd Number of Developers.
The Customer Won't Write Stories.
The Customer Won't Write Acceptance Tests.
Management Sets Unrealistic Schedules.
Management Doesn't Like Your Estimates.
Management Won't Let You Pair.
The Cost of Tea in China Doubles.
9. Can We Talk?
Pair Programming.
Stand-Up Meetings.
Planning.
Atmosphere and Environment.
It Doesn't Stop There.
Stand-Up Meetings.
Planning.
Atmosphere and Environment.
It Doesn't Stop There.
10. Planning Roles and Reality.
How XP Planning Is
Different.
How to Steer.
Out in the Open.
Requirements are a Dialogue—Not a Document.
Learning Roles.
The Customer.
The Developer.
A Tool to Introduce Reality.
How the Roles Work with Multiple Projects.
When Roles Are Clear.
The Xtreme Hour.
How to Steer.
Out in the Open.
Requirements are a Dialogue—Not a Document.
Learning Roles.
The Customer.
The Developer.
A Tool to Introduce Reality.
How the Roles Work with Multiple Projects.
When Roles Are Clear.
The Xtreme Hour.
11. Project Planning.
Charting the Course.
The Planning Game.
Exploration Phase.
The Planning Game.
The Customer Writes
Stories.
The Developers Estimate.
Breaking Down Stories.
Back to Estimating.
Determining Iteration Size.
Sorting the Stories.
The Developers Estimate.
Breaking Down Stories.
Back to Estimating.
Determining Iteration Size.
Sorting the Stories.
Exploration Phase.
12. Iteration Planning.
What Plans Are.
The Iteration Planning Game.
Task Exploration.
Iteration Plan Verification.
How to Start Planning.
The Art of Estimation.
Velocity.
The Last Word on Iterations and Planning.
The Iteration Planning Game.
Task Exploration.
Iteration Plan Verification.
One at a Time.
Fill Your Bag.
Fill Your Bag.
How to Start Planning.
The Art of Estimation.
Velocity.
The Last Word on Iterations and Planning.
13. Write the Tests, Run the Tests.
Keeping Code Clean.
Confidence.
Tests as Documentation.
How to Write Tests First.
What to Test.
How to Start Writing Tests First.
Testing Challenges.
Confidence.
Tests as Documentation.
How to Write Tests First.
What to Test.
How to Start Writing Tests First.
Testing Challenges.
Testing User
Interfaces.
Testing in Small Spaces.
Testing the Web.
Tests Have to Run Fast.
Testing in Small Spaces.
Testing the Web.
Tests Have to Run Fast.
14. Stop the Maverick.
Code Quality.
The Need for Speed.
Reducing Risk.
How to Pair Program.
Pair-Friendly Space.
Don't Ignore Problem Children.
Taking It to the Next Level.
The Inevitable Objections.
When Not to Pair.
Unusual Pairs.
Personal Space.
How to Start Pair Programming.
The Need for Speed.
Reducing Risk.
How to Pair Program.
Pair-Friendly Space.
Don't Ignore Problem Children.
Taking It to the Next Level.
The Inevitable Objections.
When Not to Pair.
Unusual Pairs.
Personal Space.
How to Start Pair Programming.
15. Making It Right.
Being Ready for
Change.
Making Change Possible.
Putting Learning into Your Code.
How to Refactor.
When to Refactor.
When Not to Refactor.
When to Stop Refactoring.
How to Start Refactoring.
Why People Don't Refactor.
Making Change Possible.
Putting Learning into Your Code.
How to Refactor.
When to Refactor.
When Not to Refactor.
When to Stop Refactoring.
How to Start Refactoring.
Why People Don't Refactor.
16. Pulling It Together.
Maintaining Speed.
Reducing Risk.
How to Integrate Continuously.
How to Start Integrating Continuously.
Techniques to Make It Easier. Chapter 17 Staying on Process.
Why Teams Lose Their Way.
How to Get Back on Process.
Reducing Risk.
How to Integrate Continuously.
How to Start Integrating Continuously.
Techniques to Make It Easier. Chapter 17 Staying on Process.
Why Teams Lose Their Way.
How to Get Back on Process.
III. THE REST OF THE STORY.
18. Designing the Simple.
Defining Simplicity.
Why People Don't Keep It Simple.
Why Keep Things Simple?
How to Start Doing Simple Design.
Why Not Start with Simple Design?
The Essential Design Tool.
Why People Don't Keep It Simple.
Why Keep Things Simple?
How to Start Doing Simple Design.
Why Not Start with Simple Design?
The Essential Design Tool.
19. It's Everybody's Job.
What Collective Ownership
Means.
Moving From “I” to “We” .
Why Have Collective Code Ownership?
How to Start Having Collective Code Ownership.
Why Not Start with Collective Code Ownership?
Moving From “I” to “We” .
Why Have Collective Code Ownership?
How to Start Having Collective Code Ownership.
Why Not Start with Collective Code Ownership?
20. Where's the Customer?
Why Have an On-Site
Customer?
On-Site Versus Available When Needed.
How to Get an On-Site Customer.
Why Not Start with an On-Site Customer?
On-Site Versus Available When Needed.
How to Get an On-Site Customer.
Why Not Start with an On-Site Customer?
21. Knowing When You're Done.
Customer Confidence.
Acceptance Tests as Documentation.
How to Write Acceptance Tests.
Automating Acceptance Tests.
What to Test.
How to Start Writing Acceptance Tests.
Why Not Start with Acceptance Testing?
Acceptance Tests as Documentation.
How to Write Acceptance Tests.
Automating Acceptance Tests.
What to Test.
How to Start Writing Acceptance Tests.
Why Not Start with Acceptance Testing?
22. Don't Get Distracted by the Code.
Why Have Coding
Standards?
How to Start Having Coding Standards.
Why Not Start with a Coding Standard?
How to Start Having Coding Standards.
Why Not Start with a Coding Standard?
23. Overtime Is Not the Answer.
Why People Work Too
Much.
What's Wrong with Burning the Midnight Oil?
How to Start Working Normal Hours.
Why Not Start with a 40-Hour Week?
What's Wrong with Burning the Midnight Oil?
How to Start Working Normal Hours.
Why Not Start with a 40-Hour Week?
24. Painting a Thousand Words.
Where the Concept of
Metaphor Came From.
How to Start Creating Metaphors.
Why Not Start with a Metaphor?
How to Start Creating Metaphors.
Why Not Start with a Metaphor?
25. Looking for Guidance.
Why You Do Need a
Coach.
What If We Don't Have a Coach?
Rookie Coaches.
How to Coach.
Minimal Coaching.
How About a Player/Coach?
Why Start Without a Coach?
What If We Don't Have a Coach?
Rookie Coaches.
How to Coach.
Minimal Coaching.
How About a Player/Coach?
Why Start Without a Coach?
26. Keeping Score.
What to Track.
How to Track.
Why Not Start with a Tracker?
How to Track.
Why Not Start with a Tracker?
IV. UNCHARTED TERRITORY.
27. Selling XP.
Erasing Objections.
How to Sell XP.
The Results.
Proving It.
Developing a Track Record.
Relationships Sell.
How to Sell XP.
The Results.
Proving It.
Developing a Track Record.
Relationships Sell.
28. XP and Startups.
The Target.
The Pitch.
Entrepreneurs.
Venture Capitalists.
Selling to Startups.
Strategic Initiatives: Startups in Disguise.
Joining Them.
The Pitch.
Entrepreneurs.
Venture Capitalists.
Selling to Startups.
Strategic Initiatives: Startups in Disguise.
Joining Them.
29. Scaling XP.
Does Anything Really
Scale?
Should You Need to Scale?
Why Can't XP Scale?
When to Scale.
How to Scale.
Reserving Judgment.
Should You Need to Scale?
Why Can't XP Scale?
When to Scale.
How to Scale.
Reserving Judgment.
30. The Next Best Thing to Being There.
The Limits of
Technology.
Can a Team Telecommute?
When to Try Distributed XP.
Can a Team Telecommute?
When to Try Distributed XP.
31. Measuring XP.
What to Measure.
The XP Challenge.
The Before-and-After Study.
What Having the Numbers Will Mean.
The XP Challenge.
The Before-and-After Study.
What Having the Numbers Will Mean.
32. Where to Next?
Index.
Caractéristiques techniques
| PAPIER | |
| Éditeur(s) | Addison Wesley |
| Auteur(s) | Ken Auer, Roy Miller |
| Parution | 25/10/2001 |
| Nb. de pages | 326 |
| Format | 18 x 23,4 |
| Couverture | Broché |
| Poids | 581g |
| Intérieur | Noir et Blanc |
| EAN13 | 9780201616408 |
Avantages Eyrolles.com
Livraison à partir de 0,01 € en France métropolitaine
Paiement en ligne SÉCURISÉ
Livraison dans le monde
Retour sous 15 jours
+ d'un million et demi de livres disponibles
Consultez aussi
- Les meilleures ventes en Graphisme & Photo
- Les meilleures ventes en Informatique
- Les meilleures ventes en Construction
- Les meilleures ventes en Entreprise & Droit
- Les meilleures ventes en Sciences
- Les meilleures ventes en Littérature
- Les meilleures ventes en Arts & Loisirs
- Les meilleures ventes en Vie pratique
- Les meilleures ventes en Voyage et Tourisme
- Les meilleures ventes en BD et Jeunesse
