Monday, March 23, 2009

Scoping in Agile Software Product Lines



Agiles methods and Software Product Lines (SPL) present similar benefits, both proven increasing customer satisfaction and productivity and decreasing time to market. Comparing the two process we can identify values and principles of agile methods which can be supported by SPL.

In context of SPL scoping the majority difficulty to join SPL and agile methods is related at the agile value “working software over comprehensive documentation”, because in SPL the planning is model-driven and vast documentation is required. However, in general, the other agile values can be used in the SPL scoping phase. The agile value ‘‘individuals and interactions over processes and tools” require experience and knowledge of the technical and business stakeholders and efetive communication between them, according to [Carbon et. al., 2006] this activa communication can bring the following benefits: I. The reuse rate can be increased. FE gets information on newly requested features early in an AE project and can evolve the product line assets proactively. Thus, in upcoming iterations AE can build upon the “right” reusable assets; and II. Redundant implementations of product specifics in several AE projects can be reduced. FE developers participate in planning games of all AE projects and thus can coordinate the work done in parallel in the AE projects. The value “customer collaboration over contract negotiation” is interessant to SPL because can help in the customers needs real identification. The value “responding to change over following a plan” can be achieved by adoption of a planning process with flexible execution.

Beyond of the values, agile methods have some principles which can be integrated at SPL in the phase of scoping. With relation at the principle “welcome changes”, the SPL scope can be opened the changes, in [Muhammad et. al., 2008] SPL planning and core asset development can, and in fact often are, conducted in an iterative manner. The principle “communication face to face” can be achieved with workshops or brainstorms, this meeting can help in the features identification in beginning of the scope definition. The principle ‘‘build project around motivated individuals” is related with the choice of representatives stakeholders to the scoping process with roles well-defined.

However, is difficult to combine SPL practices with agile methods and the researches in the area are recent. Therefore, will be possible define a agile scoping approach well-defined and of the relevancy to the industrial scenario?

2 comments:

Hernan said...

I think that we do not need to try to impose all practices defined by Agile methods, but we can try to analyze each practices and verify how that practices would be applied in SPL scoping. In this way, if we could use some practices from Agile methods would increase the benefits of using SPL.

Eduardo Almeida said...

I agree with Hernan. For me, the first point is to point out all the Agile principles and it should not be related to a specific approach.

Based on this list, I believe that you can analyze each one.

Marcela, what are all the principles considered? And what are the reasons to include or not them?