To explain how the practices of AM can be applied on an XP I will work through a
portion of the SWA
Online Case Study and show how modeling is used throughout the XP
lifecycle. XP has a project lifecycle? Yes. Figure
1 depicts a high-level view of the XP project lifecycle, modified from (Wells,
2001) to indicate a mapping of Beck's (2000) project phases (the Death phase,
not shown, would follow maintenance). Although the term phase may
bring connotations of waterfall development the fact is that phases can occur
iteratively, something that is apparent in Figure
1 by the fact that it is possible to move back and forth between the
Planning, Iterate to Release, and Productionizing phases. Phases
aren't necessarily long - the Planning phase may
only take several hours for example.
Furthermore, XP teams typically don't think of
themselves as working in phases, they just think
of themselves as working.

Having said this it makes it
easier to think about the development effort one phase at a time so let's
examine each one in turn:

The first phase that an XP project experiences is the Exploration
phase (Beck, 2000), encompassing the
initial requirements modeling
and
initial architectural modeling aspects of the agile
software development lifecycle.
This phase includes development of the architectural spike and the development
of the initial user stories.
From a requirements point of view he suggests that you require enough material
in the user stories to make a first good release and the developers should be
sufficiently confident that they can't estimate any better without actually
implementing the system.
Every project has a scope, something that is typically based on a collection of
initial requirements for your system.
Although the XP lifecycle presented in Figure
1 does not explicitly include a specific scope definition task it implies
one with user stories being an input into release planning.
User stories are a primary driver of the XP methodology - they provide high-level
requirements for your system and are the critical input into your planning
process.
The implication is that you need a collection of user stories, anywhere from a
handful to several dozen, to get your XP project started.

However, there's a potential problem.
When a project begins a software approach may not have been chosen for it, this
is often a decision that is made once a better understanding of the scope of the
effort is understood and people have been identified to the work on the project
because as Cockburn (2002) suggests you want to choose the process that best
aligns with the nature of your project, team, and organizational culture.
The implication is that if the decision hasn't yet been made to take an XP
approach then the people performing the IRUF effort may choose to create
something other than user stories - shall statements, features, and use cases
are common options.
If this is your situation you will need to convert these artifacts into user
stories.
Luckily shall statements and features are very similar to user stories so that
should be straightforward and because use cases typically have greater scope
than user stories the easiest approach is to simply declare them to be user
stories and then go about splitting them as you normally would to reduce them to
a manageable size.

For example, assume that your original IRUF efforts resulted in the use case
diagram of Figure 2 and you have decided to take
an XP approach to development.
Therefore you need to translate these use cases into a collection of
user stories, both of these artifacts are described in the article Artifacts
for Agile Modeling, several of which are presented in Figure
3.
The Place Order use case has been "converted" into a collection of eleven user
stories whereas the Search For Item(s) use case simply became a single user
story because it was a relatively simple use case.
Luckily the team that had identified the initial requirements had written up
reasonably good description for the Place Order use case, see Agile
Requirements Modeling, so all we needed to do was work through the
description and introduce user stories as appropriate, writing each user story
on an individual index card.
Why index cards?
Index cards are easy to work with, both when we are writing them as well as
using them to plan our project - several people can work on them simultaneously
as a team by simply moving them around on a table or tacking them to a bulletin
board. As part of our Release Planning effort we
may discover that we need to split some of these proposed user stories further,
but for now they should prove sufficient.

An important concept to recognize is that the user stories presented in Figure 3
may be sufficient for now because they provide enough insight for us to begin
development.
Yes, as the project progress we would need to identify user stories for other
aspects of the system, particularly order fulfillment and inventory management,
but placing orders is clearly our number one priority for SWA
Online so these are the user stories that we can start with. Remember, we
develop software incrementally, not as one "big bang", so it's valid to work
this way.
Having said that it's also important to recognize that we could also work
through all of the use cases indicated in Figure 2
and identify a large collection of user stories to be used as input into the
Release Planning phase.
We could also do something in between these two extremes and flesh out the high
priority use cases at first, likely choosing to explore the Manage Inventory and
Fulfill Order use cases in addition to Place Order and Search for Inventory
Items, and leave the rest for later.
Which approach would I take?
The one requiring the identification of the least number of user stories that
gets our project stakeholders to the point where they are confident that we
understand the system's scope enough to move forward into development of the
first release.

