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 been reading the discussion here concerning the book, but as a junior developer who's looking into the agile methodologi.
What makes this book different than many other books? I found the table of contents on the Library of Congress homepage and my initial thought was that your book was for senior developers or project managers. If I read Craig Larmans book I know I'll learn how to perform OO Analysis and Design, but im still not sure if this is an entry level book on agile development, or if this is supposed to build on top of the knowledge you get from reading many of the Agile Development books "out there".
What makes this book different than others is that it provides guidance on how to incrementally improve your processes. Most books will cover a single methodology, such as XP, with the assumption that you change everything you do and follow the new methodology. If you want to make small changes to what you are currently doing, and improve over time, then this book is good for that.
Originally posted by Bruce MacIsaac: Most books will cover a single methodology, such as XP, with the assumption that you change everything you do and follow the new methodology.
Actually "Extreme Programming Explained, 2nd. ed." doesn't do that, if I remember correctly.
In fact I agree with Jim Highsmith that talking about "Agile methodologies" or "Agile processes" is kind of misleading, as Agility is, besides other things, about "People and there Interactions over Processes and Tools", remember?
On the other hand, there is a danger in adopting an Agile approache in small steps - when you are new to Agility, you probably will have trouble seeing how the single pieces are supposed to fit together and might easily choose steps that only provide you a small part of the benefit you could otherwise get.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
sure, you get more benefits when you adopt more agile practices rather than fewer, but I am not sure I understand your reasoning. In our experience, many organizations are not able to go "the full way in one shot, starting tomorow", so an incremental approach seems to be the norm. I have e.g. not met that many projects adopting all of XPs practices, but they rather pick some of them. This is not necessrily bad, you need to start somewhere, and all practices are not for all organizations (for a variety of reasons).
So, it seems to be useful to do incremental adoption, most organizations are adopting agile development thwta way, and we hence think that a framework that provides a more structured approach for accomplish such an incremental adoption is of value. Hence the reason for the book...