Artifacts >
Project Management Artifact Set >
Iteration Plan >
Guidelines
Artifacts >
Project Management Artifact Set >
Iteration Plan >
Guidelines
Guidelines:
|
 Iteration Plan |
A time-sequenced set of activities and tasks, with assigned resources, containing task dependencies, for the iteration; a fine-grained plan. |
In Inception, the top risks are often either business risks or technical risks. The dominant business risk early on is typically ensuring project funding. Thus, a proof of concept prototype is often the result of the inception phase. The proof of concept prototype either demonstrates key functionality or some essential technology.
The first iteration of a new product is usually the hardest. There are many new aspects a first iteration must achieve besides producing software: For example, putting in place the process, team-building, understanding a new domain, becoming familiar with new tools, and so on. Be conservative in your expectations about how much of the architecture you can flesh out, or the degree of usable functionality you can achieve. If you aim too high, you risk delaying the completion of the first iteration, reducing the total number of iterations, and hence decreasing the benefit of an iterative approach. The first iterations should be focused on getting the architecture right. You must therefore involve the software architects in the planning process of early iterations.
In Elaboration, the iterations focus on defining a stable architecture, on designing and implementing the essential behavior of the system and exploring the technical architectural issues through a series of architectural prototypes. "Architecturally significant" scenarios are sub-flows which exercise the architecture of the system in defining ways.
Toward the end of Elaboration, and during Construction and Transition, change requests (also known as Software Change Orders or SCO's) begin to drive the iteration process. SCO's result from:
These SCO's are balanced against the existing project plan, iteration plans, and the existing risk list. SCO's may cause the priority of requirements to be re-evaluated, or may drive the re-prioritization of risk. SCO's must be managed carefully, however, lest project control be lost.
During Construction and Transition, the focus is on fleshing-out the architecture and implementing all remaining requirements.
Unlike the Waterfall model, where the entire system is considered at once, we only consider a portion of the functionality of the system in each iteration. During each iteration, a subset of the total system is analyzed, designed and implemented. The choice of what the subset should be and how deep to delve are critical to reducing risk in subsequent iterations. There are two basic strategies: Wide/Shallow and Narrow/Deep.
In the Wide/Shallow strategy, the entire problem domain is analyzed, but only the surface details are considered. All Use Cases are defined and most are fleshed-out in great detail, to get a clear understanding of the problem at hand. The architecture is defined broadly as well, and the key mechanisms and services offered by architectural components are defined; the interfaces of subsystems are defined, but their internal details are detailed only where significant risk or uncertainty must be managed. Very little is implemented until Construction, where most of the iteration occurs.
The Wide/Shallow strategy is appropriate when:
The strategy has some potential pitfalls, however:
In the Narrow/Deep strategy, a slice of the problem domain is analyzed thoroughly. The Use Cases related to this narrow slice are defined and fleshed-out in great detail, to get a clear understanding of the problem at hand. The architecture required to support the desired behavior is defined, and the system is designed and implemented. Subsequent iterations focus on analyzing, designing and implementing additional vertical slices.
The Narrow/Deep strategy is appropriate when:
The strategy is not without drawbacks:
Generally, early iterations will have more of a Wide/Shallow flavor, while later iterations (where a stable architecture has been developed) tend to follow the Narrow/Deep strategy.
The first iteration is usually the hardest, since it requires the entire development environment and much if the project team to be in place. Tool integration and team-building issues add to the complexity of the first iteration. Focusing on the architectural issues can help to maintain focus and prevents the team from getting bogged down in details too early.
Where exploitation of a new technology is essential to the fundamental viability of the project. Many e-business projects require new technologies to be explored to a much greater depth than might be done traditionally. The proof-of-concept prototype is still considered a "throw-away", and merely explores the viability of the project concept.
This strategy is pursued to gain an understanding of the scope of the system, and to sample the breadth of functionality of the system to ensure that the architecture is capable of delivering the desired capabilities.
This approach can help develop a sound architecture, with selective Narrow/Deep focus to address specific technical risks. In Construction, with a sound architecture established, the focus can return to Narrow/Deep, where functionality is developed and delivered in a series of integrated increments.
Construction iterations are always Narrow/Deep, with teams working in parallel to develop and deliver the required functionality.
New teams are typically overly optimistic at first with what they can accomplish. To counter this, and to avert potential morale problems which occur when actual results fall short of optimistic expectations, be modest in the amount of functionality that can be achieved in the first iteration. Try to build experience while creating a sense of accomplishment and project momentum.
If the development environment and/or methods are new to the team, reduce the functionality of the first iteration to a minimum. Focus on integrating and tuning the environment and becoming proficient with the tools, then ramp-up the functionality content in subsequent iterations.
Rework is good, up to a point. One of the major benefits of an iterative development is precisely to allow mistakes and experimentation, but early enough so that corrective actions can be taken. However technical people in particular tend to 'gold plate' or redo work to perfection between one iteration and the next.
At the end of each iteration, during the iteration assessment, the team should decide what part of the current release will be reworked. Expect rework to be allocated among phases in the following percentages, relative to the total system:
Rework is inevitable. When no one sees the need for rework, you should be suspicious. This may be due to:
Too much rework is alarming. This may be due to 'gold plating' or to an unacceptable level of requirement changes. A business case must be done to evaluate the necessity of some rework.
Note that we do not include work de-scoped from the previous iteration (because of the timeboxed approach to iteration management) in the category of 'rework'. The Project Manager has to include this de-scoped work in the pool of functionality from which to define the next iteration's contents. Obviously, such work will normally have high priority. The Project Manager should also discover and carefully consider the reasons for the failure of the previous iteration to achieve its planned goals. For example, although we do not advise the arbitrary addition of staff in a desperate attempt to meet a schedule, running a project chronically understaffed - while repeatedly making ambitious plans for each iteration - is not sensible either. It usually leads to poor team morale and an angry customer. The right balance has to be found, and estimation models such as COCOMO II (see [BOE00]) can help with this. With each iteration, a project builds a history of achievement - of productivity and quality. A strong indicator for a Project Manager, in planning the next iteration, is what was achieved in the previous one.
When the first-cut iteration plan is complete, the team leads, perhaps in
conjunction with the project manager, can refine it into a working plan at the
activity level. The included Microsoft®
Project Templates (at the activity level) show how this might appear. Note
though that these working plans are derived from the iteration plan, they are
not separately produced, independent artifacts. It is important - if the project
manager is to keep control - that the working plans can be rolled-up to status
the project manager's iteration plan.
|
Rational Unified
Process
|
