Questioning Extreme Programming
Published on 5. August 2002
Book
Paperback/Softback
224 pages
978-0-201-84457-3 (ISBN)
Description
Ever since Extreme Programming burst on to the application development scene in 1998, it has been a lightning rod for controversy. With its emphasis on programmer-based development, many professionals love it. However, Extreme Programming contradicts many of the traditional beliefs in software development; therefore, many professionals hate it. Either way, potential adopters and opponents need to make decisions on Extreme Programming. In Questioning Extreme Programming, author Pete McBreen puts this agile approach to application development under the microscope, and closely examines both sides of this heated debate.
More details
Language
English
Place of publication
Boston
United States
Publishing group
Pearson Education (US)
Target group
College/higher education
Dimensions
Height: 234 mm
Width: 187 mm
Thickness: 14 mm
Weight
462 gr
ISBN-13
978-0-201-84457-3 (9780201844573)
Copyright in bibliographic data and cover images is held by Nielsen Book Services Limited or by the publishers or by their respective licensors: all rights reserved.
Schweitzer Classification
Person
Pete McBreen is an independent consultant who actually enjoys writing and delivering software. Despite spending a lot of time writing, teaching, and mentoring, he goes out of his way to ensure that he does hands-on coding on a live project every year. Pete specializes in finding creative solutions to the problems that software developers face. After many years of working on formal and informal process improvement initiatives, he took a sideways look at the problem and realized, "Software development is meant to be fun. If it isn't, the process is wrong." Pete lives in Cochrane, Alberta, Canada and has no plans to move back to a big city.
0201844575AB07092002
0201844575AB07092002
Content
(NOTE: Each chapter concludes with a Summary.)
Foreword.
Preface.
Adopting Extreme Programming.
Resisting Extreme Programming.
Looking for Alternatives to Extreme Programming.
Improving Your Current Software Development Process.
Why You Should Read This Book.
Acknowledgments.
I. INTRODUCTION.
1. XP: Hype or HyperProductive?
Sample Claims, Counter Claims, and Misinformation.
Is There Any Hard Evidence to Support the Claims for XP?
All Processes Are Situational.
Do You Need Process Improvement or Process Change?
Understanding Software Development Processes.
Understanding the Controversy Around XP.
Is XP an Option for You?
II. WHAT IS A METHODOLOGY?
2. What Do Methodologies Optimize?
Why the Focus on Fear?
Methodologies Record Bad Experiences on Projects.
What Do Developers Look for in a Process?
Experience, Talent, and Tacit Knowledge.
Heavy, Rigorous, Tailorable, Light, Minimal, and Agile Methodologies.
3. What Are XP Projects Scared Of?
XP Was Created to Address Project Risks.
But Project Risks Are Symptoms, Not the Disease.
4. What Do Other Methodologies Consider Important?
What Do Software Engineering Projects Consider Important?
What Do Open Source Projects Consider Important?
What Is Important to Agile Projects?
5. What Is Important for Your Projects?
Reinterpreting Experience in the Light of New Knowledge.
Understanding Process, Culture, and Methodologies.
Maintenance and Evolution of the Software.
Can a Methodology per Project Really Work?
So What Is Important to Your Projects?
Learning From XP to Improve Your Process.
III. QUESTIONING THE CORE XP PRACTICES.
6. Planning Incremental Development.
Small Releases.
User Stories.
Planning Game.
Open Questions.
What Can Other Approaches Learn From XP?
7. Truly Incremental Development.
Simple DesignRefactoring.
System MetaphorCollective Code Ownership.
Continuous Integration.
Open Questions.
What Can Other Approaches Learn From XP?
8. Are We Done Yet?
Coding Standards.
Test First Development.
Acceptance Tests.
Open Questions.
What Can Other Approaches Learn From XP?
9. Working at This Intensity Is Hard.
Forty-Hour Work Week.
Pair Programming.
On-Site Customer.
Open Questions.
What Can Other Approaches Learn From XP?
10. Is That All There Is to Extreme Programming?
Keeping an XP Project On Process.
Continuous Reflection.
Distributed Development and Extreme Programming.
Open Questions.
What Can Other Approaches Learn From XP?
IV. QUESTIONING XP CONCEPTS.
11. The Source Code Is the Design?
Software Development Is Mainly a Design Activity.
Managing Complexity.
Why Now? What Has Changed?
What Does This Mean for XP?
12. Test First Development?
But Do Programmers Know Enough About Testing?
How Expensive Are Automated Acceptance Tests?
Effectively Defect-Free Versus Good Enough Software.
What About Code That Is Hard to Test?
Can Acceptance Tests Be Used to Measure Progress?
Does XP Do Proper Testing?
Why Now? What Has Changed?
What Does This Mean for XP?
13. Large-Scale XP?
Are Large Teams a Goal?
Long-Running Projects.
Coordinating Multiple Teams.
Is It OK for a Process to Have Limits?
Why Now? What Has Changed?
What Does This Mean for XP?
14. Is the Cost of Change Really Low?
What Is the Cost of a Requirements Change?
What Is the Cost of Fixing a Bug?
What Is the Cost of Fixing a Design Error?
What Is the Cost of Fixing an Error of Understanding?
What Is the Cost of a Release?
Why Now? What Has Changed?
What Does This Mean for XP?
15. Setting the Dials on Ten.
What About the Overdose Effect?
Pretty Adventuresome Programming.
Why Now? What Has Changed?
What Does This Mean for XP?
16. Requirements: Documentation or a Conversation?
Can Changes to Requirements be Controlled?
Requirements Traceability Is One Way to Handle Change.
Does the On-Site Customer Know Enough?
Emergent Requirements.
Why Now? What Has Changed?
What Does This Mean for XP?
17. Is Oral Documentation Enough?
Who Reads the Documentation?
Is a Handoff to Maintenance Useful?
Can Maintainers Really Rely on the Documentation?
Why Now? What Has Changed?
What Does This Mean for XP?
18. Playing to Win?
Does XP Actively Manage All Risks?
Does XP Require Experienced Teams?
Can We Win With a Team of Novices?
Why Now? What Has Changed?
What Does This Mean for XP?
V. UNDERSTANDING THE XP COMMUNITY.
19. ReallyStrangeSayings.
MixedCase and Initial-Slang.
WikiWords Are Not Always Politically Correct.
YouAren'tGonnaNeedIt.
The Source Code Is the Design.
OnceAndOnlyOnce.
Do the Simplest Thing That Could Possibly Work.
Getting Beyond the Sayings.
20. Feel the Hostility; Experience the Joy.
Just a Bunch of Undisciplined Hacker Cowboys?
Is XP a Return to the Dark Ages?
The Best Project We Have Ever Worked On!
Developers Are Attracted to XP.
So Is XP a Cult?
21. Transitioning Away From Extreme Programming.
Does XP Lock a Project into the Extreme Practices?
Welcome to the Hotel California?
Retraining Extreme Programmers.
Retraining Customers.
What Is Next After Extreme Programming?
Where Will the Next Process Come From?
VI. YOUR CHOICE.
22. Is XP for You?
Is Your Current Approach Broken?
Is Your Organization Ready for XP?
Do Your Developers Want to Use XP?
Is Your Customer Ready for XP?
Are Your Projects Suitable for XP?
But We Can Overcome These Difficulties.
Applying the Lessons of Extreme Programming.
Do You Really Need to Adopt XP?
Rolling Your Own Process.
23. Do You Have a Suitable First Project?
Assessing Projects for Suitability to Extreme Programming.
Preparing Your XP Team.
Epilogue.
Bibliography.
Index. 0201844575T07092002
Foreword.
Preface.
Adopting Extreme Programming.
Resisting Extreme Programming.
Looking for Alternatives to Extreme Programming.
Improving Your Current Software Development Process.
Why You Should Read This Book.
Acknowledgments.
I. INTRODUCTION.
1. XP: Hype or HyperProductive?
Sample Claims, Counter Claims, and Misinformation.
Is There Any Hard Evidence to Support the Claims for XP?
All Processes Are Situational.
Do You Need Process Improvement or Process Change?
Understanding Software Development Processes.
Understanding the Controversy Around XP.
Is XP an Option for You?
II. WHAT IS A METHODOLOGY?
2. What Do Methodologies Optimize?
Why the Focus on Fear?
Methodologies Record Bad Experiences on Projects.
What Do Developers Look for in a Process?
Experience, Talent, and Tacit Knowledge.
Heavy, Rigorous, Tailorable, Light, Minimal, and Agile Methodologies.
3. What Are XP Projects Scared Of?
XP Was Created to Address Project Risks.
But Project Risks Are Symptoms, Not the Disease.
4. What Do Other Methodologies Consider Important?
What Do Software Engineering Projects Consider Important?
What Do Open Source Projects Consider Important?
What Is Important to Agile Projects?
5. What Is Important for Your Projects?
Reinterpreting Experience in the Light of New Knowledge.
Understanding Process, Culture, and Methodologies.
Maintenance and Evolution of the Software.
Can a Methodology per Project Really Work?
So What Is Important to Your Projects?
Learning From XP to Improve Your Process.
III. QUESTIONING THE CORE XP PRACTICES.
6. Planning Incremental Development.
Small Releases.
User Stories.
Planning Game.
Open Questions.
What Can Other Approaches Learn From XP?
7. Truly Incremental Development.
Simple DesignRefactoring.
System MetaphorCollective Code Ownership.
Continuous Integration.
Open Questions.
What Can Other Approaches Learn From XP?
8. Are We Done Yet?
Coding Standards.
Test First Development.
Acceptance Tests.
Open Questions.
What Can Other Approaches Learn From XP?
9. Working at This Intensity Is Hard.
Forty-Hour Work Week.
Pair Programming.
On-Site Customer.
Open Questions.
What Can Other Approaches Learn From XP?
10. Is That All There Is to Extreme Programming?
Keeping an XP Project On Process.
Continuous Reflection.
Distributed Development and Extreme Programming.
Open Questions.
What Can Other Approaches Learn From XP?
IV. QUESTIONING XP CONCEPTS.
11. The Source Code Is the Design?
Software Development Is Mainly a Design Activity.
Managing Complexity.
Why Now? What Has Changed?
What Does This Mean for XP?
12. Test First Development?
But Do Programmers Know Enough About Testing?
How Expensive Are Automated Acceptance Tests?
Effectively Defect-Free Versus Good Enough Software.
What About Code That Is Hard to Test?
Can Acceptance Tests Be Used to Measure Progress?
Does XP Do Proper Testing?
Why Now? What Has Changed?
What Does This Mean for XP?
13. Large-Scale XP?
Are Large Teams a Goal?
Long-Running Projects.
Coordinating Multiple Teams.
Is It OK for a Process to Have Limits?
Why Now? What Has Changed?
What Does This Mean for XP?
14. Is the Cost of Change Really Low?
What Is the Cost of a Requirements Change?
What Is the Cost of Fixing a Bug?
What Is the Cost of Fixing a Design Error?
What Is the Cost of Fixing an Error of Understanding?
What Is the Cost of a Release?
Why Now? What Has Changed?
What Does This Mean for XP?
15. Setting the Dials on Ten.
What About the Overdose Effect?
Pretty Adventuresome Programming.
Why Now? What Has Changed?
What Does This Mean for XP?
16. Requirements: Documentation or a Conversation?
Can Changes to Requirements be Controlled?
Requirements Traceability Is One Way to Handle Change.
Does the On-Site Customer Know Enough?
Emergent Requirements.
Why Now? What Has Changed?
What Does This Mean for XP?
17. Is Oral Documentation Enough?
Who Reads the Documentation?
Is a Handoff to Maintenance Useful?
Can Maintainers Really Rely on the Documentation?
Why Now? What Has Changed?
What Does This Mean for XP?
18. Playing to Win?
Does XP Actively Manage All Risks?
Does XP Require Experienced Teams?
Can We Win With a Team of Novices?
Why Now? What Has Changed?
What Does This Mean for XP?
V. UNDERSTANDING THE XP COMMUNITY.
19. ReallyStrangeSayings.
MixedCase and Initial-Slang.
WikiWords Are Not Always Politically Correct.
YouAren'tGonnaNeedIt.
The Source Code Is the Design.
OnceAndOnlyOnce.
Do the Simplest Thing That Could Possibly Work.
Getting Beyond the Sayings.
20. Feel the Hostility; Experience the Joy.
Just a Bunch of Undisciplined Hacker Cowboys?
Is XP a Return to the Dark Ages?
The Best Project We Have Ever Worked On!
Developers Are Attracted to XP.
So Is XP a Cult?
21. Transitioning Away From Extreme Programming.
Does XP Lock a Project into the Extreme Practices?
Welcome to the Hotel California?
Retraining Extreme Programmers.
Retraining Customers.
What Is Next After Extreme Programming?
Where Will the Next Process Come From?
VI. YOUR CHOICE.
22. Is XP for You?
Is Your Current Approach Broken?
Is Your Organization Ready for XP?
Do Your Developers Want to Use XP?
Is Your Customer Ready for XP?
Are Your Projects Suitable for XP?
But We Can Overcome These Difficulties.
Applying the Lessons of Extreme Programming.
Do You Really Need to Adopt XP?
Rolling Your Own Process.
23. Do You Have a Suitable First Project?
Assessing Projects for Suitability to Extreme Programming.
Preparing Your XP Team.
Epilogue.
Bibliography.
Index. 0201844575T07092002