This material is from Chapter 1, XP and Ant, from the book Extreme Programming with Ant: Building and Deploying Java Applications with JSP, EJB, XSLT, XDoclet, and JUnit (ISBN: 0-672-32562-4) written by Glenn Niemeyer and Jeremy Poteet, published by Sams Publishing.
Chapter 1: XP and Ant
IN THIS CHAPTER
-
What Is XP?
-
The XP Process
-
Ant and the XP Process
-
The Scope of This Book
Extreme Programming (XP) is a software development methodology for delivering quality software while maintaining a focus on customer satisfaction. Ant is an open-source tool from the Apache Project for creating build and deployment processes. In this book, you will learn how to implement effective XP processes by using Ant.
What Is XP?
XP development is iterative in nature, and delivers quality software through continuous automated testing and integration. XP development demands simplicity. It means refactoring code that is working to eliminate duplicate or redundant code. It is a focus on the here and now, not on what might be needed a week from now. XP emphasizes constant communication between customer and developers, as well as between developers. In fact, in XP, the customer is part of the team. XP is similar to the just-in-time inventory practices in manufacturing.
Characteristics of XP
XP maintains a focus on customer satisfaction. In XP, the customer is part of the team. That means that the customer has visibility and plays an important role in the overall plan. The customer drives the implementation and releases through writing user stories and participating in the Release Planning meetings. Because software is developed iteratively in XP, a working system is always available with some level of functionality. The customer can always view this working system and assess the state of the project or make changes in the system requirements (user stories). That also means that if the customer pulls the plug on the project, he or she will have something of value to show for the investment made to date.
XP emphasizes teamwork. Developers work in pairs on production code, and they communicate with each other. The customer, or at least a customer representative, is co-located with the development team to answer questions that naturally arise. Everyone on the development team works in different areas of the system, and everyone has ownership of the code. The XP methodology facilitates teamwork and requires trust among the team members.
Using XP adds agility to a project. Because of XP's emphasis on simplicity, quality, and testing, an XP project can more easily adapt to unforeseen circumstances than other heavier-weight methodologies can. In fact, XP expects the unexpected. That's why there is the emphasis on delivering functionality as it's needed, and testing and integrating continuously. Developers are always implementing user stories and delivering functionality as it's needed.
In XP, integration problems are caught early. This is because XP is iterative. Builds, unit testing, integration, and acceptance testing are done continuously. You don't have to go through months of coding followed by a death-march type of integration cycle. Integration is easier because it's happening all of the time. If someone starts to diverge on a meaningless tangent in code development (which is unlikely with pair-programming, and the emphasis on implementing stories), the miscue is caught early, before it has a major impact on schedule.
The Core Values in XP
The heart of XP is its four core values:
-
Communication
-
Simplicity
-
Feedback
-
Courage
Communication
Communication is critical to the success of any XP project. That means effective communication between developers, and between the development team and the customer. XP expects that the customer, or a representative of the customer, should be co-located with the development team. This encourages and increases communication and is part of the just-in-time nature of XP. Formal communication occurs between the customer and developer during the Release Planning and Iteration Planning meetings.
Communication occurs between developers during pair-programming. It also occurs between customer and developer when a developer has a question and is able to get a timely response because she can just go talk face-to-face with the customer. Getting timely answers to questions increases the overall quality and success of the project. If a developer has to wait for a document, or a message to be returned, he will probably do one of two things: Either he will guess at the answer or go on to something of lower priority. Neither action is desirable. Although an e-mail dialogue can occur, face-to-face communication is better because it's easier to convey information and to judge how well the recipient understands it.
Simplicity
Simplicity is often harder to achieve than complexity. It requires a commitment to achieve simplicity. In XP, this means that we don't code things that we think we might need at some point down the road. Developers code what is needed to meet the current requirements. As a development team, we strive to maintain a simple design. It also means that we have a constant focus on refactoring to eliminate redundant code. If after a piece of code is developed, a simpler approach becomes apparent, rewrite the code. Because much of the cost of software is in the maintenance, doing this will actually save time and money in the long run. Also, you won't be afraid to change parts of the system or to refactor classes because of the emphasis on continuous testing in XP.
Another aspect of simplicity is in maintaining coding standards. If code is written in a consistent style, it's much easier for anyone to pick up a piece of code and understand it. Maintain standards for naming variables, methods, and classes. Be consistent in the use of capitalization, braces, and indentation. All of this adds to reducing the complexity and the associated cost of building and maintaining software.
Feedback
Feedback is achieved in XP through frequent and thorough automated testing. Testing includes unit tests and acceptance tests. XP emphasizes the need to write your unit test for a class before you write the class. You then write the class to pass the unit test. By doing this, a team builds up a large suite of unit tests very rapidly. This practice will more than pay for itself as the project progresses, by preventing catastrophic mistakes that are costly to debug and fix. This also helps to maintain the focus on how a class will be used, and guides the developer into creating only what is needed.
Consider the importance of feedback. For example, no one would open a word processor, disconnect the monitor, and then type a document. The constant feedback provided by seeing the results of our actions on the monitor helps to reduce mistakes. It doesn't eliminate them entirely, but it does help prevent us from going too far off on some tangent. The feedback provided in XP by constantly running automated unit tests each time a build occurs will also help to reduce mistakes. Running automated tests frequently will also eliminate much of the pain normally experienced during the integration and testing cycles of most projects, because problems will be detected early.
There's another reason for testing frequently. When a developer is working on an area of code, that is what is foremost in her mind. The best time to test code is right after it's been written, while the developer remembers exactly what she was doing. If testing is postponed until a week or two after the code was written, and a developer has moved on to other areas, testing and bug fixes will be more difficult. There is a certain amount of ramp-up time to remember what was done and why. Using iterative cycles of unit testing and acceptance testing reduces this problem.
Courage
If you have never used XP before, using this methodology for the first time might seem a bit daunting. It does require courage to get started. Courage in XP means that the customer is not afraid to tear up a user story card if it doesn't fit, and to rewrite it. As a developer, have the courage to refactor code even though it's working, but is unwieldy. Don't hesitate to throw away unneeded code or to rewrite an algorithm because you now see a simpler way to do it.
Courage also means being willing to ask questions when you don't understand something. Talk to the customer when you need more information about a story. Don't fear the pair-programming aspect of XP when writing production code. This is all part of the courage required to implement XP.
Increased Productivity
XP developers are highly productive. First, they are implementing user stories that have the most business value, as determined by the customer. They are doing what is important first. They are not spending time on functionality that is of questionable value. In XP, there is less chance that something just implemented will be useless because it was done months in advance, and the requirements changed after it was implemented. Second, XP developers create high-quality code because they are continuously testing and refining their code. Far less time is spent chasing after bugs whose cause is obscure.
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.