The customer wants to review an order online to verify it before
scheduling it for fulfillment.

The customer wants to receive an email summary of an order
when the order is scheduled for fulfillment.

The customer wants the option to update an order before scheduling it for
fulfillment.

The customer adds an item to an existing order.

The customer removes an item from an existing order.

Customers search for inventory item(s) to add to an order.

The customer indicates their shipping address for an order.

The customer indicates a different billing address for an order.

The customer indicates that their billing address is the same as their shipping address.

The customer wants to see the subtotal before taxes, discounts, and
shipping & handling for an order.

The customer wants to see a grand total for an order.

The customer wants to see applicable taxes, discounts, and shipping and
handling charges for an order.

Of course, it might just have been more effective to write the first two or three user stories and then
create a few screen sketches of what the supporting UI looks like. Different teams
will find different modeling strategies work for them.

The second aspect of the Exploration phase focuses on your system architecture.
Architecture within an XP project is less formal than in traditional
methodologies, with a preference for keeping your system flexible - XP
recommends that you embrace change, as does AM, whereas architecture-driven
approaches advise you to build the skeleton the system first because some things
are difficult to change (Wake, 2002).
The XP approach is to identify a metaphor that describes how you intend to build
your system.
The metaphor acts as a conceptual framework, identifying key objects and
providing insight into their interfaces.
The metaphor is defined during an architectural spike early in the project,
during the first iteration or during a pre-iteration that is sometimes referred
to as a zero-feature release (ZFR) (Wake, 2002).
Beck (2000) suggests that user stories for the first iteration be chosen so that
will force you to "create the whole system, even if it is in skeletal form."
So, is it during a pre-iteration/architectural spike that the system metaphor is
identified, as suggested in Figure 1,
or is it during the first iteration?
It doesn't really matter as long as it's done at the beginning of your project.
This ambiguity was one of the reasons why
Agile Model
Driven Development (AMDD) includes initial modeling, including
initial architectural modeling and
initial requirements
modeling, to make it explicit that your architecture should be
considered before getting actively involved in construction iterations.

Just because XP focuses on a system metaphor that doesn't imply that you are not
going to have an architecture, nor does it imply that you're not going to have
any architectural diagrams.
For example, Newkirk and Martin (2001)[1] created a high-level diagram overviewing their architecture to enable them
to better understand what it was they were building, and a similar whiteboard
sketch is presented in Figure 4 for
SWA Online.
Notice how it combines UML use case diagram notation for actors, the stick
figures, as well as free-form diagramming - the AM principle Content Is More
Important Than Representation advises that it's more important to model your
ideas properly than it is to use sanctioned diagramming notation or to make your
diagrams look pretty.
This diagram also shows an application of the AM principles of Depict
Models Simply and Create
Simple Content: it is just good enough to indicate our proposed technical
architecture and no more.

The diagram of Figure 4 would be
drawn by the development team, following the AM practice Model
With Others as described in Agile
Architectural Modeling, standing up around a white board. It is based on the
user stories of Figure 3 as well as the use
case diagram, and corresponding use cases, depicted in Figure
2.
The team isn't going to ignore the material captured by the use case diagram and
use cases just because they're not official XP artifacts, whatever that means,
instead we would follow the AM practice Reuse
Existing Resources and take advantage of them.
You can see that our candidate architecture seems to handle both order placement
and order fulfillment activities.
The team has also indicated two aspects of the architecture that it feels are
uncertain - it believes it can place a shipment pickup request via XML to
shippers and calculate applicable taxes via a commercial off the shelf (COTS)
system - by labeling them with question marks (Ambler,
2001a, Ambler, 2002).
At some point we will need to do spikes for these aspects of the system to
determine if they are feasible, and potentially include these tasks as part of
our initial architecture spike (just enough code to show that this candidate
architecture will work).

