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:

1. Exploration Phase  
2. Planning Phase  
3. Iterations to Release Phase 
4. Productionizing Phase
5. Maintenance Phase

Figure 1. The XP project lifecycle.

1. Exploration Phase

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.

 Figure 2.   A high-level use case diagram for SWA Online.

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.  

Figure 3.   User stories for the Place Order and Search For Item(s) use cases.

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.  

 Figure 4.   An architectural overview for SWA Online.

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.

Figure 5.   A sketch drawn while identifying a metaphor for the system.

2. Planning Phase

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.  

Figure 6.   Example task cards pertaining to searching for items.

 Figure 7.   A hand-drawn sketch representing what needs to be built for the item search page.

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.

 Figure 8. A sketch representing the logic of a task.

3. Iterations to Release Phase

Figure 9. The XP iteration lifecycle.

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.

Figure 10. The XP development lifecycle.

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.

Figure 11. The typical day of an XP Developer.

3.1 Case Study: Searching for Items

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.

Figure 12. A simple data model for SWA Online.

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.

3.2 Case Study: Totaling an Order

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.

Figure 13. CRC cards relevant to calculating shipping costs.

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.

Figure 14. A sequence diagram for calculating shipping costs.

During this process you followed the AM practices:

• 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.

• Create Several Models in Parallel when you chose to work on both the models at once.

• Iterate to Another Artifact when you chose to work back and forth between models.

• 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.

Figure 15.   Recording the potential requirements regarding tax rules as change cases.  

4. Productionizing Phase

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):

1. 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).

2. 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.   

3. 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. 

4. 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.

5. Maintenance Phase

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.

6. Recommended Resources

		The Object Primer 3rd Edition: Agile Model Driven Development with UML 2 is an important reference book for agile modelers, describing how to develop 35 types of agile models including all 13 UML 2 diagrams.  Furthermore, this book describes the techniques of the Full Lifecycle Object Oriented Testing (FLOOT) methodology to give you the fundamental testing skills which you require to succeed at agile software development.  The book also shows how to move from your agile models to source code (Java examples are provided) as well as how to succeed at implementation techniques such as refactoring and test-driven development (TDD).  The Object Primer also includes a chapter overviewing the critical database development techniques (database refactoring, object/relational mapping, legacy analysis, and database access coding) from my award-winning Agile Database Techniques book.
		Agile Modeling: Effective Practices for Extreme Programming and the Unified Process is the seminal book describing how agile software developers approach modeling and documentation.  It describes principles and practices which you can tailor into your existing software process, such as XP, the Rational Unified Process (RUP), or the Agile Unified Process (AUP), to streamline your modeling and documentation efforts.  Modeling and documentation are important aspects of any software project, including agile projects, and this book describes in detail how to elicit requirements, architect, and then design your system in an agile manner.
		The Elements of UML 2.0 Style describes a collection of standards, conventions, and guidelines for creating effective UML diagrams. They are based on sound, proven software engineering principles that lead to diagrams that are easier to understand and work with.  These conventions exist as a collection of simple, concise guidelines that if applied consistently, represent an important first step in increasing your productivity as a modeler.  This book is oriented towards intermediate to advanced UML modelers, although there are numerous examples throughout the book it would not be a good way to learn the UML (instead, consider The Object Primer).  The book is a brief 188 pages long and is conveniently pocket-sized so it's easy to carry around.

7. Let Me Help

I actively work with clients around the world to improve their information technology (IT) practices as both a mentor/coach and trainer.  A full description of what I do, and how to contact me, can be found here. 

Copyright © 2001-2009 Scott W. Ambler This site owned by Ambysoft Inc. Agile Data (AD)  |  Agile Unified Process (AUP)  |  Enterprise Unified Process (EUP)  |  My Writings   |  IT Surveys