Journal of Systems Architecture 52 (2006) 619–626

www.elsevier.com/locate/sysarc

Integrating XP project management indevelopment environments

M. Angioni a, D. Carboni a, S. Pinna b, R. Sanna a, N. Serra b, A. Soro a,*

a CRS4 – Center for Advanced Studies, Research and Development in Sardinia, Parco Scientifico e Tecnologico POLARIS,

09010 Pula (CA), Italyb Dipartimento di Ingegneria Elettrica ed Elettronica, Universita di Cagliari, Piazza D’Armi, 09123 Cagliari, Italy

Available online 9 August 2006

Abstract

Extreme Programming (XP) is an Agile Methodology (AM) which does not require any specific supporting tool forbeing successfully applied. Despite this starting observation, there are many reasons leading a XP team to adopt Webbased tools to support XP practices. For example, such tools could be useful for process and product data collectionand analysis or for supporting distributed development. In this article, we describe XPSuite, a tool composed of two parts:XPSwiki, a tool for managing XP projects and XP4IDE, a plug-in for integrating XPSwiki with an Integrated Develop-ment Environment (IDE). Moreover, we will show how the full Object Oriented implementation provides a powerful sup-port for extracting all data represented in the model that the system implements.� 2006 Elsevier B.V. All rights reserved.

Keywords: Extreme programming; XP tools; Agile methodologies; Process metrics; Distributed development

1. Introduction

Extreme programming is a software developmentmethodology which does not rely on any particulartool, but rather is based on the common under-standing of fundamental values and on a disciplinedapplication of best practices. In particular, projectsdeveloped with XP show that good results can beobtained using sheets of papers to collect user

1383-7621/$ - see front matter � 2006 Elsevier B.V. All rights reserved

doi:10.1016/j.sysarc.2006.06.006

* Corresponding author.E-mail addresses: angioni@crs4.it (M. Angioni), dcarboni@

crs4.it (D. Carboni), pinnasandro@diee.unica.it (S. Pinna),raffa@crs4.it (R. Sanna), nicola.serra@diee.unica.it (N. Serra),asoro@crs4.it (A. Soro).

requirements, wall boards to show diagrams andother project-relevant information, and sharedworkspaces to maximize face-to-face communica-tion. Nevertheless, there are a number of reasonsthat may lead XP teams to adopt software andInternet based tools to facilitate application of XPpractices:

• process data can be automatically collected andanalyzed afterwards. The process can be vali-dated and team activities can be more effectivelymeasured; the adoption level of agile practicescan be quantified;

• managers and customers have the feeling thattools are something more ‘‘concrete’’ than puremethodologies;

.

620 M. Angioni et al. / Journal of Systems Architecture 52 (2006) 619–626

• dispersed teams can work together with appro-priate Internet connections. Team members canhave a common and updated overview of theproject status.

In this article, we will describe XPSuite, a two-parts tool incorporating XPSwiki, a tool for manag-ing XP projects, and XP4IDE, a plug-in forintegrating XPSwiki into IDEs. The system has afull object oriented implementation so it is possibleto extract all data represented in the developedmodel.

In Section 2 we briefly introduce the XP method-ology and process. Section 3 contains a descriptionof possible metrics for a XP process. In Section 4 wepresent XPSuite, the suite of Internet tools we havedeveloped for eliciting requirements, collecting userstories, tracking the process, and collecting data,while in Section 5, we describe the underlying con-ceptual model. Finally, Section 6 describes the func-tionalities of XPSuite while Section 7 brieflydiscusses privacy issues.

2. An agile methodology: XP

Agile Methodologies (AM) are a promising newclass of methodologies for software developmentproposed at the end of the 90’s. They are particu-larly suited when it is difficult to understand the sys-tem functionalities during the early phase of theprocess, due to continuous requirements changing,mutable environmental factors or mutable marketconditions. So, agile methodologies are goal-ori-ented: they allow to adapt the process to all thesechanges, reaching a goal at a time, with frequentrelease cycles. They are in opposition to ‘‘heavy’’methodologies like the well-known Waterfall.