When applying AM's practices on an XP project remember that a primary value of
XP, as of AM, is communication.
The value isn't in the models that you create, it is in the modeling effort
itself - the fact that a model has helped you to understand what your
stakeholders want, or how you intend to fulfill their needs, or that has helped
you to communicate what you are doing is what is important.
Although we may choose to follow AM's Display
Models Publicly practice and leave Figure
4 on the whiteboard for awhile the fact is that it doesn't really provide a
lot of value to our team anymore, except perhaps to indicate that we still have
two outstanding issues to address.
Because the team was involved in its creation, and because they are now
developing to the technical vision captured in the diagram, they know the
technical architecture and likely will not need to look at the diagram again.
Other people may learn about your architecture, perhaps through osmotic
communication (Cockburn, 2002) described in the Communication
article as they walk by it, and perhaps you'll choose to show the diagram to your
project stakeholders to help you to explain your approach (a good example of
applying AM's Model
to Communicate practice).

Although Figure 4 provides some
insight into your technical architecture it really doesn't provide much insight
into your system metaphor.
For SWA Online traditional a grocery store metaphor would be a likely candidate.
An order is just like a shopping cart, customers browse through your online
store placing items into their carts, pull items that they don't want out of
their carts, and eventually take their carts to the checkout where taxes, fees,
discounts, and their order total are calculated.
The selected items would be then placed in boxes and shipped to us, similar to
the way that bag-boys in grocery stores put our purchased items in bags and give
them to us.
The development team would have discussed this metaphor in parallel to sketching
the overview diagram, perhaps drawing a free-form sketch such as the one
presented in Figure 5 on a another section
of whiteboard, just as AM's Create
Several Models in Parallel practice suggests.
This sketch would very likely be erased once the team had agreed on the metaphor,
having served its purpose - the team followed the AM practice Model
to Understand and now the practice Discard
Temporary Models would apply.

Following the Exploration phase is the Planning phase (Beck, 2000), the purpose
of which is for you and your customers to agree on a date by which the smallest,
most valuable set of user stories will be implemented.
When you are release planning you will brainstorm what the tasks for a given
user story (Wake, 2002), writing a task card for each task.
A task card, see Figure 6 for examples,
typically lists a text description of what you need to do to accomplish the task.
Sometimes a task card may be described using a model instead of text, for
example Newkirk and Martin (2001)
[2]
provide an example where a task was described as a sketch of an HTML page
similar to the one presented in Figure 7.
The team may have simply sketched this figure on a whiteboard, or used a
combination of Post It notes and flip chart paper to create an essential user
interface prototype at first, and once they were happy with what they had
quickly transcribed it onto an index card.
Both a whiteboard and Post It notes are far more flexible than pen and paper, so
they are a better option for you when initially thinking through the design of a
user interface component such as this one.
The reason why you want to transcribe your sketch onto a card is to have a
record of your design to base your coding efforts on during the next
iteration, and cards are the preferred medium of choice to do so -
distributed teams might choose to record tasks electronically, perhaps in a Wiki
(Leuf Cunningham, 2001) or other collaborative environment.
In this case a sketch of the screen is a more effective description of the task
than free-form text.

Modeling is clearly a potential activity during this phase.
For example Figure 8 depicts a sketch
representing the logic of a task - the team chose to create this sketch instead
of write text for it because they were more comfortable with a quick diagram.
This is perfectly fine, the AM principle Model
With A Purpose advises that you should know your audience and create
models that reflect their needs (in this case your team itself is the audience
of the task cards), and the AM practice Apply
the Right Artifact(s) advises you to create the best type of model suited
for the task at hand.

