“…easy-to-follow…enjoyable writing style…overall the book is impressive…valuable reading…” (Software Testing, Verification & Reliability, March 2003)
From the Back Cover
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 www.wiley.com/compbooks/
Visit the companion Web site at www.wiley.com/compbooks/ambler
Visit the author's Web site at www.agilemodeling.com
About the Author
Excerpt. © Reprinted by permission. All rights reserved.
Principles only mean something when you stick to them when the going gets tough.
Agile Modelings values (Chapter 2, "Agile Modeling Values")communication, sim-plicity, feedback, courage, and humilityin combination with the values and princi-ples of the Agile Alliance (2001a, 2001b), are used to define AMs 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"). AMs values, while important, are somewhat abstract and too high-level to provide much guidance to your software development efforts; hence the need for AMs principlesconcepts 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 AMs supplementary principles that define impor-tant concepts that help to enhance your modeling efforts. AMs core principles are:
Software is your primary goal
Enabling the next effort is your secondary goal
Model with a purpose
Maximize stakeholder investment
SOFTWARE IS YOUR PRIMARY GOAL
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 Alliances (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 youre not. Instead, youre actually avoiding a difficult task, likely writing and testing code that may show that your chosen approach isnt 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 isnt 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. Were not documentation developers, or even model developers; were 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.
ENABLING THE NEXT EFFORT IS YOUR SECONDARY GOAL
Your project can still be considered a failure even when your team delivers a working sys-tem to your userspart 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 occurssuch as a new or updated requirement, your team takes a new approach, or adopts a new technologyyou 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 wont 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 ..