Agile Modeling

RickHigh writes: "I've been waiting for a book like this. If you are doing software development of any kind, you should read this book. Especially if you are doing Extreme Programming and you errantly believe modeling has no place in XP. Or, your doing the Unified Process and you feel that your models and documents are more important than a working system, or you feel you are bogged down in documentation and required artifacts (more likely). Agile Modeling (AM) is a modeling methodology that enhances your modeling endeavors, whatever your process methodology inclination. Agile modeling will help you effectively incorporate modeling into your organization." Read the rest of Rick's review below. Agile Modeling: Effective Practices for Extreme Programming and the Unified Process author Scott Ambler pages 400 publisher Wiley, John & Sons, Incorporated rating 7.5 reviewer RickHigh ISBN 0471202827 summary A worthwhile melding of XP techniques with modeling of general interest to programmers of all stripes.

The title is only partially accurate as the book covers a lot more than modeling. I know from experience that picking titles is tricky (you can't please everyone). You don't need to be a UML expert to get value of this book. Any software developer should be able to appreciate it. Modelers, software developers and Yes, managers will find this material useful. In fact you may want to buy a copy and put it on your manager's desk. This book is original and well thought out. It is also well written and very readable. I wish there were more examples of applying the different artifacts in different phases of the XP life-cycle, but there has to be room for the next edition. The depth is appropriate.

Many UP developers (and those working with other prescriptive processes) get bogged down in the tonnage of documents and artifacts that are required. They wonder if they are ever going to have time to actually write the code.

XP offers a methodology for building high quality software fast. However, many XP developers, and I've spoken to them about this very subject on many occasions, find that XP does include time to do models. This books shows how to integrate XP and modeling.

This book sets the record straight about design and Extreme Programming. Actually, Kent Beck set the record straight with the first book on XP when he said 'In the time it would take you to code one design, you can compare and contrast three designs with pictures.' Kent Beck's views were corrupted over the years for various reasons that Agile Modeling explains, as it clarifies once and for all the relationship between XP and modeling.

The book emphasizes that you should model to understand the problems and only apply the right artifacts, i.e., that not all modeling must lead to writing code.

Despite the title, he AM book transcends just being a book on modeling; the book covers many aspects of developing software. Agile Modeling endeavors to be real. By real I mean it talks about real issues and how things are handled in the real world, not the perfect world covered by most books. For example, the chapter on documentation is an excellent coverage of the subject, but not idealized beyond all usefulness.

Like the original XP book, the AM book lists values, core principles and practices. It also adds supplementary principles like 'Content Is More Important Than Representation.' A key lesson from the book is that models are important if they help you understand and solve problems. And, models do not have to be perfect -- in fact they can be thrown away when you are done with them. After all is said and done, 'Software is your Primary Goal.'

The author, Scott Ambler is the author of numerous books (and by numerous I mean a lot) for the Unified Process, and UML. He also contributed to the Mastering EJB Book, and the Java Elements of Style book. All his work in UP seems strange since AM seems to have closer ties to XP than UP, but that is probably my own warped misconceptions of the world. Bottom line, Scott has mastered the craft of writing and I really enjoyed his writing style. The first few chapters seemed a little slow, probably because their content has been covered before in other books. The chapters on AM and XP, though, were informative and useful (as was the chapter on agile documentation mentioned earlier).

If you are doing software development of any kind, you should read this book. It is an informative and enjoyable read.

What's covered? Here are the chapter headings:

• Table of Contents:
• PART I: INTRODUCTION TO AGILE MODELING.
  • Introduction.
  • Agile Modeling Values.
  • Core Principles.
  • Supplementary Principles.
  • Core Practices.
  • Supplementary Practices.
  • Order from Chaos: How the AM Practices Fit Together.
• PART II: AGILE MODELING IN PRACTICE.
  • Communication.
  • Nurturing an Agile Culture.
  • Using the Simplest Tools Possible?
  • Agile Work Areas.
  • Agile Modeling Teams.
  • Agile Modeling Sessions.
  • Agile Documentation.
  • The UML and Beyond.
• PART III: AGILE MODELING AND eXTREME PROGRAMMING (XP)
  • Setting the Record Straight.
  • Agile Modeling and eXtreme Programming.
  • Agile Modeling Throughout the XP Lifecycle.
  • Modeling During the XP Exploration Phase.
  • Modeling During an XP Iteration: Searching for Items.
  • Modeling During an XP Iteration: Totaling an Order.
• PART IV: AGILE MODELING AND THE UNIFIED PROCESS.
  • Agile Modeling and the Unified Process.
  • Agile Modeling Throughout the Unified Process Lifecycle.
  • Agile Business Modeling.
  • Agile Requirements.
  • Agile Analysis and Design.
  • Agile Infrastructure Management.
  • Adopting AM on an UP Project.
• PART V: LOOKING AHEAD.
  • Adopting Agile Modeling or Overcoming Adversity.
  • Conclusion: Choose to Succeed.
  • Glossary of Definitions and Abbreviations.
  • References and Suggested Reading.
• Appendix A: Modeling Techniques.

Sites of interest

• The Agile Modeling site
• The XP programming site
• The Agile Alliance site
• Scott Amblers Website
• Applying XP to J2EE

You can purchase Agile Modeling from bn.com. Want to see your own review here? Just read the book review guidelines, then use Slashdot's handy submission form.

Comments

bn.com? wtf?

[titonutz]

Everyone knows Amazon is better. Compare:

Price at bn.com: $27.99 (%20 off)
Price at amazon.com: $24.49 (%30 off)

Buy from amazon.com

amazon.com? wtf?

[Anonymous Coward]

Everybody knows that the only place to find book prices is bestwebbuys.com.

Compare:

Bookpool $21.50
Vs.
Amazon $24.49

Re:bn.com? wtf?

[Voytek]

or you could go to http://www.bookpool.com/.x/riiycqqu4m/sm/047120282 7 and get it for 21.50

Re:Ok

[jamesmartinluther]

Modeling, as in other fields, is forming a simplified representation of reality which assists in the understanding of reality (and often modeling even distorts this understanding). In the world of software development, I would say that modeling is a conceptual architecture that can help developers organize the work.

When I'm modeling a new project, people will notice diagrams and other scribblings on my desk as I attempt to work out how all of the basic utilities, resources, and user interfaces of an application will work together.

Re:Not so good ideas...

[kaladorn]

No. But a lot of times refactoring is slightly more complex than something that can be done in a couple of hours. Especially if you enjoy the "joy" of having inherited part of a large multi-platform project with multiple applications that have to interop. Assuming the whole thing has been assembled, many times perhaps to satisfy requirements for rapid demonstrations, etc. in order to acquire sales leads, etc, then refactoring becomes a large task in and of itself.

Of course, in a perfect world, this would never happen. If you happen to live in one, let me know where and I'll emmigrate.

The definition of bite you in the ass later is: Costs you more to fix later than it would have to do right in the first place.

This hinges on several factors:
1) That, by the time you later refactor, your own knowledge of the situation/requirements/code/etc hasn't improved drastically
2) or that by the time you refactor, some change hasn't altered your requirements radically thus making your refactor actually a redesign (so if you'd refactored before, perhaps you wasted your time and money)
3) or that a dollar today and a dollar six months down the road are equal - which isn't true in many cases... a dollar now may be something scarce and so refactoring time is VERY expensive, and later that same dollar (or even two given it will be harder to refactor) may be less problematic and more affordable

I distinctly recall drawing the distinction that it depends on situation. In some cases, it makes sense to refactor always. In some cases (especially where you inherit a large, convoluted code base but have to start working on features without uptake time), refactoring immediately is a dumb idea. In an emerging market, refactoring immediately may well be wasting your time as that entire feature set or product direction may be entirely abandoned.

So, although I support refactoring, I think the real world shows us places where it takes on a semblance of creeping elegance. I myself do it fairly regularly (mostly to make things easier for me and those following to understand), but I've seen the time hit this can incur trying to unravel a messy class heirarchy and I've seen the severing of whole feature sets as marketing/sales scramble for market position. That's why the real world isn't like the inside of any textbook.