Experience Report


To put DXP into practice, we set up a distributed team to work on a common project called the Web-Desktop Project. The team consisted of:

  • Prashant, an Indian, working in Delhi, India

  • Michael, a German, working in Munich, Germany

  • Angelo, an Italian, traveling between St. Louis, Missouri, USA; Catania, Italy; and Irvine, California, USA

  • David, an American, working in Pittsburgh, Pennsylvania, USA

In this section, we describe the project and how the team worked together. We then present our experiences in doing DXP.

Project Description

The goal of our project was to develop software called Web-Desktop that would provide the working environment for DXP. The Web-Desktop is a desktop that is accessible via a Web page. All applications launched on this desktop actually run on the machine where the desktop was downloaded. The Web-Desktop provides a set of applications needed for most of the development and management processes. Additional applications are available for on-demand installation.

The Web-Desktop is stateful; the state is maintained in the server that provides the Web-Desktop service and its components. Clients are completely stateless. This makes it possible to have real user mobility. Such software would enable a team member to use any PC connected to the Internet to log on and have the same look and feel and the same working environment. The development team need only provide the URL of the project desktop to the customer to bring the customer "on-site." The solution would give a lot of flexibility to mobile team members working on a project. A mobile team member could go to an Internet cafe and plug in a Web cam and/or microphone and be connected to the rest of the team. There would be no need to download and install software on every machine that the team member uses.

Within the project, we defined roles for each person. David was the customer, and Michael, Angelo, and Prashant were the programmers. Because we had very little time available, only about three weeks, we needed to make sure that we focused on the four XP practices selected in the section DXP (see Table 44.1).

  • Planning game We ran several videoconference sessions with David, our customer, discussing user stories. We used a regular editor and shared it via Microsoft NetMeeting application-sharing software.[2] The story cards were then discussed and estimated among the programmers. Finally, David assigned priorities and selected the cards for the first iteration. Similar work was done for further iterations.

    [2] See http://www.microsoft.com/windows/netmeeting/.

  • Pair programming We assigned story cards to pairs of programmers and began the development process. We used RPP, as described in the section Addressing XP Practices and Values in DXP, thus making extensive use of videoconferencing and application sharing. We used e-mail to schedule appointments for our RPP sessions.

  • Continuous integration We used CVS as our configuration management tool.[3] We integrated our changes directly from our development branch into the main branch, without changing computers because no integration computer was available.

    [3] Concurrent Versions System, GNU Project, Free Software Foundation; see http://www.gnu.org/software/cvs/.

  • On-site customer We used videoconferencing to effectively involve our customer throughout the project lifetime. We used e-mail to communicate the time and channel for upcoming videoconference sessions.

Resources Used

We used tools that were well supported and easy to use and integrate in our working environment. Whenever possible, we picked tools that were either supported on multiple platforms or could interoperate with analogous software on other platforms or followed some standard. As an example, both NetMeeting and CUseeMe support the ITU conferencing standard and thus can interoperate.

Every computer (desktop or notebook) had a microphone, speakers, and a Web cam installed. We used NetMeeting as the videoconferencing and application-sharing software. For connectivity, we used a variety of links, ranging from 33Kbps modems and 64Kbps ISDN to 100Mbps LAN connections.

Hurdles Encountered

During the project, we experienced several hurdles.

  • Our videoconferencing software, NetMeeting, did not allow more than two participants in a session. An additional conference server would have been needed to enable conferences with more than two participants.

  • It was cumbersome to capture story cards in a text file. A better solution might have been to use a custom WikiWikiWeb.[4]

    [4] See Ward Cunningham's Portland Pattern Repository at http://www.c2.com/cgi/wiki?WikiWikiWeb.

  • Sharing applications across operating system platforms was not possible using the NetMeeting application-sharing functionality. Virtual Network Computing might be a solution to this.[5]

    [5] AT&T Laboratories, Cambridge; see http://www.uk.research.att.com/vnc/.

  • We used a simple text editor for brainstorming, making the process quite cumbersome. A tool like MindMapper could have made discussions about new ideas easier.[6]

    [6] Mind-mapping software from the Bosley Group; see http://www.mindmapper.com.

  • Narrow-bandwidth connections (for example, dial-up) hindered the use of video because of jitter introduced in audio, along with reduced responsiveness of application sharing. Our fallback strategy was to use only audio conferencing or to switch to a chat channel.

  • Power outage is, at least in India, still a problem. A notebook computer with its own battery can be a valuable help, at least for short outages.

  • Lack of uniform access to the source code repository is not a major hindrance but results in inconveniences that can have larger effects in the long run. Because Prashant had to work most of the time from behind a firewall, he was not able to connect directly to the team repository. Other team members had to send him snapshots of the code via e-mail. This process was tedious and could introduce faults.

  • Some of the keyboard settings were different among the team members. For example, some characters, such as braces, seemed to work only if the parties involved in the conference used the same keyboard that is, both American or both German.

Lessons Learned

Our project was quite successful in using DXP, and in the process we gained some valuable experience.

  • We found that using a combination of synchronous communication, such as videoconferencing, and asynchronous communication, such as e-mail, was the most effective. Even though we used videoconferencing along with application sharing, it could not completely substitute for the physical closeness and effectiveness offered by XP. A video picture of the partner was sufficient to tell what he was thinking or how he reacted to a comment. However, what was missing was the physical presence of the partner, which usually provides company and can therefore never be completely substituted with any kind of videoconferencing tool.

  • Parallel development raises the issue of source code integrity. Tools such as CVS and Rational ClearCase address the issue.[7] Even though these tools support distributed development, we have found that making mutually exclusive changes helps reduce merge conflicts. Therefore, we used an e-mail token to serialize change access when teams were working on common code sections.

    [7] See http://www.rational.com/products/clearcase/index.jsp.



Extreme Programming Perspectives
Extreme Programming Perspectives
ISBN: 0201770059
EAN: 2147483647
Year: 2005
Pages: 445

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net