Furthermore, John compared the pieces of each approach, and depicted some suggestions about how to re-construct a hybrid method, through the deconstruction the product line and agile practices.
Some personal assumptions were highlighted by John:
(i) Agile product line method can improve how we develop software intensive products
(ii) No one wants to do extra work
(iii) Strategic levels of reuse is what provides the productivity and time improvements that make the software product line approach useful
He assumes that agile is an adjective for software product line treating agility as a quality attribute of the process.
It is important to highlight that agile approaches are strongly based on incremental, iterative, adaptive and evolutionary approaches. Several agile methods are defined, documented and publicized (XP, SCRUM, DSDM, FDD). All these methods and approaches have a common base, the agile manifesto.
The agile manifesto has values and principles and John uses the twelve principles to deconstruct the agile approach.
As John, I don't disagree with any of those agile principles, as well as, the agile values. However, he remembers that maybe some relative term drove by the business goals is better. For example, in the face-to-face communication, in a scenario with few financial resources, what is the better? We have a person with experience occasionally or a person without experience every day!? I prefer a person with experience occasionally, and you?
The Software Engineering Institute (SEI) has developed a Framework with 29 practices that affect the success of a software product line organization. John uses this framework to deconstruct the process of a product line. He uses two different decompositions of the practices as the base for the discussion. Both decompositions have activities that are smaller and more tractable with agile practices.
The first decomposition is in the practice areas: Software Engineering, Technical Management and Organizational Management. The second decomposition is in the essential activities: core asset development, product development and management.
In the column, John considers that three dimensions have an affect into agile software product line method: the degree of commonality among the products, the volatility of the relevant domains and the size of products, teams, and of the organization. Considering the coordinate system 3 dimensions, the point position can indicate the agile degree into software product line, as well as, the systematic reuse degree into agile approach. Thus, this point can indicate the method for this context. See the image below, adapted from Barry Boehm.
John, remember that both agile and software product line approaches are collaborative, operate within a scope and maximize the amount of work not done. Moreover, agile accepts the requirement changes while software product line accepts variable requirements by anticipating and planning them by including variation points in the design of each asset. In addition, agile produces pieces of software early during the software development, while product building teams in a product line do so as well, by assembling and configuring core assets.
Thus, John described some method fragments that could be used in some particular situations. He described a proposal by starting with the software product line method (SEI's framework) and adding the quality of agility when it is appropriate and possible. Thus, the two approaches been arose: Micro and Macro approaches.
In the micro approach each of the 29 practice areas are examined in order to apply some agile principle. In Mix and Match it is addressed several specific practices.
In the macro approach it is necessary to identify a place where a narrow interface is possible and allow tasks on one side of the interface to use an agile approach. In the software product line, this interface can be the communication between core asset team and product building team. If the process of feedback among them is agile, then faster the core asset team can comply with new assets. Here, it is important to observe that both teams can apply independent methods. Thus, product building can use agile method to build their products independently from the core asset team, because product building team has a contact direct with the customer, though the context be stable, well-understood domain. On the other hand, core asset team can use agile approach because is an exploratory process that could have benefit from those highly-motivated people.
John summarized that there are evident synergies between the agile and software product line methods. Some research are being conducted in Calgary, Canada and Dallas, EUA where tailored instantiations of these methods preserving the basic characteristics of each method.
I think that others possibilities or adjusts in the John’s ideas can be thought to combined the approaches: bottom-up approach where the software product line is built iteratively from products instances; test–driven development approach that need all feature development be driven by acceptance tests defined by the business stakeholders. This acceptance tests are core assets that drive reuse of artifacts in the product line and the large-scale component-driven development each component with teams (maybe less 10 people) could apply agile approach individually, for component development.
No comments:
Post a Comment