Xp Practices Examination

We first examine on-site customer practices because it provides the major premise for our following discussion. XP recommends that a customer sit with the team full time

Practices Benefit

Planning game Benefit communication between project manager, developer and customers.

Small release _{Benefits rapid feedback between developer and customers.} Metaphor Provides easy understandable communication platform for

developers, project manager and customers.

Simple design Facilitates communication within developers, and between developers and project manager.

Tests _{Provide rapid feedback between customers and developers.} Refactoring Makes it easy to communicate between customers and

developers.

Pair programming _{Provides instant communication between paired developers.} Continuous integration Provides developers with rapid feedback on the quality of the

code.

Collective ownership _{Benefits communication between developers}

On-site customer Benefits communication between project manager, developer and customers.

40-hour weeks _{Not identified}

Open workspace

Benefits communication between developers, and developers and project manager.

27

during the entire life cycle. This practice requires that the customer have a thorough understanding of the desired software. In [36], the authors identified this “bad smell” when practicing XP as well. They noted that the customer must be coached sufficiently to provide honest and substantial feedback from the very beginning of development process. In most cases, one customer cannot fully provide requirements to the development team; there will be multiple customers involved. When the project is globally distributed, it is costly to set up on-site customers. Plus, there are other issues involved, such as international visa, travel time, etc. A timely customer presence, especially when an emergency happens, can hardly be guaranteed. When the project is distributed across multi-sites, customers have to travel between the sites, which decreases productivity and increases costs. As a consequence, a tool that can provide the customer‟s virtual on-site presence is needed to apply this practice to GSD projects. E-mail, Instant Messenger, and conference calls are good options to help facilitate communication among customers and development teams that are globally distributed. For teams more than five time zones away, telecommunication can be held at the beginning and the end of each release and iteration, or as necessary. Even though e-mail is less efficient than face-to-face communication, it can be responded to within 24 hours. Moreover, when there is a language difference, people tend to feel more comfortable communicating in writing than through oral means.

4.3.2 Planning Game

In the planning game, customers decide the scope and timing of the release based on estimates provided by the developers. Developers implement in any one iteration only the functionality demanded by the stories. In XP, there are two kinds of planning games:

Release Planning and Iteration Planning. After customers finish editing the user stories, a meeting is set up to create the release plan which lays out the overall project. The idea of this meeting is for developers to estimate how long in programming days it will take to finish each user story, and for customers to then decide which user stories to complete. The release plan is then used to create iteration plans for each individual iteration. In this way, every team member has clear goal of project progress. GSD throws a wrinkle into this process. First, as we stated before, when there is no on-site customer present it is difficult to organize a release plan meeting. A conference call may be the best option, but still has its limits. Especially at the beginning of project, a meeting is inevitably going to last longer than it is in the latter part of project because of negotiation between development team and customers, such as requirement clarification. Another problem is the more stakeholders involved, the more unorganized the negotiation tends to be. A role such as a project manager for each development team is necessary to ensure the meeting goes smoothly. The project manager collects the estimate from developers. Discussions or meetings can be conducted before release plan meeting if the project manager feels the developers‟ estimates are problematic. After gathering all information, the project manager attends the meeting as the representative of team to negotiate with customer. When necessary, the project manager brings back the customer‟s feedback to discuss with specific developers. This systematic communication enables release plan meeting to be more organized and efficient.

Another communication issue that needs to be considered is the format of the user story. In traditional XP practice, the user story is written on a physical card. Together, developers and customers move the cards around on a large table to create a set of stories

29

to be implemented as the first (or next) release. In the GSD environment where there is no on-site customer, a virtual large table that gives the customer and the development team synchronized access to virtual user story card is needed. A tool support this functionality will benefit both communication and project management.

4.3.3 Small Release

The development team needs to release frequent iterative versions of the system to the customer. This is critical in getting valuable feedback in time to have an impact on the system's development. Declaring the introduction of important features shortens the implementation time. How to control the releases in GSD needs to be further considered. When a release plan includes user stories from multiple development sites, a methodology that makes the plan easily understandable for all development teams and customers helps relieve the misunderstanding problem we stated before.

4.3.4 Simple Design

XP emphasizes keeping things as simple as possible. It frees the developers‟ from the requirement of heavy documentation in an effort to focus more attention on the design itself. Simple design eases communication among developers, and between developers and the project manager. We suggest using a standard design language such as UML diagrams for better communication in GSD projects especially in cross-site communication. As we stated before, developers tend to have miscommunication problems when they come from different cultural backgrounds. The frequency of cross- sites communication drops for the same reason as well. A standard design methodology such as UML remains a design simplicity that all developers understand. “Where to find who” is also a common problem in GSD. A methodology that helps development team

members to easily locate the partner they want to communicate with should also be applied in GSD project.

4.3.5 Testing

The acceptance test for each user story is conducted by the customers and a test score is given after that. This practice provides fast feedback between the development team and the customers. This convenience should not be jeopardized by the communication gap in GSD projects. What is the convenient way to transmit the feedback from customer to development team without introducing too much overhead? How to make sure developer will be notified timely without interference from the time and special distance? A methodology that provides timely notification of test feedback is required here.

4.3.6 Collective Ownership

In XP, the practice of collective ownership means that every programmer improves any code anywhere in the system at any time. It benefits communication between developers because, in this way, everybody can learn from each other. For co-located development teams, it is easier to trace back to the author who made the change when the defect is introduced by such change. Co-owners can initiate the communication easily. There is also no copyright issue involved. For globally distributed development teams, it may cause legal issue if one site modified the source code of other side that belongs to other company. Even there is a mutual agreement on source code ownership. It is hard for developers to accept the fact that a stranger from other company can make changes to software they authored. The traceability of changes across sites decreases significantly as

31

well. Therefore, we suggest collective ownership to be practiced within each development site, but not practiced among development sites.

CHAPTER 5