Agile Modeling: Effective Practices for eXtreme Programming and the Unified Process 1st Edition

Scott has done a great job of hitting a sweet spot of modeling. I've gotten a tremendous amount of value from this book. He walks the talk, and I love how most of the models are hand-drawn.

The book covers in detail what is agile modeling and how to implement it. The author delves into the often uncharted territory of agile requirements engineering and agile software design. In these two particular topics I found the book to be pretty useful and I learned some new fresh perspectives on how to solve these problems. The book, though, is unnecessary long and the author tends to be too verbose, often reiterating over and over the same ideas to the point of absolute boredom. I found it really difficult to read the book cover to cover and skipped several pages, just browsing, looking for interesting headlines where to stop and read further. The book is old and some of the methodologies mentioned in the book may be considered outdated by many (e.g. the book has a chapter on how to do agile modeling with RUP). Many reference links to other materials mentioned in the book are no longer valid and the referenced web pages do not exist.

If you have never done OO modeling, then this book doesn't have enough detail on modeling to be your only source of instruction. And if you do know modeling, then you only need common sense to know you that you need to avoid getting stuck with "analysis paralysis". I think this book should have been just a magazine article. Hats off to Mr. Ambler for being able to generate so many words with so little to say.

If you are doing software development of any kind, you should read this book. Especially if you are doing Extreme Programming and you erroneously 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 despite your process methodology inclination. Agile modeling will help you effectively incorporate modeling into your organization.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 get value out of this book. 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 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 this book explains and finally this book sets the record straight once and for all about XP and modeling.This book drives the point home about XP and modeling and also explains how to avoid following prescriptive methodologies that require certain artifacts. Instead the book brings out that you should model to understand the problems and only apply the right artifacts, i.e., all modeling lead to writing code.The AM book transcends just being a book on modeling, despite the title, the book covers many aspects of developing software. The book endeavors to be real. By real I mean it talks about real issues and how things are handled in the real world not a hypothetical world, i.e., not the perfect world covered by most books. For example, the chapter on documentation is an excellent coverage of the subject.Like the original XP book, the AM book lists values, core principles and practices. It also added supplementary principles like "Content Is More Important Than Representation". A key take away from the book is 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".Strangely enough, 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 Element 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 his craft of writing and I really enjoyed his writing style. The first few chapters seemed a little slow probably because it has been covered before in other books. The chapters on AM and XP were really 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.

The hype that grew around eXtreme Programming (XP) in the year 2001, and the publication of now almost 2 dozen books devoted to XP has not cleared up the original vagueness of what practices are allowed and what aren't. To a casual observer the XP culture seems replete with "Thou shalt not's"¯ don't do Big Requirements Up Front, don't do Big Design Up Front, don't build models because it's only the code that matters, etc. For those of us who think it's important to have a map of where you are going before you start a long trip, some of the radicalness of XP was¯well, too radical and too unplanned.Scott Ambler's new book, Agile Modeling, addresses a sane middle ground between the apparent unstructured XP and the overly structured approach in the Rational Unified Process (RUP). Agile Modeling is arguably Ambler's best book to date. It conveys an approach that is truly a confluence of best practices and does so in a very readable, accessible presentation.Ambler presents Agile Modeling (AM) as a set of values, principles and practices. AM's values are borrowed directly from those in XP: Communication, Simplicity, Feedback and Courage, with Ambler's addition of "humility". In my experience this additional value is a defining characteristic of an effective modeler and mentor. From these 5 values Ambler defines the principles for AM, including: Software is your Primary Goal, Travel Light, Embrace Change, use Multiple Models, etc.It is interesting to me that no one would refute these principles: they are too close to Motherhood and Apple pie. But it is disturbing how seldom I see any of these principles actually embraced by the dozen or more organizations I provide mentoring services to each year.The bare-metal practicality of AM is in the chapters on "Agile Modeling in Practice". Here Ambler goes into detail on the practices that support the AM principles. Are you curious how your culture might adopt AM? See his chapter on "Nurturing an Agile Culture". In a quandary over what expensive OO CASE tool to buy? See "Using the Simplest Tools Possible?" In his broad reach in this book Ambler covers issues surrounding how you can effectively set up your work areas, how to conduct modeling sessions, how to staff your AM teams, and more. And each chapter ends with a pragmatic commentary on "How to Make This Work in the Real World".I predict that if one chapter is read more than any other it will be the one on "Agile Documentation". This is also the longest chapter in the book, and Ambler skillfully addresses the two big questions of "Why Do People Document?" and "When Does a Model Become Permanent?" And if for some perverse reason you didn't read any chapter but this one, it alone would justify the cost of the book.The last two sections of the book show how to apply these principles and practices to an XP environment (Part 3), and then how they can be applied to a Unified Process environment (Part 4). Again the approach is on the practical application of AM so that you can have a better chance of succeeding on your next (or current) software project.If you are a software developer, a technical manager or project manager, you cannot afford to dismiss this book. Forty years ago no one did the "waterfall" process (Winston Royce hadn't defined it yet) and forty years from now we will certainly be building software in ways we have not yet even conceived. But this year and for the foreseeable future we will be using every idea from Agile Modeling to build better software faster. As Ambler says about building an agile culture, "You can be agile or you can be fragile." That says it all, so get this book and learn how AM can make you a winner.