Agile Modeling and over one million other books are available for Amazon Kindle. Learn more

Vous voulez voir cette page en français ? Cliquez ici.

Sign in to turn on 1-Click ordering.
Amazon Prime Free Trial required. Sign up when you check out. Learn More
More Buying Choices
Have one to sell? Sell yours here
Start reading Agile Modeling on your Kindle in under a minute.

Don't have a Kindle? Get your Kindle here, or download a FREE Kindle Reading App.

Agile Modeling: Effective Practices for eXtreme Programming and the Unified Process [Paperback]

Scott Ambler
3.7 out of 5 stars  See all reviews (22 customer reviews)
List Price: CDN$ 65.99
Price: CDN$ 41.37 & FREE Shipping. Details
You Save: CDN$ 24.62 (37%)
o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o
Only 1 left in stock (more on the way).
Ships from and sold by Gift-wrap available.
Want it delivered Tuesday, December 30? Choose One-Day Shipping at checkout.
‹  Return to Product Overview

Product Description


“…I would not hesitate in recommending this book…” (CVu, October 2004)

“…easy-to-follow…enjoyable writing style…overall the book is impressive…valuable reading…” (Software Testing, Verification & Reliability, March 2003)

From the Back Cover

"In Agile Modeling, Scott Ambler captures the spirit of skillfully applying the UML, patterns, and more-the balance between too much and too little."
-Craig Larman

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.

In this innovative book, Scott Ambler reviews how to:
* Model on an XP project without detracting from its fast-moving and agile software development approach
* Simplify the modeling disciplines/workflows of the UP without losing any of the true benefits of those disciplines
* Use modeling to explore an issue or to facilitate communication
* Effectively apply the UML, and extend it with other methodologies, to meet your real-world development needs
* Reduce the documentation burden on your project by writing agile documents
* Use simple modeling tools, such as index cards and whiteboards, and know when to use complex CASE tools
* Rethink your approach to work areas, modeling teams, and modeling sessions

The companion Web site includes updates to the book, links to XP and AM resources, and ongoing case studies about AM.

Wiley Computer Publishing
Timely. Practical. Reliable.

Visit our Web site at
Visit the companion Web site at
Visit the author's Web site at

About the Author

SCOTT W. AMBLER is President and a senior consultant of Ronin International (, a software services consulting firm that specializes in software process mentoring and object/component-based software architecture and development. Scott is the author and/or coauthor of numerous books and also coeditor, with Larry Constantine, of the Unified Process series from CMP Books. Scott is a contributing editor with Software Development magazine and a columnist with IBM developerWorks. Scott has spoken at UML World, Software Development, OOPSLA, Object Expo, Java Expo, and Application Development.

Excerpt. © Reprinted by permission. All rights reserved.


Principles only mean something when you stick to them when the going gets tough.

Agile Modeling’s values (Chapter 2, "Agile Modeling Values")—communication, sim-plicity, feedback, courage, and humility—in combination with the values and princi-ples of the Agile Alliance (2001a, 2001b), are used to define AM’s principles. When applied on a software development project, these principles set the stage for a collec-tion of modeling practices (Chapters 5, "Core Practices," and 6, "Supplementary Prac-tices"). AM’s values, while important, are somewhat abstract and too high-level to provide much guidance to your software development efforts; hence the need for AM’s principles—concepts that are far more concrete. Some of the principles have been adopted from eXtreme Programming (XP) (Beck 2000), which in turn adopted them from common software engineering techniques. Reuse! For the most part, the principles are presented with a focus on their implications to modeling efforts and as a result, material adopted from XP may be presented in a new light.

This chapter overviews AM core principles; principles that you must adopt in full to be truly able to claim that you are agile modeling (more on this later). Chapter 4, "Supplementary Principles," overviews AM’s supplementary principles that define impor-tant concepts that help to enhance your modeling efforts. AM’s core principles are:

— Software is your primary goal
— Enabling the next effort is your secondary goal
— Travel light
— Assume simplicity
— Embrace change
— Incremental change
— Model with a purpose
— Multiple models
— Quality work
— Maximize stakeholder investment


The primary goal of software development is to produce high-quality software that meets the needs of your project stakeholders in an effective manner. This principle is effectively a re-wording of the Agile Alliance’s (2001b) principle that "working software is the primary measure of progress." Like it or not, the primary goal is not to pro-duce extraneous documentation, extraneous management artifacts, or even to produce models. Creating extraneous documentation can be comforting because you can fool yourself into believing that you are making progress when in fact you’re not. Instead, you’re actually avoiding a difficult task, likely writing and testing code that may show that your chosen approach isn’t working as well as you thought it would. Writing sta-tus reports, trumpeting your successes to everyone, or even worse, covering up your failures, may make you feel good, but it isn’t getting you any closer to your end goal. Have the courage to focus on what is important, the creation of a system for your users. We’re not documentation developers, or even model developers; we’re software devel-opers. Think about it. Any activity that does not directly contribute to the goal of producing quality should be questioned and avoided if it cannot be adequately justified.


Your project can still be considered a failure even when your team delivers a working sys-tem to your users—part of fulfilling the needs of your project stakeholders is to ensure that your system is robust enough so that it can be extended over time. As Alistair Cockbum (2001b) likes to say, when you are playing the software development game, your secondary goal is to set up to play the next game. Your next effort may be to develop the next major release of your system or it may simply be to operate and support the current ver-sion that you are building. To enable it, you will not only want to develop quality software but also create just enough documentation 50 that the people playing the next game can be effective, transfer skills from your developers to others, motivate existing staff to stay and develop the next release of your system, or simply motivate team members to stay with your organization. Factors that you need to consider include the nature of your develop-ers,!
the nature of the next effort itself, and the importance of the next effort to your organi-zation. In short, when you work on your system, you need to keep an eye on the future. This principle supports the AM value of Communication.


Traveling light means that you create just enough models and documentation to get by. Every artifact that you create, and then decide to keep, will need to be maintained over time. This includes models, documents, and project management artifacts such as schedules, test suites, and source code. For example: You decide to keep seven models. Whenever a change occurs—such as a new or updated requirement, your team takes a new approach, or adopts a new technology—you will need to consider the impact of that change on all seven models and then act accordingly. If you decide to keep only three models, then you clearly have less work to perform to support the same change, making you more agile because you are traveling lighter.

Similarly, the more complex / detailed your models are, the more likely it is that any given change will be harder to accomplish (the individual model is "heavier" and is therefore more of a burden to maintain). Every time you decide to keep a model, you trade off agility for the convenience of having that information available to your team in an abstract manner (hence potentially enhancing communication within your team as well as with project stakeholders). Never underestimate the seriousness of this trade-off. Jim Highsmith (2000) points out that someone trekking across the desert will benefit from a map, a hat, good boots, and a canteen of water. They likely won’t make it if they burden themselves with hundreds of gallons of water, a pack full of every piece of survival gear imaginable, and a collection of books about the desert. However, it is possible to travel too light - clearly, it would be foolish to try to cross a desert without a minimum of supplies. Similarly, a!
development team that decides to develop and maintain a detailed require-ments document, a detailed collection of analysis models, a detailed collection of architectural models ……..

‹  Return to Product Overview