Implementation of agile embedded product line development through Rational Team concert

Overview

In the past 10 years, the software community has adopted a large number of agile practices. These practices reflect the drawbacks of the existing waterfall software development process:

Slow delivery

A waterfall approach can take months or even years to create an executable (and auditable) system, thus reducing the opportunity for stakeholders to provide feedback and limiting business agility.

Early decision making

Given the limited opportunities to provide audits and recommendations, stakeholders must identify features that are critical to the success of the system as soon as possible.

Limited opportunity to adjust

Long-term, fixed plans reduce the ability to adapt to new environments, whether from technology discovery or business change.

In contrast, agile practices consistently integrate small system changes, providing an environment for continuous auditing. They decompose large projects into relatively small user stories and tasks, and then integrate them into a continuous integration and build process. Continuous integration changes can expose errors as early as possible for earlier system validation. It also supports more frequent audits, which helps to achieve early validation.

In a typical scrum process, the stakeholder (product owner) determines the priority of a work list (user story) in the Product Backlog catalog. At the beginning of each iteration, the product owner selects the highest priority work items from the product backlog and discusses their details with the development team. The development team then breaks these stories down into tasks and completes them in the next 2-4-week sprint (iteration). During the sprint phase, the development team meets continuously (the daily Scrum meeting) and continuously integrates the changes. At the end of the sprint, the development team demonstrates new features from the latest system builds to the product owner.

Many early agile success stories have the same characteristics: small teams, same locations, building relatively small IT types of Web or database applications. However, complex system development can (and indeed has) benefited from these agile values, including faster delivery, deferred decision making, continuous integration, early feedback, and adaptive planning.

For example, in this article, a fictitious telecoms company provides a product line for embedded parts. This article describes the agile practices they follow, the challenges they face in their existing development infrastructure, and how they respond to these challenges when they migrate to IBM Rational Team concert Collaborative software.

Project background

A telecommunications provider in the mobile communications industry is responsible for the supply of mobile phone components. Their teams are organized into hardware teams, firmware (software teams), test teams, and an application support team. Application support teams create development tools and test platforms and provide support to customers who are experiencing problems. Customer product Leadership (leads, CPL) manages relationships with customers and delivers enhanced requests and defect reports from customers to the engineering team. CPL is similar to the product owner role in Scrum project management.

Previously, CPL used a spreadsheet to track work. Continuously adjust the priority of development by moving up or down the spreadsheet. The engineering team used a separate system developed internally to track testing and customer discovery flaws. The firmware team has two work backlog lists: spreadsheets and problem tracking bugs. Engineering Managers Write Visual Basic (VB) macros in Microsoft Excel to collect data from outside the problem tracking system, and then collect metrics. They use an existing, branching based tool to handle configuration management (CM).

Figure 1. The organizational structure of the project

Business extension

The economic downturn at the end of last century gave the company an opportunity to expand its customer base. Each customer has a unique requirement, and there may be additional hardware requirements. A single product on the original hardware platform has grown to more than 18 product variants (product variant) across 4 hardware platforms. Figure 2 depicts part of the growth process from single product A to product variants across multiple hardware platforms. Each line represents a variant of the product, and the arrows indicate how the changes flow between product variants.

Figure 2. Product variation streams for software and hardware products

The mobile communications industry is highly dynamic and agile. Manufacturers continually integrate new versions of suppliers ' components based on feedback to reveal problems and show progress as early as possible. As a result, the provider needs to provide a new version frequently, sometimes one months to provide multiple versions that would otherwise respond to feedback. CPL continuously communicates with the manufacturer to determine what changes will be included in future deliveries. Based on these dialogues, CPL is scheduled to work two times a week with the firmware team leader (two sprints per week, from an agile standpoint).

For a variety of reasons, an expanding customer base presents a number of challenges for the firmware team. Each new customer usually has a custom enhancement. Not all changes (enhancements and bug fixes) are available to each customer product variant due to factors such as functional cost, hardware platform, available memory, and so on. To make things worse, customers may choose to get changes in a different order. In the example shown in Figure 3, customer a needs to deliver a change, but he does not need the previous 2 changes. At some point in the future, previous changes may or may not be available to customer A's product variants.

Figure 3. Changes are not provided in order to customer A

See more highlights of this column: http://www.bianceng.cnhttp://www.bianceng.cn/Programming/extra/