4.2 DART Project
4.2.3 Best Practices
In this section, on the basis of our empirical studies, we propose the best agile practices can be easily applied in the Web development and in tab. 4.2.3 we show their applicability degree. Web projects are different from software projects and there is a need to adapt XP practices to suit the needs of a multidisciplinary team.
Pair Programming. In pair programming practices two developers work together on the same problem. This practice allows knowledge sharing. In Web de-velopment there are different skills and knowledge and this practices could be useful. For example, if the graphic designers work with a developer, for sure s/he could understand how pages are put together in order to improve its cre-ations. This collaboration provides best results. It is advisable also interfacing customers with testers since the customers generally don’t have experience in testing and it is hard to define acceptance tests. Moreover this practice is useful also for testers: customer feedback improves test development. Finally the pair programming seems supporting only co-located team members. Ac-tually in literature there are some examples in which the pair programming is adopted in distributed environments (see [51] and [27]). These problems can be
4.2 DART Project 101
overcome adopting tools such as sobalipse10 or skype 11. These tools assure a good level of communication in the case of distributed pair programming. We used these tools also in MAD project (see sec. 4.1), and we obtained the same results. Moreover they are completely integrated in distributed environments such as Eclipse. 12 Finally as shown in section 4.2.2, when the development phase (phase 3) is characterized by strong pressure for releasing new features and by a minimal adoption of pair programming, we observed a growth both in the coupling metrics and in the local metrics, indicating that in this phase the quality has been sacrificed.
Sit Together. In “sit together team”, all team members would work together in open spaces in order to maximize the communication. This practice is easily manageable with the co-located team. A wiki or mailing list can be used in distributed team. Also customer always present is an effective practice because having someone to approve a design, explaining a business process, or suggesting a way around problems drives the project faster.
Short Iterations. Our advice is to keep iterations small. In [58] it is recommended that Web project follow a two-week iteration schedule. This is a good practice because it allows you to work on a number of stories across the Web suite without having to include one that depends on another. Generally the graphic design process calls for a number of stories that take two weeks. Two weeks
10http://sourceforge.net/projects/sobalipse/
11http://www.skype.com
12Eclipse (http://www.eclipse.org) is an open source community whose projects are focused on building an open development platform comprised of extensible frameworks, tools and runtimes for building, deploying and managing software across the entire lifecycle. Eclipse is well known for its Java IDE. However, there are Eclipse base language IDEs from most of the popular lan-guages. There are a number of Eclipse project that provide framework that can be used functional building blocks to accelerate the software development process. Eclipse projects provide tools and frameworks that span the entire software development lifecycle, including modeling, development, deployment tools, reporting, data manipulation, testing and profiling. The tools and frameworks are primarily focused on building JEE, web services and web applications. Unlike developer tools, application framework are deployed with the actual applications. these framework can be used either as standalone addition to Java applications, or can be leveraged as components on top of the Eclipse RCP. This enables applications to use an integrated stack of open source framework on RCP for quickly building and deploying their application. This provides a powerful combination for building software.
4.2 DART Project 102
is along enough iteration to make good progress without adding unnecessary risk.
User stories. In the XP approach user stories are written from the customer. In Web development the customer is not expert in Web projects. A priority is to write simple stories (to use a natural language, that is the customer language).
In this environment using tools supporting practices during the process is an important requirement. We propose XPSwiki [45], a tool supporting the process in the phase of requirement gathering or planning game
Design. In Web applications the code can be optimized through:
• writing code as more simple as possible;
• using CRC cards (Class Responsibilities and Collaboration) to define the classes to implement;
• naming conventions: at the beginning of each project, the team should discuss and agree to a directory structure and file naming conventions in order to save time;
• using prototypes in order to reduce risks: every Web project is different from the one before. There is always a feature that you haven’t done, new navigations, and so on. These risks can be reduced with the prototypes;
• refactoring. Over time Web site components become obsolete and the design needs to be updated. At the end of each iteration refactoring is useful in order to verify that multiple objects doing the same thing are not present or that the site communicate the original vision. Refactoring the stories is also very important to improve customer relationships.
Testing. Unit testing for Web projects is almost identical to that for software de-velopment because most programs run on the server side. The difference is that in Web projects many programs require input from and output to a re-mote customer, typically the communication between the server object and the