Customer Reviews
A treasure. How to apply Extreme Programming in a real project - By: Dr. R. Spooner, 19 Nov 2008 
This book is a treasure. Not only does it explain Agile Development
clearly & entertainingly, but it is thoroughly groundedin how it pans
outin real organisations. It also covers several business & software
engineering issues which I didn't expect, such as unit testing
techniques & process improvement.
It is aimed at people who want to start using Extreme Programming on
their software development projects. It seems that XP is almost, but not
quite, synonymous with Agile Development. For each of its principles, we
learn the concept, what the outcome should be, how it might go wrong,
and where to read more. Sometimes there is a short FAQ section. If your
existing organisation can't incorporate this principle; sometimes you
can make up for itin other ways, or sometimes you can follow the
principle while still satisfying your bosses.
The book starts with the thoughtful principles of XP, such as pair
programming (continuous review & better design through discussion),
energised work (sleep well, be motivated, & focus whenin the
office), an informative workspace (sharing progress with the team),
root cause analysis (ask "why" 5 times, to get to a more substantial
answer), retrospectives. The book goes on to collaborating: sit
together, real customer involvement, & more. The next part is
releasing: continuous integration, weekly iterations, all the follow-on
tasks like integration done. Planning includes product vision, release
planning, iterations (development cycles), risk, stories (tasks), and
estimating. Finally, the principles of development include incremental
requirements, test-driven development, refactoring, & simplicity.
The book is designed either to be dipped into, having cross references
and a target audience for each section, or to be read cover to cover.
It's really all about how to apply Agile Development within a real
project. What should you do if some people don't want to join in? How
large or small can a team be? What information do you share with
stakeholders outside the team itself? Can you manage without a
particular principle?
Despite having started with a tone that didn't capture my enthusiasm
immediately, the body of the book is engagingly & genuinely plausible.
The authors have workedin real companies on real projects, & know how
to get Agile to work. Personally however, I tend to feel that Agile
development works better with trustworthy, skilled & flexible staff,
than with "entry-level" skills. If people don't have the confidence to
go from designing to testing to developing to releasing all within the
same day, then I think they may find this more challenging than working
to a specification.
One of the ideas new to me is the "retrospective". This is a regular
meeting, perhaps once after each iteration which should ideally be
weekly. The team discusses what went well, & what didn't, then chooses
a single topic to improve for the next time. This bright approach to
process improvement isin contrast to the procedures, audits and
cheeseburger outcomes of some quality management philosophies. The book
also explores testingin more detail.
The final section explores ways to improve your results with XP even
beyond the textbook methods. Many of the ideas are hinted at throughout
the main text, so this might be seen as a kind of conclusion to wrap up
the volume.
The whole book is a pleasure to read. Without being jokey, it is fun and
informative. It is well printed & laid out with extensive cross
references & some summary boxes or quotations. The references to other
books make it very well linked within its area of software engineering.
Without doubt, the greatest strength of this book is the integrity and
experience that shines through the wise responses to real world
challenges posed by traditional organisations.
Great springboard into Agile and XP. - By: R. Hart, 02 Apr 2008 After reading a couple of books on Agile, The Art of Agile Development does the best job of presenting all the ideas & concepts needed to start putting it all into practice. Previously I've been left with questions about how to go about implementing certain ideas or mis-understood key concepts, I felt able enough to start putting a lot of Agile & XP concepts into practice straight away.
The material itself is very digestable & writtenin a great down to earth manner. Rather then being a case of teacher lecturing to their student, it felt a lot like someone who's been there & gone through all the pains before hand, had come round to visit one afternoon to tell you what they had learnt & what they believe works best.
I've recommended this book to nearly all my development friends & work colleagues/bossesin different departments & even offered to buy the skeptical one their own copy.
A warts and all account of Agile development - By: Hudba, 11 Jan 2008 I received this book then skimmed the authors biographies to see if they are web 2.0 hippies. My experience with the agile method is that is used to excuse sloppy work practises or when a developer wants to avoid boring stuff like documentation, requirements gathering, project planning or testing. I rank it along side similar claims such as graphic designers cannot arrive at work on-time & sober because artistic inspiration only strikes earlyin the morning in night clubs while talking to beautiful people. In short I don't understand it & it is what the cool people do.
My objectives of reading this book were to
Understand what agile Development really is.
Assess whether adopting agile methods will be of benefit to our team.
This book helped me partially achieve both of them quite easily so I recommend it.
My major reservation is that I'd appreciate more support for the book via a web site. James Shore has a good site but http://jamesshore.com/Agile-Book/
is the only page I could find about the book.
There was a checklist to determine how Agile are the work processes are that I use at the moment. I'd like this to be provided on a website & to be interactive.
The provision of more code examples & templates would be also useful.
The art of agile development does not evangelise or attempt to hard sell Agile. The case studies given seem contrived but are used by the authors give a warts & all account of Agile development. On finishing reading this book I feel I am much more aware of the potential benefits & risks of this approach but not confident it's the right way to go.
This book plays the role of an honest consultant rather then a salesman. James Shore & Shane Warden are skilful writers & have covered a technical subject with élan. If you are anyway involvedin software production & considering Agile, then buy it.