The Iterations to Release Phase (Beck, 2000) encompasses the primary effort of
an XP project, more typically referred to as construction iterations or simply
iterations, as this is where your major development efforts including modeling,
programming,
testing, and integration occur. Figure
9 (Wells, 2000) depicts the lifecycle for an iteration. Iteration
planning is the same type of effort as release planning, described above, the
only difference being that the focus is on the user stories assigned to the
current iteration. When you are working on iteration N you will find that
new user stories, ones that have not been estimated, have been added in
therefore you need to go through the effort of identifying tasks so you may
accurately estimate each user story. After estimating the new stories, and
perhaps revisiting the other stories just to be on the safe site, you may find
that you have too many or too few stories for the iteration and will need to
move stories to/from other iterations.

From the point of view of modeling, the interesting aspect of an iteration is in
the development aspect of Figure 9,
a detailed lifecycle for which is presented in Figure
10 (Wells, 2000).
A lot of the modeling that occurs during development happens in stand-up
meetings where the team gathers to discuss what they are currently working on,
often asking for advice regarding how to approach a specific issue.
When this happens it is quite common to discuss the issue around a whiteboard,
drawing sketches as needed to enhance the communication effort.
Stand up meetings are called exactly that because everyone stands up when
attending them, which tends to make them brief (Beck & Fowler, 2001).
Figure 10 hints at the idea that
after the stand-up meeting the team breaks up into pairs to work on their parts
of the system.

An alternate view is presented in Figure 11
that depicts a typical XP developer's day (Wake, 2002).
It explicitly shows that people pair up after the stand-up meeting, often
starting with a quick design session as required to formulate an initial design
strategy for what they are working on.
A fundamental aspect of XP is that people work together in pairs, following a
practice called Pair Programming, which would have been more
appropriately called Pair Development, which is defined as a dialog
between two people trying to simultaneously program (and analyze and design and
test) and understand how to program better (Beck, 2000).
XP developers will hold a quick design session, what AM calls an
ad-hoc or impromptu modeling session (see the article Rethinking
Modeling Sessions), whenever they are not sure how to proceed with
programming (Jeffries, Anderson, & Hendrickson, 2001).
The basic idea is that you get a few people together to work through the issue,
in other words follow AM's Model
to Understand practice, to spend a few minutes discussing ideas and modeling
as necessary.
You will naturally want to follow the practice Apply
the Right Artifact(s) and work on the type of models that are appropriate to
the issue you are discussing, for example CRC cards are a good option if you are
exploring the structure of your code and an essential user interface prototype
may be just the thing if you are exploring the design of your user interface.
You'll sometimes find that a design issue will require several models, perhaps
you need to create both a CRC model and an essential UI prototype to fully
explore the problem, and will therefore want to follow the practices Create
Several Models in Parallel and Iterate
to Another Artifact.
These modeling sessions are typically very short, hence the name quick design
session, lasting anywhere from ten to thirty minutes.
To gain feedback regarding your design you want to quickly get back to coding,
following the practice Prove
it With Code, to determine if your approach works or not.
If it does then great, if not then back to the whiteboard for another quick
design session.

