5.0 out of 5 stars We love it, managers hate it
I work at a consulting firm where the management lies and rips off the customer all the time. The day someone brought in this book and start talking about agile modeling, the managers were scared. A meeting was called and this book was banned. The reason is simple: If everyone practice what this book is advocating, the business of charging the customers like hell by...
Published on Nov. 12 2003 by Craig Holter
3.0 out of 5 stars If you live in a world of too much documentation, read this
For those few places left that steep themselves in documentation and don't have a legally-required reason to do so (do they exist?), this book should help motivate why producing too much documentation and doing too much modeling up front can hurt rather than help. Even for a company that sees itself as lightweight, he's got some rough assessments you can do to see if...
Published on Dec 22 2003 by Lars Bergstrom
Most Helpful First | Newest First
4.0 out of 5 stars I recommend this book,
This review is from: Agile Modeling: Effective Practices for eXtreme Programming and the Unified Process (Paperback)Good book with lots of behind the scenes process info about how to implement agile modeling techniques. If you are looking for step by step instructions to modeling or how to model, look elsewhere. It doesn't cover specific modeling, but techniques. Some of the techniques are common sense, but there were lots of suggestions of how to apply them in a difficult political environment. I did not completely agree with the often repeated
statement that unless you apply all of the techniques you cannot truly claim agile modeling success, which I think is a somewhat arrogant statement. Agile modeling is a huge cultural change and implementing as much as possible, if not all, is still a great idea.
3.0 out of 5 stars If you live in a world of too much documentation, read this,
This review is from: Agile Modeling: Effective Practices for eXtreme Programming and the Unified Process (Paperback)For those few places left that steep themselves in documentation and don't have a legally-required reason to do so (do they exist?), this book should help motivate why producing too much documentation and doing too much modeling up front can hurt rather than help. Even for a company that sees itself as lightweight, he's got some rough assessments you can do to see if you're overdoing things, which were relevant even where I work.
The only bad thing is that it was a very theory and ideal oriented book. It didn't contain concrete examples of what Agile Modeling would look like on a real project, how it would feel, and how what models were produced would evolve. This made it a bit difficult to verify my interpretation of the book.
5.0 out of 5 stars We love it, managers hate it,
This review is from: Agile Modeling: Effective Practices for eXtreme Programming and the Unified Process (Paperback)I work at a consulting firm where the management lies and rips off the customer all the time. The day someone brought in this book and start talking about agile modeling, the managers were scared. A meeting was called and this book was banned. The reason is simple: If everyone practice what this book is advocating, the business of charging the customers like hell by purchasing expensive modeling software, creating tons of documentations without doing any real work, and always prolonging the project will end sooner than the owners getting their BMWs and McMasions.
The simple fact that this little book caused headaces to the criminal minded management team tells me how great it is! I wish I can give it ten starts!
2.0 out of 5 stars Violating its own principles,
This book is neither a modeling tutorial nor an introduction. And if you have had any decent amount of practical modeling experience then chances are you have already learned the above lesson. As such, the book fails to hit the mark for both experts and novice modelers. Nevertheless, the lesson it contains is important, thus the two stars. The book itself, however, receives a flat zero rating.
4.0 out of 5 stars A Challenge from Common Sense,
A model can be almost anything that developers make to describe the software that they build--just like an architect's drawings.
A given software development effort might call for any number of different types of models including data models, class models, sequence diagrams, dataflow diagrams, statechart diagrams, etc. The set of models used on any particular project will depend partly on the nature of the project and partly on the preferred methodology of the software developers.
Agile Modeling (AM) is not itself a software development methodology. It is a collection of principles and practices to follow when using models to develop software according to a methodology like Rational Unified Process (RUP) or eXtreme Programming (XP). Many of the practices derive from an application of XP concepts.
AM challenges a number of practices widely followed (or at least preached) in organizations developing software:
AM does not in all cases prohibit these practices, but it emphasizes that the purpose of a software development project is to develop software--not just to develop models. The practices of AM help to keep models in their proper subordinate relation to the working software that is the true goal of any development project.
People with more luck than experience might doubt the need for agile modeling. Please accept from a reader with much more experience than luck an assurance that the need is great. This reader has personally witnessed development projects undertake the costly construction of models having at best a tenuous relation to the software to be developed.
It should in fact come as no surprise. Who would not agree that it is easier to waste other people's money than to abandon one's own obsessions?
At any rate, Mr. Ambler tries to keep us on track with this excellent book, challenging us to use models but to stay focused on software.
Different readers are likely to be challenged to different degrees by AM's various principles and practices. This reader easily accepted, for example, the practice "Create Several Models in Parallel," counseling us to construct multiple model types simultaneously and to eschew the antipatterns of "Single Artifact Developers" and "Single Artifact Modeling Sessions" (pp. 47-50).
The principle "Maximize Stakeholder Investment" proved more challenging. It counsels that project stakeholders (i.e. the businesspeople commissioning the development project)--not software developers--ought to decide whether to develop software documentation (p. 37). True, the stakeholders pay the bills, but architects and accountants also have paying clients who are nevertheless not able to dictate everything about their work. Clearly software development should have professional standards whose suspension may not be commanded even by a paying client.
Another challenge for this reader: "Agile modelers typically do not bother to distinguish between the different "flavors" of modeling, . . . (p. 252)." Here Mr. Ambler is writing about what Martin Fowler calls "perspectives"--conceptual, specification, and implementation--that a model might take on its subject. These perspectives correspond to the business analysis, system analysis, and system design phases of a software development project.
In his "UML Distilled," Mr. Fowler differs sharply from Mr. Ambler: "Understanding perspective is crucial to both drawing and reading class diagrams. . . . it is very important to separate the specification perspective and the implementation perspective (p. 52)."
Or does he? Mr. Ambler hedges his position in the very same sentence: ". . . they just model appropriately as the situation calls for." Now, how can one "model appropriately" if one does not first "bother to distinguish"?
Elsewhere too, the advice of AM can seem equivocal (or is it "nuanced"?). The practice "Collective Ownership" allows everyone on a project to work on any of the project's models. This "power to the people" is however greatly diluted by the practice "Model with Others," prohibiting anyone from modeling alone. Further dilution appears in the case study, where it is recognized that one would be foolish to work on a database design without consulting "Brendan, the database administration (DBA) expert on the team (p. 288)."
It is interesting to compare Mr. Ambler's populist principles for teamwork with the more elitist principles of Frederick Brooks in "The Mythical Man-Month." Mr. Brooks begins his third chapter by citing the "wide productivity variations between good programmers and poor ones." He derives from this observation a software development organization patterned after a surgical team--with one operating surgeon and a small flock of assistants.
Although starting from opposite principles, Brooks and Ambler finish peculiarly close in their team-building practices. A la XP, Brooks's ideal team pairs the "surgeon" with a colleague equally gifted though less experienced. Inversely, Ambler approaches Brooks by listing in Chapter 12 the qualities of superior software developers. "Everyone can learn from everyone else" is one of the "supplementary principles" of agile modeling, but clearly some people have less to learn than others.
Mr. Ambler seems well read. He frequently cites related books throughout the text, adding a special recommendation here and there. One of these recommendations surprised this reader, who was astounded that Mr. Ambler found "UML for Database Design" by Messrs. Naiburg and Maksimchuk "a good read (p. 170)." You may find this reader's differing opinion filed with Amazon.com
Our difference on this small point serves only to highlight the strength of this reader's recommendation.
This is a provocative and well-reasoned explication. Agile Modeling will leave its mark.
5.0 out of 5 stars "Modern" software development explained,
2.0 out of 5 stars Spend your money elsewhere,
By A Customer
This book could probably convey the same ideas in a white paper, and would take the reader a lot less time to get through.
Unfortunately, most of the book states common sense ideas (like only write documentation if somebody is going to read it, or think before you use your fancy CASE tool when drawing a diagram) but takes dozens of pages to explain them.
Look to books by Martin Fowler instead - they have a lot more meat!
4.0 out of 5 stars Disturbing,
I was exposed to a few model types I didn't know and didn't care to learn because my fancy tools didn't support them. Agile Modeling - low-tech alternatives in particular - gives me tremendous freedom for my modeling efforts from now on.
Scott's pragmatic and comprehensive style is wordy but leaves no space for BS.
Expect people defending their niche in heavy document-centric processes to be very upset by this book.
5.0 out of 5 stars Seeing the forest through the trees,
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.
4.0 out of 5 stars Lots of Information,
I have read Scott Ambler's work before and am an admirer of his contribution to software development. I found the book helpful, as with most of Scott's work, despite the sometimes redundant information.
Despite my cautionary introduction above, I recommend this book to developers and project managers.
In this book the reader can expect to find information on how to implement development processes with Agile Modeling (AM).
There is a comparison chapter on AM and XP which is helpful. AM, like all development processes, is a mixture of art and science. It is not carved in stone - although many may disagree with this statement. This book will help the reader decide what is appropriate to utilize for the project, given the real-world scenarios.
Hope this helps - please let me know if you have any questions or suggestions.
Most Helpful First | Newest First
Agile Modeling: Effective Practices for eXtreme Programming and the Unified Process by Scott Ambler (Paperback - April 4 2002)
CDN$ 59.99 CDN$ 37.61