XP and Ant, Page 3
The XP Process
In XP, the customer drives the development priorities. The process starts by the customer developing user stories that describe the operation of the system. User stories should be written on index cards, so they can be shuffled around, marked up, or even torn up. A user story might say something like: "When the user finds an item they want to buy, they can add it to their shopping cart, and continue shopping." A user story should be something that a developer can implement in about a week. Of course, the customer has no way of knowing what a week's worth of work is for a developer. So it's the developer's responsibility to ask the user to break up a story into smaller stories if it's too big, or to combine small user stories into an appropriate sized story.
The user stories form the system requirements, and the customer gets to drive the order and priority of implementing those stories. When the developers look at the user stories, some concerns may arise about how to implement a story or the technology that may be used. In such cases where things are fuzzy, and therefore risky, the answer is to write a spike. The spike is intended to be throw-away code, so it doesn't get developed with the same rigor as production code. The intent is to test and perform a proof-of-concept for something specific. This will allow a more accurate estimate of the time required to implement a particular user story. The phase where customers are writing stories and developers are experimenting with spikes is considered the exploration phase of the iteration.
The Phases of an Iteration - Releases are composed of iterations. A release should contain about three iterations, and each iteration should be about one to three weeks in duration. XP divides the activities within releases and iterations into three phases: exploration, commitment, and steering.
The exploration phase is for information gathering. It involves collecting user stories, determining the requirements of the system, and performimg spikes.
In the commitment phase, the developers take the story cards and estimate the difficulty of each task. Here is where stories might be combined or broken up to create work units of the correct size. Then a release or iteration planning meeting is held to plan the work. At this point, the user stories for the upcoming release or iteration are chosen, based on their business value.
The steering phase encompasses the rest of the iteration or release. Steering occurs by gathering project feedback and then taking corrective action based on that feedback. It is a process of continuous course corrections, much like steering a car. Steering is a very important part of the XP process, because it's done continuously. Some traditional forms of project management may go weeks or months without serious corrective action based on feedback. It's easy for projects like this to go astray. In XP, software is tested and integrated many times per day. Continuous steering ensures that the project will stay on track.
The next step is the Release Planning meeting. The customer and the development team meet and go over the user stories that the customer would like to have in the first release. The developers divide into groups and go over the user stories, assigning a difficulty rating, or points to each story. The harder a story is to implement, the more points it gets. This is also the opportunity for developers to ask the customer questions about stories. The developers attempt to estimate how many points they can get done in an iteration, and therefore, how many stories can be implemented in the first iteration. If it's not possible to accomplish everything in the first iteration that the customer wants, it's up to the customer to decide what the priorities are. The customer makes that decision based on the business value of each story, and its estimated difficulty. It's important to plan small, frequent releases, to put new capability into the hands of the customer as quickly and as often as possible.
XP projects typically work in 3- to 4-week cycles called releases. At the end of each release, new functionality in the form of an incremental release is delivered to the customer. Each release is broken up into iterations, which typically are a week long. At the start of each iteration, an Iteration Planning meeting occurs with the development team and the customer. The customer will present each user story in detail, and permit the developers to ask questions about it. The developers in turn will discuss the technical aspects of implementing the story, and put them up on a board. At the end of the meeting, developers sign up for tasks and make commitments for completing those tasks.
After each Iteration Planning meeting, and within each iteration, developers will meet for short design sessions. The tools might include Class-Responsibility-Collaborator (CRC) cards or some Unified Modeling Language (UML) sketches, to get a good idea of what objects are involved, and how they will collaborate.
When the team starts to actually develop code, developers will pair up. The pairs are not permanent arrangements, but arranged to address some particular phase of development. Any given developer might pair with several different people during the course of the work day. When writing code, the pair first writes a unit test that will test the aspect of the class that they're going to implement. Then the class is written, compiled, and tested. Writing the unit tests and classes can be iterative in itself. For example, the unit test may be written to test one method of the class, and then that method is implemented in the class. Then another unit test may be written to test the next method of the same class, and then the second method added. The point is to make incremental changes and test often. Because of the frequency of unit testing, it's imperative that unit testing be automated. In this book, we'll show you how to automate unit tests and make them part of your build process. Also, by having automated unit tests, it will become immediately apparent if a developer makes a code change that breaks something.
At any point when code compiles and passes unit tests, it can be committed to the revision control repository. When this happens, it will be integrated and tested in the overall system. XP relies on a process of continuous integration. This means that the entire system is built on a regular basis, perhaps many times per day. The purpose is to catch problems and inconsistencies as quickly as possible, while they're still easiest to fix. As part of the integration build, tools are used to check for compliance to coding standards, and metrics can be generated. This book also covers the use of open-source third-party tools for accomplishing these tasks, and how to integrate them with Ant as part of the build and deployment process.
Prior to delivering a release to the customer, automated acceptance tests are run. If any of these fail, the bugs are fixed, and the code is rebuilt and tested again. If you plan small releases, functionality can be added incrementally, and quality maintained, while delivering new functionality to the customer on a frequent basis.
The Need for Speed
Working in an iterative methodology like XP means that a development team will be performing builds, unit testing, and integrating many times per day. These tasks need to happen as accurately and rapidly as possible to increase the project velocity. Also, these processes need to be repeatable. That's why these processes must be automated into a repeatable build, testing, and deployment process.
Creating an automated process provides another advantage by enforcing a discipline in the thought process. When creating an automated build process to perform a task, you as a developer are forced to think through all the details with greater stringency than you would if you simply documented a procedure. A written procedure doesn't have to compile or execute, and it's easy to miss a step or make a mistake. Certainly, the written process can be tested by users and debugged. Conversely, an automated procedure is not guaranteed to be bug-free. But even with a well-debugged written procedure, as complexity increases, so does the likelihood of human error when following it.
In short, an automated process means less drudgery for the developer and fewer errors. That translates into increased speed. In the spirit of XP, it's mandatory to automate as much as possible to reduce the developer workload and the likelihood of errors each time a process is carried out. Any task that must be repeated on a frequent basis should be automated.
Sharing the Knowledge
Another advantage that results from automating a process is that the whole team gets to share the benefit of the knowledge of the developer who created the process. It also preserves that knowledge for the team. When you've validated that an automated procedure works correctly, you only have to make it available to other developers to ensure that this procedure will then be run consistently by all users.
This can shield the development team from having to know the details of every product in the development environment. This is accomplished by developing Ant rules that handle the details of certain complex tasks. When the team size gets larger, it's unlikely that everyone will have an in-depth knowledge of every aspect of the system, such as the revision control system, for example. Suppose you're using Concurrent Versions System (CVS). Most developers will probably know how to perform basic operations, such as how to do an update, how to check out a module, and how to commit changes to the revision control system. However, they might not understand the nuances of branching or tagging. Perhaps your deployment process requires the developer to deploy Enterprise Java Beans (EJBs) to an EJB container, such as JBoss. This can be a complex task to get right every time, especially when you're under the pressure of a deadline. But if you develop the right rules in your build and deployment tool, the developers won't need this level of knowledge.
Also, as team size increases, it's likely that not every developer will perform certain operations, such as branching, in the same way, even with a written procedure. This could be because of simple human error or a miscommunication. By creating rules in a tool such as Ant to perform development tasks such as revision control access or EJB deployment, you've abstracted the details of the underlying tool.
If you've created the necessary rules in your build process to perform all the tasks that your development team needs to perform for a function such as revision control, it's possible to change the underlying service while maintaining the same procedures for the development team. This really follows the spirit of good object-oriented (OO) design practices at a developer interface level. It's considered a good practice in OO design to "program to an interface, not an implementation" so that your design is not tied to a particular implementation. By abstracting the details of tasks such as EJB deployment or revision control, your team won't have to learn a new set of procedures if the underlying tool changes.