Let's work through an example. Figure 6 includes a task called "Submit Search
to DB".
Let's assume that we've already built things in the past such as this - we need
to pull information out of an HTML response, replace any wild cards within the
criteria with SQL equivalents (e.g. replace * with %), build a string
representing an SQL statement, and submit the string to our database - and
therefore don't need to spike anything.
What modeling would we consider doing?
Pulling information out of the HTML response is fairly easy to code as is
replacing wild cards within the text.
We may even want to consider refactoring our existing code, if we haven't
already done so, to include classes or components that implement the two common
services.
Building an SQL statement is also straightforward, you simply write code to
concatenate strings together, although it hints at something we may want to
model: our database design.
To build an appropriate SQL statement we need to know the layout of the database,
including the names of tables and columns as well as the type of the column.
Knowing what indices exist for the tables we are accessing, and any relevant
stored procedures for searching those tables, provides some insight into
potential performance and implementation issues that we want to consider.
Many development teams will create and maintain a physical data model that
depicts some or all of this information.
Very good data modeling tools exist to do this, tools that will not only
generate the DDL (data definition language) that you need to create the tables
in your database and triggers on those tables but will also reverse-engineer
existing legacy schemas as well so you can understand legacy data schemas that
you may need to access.
As your project progresses your team updates the data model, automatically
generating the database code that they require, to reflect new requirements.
In the case of this task you would want to ensure that your database includes
columns that store the name of an item, the item number, the item category (e.g.
clothing, electronic goods), and the price as Figure
7 implies.
Luckily your team has a physical data model in place, see Figure
12, for the work you have already done and it indicates that this information
exists in the database.
However, you notice that the primary key of the Item table is not the
Item_Number column but instead is Item_OID, a persistent object identifier
something that data professionals often refer to as a surrogate key (Ambler,
2001e).
The issue is that according to the task card we must order the results by order
number, something that is easy to achieve via SQL's "ORDER BY" clause, albeit
something that may have slow performance because the primary key isn't the same
column we are sorting on.
The implication is that if we find that we have performance problems we may want
to use our CASE tool to add and generate a secondary index based on Item_Number
as a potential solution.

The idea of using a CASE tool on an XP project to maintain your DB schema brings
up an interesting issue - do you train everyone on how to use the CASE tool?
On the SWA Online team we have one person, Brendan, who is working on his
certification as an Oracle DBA and is very eager to do any database-related work
and has been working with the tool for several years now. We also have
Marion, someone who has been developing for years and who has significant
database and data modeling experience who also has worked with the tool.
Other developers on the project - Henri, Ed, Marc, and Tyler - have all paired
with Brendan and Marion from time to time to work on the data aspects of the
project but have minimal experience with the tool. Should you train the others
on the tool? Right now your project team is working smoothly, you have two
people intimately familiar with the tool and four that could use it if they
needed to. If anyone wanted to learn about the tool some more they would
be more than welcome to pair up with Brendan or Marion whenever a database-related
task came up, and if they wanted formal training I would in fact consider giving
it to them at the time. Would I send everyone to go on the training course?
Likely not because it wouldn't provide a lot of value to do so.

How does everyone stay up to speed about the data model? First, during the
stand-up meetings everyday anyone who has made a change to the database schema
the previous day should say so. Second, the data model is a good candidate
for printing and putting up on the wall, as the practice Display
Models Publicly suggests. This way when you're having quick design
sessions and you need to consider a database change you have the schema in front
of you, and if you like you can even hand-draw changes as you talk about them.
Note that you don't need to print out your diagram every time you make a tiny
change, let AM's practice Update
Only When it Hurts guide you with this (most people can live with a diagram
that has a few hand-drawings on it). If you do make it a habit to print
your diagrams I highly suggest investing in a plotter - taping printer-size
pages together quickly becomes tedious.

Let's work through another example. Figure 3 includes a user story that describes
the totaling of an order, indicating that the system calculates applicable taxes,
discounts, and shipping and handling charges for an order.
Working through XP's Planning Game practice you quickly realize that this user
story is quite large and decide to split it into three separate stories, one for
taxes, one for discounts, and one for shipping and handling charges.
Our customers decide to make the discount user story low priority, so we put it
at the bottom of our stack of story cards, and the other two are given high
priority and assigned to this iteration.
Because this is SWA
Enterprise's first foray into selling directly to consumers it has never had
to deal with complex taxation or shipping issues before.
You've got a problem, what do you do?

