Agile Modeling: Effective Practices for Extreme Programming and the Unified Process

In this book, Scott Ambler provides a practical approach to modeling that allows you to successfully deploy best practices on your agile software development project. From use case modeling to deployment diagrams, agile modeling defines these best practices for rapidly moving from requirements to code in a single, easy to read book. Additionally, Scott presents many of the nuances of software modeling that cannot be found in any other book.Perhaps the most interesting part of Agile Modeling is that it is not only a book about a great software development methodology; it also suggests cultural changes to the way that we view modeling. These changes blur the line between traditional approaches such as those espoused by the Unified Process and the new culture espoused by XP. These ideas are very much in line with the way that software is successfully produced. This book is not an entry-level UML book. If you are looking for basic UML, look at some of the entry level UML books. Instead, this book geared toward those who are actively producing customer grade software applications. It hits the mark squarely for those who want to be more successful in this endeavor.

I really liked this book. Ambler describes how modelling actually works in the real world, not how it is supposed to theoretically happen. It is about time somebody stood up and said that modelling is something that all developers should do and that it isn't simply the purview of "professional modellers". It is also refreshing to see someone come out and say that you don't have to do all your modelling up front, that you don't have to use complex CASE modelling tools, and that you don't have to restrict yourself to just the UML. This book provides practical advice for any actively involved in building software.I especially liked how Ambler didn't waste any time teaching me the basics of object orientation, the UML, data modeling, or any of the other techniques that he refers to in the book. If he had then it would have been huge. He provides summary of a large number of common models in the back of the book, I was surprised how many there were, and suggests when and when not to use them. This is worth the cost of the book alone.I don't see what the people promoting the MDA are complaining about, Agile Modelling could easily fit right in with the MDA vision. Agile Modelling tells you to use the simplest tool for the job. If someone was to build a CASE modelling tool that actually fulfilled the MDA vision then an Agile Modeller would very likely use it. Of course, such a tool doesn't actually exist yet. Probably why the book doesn't waste any space on it.I have to agree that the book could have been edited better. It did repeat in places but that's actually good practice when you're trying to teach someone new techniques. Too bad the MDA people didn't understand this. If they had they might have learned something that they could actually use in practice. I think we'll all be waiting a long time for the MDA academics to produce a tool that fulfills their vision. Until then I'll be following the Agile Modelling practices on my whiteboard.

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 o

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 p

Finally somebody wrote a book like this. I've been following the AM site for awhile now and have been very impressed, and this book goes one step further. Anybody involved with software development needs to read this book. I've been showing it to a couple of Java developers who swear up and down that modeling is a waste of time, but now with this book they're rethinking their ways. If you're working on a project where everyone thinks that modeling means writing a lot of documentation, and I've been on those, then you need to read this book. It's okay to create models on whiteboards!!!!! It's okay to not spend days transcribing those models!!!!! AM describes real-world, practical techniques for improving your modeling and documentation efforts. Although there is only one chapter on documentation it very likely is the best advice that you're ever going to read on the subject. I wish this book was available years ago when I first started out as a developer, I'd be significantly more productive now. Modeling is one of the few skills that I can see using throughout my entire career -- I was a C programmer a few years ago, I'm a EJB developer now, and a few years from now I don't know what language I'll be programming in. What I do know is that I'll still be modeling, and I'll still be writing documentation, so I need to get good at these two things. Agile Modeling describes exactly how to do this.