Agile Modeling
- Taking a Tour Through Agile Modeling
- Using Agile Modeling in a Sample Session
- Summary
- Q&A
- Workshop
See all Sams Teach Yourself on InformIT Programming Tutorials.
This chapter is from the book
This chapter is from the book
This chapter is from the book
Extreme Programming is part of a growing number of Agile technologies and methods. A recent addition to this family of Agile methodologies is Agile Modeling (AM). This is an exciting approach that involves combining industry standard or best practice modeling with Agile thinking. You'll learn the following this hour:
What Agile Modeling is
How Agile Modeling shares basic values with XP
What the values, principles, and practices of Agile Modeling are
How Agile Modeling compares to XP
How Agile Modeling can be used in an XP project
Taking a Tour Through Agile Modeling
There are a lot of street rumors and urban myths when it comes to XP; opinions abound about what it is and isn't. One of these mistaken perceptions is that XP has no documentation or modeling at all; programmers just get on with program-ming. There's a world of difference between light documentation or enough documentation and none at all. At one end is the hacker and at the other, the Agile developer who knows when to use techniques or tools at her disposal.
NOTE
In a software engineering sense, modeling refers to the use of diagrams to describe a process, solution, or problem. These diagrams can be supported by documentation.
What is Agile Modeling? Don't worry; it has nothing to do with acrobatics and clay! Briefly, it is a practice-based methodology founded on values, principles with a goal to support and enable software development by the effective use of modeling tools and techniques. It isn't an explicit list of steps or procedures. The beauty of AM is that it allows each user to modify the approach to his local setting. There is much to compare between XP and AM.
AM was primarily developed by Scott Ambler. His Agile Modeling site (http://www.agilemodeling.com/) has a wealth of information on the subject.
NOTE
This hour is based in part on Ambler's book Agile Modeling: Effective Practices for Extreme Programming and the Unified Process (Wiley, 2002). This is a must read for any XP developer who wants to use his or her modeling skills with Extreme Programming.
So, AM is doing "just enough" modeling but do we need modeling at all? Modeling is an important way to communicate between team members at all stages of the software development lifecycle. We begin the iteration with a collection of user stories and tasks; invariably questions arise from these high-level requirements. Questions like, "what should the screen look like?" or "So, what is the exact process of taking an order?" Soon you're at the whiteboard sketching and modeling to close the comprehension gap. Developers might use class diagrams or the like as they express lower-level understandings to each other. With AM, these models, whether on paper or whiteboard are typically thrown away after they outlive their usefulness. However, these models may be kept if they provide some value.
Before we investigate how we might use AM techniques on an XP project, we'll take a few minutes to get an overview of AM.
Agile Modeling Values
A methodology based on values—sound familiar? Scott Ambler makes no bones about being inspired by Kent Beck to take this approach from XP when he came to forming AM. AM values have added one extra value to our core XP values: humility. Developers can get possessive when it comes to "their" models and will resist and attempt to change or adjust. Some developers are also unwilling to work with others, particularly nontechnical people, because they don't have the humility to accept that others can also provide significant input into the overall effort. The truth is, often the model isn't wrong, but it simply fails to communicate. We could add humility as a value to XP but for now we'll leave that for XP version 2!
Table 23.1 lists the AM values and explains their relevance.
Table 23.1 Agile Modeling Values
|
Value |
Description |
|
Courage |
Choosing AM requires courage; you're forced to rely more on your own judgment and experience, rather than blind adherence to the "book." It takes courage to admit that your model is weak or wrong and accept new direction. |
|
Communication |
Models exist for the purpose of communicating between people, including both stakeholders and developers. If a modeling approach fails to communicate, change it for one that does. |
|
Feedback |
Get feedback on your models early and often. Build the model as a team or group, letting it evolve in a shared space. Validate the model with your customer to ensure it is accurate and effectively explanatory. |
|
Humility |
Agile modelers hold their models loosely and will lay them down if required. They have the self-confidence to let others criticize or question. Sometimes your model is perfect but the customer just doesn't get it! It takes humility to discard your perfectly formed UML and let the customer doodle her thoughts. |
|
Simplicity |
Keep models and approaches as simple as possible and change tomorrow if you need to. Assume that the simple approach will work before you attempt the more complex. |
NOTE
UML (Unified Modeling Language) has become the industry standard for modeling over the last few years. At the time of writing it is still not the complete answer to all your modeling needs. It has no database or user interface modeling support and so you should expect to supplement it with other notations for these. The Web home of UML is at http://www.uml.org/.
Agile Modeling Core Principles
The core principles of AM give concrete definition; they are a less abstract guide than the five values. Developers who claim to be Agile Modelers must adhere to the principles listed in Table 23.2.
Table 23.2 Agile Modeling Core Principles
|
Principle |
Description |
|
Assume Simplicity |
Keep your models as simple as possible and assume that the simplest solution is best. Only model what you need today and trust that you can remodel if needed. |
|
Embrace Change |
Change will happen on your project as understanding grows. Rather than fight changes to your models or views, accept them and have the courage to rebuild. |
|
Enabling the Next Effort Is Your Secondary Goal |
Development does not happen in a vacuum; others might need to extend or improve your project after you leave. Leave just enough documentation and models to enable the next team to win. |
|
Incremental Change |
Your models don't have to be perfect the first time; they will change over time as the project develops. Make small changes to models as required. |
|
Maximize Stakeholder Investment |
The team is producing software to maximize return for the customer. Does the model or documentation you're creating add to this value? There comes a point where some models exist for their own sake! |
|
Model with a Purpose |
Create models with an end in mind, not as exercises or because "that's the way you do it." Be clear in your own mind why you're creating the model; who is it for and what are you trying to communicate? |
|
Multiple Models |
There are many ways of modeling solutions; choose those that fit your situation. For example, data models for a database team. Remember that the UML is a good start, but that it isn't the complete solution. |
|
Quality Work |
Just enough modeling isn't a license for carelessness; strive to model in ways that accurately communicate. |
|
Rapid Feedback |
Getting quick feedback on your model will close the loop of understanding. Model a little, show, and then model again. This ensures your model is accurate while increasing your own knowledge. |
|
Software Is Your Primary Goal |
Models are but a means to the end; the end is to build software for your customer. Documentation and modeling must directly support the goal of software development. |
|
Travel Light |
Traveling light means you have just enough documentation for your journey. Too little and the team will lose its way; too much and we've forgotten our primary goal is writing software not documents. |
NOTE
A great quote from Ambler: "System documentation is a business decision." This means that whether you write documentation or save project artifacts, it is a cost-risk trade-off for the customer. As software developers we often assume that the customer must have system documentation for maintenance or support purposes. If they choose to forgo or reduce this, they risk that maybe they'll be exposed in the future.
Agile Modeling Secondary Principles
The principles covered in the previous section are necessary for Agile Modeling but a number of secondary principles can further enhance your modeling effectiveness. You might choose to add your own principles based on your own or the team's collective experience. Table 23.3 lists and describes the secondary principles.
Table 23.3 Agile Modeling Secondary Principles
|
Principle |
Description |
|
Content Is More Important than Representation |
What is being conveyed is more important than the way you choosing to convey it. Don't get lost in inane arguments over CASE tools versus paper-based methods. |
|
Everyone Can Learn from Everyone Else |
Learning and education don't come from books alone; expect to learn while you work with others. Technology changes at such a pace that no one person can claim to know it all. |
|
Know Your Models |
As an Agile Modeler, you'll select different modeling techniques based on the situation. You can't do this if you lack clarity on the relative strengths and weaknesses of each. |
|
Know Your Tools |
Similar to Know Your Models, select the appropriate software tool based on your knowledge of the package rather than lack of experience with it. More often than not you'll choose paper over computer but there will still be times when you'll select a CASE tool or similar. Be prepared for this! |
|
Local Adaptation |
Keep in mind that AM is not a dogmatic approach to modeling; adapt and modify based on your own requirements and skills. There may be cases where your customer insists on certain modeling tools or standards. AM allows you the flexibility to accept and work with this. |
|
Open and Honest Communication |
Using a non-prescriptive approach like AM requires those on the team to express ideas, feelings, frustrations, and viewpoints. The team will make better more informed decisions by cultivating an open and honest workplace. |
|
Work with People's Instincts |
The customer gets that glazed look or begins to nod mechanically; this is a sign that you're not connecting. It's time to put aside your model and work through why communication has broken down. We're getting into the "touchy-feely" or EQ (Emotional Quotient) zone here but the reality is that you're talking to people not computers. Agile modelers will go with their instinct even when communication seems to be going well. |
Agile Modeling Core Practices
AM's core practices are where the rubber meets the road, where the real work of modeling gets done. These practices are guided and framed by AM's values and principles. Table 23.4 lists the core practices of AM.
Table 23.4 Agile Modeling Core Practices
|
Practice |
Description |
|
Active Stakeholder Participation |
AM works in part because it relies on customers to become actively engaged in the modeling process. This in turns requires that developers exhibit flexibility with modeling notation and approach. |
|
Apply the Right Artifacts |
Agile Modelers choose the right tool for the job. There are so many artifacts you could select: UML state diagram, data flow diagram, or conceptual data model. Apply the artifact that fits your situation—for example a physical data model when displaying database relationships. |
|
Collective Ownership |
The team owns the models; this is encouraged by the use of collaborative tools like whiteboards that exist in shared space. Rather than allow a single developer to assume the role of "model guru," Agile Modelers spread the task to the wider team. This becomes even more important when the team comes to explaining "their" model to the customer. |
|
Consider Testability |
As you develop your model, consider how and if it can be tested. |
|
Create Several Models in Parallel |
In the search for understanding you might need to use more than one modeling notation. You might sometimes switch back and forth. Later in this hour I'll demonstrate this as I explain how to derive user stories. |
|
Create Simple Content |
In line with the AM value of simplicity, your model should contain the fewest possible elements required to communicate and fulfill its purpose. |
|
Depict Models Simply |
When you model, use a subset of your base-modeling notation. Avoid large, complex diagrams that obscure meaning. Remember that as XPers, we are not looking for detail in our models and that they are primarily temporary aids to communication. |
|
Display Models Publicly |
Displaying models in public emphasizes the shared nature of AM and also gives the customer a definite sense of direction. It may help capture metaphor and vision for the whole team; they have something to hang their hat on. |
|
Iterate to Another Artifact |
When you come to an impasse with the model you're using, either because of limitations inherent in the model or because it's inappropriate, you might find you need to iterate to another model type. Sometimes the act of changing notations is all that is required to free up communication. This practice is connected with the practice of creating several models in parallel. |
|
Model in Small Increments |
Modeling in Small Increments fits within the context of iterative software development: model, communicate, refine, and remodel. Modeling in this way opens up the possibility to change models mid-stream if needed. |
|
Model with Others |
XP and AM are team efforts where the synergy of the group amplifies the effectiveness of the team. This is loosely related to the XP practice of Pair Programming. |
|
Prove It with Code |
Sometimes the best way to validate your model is with the code itself; after all that is the point of the model! We could compare this to the use of a spike in XP to validate technical assumptions or deal with issues. |
|
Use the Simplest Tools |
Developers tend to model on paper or whiteboard and then transcribe back to a formal design tool, like Microsoft Visio. Agile Modelers aren't afraid to leave the sketch as is and either file it or scan it so it forms part of the documentation. The falling price of digital cameras simplifies the chore of transcribing from flip charts or whiteboards. Agile Modelers will use a more complicated CASE tool, such as TogetherSoft's ControlCenter (http://www.togethersoft.com/products/controlcenter), when it makes sense to do so—they use the simplest tools, not just simple tools. |
Agile Modeling Secondary Practices
Once your team has adopted and is comfortable with the core AM practices, they should also integrate the secondary practices into their daily modeling routine. These practices help achieve better productivity, motivation, and a clearer understanding of the place documentation holds in AM. Table 23.5 lists the secondary practices of AM.
Table 23.5 Agile Modeling Secondary Practices
|
Practice |
Description |
|
Apply Modeling Standards |
AM modeling standards fit the "just enough" bracket of guidelines and standards. As a group, decide on certain standards and tools; having these standards in place stops some of the meaningless arguments about style or preference. As with Coding Standards in XP you can evolve these in a "just in time" approach, storing your standards in the project Wiki Web site. Visit http://www.modelingstyle.info for UML modeling guidelines. |
|
Apply Patterns Gently |
Modelers are used to applying architectural patterns when solving problems and creating models. In AM the practice is apply them where it makes sense, in a minimal or gentle sense. With XP, code is developed with the expectation that future refactoring may occur and you should keep this in view while you model. |
|
Discard Temporary Models |
Models exist mainly for communication and understanding; discard these once they have served their purpose. |
|
Formalize Contract Models |
If your system interfaces with third parties, you should adopt the AM practice of formalizing your contract models. These models usually indicate protocols and the interface to the system, such as an API to a function library, an XML schema for an XML file transfer, or a physical data model for a legacy database. |
|
Model to Communicate |
Depending on your audience you'll need to model using varying approaches. Senior management might expect a slide presentation, demonstrating a high-level solution map; on the other hand, developers may find a DFD useful. |
|
Model to Understand |
You might model your problem or issue to explore and understand it. Working with customer or developers to clear your understanding before the team attempts to offer a solution. |
|
Reuse Existing Resources |
With the aim to maximize shareholder investment, look to reuse any existing models or resources. In XP, you're more likely to reuse the approaches you've learned rather than an actual deliverable. |
|
Update Only When It Hurts |
If you wait long enough, your model will become out of date, as source code develops or requirements change. Should you go back and update your model? The AM answer to this question is that only if you absolutely need to for reasons of comprehension. An example could be where a section of the system is undergoing large refactorings and the team needs to step back before they start; an up-to-date model could help here. |
TIP
For an example of UML style guidelines see http://www.modelingstyle.org/.
Comparing XP with Agile Modeling
In case you forgot: This book is about XP, not Agile Modeling. Still as XP developers we are very interested to see how AM and XP are aligned. Clearly, there is a synergy at values and principles levels, but how do the practices relate? Before I walk you through a sample modeling session, I'll review how XP and AM cross-reference. Table 23.6 lists each AM practice and compares it to XP.
NOTE
This table is based on Ambler's essay "Agile Modeling and Extreme Programming (XP)" from http://www.agilemodeling.com/essays/agileModelingXP.htm.
Table 23.6 Cross-referencing AM and XP Practices
|
AM Practice |
XP Practice |
|
Active Stakeholder Participation |
This practice equates to the XP practice of On-Site Customer. |
|
Apply Modeling Standards |
This is the AM version of XP's Coding Standards practice. |
|
Apply Patterns Gently |
This practice is in conformance to XP's practice of Simple Design. |
|
Apply the Right Artifact(s) |
This does not directly relate to any XP practice. |
|
Collective Ownership |
AM has adopted XP's Collective Ownership practice. |
|
Consider Testability |
This relates to the XP practice of testing. |
|
Create Several Models in Parallel |
This does not directly relate to any XP practice. |
|
Create Simple Content |
This is complementary to XP's Simple Design practice that advises to keep your models as simple as possible. |
|
Depict Models Simply |
This is complementary with XP's Simple Design practice that suggests that your models do not need to be fancy to be effective, perfect examples of which are user stories. |
|
Discard Temporary Models |
This practice reflects XP's Travel Light principle. |
|
Display Models Publicly |
This practice reflects XP's value of Communication and principle of Open & Honest Communication and relates to its practice of Collective Ownership. |
|
Formalize Contract Models |
This does not directly relate to any XP practice. |
|
Iterate to Another Artifact |
This does not directly relate to any XP practice. It does reflect the way that XPers will iterate back and forth between working with user stories, tasks, CRC cards, code, and tests. |
|
Model in Small Increments |
This practice supports XP's iterative and increment approach to development. Both XP and AM prefer an emergent approach to development and not a big design up front (BDUF) approach. |
|
Model to Communicate |
This practice is modeling-specific, describing one reason why you would want to model, a practice that reflects XP's and AM's principle of Open and Honest Communication. |
|
Model to Understand |
This practice is modeling-specific, describing the primary reason why you would want to model. This practice is consistent with XP's existing use of CRC cards to explore design issues. |
|
Model with Others |
This is the AM version of XP's Pair Programming practice. |
|
Prove It with Code |
This is the AM version of XP's Concrete Experiments principle. |
|
Reuse Existing Resources |
This does not directly related to any XP practice. |
|
Update Only When It Hurts |
This practice reflects AM and XP's Travel Light principle, advising that you should update an artifact only when you desperately need to. |
|
Use the Simplest Tools |
This practice reflects AM and XP's Assume Simplicity principle and is consistent with XP's preference for low-tech tools such as index cards for modeling. |
Looks like we have a good value, principle, and practice alignment between AM and XP! The next section looks at how we apply AM principles and practices, during a typical design session.