Overview of Open Source Tools for Agile Development

Tools support is extremely important in Agile development. As described in the previous chapters, the Agile development is based on the identification and the subsequent reduction of activities that do not provide value to the customer and the ability to change the code without including new and undetected bugs in the code.

Design Approaches

In this chapter we compare agile and OS development in terms of the adoption of design practices. We review the practices of AMs to identify the agile approaches to the design and we inspect the code of a set of open source projects to determine whether these approaches are undertaken by OS projects.

Other Agile Methods

In the early ‘90s, the IBM Consulting Group hired Alistair Cockburn to build a methodology for object-oriented development. Cockburn investigated a large number of software projects and asked to each team to identify the main reasons for their own success. Cockburn has defined Crystal (Cockburn, 2004) as a family of AMs, because he believed that different kinds of projects require different development methodologies.

Trust Elements in Open Source

The quality of a software development process is based on a large spectrum of various elements that must be identified and assessed. The majority of elements can be measured quantitatively and possibly using an automatic process. Some elements, however, are rather subjective and depend strongly on different opinions of people using or evaluating the software development process. An automatic measurement approach is difficult to achieve (for example by on-line questionnaires or surveys inserted inside software products or software development tools). The foundation for all assessments is a set of elements that will be at a certain point of development or use measured and evaluated.

Adoption of Open Source Processes in Large Enterprises

This chapter summarizes the results of a questionnaire submitted to 50 companies and focusing on their usage of OSS. The people interviewed are project managers.

Project Management

Surveys covering over 8000 projects indicate that the major sources of software project failure lie less with shortfalls in formal methods skills and more with shortfalls in skills to deal with stakeholder value propositions (Johnson, 1999). Five of the top six reasons of failure do not deal with programming languages, development environment or hardware choices, but are related to communications among developers and customers (Boehm, 2002). Moreover, the updated Standish Group study, conducted in 2000, identified 10 software success factors. The second factor is user involvement and the third is experienced project manager. This means that most projects fail because of people and project management issues rather than technical issues (Thomsett, 1993). Several recent studies (Philips, 1998) indicate that project managers are learning how to become more successful at IT project management. To improve the software success, more highly skilled project managers are using improved management processes.

Improving Agile Methods

Apart from personal experience, anecdotal evidence and demonstrations are still the most prevalent and diffused methods on which software engineers have to base their knowledge and decisions. Although – by searching on line databases such as the ACM1 or IEEE2 libraries – we find numerous papers for example on software quality or cost estimation many of them either do not perform any empirical validation at all (they are mostly experience reports or base ideas more on personal opinion than hard data) or the performed validation has limited scientific value

A Framework for Collecting Experiences

An informed introduction to AMs requires the ability to determine whether and when AMs are better than traditional software development methodologies. The risk is that AMs are considered just like another tool. Altogether to accredit AMs we need to show the qualified evidence of their effectiveness, performance, productivity, in the different contexts where they can be introduced. This analysis is difficult as such effectiveness varies with the development environment, depending on several aspects, such as skills, resources and culture. However, this analysis is a key ingredient for the creation of a comprehensive body of knowledge on AMs.

Case Studies

AMs have been developed considering mainly environments that are limited such as companies. For instance, XP defines practices such as 40-hours per week and pair programming that make sense only inside companies. However, the basic principles and most of the related practices are not bounded to such environments and can be useful to organize Agile teams in different contexts such as in OS communities.

Code Ownership

In many AMs, such as XP, the source code does not belong to the developer that wrote it. The common practice is that all the code belongs to the whole team; therefore every member can modify it. Collective Code Ownership encourages everyone to contribute new ideas to all parts of the project. Any developer can change any line of code to add functionality, fix bugs, or refactor. No one person becomes a bottle neck for changes. This could seem hard to understand at first. It is almost inconceivable that an entire team can be responsible for the architecture of the system (Beck, 1999; Feller & Fitzgerald, 2001).