Agile Modeling: Effective Practices for eXtreme Programming and the Unified Process FROM OUR EDITORS
The Barnes & Noble Review
Executives talk about creating agile business processes. Developers increasingly talk about using agile methods -- witness the explosion of interest in Extreme Programming (XP), Scrum, Crystal, and other "light" methodologies. But, until recently, there's been no agile equivalent for the folks who model and document software.
Worse, there's been a widespread perception that careful modeling is the enemy of agility. It needn't be that way. Nor should it be. Even XP creator Kent Beck has written, "Contrary to the claims of some of XP's detractors, you do in fact invest time modeling when taking an XP approach, but only when you have no other choice. Sometimes it is significantly more productive for a developer to draw some bubbles and lines to think through an idea, or to compare several different approaches to solving a problem, than it is to simply start hacking out code."
Agile Modeling aims to show IT professionals how they can gain the benefits of modeling without losing speed and flexibility. In the book by the same name, Scott Ambler -- author of The Object Primer and co-author of classics like Mastering JavaBeans -- explains exactly what AM is, and isn't.
AM begins with the core principles and values of the agile development community: communication, simplicity, feedback, courage, and humility. As the Agile Alliance has put it, "Individuals and interactions over processes and tools; working software over comprehensive documentation; customer collaboration over contract negotiation; responding to change over following a plan."
For the modeler, these values translate in many ways. For instance, simplicity means not over-modeling your system. Model based on your current requirements, and refactor when they change. For those accustomed to conventional modeling, that can definitely take courage.
Equally important, "Model With a Purpose." Ever encounter a pile of artifacts whose size is matched only by its irrelevance? Ask: Why are you creating that artifact? For whom? How much complexity do they need and want? (Not sure? Ask.) Once your artifact has met its goals, put it aside and move on.
AM is not a complete replacement for other software processes. It doesn't encompass programming, testing, project management, deployment, system operations, or support. Therefore, folks who implement AM are likely to do so in the context of some other software process. The processes you can use AM with range from XP to behemoths like the Unified Process (UP). In fact, Ambler offers in-depth coverage of integrating AM with both XP and UP.
Ambler points out that UP is more flexible and agile than it's often given credit for, and that many of AM's principles are already part of AM -- including a reliance on testing, the creation of multiple models in parallel, and an openness to iterative modeling. Other principles can be added easily, assuming that project team members are willing.
But, he admits, it's all too easy to go overboard with the paperwork. AM users should "...question every single model that the UP suggests creating because it purposely describes a wide variety of artifacts, many of which your project simply doesn't need... the business modeling set includes a business use-case model, business rules, a business architecture document, and a business supplementary specification. Do you actually need all of these things? Likely not. If you do need them, do you need them as formal documentation? Likely not."
Along the way, Ambler introduces the essential practices of Agile Modeling. Many of these focus on transforming teamwork from talk to reality: modeling with others ("modeling is a group activity"), collective ownership (anyone can work on any model) and publicly displaying all your models. Others focus on staying grounded in reality. "Prove It with Code": think you understand the logic of a complex business rule? Try coding it. "Apply Patterns Gently": Suspect a design pattern applies to your situation? Don't incorporate that pattern's "overhead" until you're more confident (if you're iterating constantly, it won't be long).
Want agility? Don't want to sacrifice the clarity that modeling can deliver? With AM, you can have both -- and this book is the place to start.
(Bill Camarda)
Bill Camarda is a consultant, writer, and web/multimedia content developer with nearly 20 years' experience in helping technology companies deploy and market advanced software, computing, and networking products and services. He served for nearly ten years as vice president of a New Jersey–based marketing company, where he supervised a wide range of graphics and web design projects. His 15 books include Special Edition Using Word 2000 and Upgrading & Fixing Networks For Dummies®, Second Edition.
FROM THE PUBLISHER
Extreme Programming (XP) and the Unified Process (UP) have both caused quite a sensation in the software development community. Although XP offers a methodology for faster software development, many developers find that it does not explicitly include modeling time, which is crucial to ensure that a project meets its proposed requirements. UP developers, on the other hand, have found that the UP approach to modeling is too documentation-intensive and top heavy, thus impeding progress. Enter Agile Modeling (AM) -- a unique methodology specifically designed to enhance your modeling efforts on software development projects.
FROM THE CRITICS
Booknews
Agile Modeling (AM) is defined as a practices-based process for effective software development modeling and documentation. Following an introduction to AM methodology, the author treats AM in the practical contexts of its principle of using the simplest tools possible, work areas, modeling teams, eXtreme programming, and barriers to developing an "agile culture." Includes a glossary. A companion Web site is available. Ambler is a computer consultant and contributor to such publications as Software Development magazine. Annotation c. Book News, Inc., Portland, OR
Home