The first step is to recognize that you need to identify requirements for these
two user stories, the source of which is your on-site customer.
You ask Wendy, your customer, to help explain these user stories to you - an
example of Q&A from Figure 11.
During Q&A the customer is available to provide immediate answers, often to
make decisions regarding how something should work or to provide information to
the developers.
Luckily Wendy has previously worked in your existing shipping department so has
some idea how shipping and handling charges may work, however, she does not have
any knowledge of tax rules.
She tells you that for now assume a flat shipping and handling charge of $5 and
that your state tax of 6.5% is the only applicable tax and it should be applied
to all products that SWA Online will carry.
She agrees to add the appropriate acceptance tests for these two decisions to
the test suite that she has been evolving throughout the project. She also tells
you that she will look into both issues for you and get back to you in the next
day or so.

Often the customer will be asked to write an acceptance test answering the
question or sometimes to write a new story (Wake, 2002).
This is an interesting aspect of XP - instead of writing a detailed requirements
document and then developing based on its contents XP teams instead build up a
collection of acceptance tests with their project stakeholders and ensure that
their system fulfills those acceptance tests.
This leads many XP developers to claim that acceptance tests are requirements,
and you know what, they're right.

You now have a place to start because your customer has made a decision.
Yes, the details are likely to change when more information is available but
that's no problem because you'll deal with the changes when you know about them
- After all, you're part of an XP team so you embrace change.
As Figure 11 indicates you get into a Test-Code-Refactor
cycle and start coding.
With XP, you start with a test so that you know when you are done.
You design and implement just enough to get that test running, and whenever you
see a chance to make the design simpler do so through refactoring.

Later that day Wendy drops by your desk as you and your pair are working away.
She tells you that she has left a voice mail with someone in accounting who
should be able to explain the relevant tax rules to you.
She has also gotten in contact with a friend of hers, Jake Blues, who works at
Fly-By-Nite Shipping, the courier whom SWA Enterprises intends to use for the
first release of the system.
Jake is available tomorrow morning at 9 am for a half-hour conference call which
Wendy wants the two of you to attend.
You also take the opportunity to show the work that you have gotten done on the
user story, showing that a line has been added to the order summary indicating
the shipping and handling charges and the new total for the order (the original
subtotal plus the new charges).
She doesn't like the way it looks on the screen, you got the alignment wrong, so
you promise to correct the problem.

The next morning you, your current pair, and Wendy get together in a meeting
room and call Jake. The three of you agree to take notes to ensure that
you record the information from Jake. Jake informs you that Fly-By-Night
negotiates shipping rates with its clients and provides an electronic
spreadsheet once a quarter of the rates for that quarter, a sample of which he
emailed to Wendy earlier that morning. There are two basic reasons why a
new spreadsheet is produced quarterly - the overall rates may change based on
changing costs for the shipping company, fuel being the main factor, and the
amount of business that you do with them (the more you ship, the lower your
rates). The spreadsheet is generated by Fly-By-Night's accounting
department and is provided to their customers no less than two weeks in advance
of any rate changes. Within the spreadsheet the rates vary by the weight
of the package being shipped, the size of the box, and the distance the package
is going. Weight is measured in ranges - for example < 6 oz., 6 to 12
oz., and so on - as is the size of the box. Distance, on the other hand,
is measured in zones. Jake asks you for your fax number so he can send you
a map indicating the zones. The zones are fairly straightforward, working
outwards from their major distribution center in rough circles. The good
news is that an entire state is either in a zone or it is out of it and this
zone system has been in place for almost ten years and hasn't changed for seven
years now. He provides you with a few more details and offers to be
available via phone and email if you have any more questions.

After the phone call the three of you walk back to your work area and decide to
have a quick design session to understand your approach to implement the
calculation of shipping and handling charges.
Wendy points out that not only do we need to charge the right amount for Fly-By-Night's
fees we also need to cover our own internal fees too.
Wendy remembers that the accounting department feels that $0.50 a shipment was a
fair price but she would need to verify that with them.
More importantly, you need to understand how to calculate the shipper's portion
of the fees.
The three of you start by working through some CRC cards, presented in Figure
13, to identify the potential classes and responsibilities that you believe
you need.
In parallel you also sketch a UML sequence diagram, presented in Figure
14, which shows the interaction between the classes to support this
functionality.
You work back and forth between the two models for about ten minutes until you
think you have a good strategy for implementing the calculation so you're ready
to start coding.
As you work on these models you also discuss how you will need to test
this functionality, information that Wendy records on index cards, one for each
acceptance test.