The most famous and common AM is eXtremeProgramming (XP). Simplicity, communication,feedback and courage are the founding values ofXP and all the XP best practices are coherent withthese values (for a complete description of XP see[2]). XP is ‘‘extreme’’ because it carries to an extremedegree some of the best practices already used in tra-ditional software development. For instance, if unittesting produces high quality code, then it must beapplied to its extremes, writing unit tests before thecode itself. Similarly, if refactoring produces a bettercode, then ‘‘refactor mercilessly’’. Also communica-tion is ‘‘extreme’’: to share a common vision of pro-ject’s requirements and project’s status, to avoid anymisunderstanding and to develop exactly what is

required, the customer (or an effective representa-tive) is ‘‘embedded’’ as a member of the team. Inaddition, daily meetings are held to check the pro-gress of the team, to identify and manage problemsand to propose corrective actions.

The first step of a XP project is the planning phasecalled Planning Game, where developers and custom-ers elicit requirements and define the functionalitiesto be developed during the project. Customers anddevelopers identify and isolate specific functional-ities and describe them in pieces of papers called User

Stories, with a business value and a priority. Effortrequired to implement a story is estimated by devel-opers, who divide stories into micro-activities, calledTasks, to be performed in 2–3 ideal working days(‘‘ideal’’ stands for 8 h of effective work). Developerschoose voluntarily which task to develop and takeresponsibility for their task being completed on time.

Each story generally requires an effort of 1–2weeks. A story is considered complete only if all itsAcceptance Tests pass. Acceptance Tests are func-tional tests that guarantee the correctness of the func-tionalities specified with User Stories. The customer isresponsible for specifying and verifying the validity ofthe tests, that should be automated in order to berun often. Stories are grouped into Iterations, eachone with a duration of 2–3 weeks. After a cycle of2–3 iterations, the product is released to the customer.

The customer is aware that the first release willprovide only some functionalities and that manyreleases could be necessary before all functionalitiesare implemented. These periods of time, indicatedby [2], can vary depending on the specific project,but the idea is always the same: release cycles mustbe very frequent.

In XP, one of the team members plays the role ofTracker: tracking is the critical activity of measuringthe team progress. The essence of tracking is theface-to-face contact with the team, to check andtrack what is done, what is in progress, what is instand-by and why. In fact, the tracker asks develop-ers questions like:

• which is the status of your task?• how many (ideal) days have you worked on this?• how many more (ideal) days do you need before

you have done?• which issues are delaying your task?

This information is critical to assess whether ornot the effort estimated during the Planning Game

is realistic.

Fig. 2. Standard deviation estimation error for each iteration.

M. Angioni et al. / Journal of Systems Architecture 52 (2006) 619–626 621

3. Measuring the XP process

Measurement is an inherent and fundamentalactivity of all engineering disciplines. Measurementprovides the mechanism for answering a variety ofquestions associated with the enactment of any soft-ware process. It helps to support project planning,to determine the strengths and weaknesses of thecurrent processes and products, to evaluate thequality of specific processes and products. Measure-ment also helps, during the course of a project, toassess its progress, to take corrective action basedon this assessment, and to evaluate the impact ofsuch action.

What exactly is being measured can changedepending on the point of view. For instance, indus-try managers are mainly interested in maximizingthe value of products minimizing costs and time tomarket, while engineers may be more interested inmeasuring product quality to decide what has tobe changed in the process to improve it. While AgileMethodologies and Extreme Programming are notmetric centric processes, measurement still plays afundamental role as a steering tool for controllingthe development process. One of the principles inthe Agile Manifesto [1] states:

At regular intervals, the team reflects on how to

become more effective, then tunes and adjusts its

behavior accordingly.

Kent Beck, explaining the eXtreme Programmingmethodology [2], points out that the measurementrepresents the basic management tool to get control

Fig. 1. Mean estimation error for each iteration.

on the project evolution. For example, he suggeststhe ratio between estimated and actual developmenttime as a basic measure for playing the planningphase and to set the project velocity. Such metricsonce collected can be presented in the form of tablesand diagrams as a visual representation of projectevolution. For example, Figs. 1 and 2 show meanand standard deviation of the task estimation errorfor each iteration.

Measurement and metrics can also be used toquantify the process agility. For leading this pur-pose, Ron Jeffries argues that a very powerful metricis the Running Tested Features in time (RTF, see[4]).

