The Strategic Reuse Discipline: Scaling Agile Software Development
|
|
The Strategic Reuse Discipline: Scaling Agile Software Development |
|
 |
Reusability is one of the "holy grails" of the information technology (IT) industry, one that is seldom achieved. Many organizations fail at reuse because they don't understand its scope; reuse between projects is where you get your payback, not reuse within a single project. Many organizations prematurely give up on reuse when they don't see positive returns on their first few projects or even on their very first one. Strategic reuse is a long-term endeavor that has strategic returns instead of tactical ones. This is why it is critical to look beyond the needs of a single project to the needs of your entire organization: hence Strategic Reuse is an Enterprise Unified ProcessTM (EUP) discipline, the goal of which is to define how organizations can succeed at reuse, ideally in a manner that is as streamlined and agile as possible. It is possible to succeed at reuse if you've adopted an iterative/agile process such as the Rational Unified Process (RUP), Extreme Programming (XP), or Scrum, you just need to look at the entire enterprise picture. |
|
|
Let's start with some definitions. An asset is a project artifact that is retained at the end of a project. A robust asset is well documented, generalized beyond the needs of a single project, thoroughly tested, and ideally has several examples to show how to work with it. Robust assets are much more likely to be reused than items without these characteristics. A reusable asset is a robust asset that has been used on three separate projects by three separate project teams (at a minimum). You can claim that something is reusable, but it isn't truly reusable until it's actually been reused; reusability is in the eye of the reuser, not in the eye of the creator. Reuse is often described as not "reinventing the wheel," and the first step for succeeding at reuse is to understand that you have more than one option at your disposal. You can reuse source code, components, development artifacts, patterns, and templates. |
 |