Knows
shipment cost for a given box size and weight
range within a delivery zone

State

Knows
delivery zone the state is in

Order

Knows
ship-to address

Knows order
items

Calculate
shipping and handling costs

Shipping
Cost Calculator

Order Item

Order Item

Knows number
of items ordered

Knows item

Item

Item

Knows weight

Knows width

Knows height

Knows breath

An interesting observation is that the CRC cards of Figure
13 and the UML sequence diagram of Figure
14 aren't perfectly consistent with one another. That's ok. In
general, agile models don't need to be in sync with one another, they just need
to be good enough and these two models are. When you discover that two artifacts
are out of sync you should follow the practice Update
Only When it Hurts and fix them only if provides positive value to your
project.

Apply
the Right Artifact(s) when you chose to work with CRC cards to identify the
static structure of your software and sequence diagram to explore the dynamic
nature of the interactions between those classes.

Consider
Testability when you identify acceptance tests while working on the sequence
diagram and CRC cards.

Discard
Temporary Models once you are finished coding the information captured by
your models they likely won't provide any more value to you so you had might as
well erase the diagram from the whiteboard and throw away the cards.

You're just about to start coding when Wendy points out that you're not done yet.
You need to introduce a new user story for accepting the spreadsheet from Fly-By-Night
Shipping and getting the new figures into the system. She indicates that
this is a high priority item that will likely need to be included in the next
iteration. You realize that your team may want to follow the practice Formalize
Contract Models and put together a short document describing this interface
to the shipping company. It would likely include a paragraph or two
describing the process of receiving the spreadsheet, an example of the
spreadsheet itself, and a description of the import process (either automatic or
manual depending on your solution). This document would become part of
your overall system documentation.

Later that day Wendy hears back from the accountant she contacted regarding the
tax rules. It appears that if you ship a product to someone within this
state then a state tax of 6.5% applies for all products, otherwise no sales
taxes are collected. He also indicated that individual states are in the
process of considering laws that require the collection of taxes for online
sales where the shipping address is in their state, and he feels that it is very
likely that some states will pass these laws within the year. He also
indicated that the Federal Government is considering a value added tax (VAT) of
3% on online sales although it is unlikely that this will come about any time
soon. Finally, he pointed out that most foreign countries have duties and
sales taxes that would be applicable once SWA Online went international.
This information has made Wendy a little nervous.
What would happen if the tax rules changed suddenly?
You reply that the project team would act accordingly at that time.
She asks whether or not you need a big design session to ensure that your system
can handle these changes.
You reply that you don't want to overbuild your system to implement
functionality that you may not ever need, and you certainly wouldn't want to
have to maintain that additional code over time either.
But she's still worried, she wants to make sure that the team understands that
the way you handle tax will need to change over time.
So you suggest a compromise - instead of overbuilding your software why don't we
simply record these potential requirements and describe them to the rest of the
team at tomorrow's stand up meeting?
Wendy's accepts this idea, it's worked well in the past, and you quickly write
up some index cards as depicted in Figure 15.

XP's Productionizing phase (Beck, 2000) is very close to the deployment phase in
the agile
software development lifecycle and encompassing the Acceptance Testing and
Small Releases part of Figure 1.
He states that there is typically some process for certifying that the software
is ready to go into production, potentially what I call "testing in the
large" techniques (Ambler,
1999; Ambler
& Constantine, 2002) such as system testing, load testing, and
installation testing to name a few. During this phase you will slow down
the rate at which you evolve the software, evolution doesn't stop, but the risk
of whether something should go into the next release become important.
Note that on some projects this phase is little different than a
typical construction iteration, the major difference being that you
release your system into your production environment instead of into
your development sandbox.