The suite of tools we have developed has a pri-mary role as it is able to gather process data thatcould prove useful for calculating the desired pro-cess metrics.

4. XPSuite: tools for the XP process

In this section we provide an overview of twoInternet based tools we have developed to supportplanning and tracking in a XP project: XPSwikiand XP4IDE.

4.1. XPSwiki

XPSwiki [5,6,8] (Fig. 3) was developed to meetreal needs for software businesses to collect require-ments and schedules in an electronic format. Man-agers, customers and developers can accessXPSwiki by means of a Web browser. XPSwiki is

Fig. 3. The GUI of XPSwiki.

622 M. Angioni et al. / Journal of Systems Architecture 52 (2006) 619–626

built on top of a Wiki [3] engine written in Smalltalkcalled Swiki [7].

Wiki is a very simple and effective content man-agement system. Users can browse Wiki pagesand, if they have the appropriate privileges, can alsoedit the pages directly from the Web, using a smallset of simple formatting rules.

Swiki also enables to add structure to pages,defining input forms for them. In this way, in aSwiki one can have pages constrained by a givenstructure, that are used to hold structured informa-tion, as well as free-format pages, freely added toexisting pages like Post-it notes.

The direct advantages of a Web based tool forthe management of XP process data can be summedup as follows:

• the Tracker and the developers can enter effortdata directly from the Web, without handlingpaper documents, minimizing risk and errors;

• dispersed teams can co-operate and view theoverall project status;

• everyone can have a common and updated visionof the project tracking;

• User Stories, Tasks assignments and any relevanteffort data are immediately available on the Web,and accessible from programmers pairs work-stations.

Although a Web based tool is effective during thePlanning Game, it does lack one major feature: it isnot integrated into the user’s development environ-ment. So, the synchronization between developersprogresses and tracking data collected in the XPSwikiis not automatic, but left to the common sense andthe firmness of the developers. Team members mustedit and submit information on the XPSwiki, andthis is possible only using the Web browser.

In the next section we will describe XP4IDE,which integrates some of the XPSwiki functional-ities directly into the IDE, providing some addi-tional features:

• effort can be automatically recorded by the IDE;• developers can view the XP process integrated

with their development tools;• the choice of what task to deal with is in real-time

automatically communicated to the project man-agement tool;

• time spent tracking the project sensitivelydecreases;

• developers stop hating the Tracker!

4.2. XP4IDE

XP4IDE is an Internet based tool which connectsto a XPSwiki server and provides a view of the XP

Fig. 4. The GUI of XP4IDE embedded in IntelliJ IDEA.

Fig. 5. Effort data and properties of a Task in the XP4IDE GUI.

M. Angioni et al. / Journal of Systems Architecture 52 (2006) 619–626 623

process data embedded in the GUI of the IDE(Fig. 4).

The role of XP4IDE is twofold: on the one handit enables the developer to view, directly integratedinto the IDE, process data, User Stories, Tasks,Acceptance Tests and Artifacts (classes, documenta-tion files, Make files or Ant files, test cases, etc.), allmanaged and saved on the XPSwiki server. On theother hand, it measures the specific time spent onUser Stories, Tasks and Artifacts and sends thisinformation to the XPSwiki server, automating thetracking activity. The overall system architecture isquite simple: XPSwiki acts as backend in a client-server architecture where the application protocolis built on top of SOAP/TCP/IP. The integrationbetween XPSwiki and XP4IDE provides the follow-ing advantages:

• each actor in the XP process accesses to processdata with the right user interface for the rightphase. Developers can use the IDE during devel-opment, while customers and managers can useXPSwiki by means of a simple Web browser.Both of them can use the Web interface duringthe Planning Game;

• it is possible to associate the Artifacts to theTasks in which they are created and developed.

This way, the tool collects data about the timespent on every Artifact, every Task and everyUser Story;

Fig. 6. UML model of the XP process as supported by XPSwiki.

Fig. 7. Extension of the XPSwiki model in order to support datacollected by XP4IDE.

624 M. Angioni et al. / Journal of Systems Architecture 52 (2006) 619–626

• measuring effectively the effort spent and present-ing this information to developers (Fig. 5), is oneway of building a knowledge base useful forenhancing their ability to estimate stories infuture planning activities (see Section 3);

