Case Studies

10.1 Introduction

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.

There are several OS tools that are developed using Agile techniques (e.g., JUnit, Eclipse, Funambol, etc.). The case of Eclipse is particular for several aspects such as:

• •

  The development is lead by an organization (IBM at the beginning, the Eclipse Foundation at present)

• •

  There is an active community contributing

• •

  The system includes several sub-projects developed independently

Since the Eclipse IDE includes several sub-projects developed independently, it is not possible to talk about a general Eclipse Development Process applied to the entire system but we need to focus on specific sub-projects. The core part of the Eclipse IDE is the Eclipse Platform that defines the basic infrastructure used by all the other sub-projects. This part of the system has been developed using Agile practices adapted to the specific environment. This is an example of how Agile development can be customized to support the specific needs of a company or a community.

10.2 The Eclipse Software Development Process

Even if we focus only on the Eclipse Platform development team, it is difficult to define an Eclipse Development Process since it is not fixed but it is evolving continuously adding, removing, or modifying the practices used. In this way, the team is able to tune the process and improve its ability to:

• •

  Deliver quality software on time: Quality and schedule are two main problems of software development (Brooks, 1995), in particular if the product is the base for several other projects that rely on it. The development process should help developers in accessing the quality of the software produced to avoid rework and problems that may generate schedule slips.

• •

  Be predictable: Make reliable estimates of the time required to complete a set of tasks it is always difficult and requires a lot of experience and a development methodology that helps in the definition of such estimates (DeMarco, 1982).

The development process is organized in cycles corresponding to releases of the platform. Each cycle includes three main phases (Figure 1): warm up, steady state, and end game.

Figure 1.

The Eclipse development process

In the warm up phase, the team recovers from the stress of the previous release (decompression) (often they schedule it in conjunction with holidays). When the developers are back to work and refreshed they do a retrospective of the previous cycle and define an initial release plan. The plan is not static but dynamic: it may change during the cycle according to the feedback (from the development team and from the community). The plan lists all the potential features to add and the team marks each item as committed, proposed, or deferred. The plan is public and the team likes to receive feedback on that. In particular, related to the proposed features.

In the steady state, the development is organized in milestones that are released at regular intervals (6 weeks). Milestones are organized in the same way as cycles, including a shorter version of the same phases called: plan, develop, and stabilize.

After the release of the last milestone, there is the end game phase. This is a sprint phase in which the goal of the team is to increase the quality level of the code through short fix-and-test cycles. At the beginning of the end game, they test for 2 days and fix for a variable number of days (usually 3-5 days).

The entire cycle for a release lasts about 12 months distributed as follows:

• •

  Warm up: 1 month

• •

  Milestones: 9 months

• •

  End game: 2 months