This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
I've read "Agile Software Development Methods Review and Analysis" from VTT, which covers 8 (+other) agile development approaches. The Amazon.com description of this book says that it is focused on Extreme Programming. Why should I be interested in a book with this narrow focus? And why isn't the book called "Extreme Programming" rather than using the title that suggests a broader treatment of the subject? [ October 30, 2007: Message edited by: Roger F. Gay ]
I think the length of VTT's paper helps answer your question. There are excellent books that provide overviews, such as Cockburn's Agile Software Development and Highsmith's Agile Software Development Ecosystems. The downside of these books is that their breadth make it impossible to discuss how to put the ideas into practice. What does test-driven development look like? How do you choose your on-site customer? How do you create a release plan? These questions need an in-depth treatment.
We chose to focus on one method because it allowed us to go very deep. (The book still ended up 400 pages long!) For example, even Kent Beck's Extreme Programming Explained only spends four or five paragraphs on the "Slack" practice. We give it seven pages, and there's no fluff in there, either.
That said, XP isn't our sole focus in the book. This may sound a little mystical, but our goal for the book was to allow capable, motivated readers to master the art of agile development. We follow a pattern called "Shu-Ha-Ri" in martial arts, which approximately translates as "Learn the Rules, Break the Rules, Leave the Rules". The idea behind this pattern is that beginners do best when they have simple, unambiguous rules to follow ("Learn the Rules"). As they learn, they need more nuance and flexibility--they need to learn when rules can be changed and improved ("Break the Rules"). Over time, the ideas become so ingrained that they become second nature, no rules needed ("Leave the Rules").
We start by providing a clear, unambiguous scenario that's easy to understand and apply. Over time, I expect that our readers will discover that our "rules" don't apply perfectly to their situation. (How could they?) We help them by discussing contraindications and alternatives along with each practice. In Part III, we explicitly leave XP behind and talk about how and when to break rules.
I think our book hits a perfect balance of depth and breadth. We cover all aspects of software development, yet we don't cover so many agile methods that we can't talk about "how" or give specific hints. I think it's a good balance.
James Shore, coauthor of <a href="http://www.amazon.com/Art-Agile-Development-James-Shore/dp/0596527675" target="_blank" rel="nofollow">The Art of Agile Development</a>. Website and blog at <a href="http://www.jamesshore.com" target="_blank" rel="nofollow">http://www.jamesshore.com</A> .