|
 |
EXtreme Programming (XP) For The Not-so-extreme
By Ari Roy
Expert Author
Article Date: 2007-02-19
When I first heard the phrase "extreme programming" 5 years ago, my first thought was that XP was just another development discipline which will require a software developer like myself who is already pressed for time to put in even more hours and burn the midnight oil.
One month after the start of my first XP project, I realized the word "eXtreme" is not about putting "eXtreme" pressure on the programmer, but about building software in an extremely adaptable environment. After 12 years in the software development and solution delivery space, utilizing the traditional "waterfall," RAD and RUP approaches, I can say that that I have never experienced and utilized a more effective methodology.
Primer on XP
Many people have tried to define and redefine XP in a variety of ways to show how similar the methodology is to other development disciplines, emphasizing factors such as the test driven design factor, continuous refactoring and more. But even in it's simplest form, XP is not just another discipline of software development. XP is specifically designed to simplify and expedite the process of developing a new application and revolves around the idea that the customer wants a high quality working system in shortest possible time. Kent Beck, popularly acknowledged as the father of eXtreme Programming defines it as methodology that is best used with small teams of developers who need to develop software quickly in an environment of rapidly-changing requirements.
XP is more than a paper-based, control-centric methodology. The success of utilizing this development methodology depends on core values such as effective communication, proper feedback, courage to innovate and the drive to keep things simple. These specific core values form the basis for the following 12 principles that drive the XP methodology:
1.The Planning Game:
Functional and non functional features of a software system communicated by the customer using 'user stories,' are combined with cost estimates provided by the programmers to determine the critical success factors for development. Associated release planning and schedules takes stories involving code refactoring into account for overall planning.
2.Small Releases:
The development project is broken down to number of small iterations after prioritizing the 'user stories' which typically last 1 to 4 weeks.
3.Simple Design:
The software should include only the necessary code to achieve the desired results communicated by the customer at each stage. The objective is to build the software with simple upfront design and refractor as necessary for future versions.
4.Metaphor:
The team members in an XP project use common names and descriptions to guide development, facilitating communications based around common terms versus technical jargon.
5.Testing:
As one of the cornerstones of XP. unit and integration testing are done consistently throughout the entire process. Programmers design the tests first and then write the software to fulfill the necessary requirements. The customer also provides acceptance tests at each stage to ensure success.
6.Pair Programming:
All code is written by a pair of programmers working at the same machine. It is usually encouraged to rotate the pair to give everyone better exposure.
7.Refactoring:
XP programmers strive to improve the design of the software at every stage of development life cycle versus waiting until final delivery. Because of the continuous integration, bugs are detected early in the process and 'new stories' can be created, improving and making the code reusable. The programmer with guidance of an 'XP Coach' and 'Technical Expert' can then make a judgement call on whether to make certain components generic or not, depending on the appropriate references.
8.Collective Ownership:
No code is proprietary to any specific developer, meaning that each programmer can change each other's code. In the possibility that the change might be related to infrastructure or integration.the programmer would consult the technical chair of the project to ensure speedy resolution.
9.Continuous Integration:
The XP team integrates and builds the software system multiple times per day to keep all the programmers at the same stage of the development process at once.
10.40-Hour Week:
The XP team does not work more than 40 hours any week, ensuring that the team is well-rested, alert and productive. This also helps in maintaining high morale eliminates the potential for programmer burn out.
11.On-Site Customer:
The XP project is directed by the customer who is available all the time to answer questions, set priorities and determine requirements of the project. In the event that an XP project is globally distributed, the customer can appoint a 'proxy customer' on the development site available for all consultation and direction.
12.Coding Standard:
The programmers all write code in the same way. This allows them to work in pairs and to share ownership of the code.
XP In Action - An example of a successful project using the XP development methodology
An application developed for a high-profile financial services client possessed a tight development and delivery schedule, with delivery of the first application component in less then 5 weeks. To effectively accomplish the goals set, we needed to look into and adapt the 12 principle steps of XP to work in this environment . Unlike other projects using other methodologies, I along with my team member tried to determine how best to accommodate them given the current challenges. While the majority of developers were co-located in New York, somoe of the key members were remotely working from Arizona and California, making it especially difficult as XP is not specifically tailored for global delivery.
To accommodate this, the planning game was done via videoconference sessions with the architect and customers in New York discussing their 'user stories' and explaining key expectations. Microsoft NetMeeting and other web tools with whiteboard integration was used to discuss and explain difficult concepts. Once this was complete, the architect would assign priorities and select the stores for the first iteration. Future iterations would also follow a similar pattern. Pair Programming easily accomplished for co-located developers, with each team assigned a story card before beginning the development process. We used XPlanner (http://xplanner.org/), project planning and tracking tool to support this process. Sub Version (http://subversion.tigris.org/) and open source build tool Ant (http://ant.apache.org/) was used for Source control and continuous Integration respectively.
Key stages of our XP-based project included:
Exploration
Exploration is where discovery of the system vision and mission takes place. The first "journey of discovery" with clients is always challenging as there are terms and business flows that are unfamiliar to team members. In this inception phase, the customer develops primary high-level user stories which developers could use for the basis to estimate time to implement. There's an implicit understanding that any estimates at this stage are rough and will be refined at iteration level as the project progresses. In some cases, developers undertake spike (prototyping and researching technical issues) to get a more accurate estimate. Technology specialists are consulted in validating high-level approaches and also play a key role in the spike and researching feasibility approach.
In our project, the provider,in the exploration phase delineating the messaging architecture took some weeks. Most of the components built in this spike were reused later in the project.
Planning
Planning was one of the more shorter phases in which customers and developers agree on features for the first release. Features (user stories) are delivered in a method that makes business and technical sense. Ultimately, the name is immaterial; the important thing to grasp is that the event is informal, lightweight, and pragmatic. User requirements are written on index cards and are handled and/or discussed during the planning game. In our project, utilizing our global project management tool, we developed SharePoint 'web parts' which allowed the user to write the 'stories' and notify the assigned developers
Iterations to First Release
The release was reduced to a number of iterations with a typical length of 1-5 weeks. The initial iteration focused on the architecture components required to provide a baseline system. Each of the iterations was ensured to deliver some sort of business value that continues to grow over time. Subsequent iteration content was driven by the customer, in which the stories were picked for the developers to complete the build. This approach, allowing customers to change their mind in the middle of development was frustrating to developers. The only consolation was that the iteration was time boxed, meaning the scope never changed but the user stories developed did.. In our XP project, we recommended adding development resources to increase velocity and not to allow "scope creep."
Iterations were also used to measure progress which in turn was used for future planning. During the iteration, the team used continuous integration supported by automated build frameworks like Apache Ant. At the end of the iteration, customers performed the acceptance tests they had written as a form of quality assurance.
Product launch or release
At the end of the release, the product was verified and certified for deployment into the customer's production environment. This phase involved system or application tuning and database performance tuning, depending the target environment. Tuning was executed in the staging environment, which was a mirror of the production system. The overall goal was to stabilize the system.
Risks and Challenges
A lot of the hurdles we encountered during the project found it's root in the limitations of the web tools used, although I believe that these tools have evolved from what they were in the past. Despite this, the tools used would not allow more than two participants in a session which in some cases was frustrating.
For example, the web portal used for capturing and negotiating 'user stories' were not very intuitive. Some of the story cards were a challenge to describe and ultimately interpret to a development environment. In addition, the wiki portal, utilized in this project as a 'go to' place for any problem was lacking the desired sophistication needed. It was also a challenge to replicate some of the environment in remote desktops. This was of course resolved in later steps.
Otherwise, there were challenges in some of the fundamentals of adapting the 12 principals of XP to this project. For example, when it came to the type of pair programming arrangement executed in this project, individual psychology played a critical role. In this case, we paired up a junior and senior program, although in a lot of cases, both within this project and in other projects, I specifically observed that developers felt very uncomfortable with the 'pairs' arrangement, restricting the potential for creative solutions. Some of the best programming innovations have been achieved after absorbing oneself in a problem. This was not easily possible in the realm of pair programming.
Unit testing was also overkill at times. Writing test cases that you anticipate breaking is one of the best ways we found to combat this, however some programmers tended to religiously write unit test cases for each and every method of the class. This effort added little value to the project.
Lessons learned:
Despite the situation, the project was quite successful using XP and provided us with valuable insights on the pitfalls to watch for in future projects. We found that using a combination of synchronous communication, such as videoconferencing and asynchronous communication like SharePoint's alert notification system was very effective. Our conclusion was that sticking to and adapting on the principals of XP does in fact allow for integration of remote and mobile team members into the development process, providing the potential for true globalization through the 12 core principals. In addition, XP allowed for a more effective involvement from the customer, in situations where it seems impossible to have an on-site customer.
Conclusion
Although the practices of XP are not new, the way the conceptual foundation is closely knitted makes it an attractive offering in today's environment where business processes change rapidly. The four basic success factors that I have experienced in all the XP projects involved were specifically collaboration, simplicity, re-factoring and reduced cost for incremental changes. It is critical to understand that even though XP functions around quick delivery and quick and often change control, it does so without sacrificing the architectural flexibility or design values. The biggest lessons I learned with my experience in XP were that you need to know your customer well, anticipate and be prepared for the any potential change because requirements never stay the same even for few days. We better get used to it or even better, take advantage of it lest we fall short of success.
Tag: eXtreme programming
Add to  Del.icio.us |  Digg |  Reddit |  Furl
About the Author:
Ari Roy is a senior project manager with DATA Inc. and has over 12 years of experience in software application development and solution delivery. He has been involved in a number of large scale implementations for financial services companies using Java, J2EE and web services technologies. He can be reached through the DATA Inc. website at www.datainc.biz.
|
|
|