A key component to reuse is open communication within your organization: this is usually the major point of failure in implementing any reuse program in our experience. It's plausible that the greater levels of communication and collaboration on agile teams, and their greater focus on quality, seems to increase the odds that agile teams will increase their chances of success.
Reuse isn't free; it isn't something that happens simply because you're using certain tools or working with certain technologies. Instead, reuse is something that you have to work at very hard, as you can see in the high-level workflow for the Strategic Reuse discipline in Figure 1. The detailed amalgamated workflow is depicted in Figure 2. An important message of this discipline is that in order for it to succeed your organization must be as agile as possible: it is possible for enterprise-level professionals to work in an agile manner, but they must choose to do so and be allowed to do so.
Figure 1. The workflow of the Strategic Reuse Discipline.
Figure 2. The amalgamated workflow of the Strategic Reuse discipline.
You must actively plan and budget for reuse: you need to allocate the time and resources necessary to make reuse a success. You must invest the time to generalize or harvest your work, otherwise project pressures will motivate you to put that work aside. The bottom line is that you need to plan for and then operate a reuse program within your organization. This is often difficult for some organizations to do. There is an upfront cost to reuse that may impact early projects. You must be willing to tolerate short-term pain for long-term gain.
Your reuse program must reflect both the goals of your organization, which are reflected in your enterprise architecture and your portfolio specification, and your willingness to fund and follow a reuse program. I can't overstate how difficult it is to succeed at strategic reuse. Most organizations fail because they make their programs too complicated, because they assign the wrong people to the reuse team, or because they starve the team of resources. Important issues that your plan should encompass:
Generalizing an asset requires great skill: the reuse engineer needs to be familiar with not only the technology or technique behind the asset but also with how it will potentially be used in practice. Part of generalization ensuring that it conforms to appropriate guidance (see Supporting Project Teams), and making it easy to understand by its intended audience. You also want to validate the asset. You'll need to unit test code-based assets and review templates and non-code artifacts with their target audiences. Concise overview documentation is important, but far more important are one or two good examples showing how to use the robust artifact properly. In the case of code, your unit tests may be sufficient. For templates, you should capture an actual example of the document for which it is a template (for example, to support a use case template, you should harvest one or two well-written use cases from a project team). Figure 3 depicts the workflow details diagram for harvesting existing assets.
Figure 3. Harvesting existing assets.
There are four basic harvesting strategies that you can follow:
A significant number of assets developed outside of your organization may be available to you. Years ago, our advice would have been to "buy before you build," but with the rise of open source software (OSS) and other forms of free software, our advice is now "download and evaluate before you buy, and buy before you build." There are three basic sources of external assets that you should consider: OSS, Other freeware, and commercial off the shelf (COTS) products. Much of the effort is similar to harvesting an existing asset because you're likely to find that you need to tailor the external asset to meet your exact needs.
You need a "shopping list" of requirements against which to assess candidate assets. For example, if you're searching for a persistence framework, you'll discover that you have many options to choose from, some of which will meet your needs and some of which won't. Without these requirements, you run the risk of being unable to determine which candidate assets meet your needs; we've seen searches that should have taken hours or days last for months because the people evaluating the candidates kept getting distracted by "really cool" features that they didn't even need.
It is good advice to rarely, if ever, to start building an asset specifically to be reusable because you run the risk of building something that you don't need. How many projects have you seen where the team spent the first six months building the infrastructure that they "required" for the rest of the project, only to see the project get cancelled before delivery? How many times have you seen a potentially reusable asset be built but never actually be used in practice? How many times have you seen an asset be built and then reused, only to discover that the reuse consumers only needed a small portion of that asset? The bottom line is that when you build something to be reused before you have clear evidence of actual need, you run the risk of wasting resources by overbuilding: in the vast majority of cases, you are better advised to build something for specific use and then generalize it for reuse when you actually need it.
When it comes to building something to be reusable, four basic options are available to you:
An often-overlooked issue in reuse programs is how you'll evolve your robust assets over time. When an asset is available for reuse, you will discover that you need to evolve it to meet new requirements, to fix bugs, or simply to port it to new platform versions. You need to consider three fundamental issues:
After you have obtained a robust asset, you need to make it available to reuse consumers. If your robust assets are hard to find, then they likely won't be reused. Your Reuse Registrar is responsible for maintaining and supporting your reuse repository and registers the robust asset into your repository. The role of the Reuse Registrar is typically filled by a senior staff member such as the reuse manager, reuse engineer, enterprise architect, or project architect. Your reuse repository could take several forms, such as a shared directory, a version control tool, or a full-fledged reuse repository tool. Your registration procedure will vary depending on the tool; our advice is to keep it as simple as possible.
After the robust asset is registered, the next step is to communicate, and even actively market, its availability: it isn't enough to simply be able to search for assets. This can be done via mailing lists or web pages, although our experience is that word of mouth from successful project teams using the asset is often the key to your success. Just as some things get done through "official channels" and some get done through your informal network of contacts, sometimes you find reusable assets by looking in the repository and sometimes you get them from your friends. Your reuse engineers should become the people that everyone trusts.
One of the activities of a reuse registrar is to retire older versions of assets. As newer versions of assets are published into your reuse repository, you must decide whether older versions should be removed because you can't support everything. The retirement of a reusable asset can be as simple as assigning it a "deprecation date", after which your team will no longer support it, the implication being that anyone who continues working with the older version is on their own because the reuse team can only do so much. The retirement of an asset can also be as complicated as the retirement of a full-fledged system: this is particularly true of large-scale assets such as frameworks or common application architectures.
The primary goal of your reuse team is to support and enhance reuse within your organization. To do this, you want to make it as easy as possible to reuse the robust assets within your reuse repository. A critical success factor is to be flexible; remember that each reuse consumer has his or her own unique needs -- a Java developer will be interested in Java code and frameworks, a business analyst in documentation templates and existing domain models, an architect in candidate architectures, and a project manager in project plan templates.
An important part of a reuse engineer's job is to work with project teams to modify an asset so that it can be reused effectively by them. Ideally this modification is nothing more than configuring the asset properly. However, sometimes the asset needs to be evolved to meet the needs of the team, which is the goal of the Evolve Asset activity.
There are several strategies for effectively supporting reuse within your organization:
When you put your reuse program in place, you define your goals for it, such as improving quality, reducing cost, and/or reducing time to market. It's very easy to set these grandiose goals, but it's not so easy to prove that you've achieved them in practice; any good senior management team will certainly want evidence that their investment in your reuse program is effective. Your team will also want to collect metrics to determine how effective their efforts are so that they can redirect their energies accordingly. I suggest that you consider collecting the following metrics:
 |
The Enterprise Unified Process: Extending the Rational Unified Process by Scott W. Ambler, John Nalbone, and Michael Vizdos. Whereas the RUP defines a software development lifecycle, the EUP extends it to cover the entire information technology (IT) lifecycle. The extensions include two new phases, Production and Retirement, and several new disciplines: Operations and Support and the seven enterprise disciplines (Enterprise Business Modeling, Portfolio Management, Enterprise Architecture, Strategic Reuse, People Management, Enterprise Administration, and Software Process Improvement). |
|
|
Copyright
© 2004-2010
Scott W. Ambler |
 |