So how does AM apply in this phase?In two ways. First, you may find that you need to model as part of your
rework efforts resulting from newly discovered defects. Second, this point in your project is a good time to consider
cleaning up your documentation. Although
the XP philosophy is write very clear, understandable code and to include
effective comments in the code as necessary, the reality is that you still need
supporting documentation. Remember
that you have a wide range of project stakeholders, including users, senior
management, operations staff, and support staff. These people do not have
access to the code, nor would many of them understand it even if they did, so
they will require other forms of documentation. This documentation should
be at the request of project stakeholders, as the AM principle maximize
stakeholder ROI points out it's their resources that are being
invested in the documentation therefore they have the final word on what should
be done. I prefer to write
documentation such as this late in the project lifecycle because what you are
writing about, the system, has become relatively stable for the current release
and therefore the documentation you write will be stable too.You may also need to produce these documents (following the principles
described in Agile
Documentation):

System documentation. For developers, including maintenance professionals, this is
the most important type of documentation.The purpose of this document is to provide an overview of the system
and to help people understand the system.Common information in this document includes an overview of the
technical architecture, the business architecture, the high-level
requirements for the system, a summary of critical design decisions,
architecture-level diagrams, and important design models (if any).

Operations documentation. This documentation
typically includes an indication of the dependencies that your system is
involved with; the nature of its interaction with other systems, databases,
and files; references to backup procedures; a list of contact points for
your system and how to reach them; a summary of the availability/reliability
requirements for your system; an indication of the expected load profile of
your system; and troubleshooting guidelines.

Support documentation. This documentation includes training materials specific to
support staff; all user documentation to use as reference when solving
problems; a trouble-shooting guide; escalation procedures for handling
difficult problems; and a list of contact points within the maintenance
team.

User documentation. Your users may require a
reference manual, a usage guide, a support guide, and even training
materials. It's important
that you distinguish between these different types of documents because the
way that each one is used varies: one is for quick lookups, one is for
discovering about how to work with the system, one is for how to obtain
additional help, and one is for training.

The XP Maintenance phase (Beck, 2000) is the normal state of XP projects because
you keep evolving them over time. This phase encompasses the Planning,
Iterations to Release, and Productionizing phases for releases 2 through N of
your system. By implication it also includes the activities of the agile
software development lifecycle's Production phase for the current release(s)
of your system in production. It is important to recognize that systems built
taking an XP approach are put into production just like systems built using any
other approach. Production issues, such as operations and support, are
outside of the scope of both AM and XP. However, it is important to recognize
that your team needs to take production-related issues into account which is why
AM explicitly includes operations and support staff as potential project
stakeholders. Remember, there is little value building a system if you can't
deploy it and then keep it in production.

Share with friends:

Let Us Help

We actively work with clients around the world to improve their information technology (IT) practices,
typically in the role of mentor/coach, team lead, or trainer. A full description of what we do, and how to contact us, can be found at Scott Ambler + Associates.

Recommended Reading

This book, Disciplined Agile Delivery: A Practitioner's Guide to Agile Software Delivery in the Enterprisedescribes the Disciplined Agile Delivery (DAD) process decision framework.
The DAD framework is a people-first, learning-oriented hybrid agile approach to IT solution delivery. It has a risk-value delivery lifecycle, is goal-driven, is enterprise aware, and provides the foundation forscaling agile.
This book is particularly important for anyone who wants to understand how agile works from end-to-end within an enterprise setting.
Data professionals will find it interesting because it shows how agile modeling and agile database techniques fit into the overall solution delivery process.
Enterprise professionals will find it interesting beause it explicitly promotes the idea that disciplined agile teams should be enterprise aware and therefore work closely with enterprise teams.
Existing agile developers will find it interesting because it shows how to extend Scrum-based and Kanban-based strategies to provide a coherent, end-to-end streamlined delivery process.