• beginners can immediately have a view of the XPprocess. Concepts, roles and process data arepresented in a structured way, minimizing thelearning curve.

5. Process data

This section describes the conceptual modelunderlying the XPSwiki and XP4IDE suite, show-ing the entities and their relations by means ofUML class diagrams. This object oriented structurecan be navigated to extract process data for thecomputation of useful metrics.

As previously mentioned in Section 4, XPSwikiextends a Wiki structure, inheriting in this way allits attractive features like the versioning capability.This feature enables XPSwiki to keep track of allthe versions of each entity (Task, User Story, Itera-

tion, etc).Now we give a description of the UML model of

the XPSwiki shown in Fig. 6. Since this model rep-resents the basis for managing a XP process asdescribed in Section 2, only a brief description ofthe model is shown here.

A XP Project is performed by a Team. A Team

is composed of one or more TeamMembers. TheProject is then divided into Releases and Iterationsof fixed length through the timeboxed approach ofXP. A number of instances of UserStory must beimplemented within an Iteration. Each UserStoryis divided into one or more instances of Task

and has one or more Acceptance Tests. Thesuccessful completion of all its Acceptance

Tests proves the successful implementation of aUserStory.

To fully integrate the model with the develop-ment data collected by XP4IDE, we have extendedthe XPSwiki model to include other entities, suchas Artifacts. As shown in Fig. 7, Tasks and Arti-

facts are associated with a many-to-many relation(an Artifact could be created in a Task and modi-fied in another one). An Artifact may be of differ-ent types such as SourceCode or a genericDocument. A Task has its own TrackTable whichstores information concerning the effort expendedby developers for each specific working Session.

In more detail, each Session contains the followingfields:

• subscriber: the TeamMember who subscribed tothe Session on that Task;

• pairProgrammer: the TeamMember who was pro-gramming with the subscriber in that Session;

• startTime: date and time subscriber started work-ing on that Session;

• subscribedDelta: duration of the Session.

Moreover, each Session has its own Artifacts-

TrackTable which keeps track of the effort spenton each Artifact modified or created during thatSession (ArtifactSession). More in depth, each Arti-

factSession stores the following data:

M. Angioni et al. / Journal of Systems Architecture 52 (2006) 619–626 625

• artifact: Artifact involved in the Session;• startTime: date and time subscriber started work-

ing on that Artifact in that Session;• activationDelta: the period of time the Artifact

window was active during that Session;• codingDelta: the time spent on coding (typing)

that Artifact during that Session.

6. Working with the XPSuite

In this section we describe the functionalities ofthe XPSuite from the developer point of view duringa development session. To better harmonize withXP, the functionalities are described in the form ofUser Stories.

6.1. Story: Login and connection to a project

To start a working session, the developer opensthe IDE, selects the docked GUI called XPView,the view of the XP project, which prompts for loginand password to connect to the XPSwiki server.Then the developer selects the pair programmerwith whom he is going to work with and the projectamong those available on the XPSwiki. Project dataare loaded in the IDE and presented in the XPViewin the form of a tree. The tree is composed ofReleases, Iterations, User Stories, Tasks and Arti-

facts. Tasks already assigned to the developer arehighlighted and sorted by priority. Every tree ele-ment has a property window which presents theattributes for that element (for instance, a storyhas a title, a description, a priority, a risk and anestimated effort).

6.2. Story: Subscribe to a task

Once the developer has logged in, he can select aTask and subscribe to it. The status of the Task

changes from ‘‘inactive’’ to ‘‘in progress’’. Develop-ers subscribed to a Task can create and associatenew Artifacts to that Task or modify existing oneseven if associated with other Tasks.

6.3. Story: Automatic measure of effort spent

During the working session, the XP4IDEmeasures:

• the Artifact activation delta (the period of timethe Artifact window was active);

• the time spent coding an Artifact;• the Task activation delta (computed as the sum

of the activation delta of all Artifacts developedin the Task);

• the time spent on coding within a Task (com-puted as the sum of the time spent on codingall Artifacts developed in the Task);

• the subscribe delta (total amount of time thedeveloper is subscribed to a Task).

This measurement should be sent to the XPSwiki,choosing one or more of the following options:

• periodically;• when the developer unsubscribes to a Task;• when the Task is completed;• when the IDE is closed.

6.4. Story: Open a thread on a story

A developer can post from the IDE user interfacean issue or a question opening a new thread. Theother members of the team can follow up the discus-sion and provide solutions or suggestions.

6.5. Story: Managing a task

A developer should be able to see the status of aTask, to launch its tests, to work on its Artifacts, toclose the Task or to suspend the Task defining a pre-requisite (for instance Task1 depends on Task2).

7. Privacy issues

Concern may arise over privacy issues, since soft-ware tools such as XPSuite could clearly be used tospy the behavior of developers, instead of support-ing them in their daily activities, as they are sup-posed to do. Such objections, perfectly justified,should be seriously taken into account when devel-oping and deploying systems like XPSuite. In fact,Extreme Programming is claimed to be a peoplecentered methodology, hinged on trust and recipro-cal esteem between team members, and making fulluse of human resources, instead of imposing controland authoritarian management.

In our opinion, XPSuite (and other similar tools)should be adopted, upon mutual agreement withteam members, if necessary in a smooth, gradualway. On the other hand, the use of XPSuite has pro-ven valuable in the experimentations conducted sofar, both for the advantages that it offers when

626 M. Angioni et al. / Journal of Systems Architecture 52 (2006) 619–626

co-ordinating dispersed teams and for its ability togather process data contextualized against the spe-cific task and process phase. Being able to measurethe exact time spent on any given artifact or task,and not solely relying on the estimates and reportsprovided by the developers, that may contain errors,is a clear advantage for the whole team.

These data can of course be of interest even toresearchers, because they help to expose mecha-nisms and behaviors underlying the developmentprocess, and are an invaluable tool to assess criticalphases and to prevent errors.

8. Related works

There are a number of nascent or on-going pro-jects similar to XPSuite and it is a matter of fact thatthe integration of IDEs with server side XP manage-ment tools is recognized as a valid option. Amongothers we mention:

• xplanner-idea: a plug-in for IntelliJ IDEA whichconnects it to the XPlanner tool (http://source-forge.net/projects/xplanner), using a SOAP API;

• ecliXPweb: a plug-in for the Eclipse IDE whichallows to connect to a XPWeb database.

In our opinion, it may be of some advantage todefine a common protocol for the communicationbetween IDEs and server side project managementtools, in order to facilitate interoperability betweenclients and third-party servers.

9. Conclusion

In this article, we have outlined the nuts andbolts of XPSuite, a set of tools aimed to provide

support and assist metrics gathering in a XP project.The tools allow multi-channel interaction with pro-cess data, both via Web pages and by means of richuser interfaces, directly embedded in the IDE.Although the tools have been used for internaldevelopment and have proven effective for support-ing activities of dispersed teams, they are in anearly-stage of development and we would like tohave other teams use these tools to obtain valuablefeedback.

Acknowledgements

This work was supported by MAPS (Agile Meth-odologies for Software Production) research pro-ject, contract/grant sponsor: FIRB research fundof MIUR, contract/grant number: RBNE01JRK8.

References

[1] Manifesto for agile software development. Available from:<http://agilemanifesto.org>.

[2] Kent Beck, Extreme Programming Explained: EmbracingChange, Addison-Wesley, 1999.

[3] Ward Cunningham, Bo Leuf, The Wiki Way, Addison-Wesley, 2001.

[4] Ron Jeffries, A metric leading to agility, June 2004. Availablefrom: <http://www.xprogramming.com/xpmag/jatRtsMetric.htm>.

[5] Sandro Pinna et al., Developing a tool supporting XPprocess, in: Extreme Programming and Agile Methods,Lecture Notes in Computer Science, Springer, 2003, pp.151–160.

[6] Sandro Pinna et al., XPSwiki: an agile tool supporting theplanning game, in: Proceedings of the 4th InternationalConference XP2003, Springer, 2003, pp. 104–113.

[7] Swiki: The Wiki engine written in Smalltalk. Available from:<http://minnow.cc.gatech.edu/swiki>.

[8] XPSwiki: an open source web tool for eXtreme Programmingteams. Available from: <http://agile.diee.unica.it/xpswiki>.