Now let's examine how to build a fine-grained plan for one iteration, an activity that you will repeat once per iteration. We have seen that the nature and focus of iterations vary over time from phase to phase. Although the criteria that we will take into consideration will vary through the lifecycle, the detailed recipe remains the same. So we take an iteration in the elaboration phase as our main example, and later we describe how iterations differ in other phases. First, consider the iteration, its length, and the resources you have allocated to it to be the bounding box. The idea is to avoid a situation in which you first define ambitious goals and plan to achieve them, only to discover that one iteration is not enough. You must define only enough work to fill the iteration. You are scheduling by time and not by volume. The iteration plan describes at a fine level of granularity what will happen in the iteration. It allocates activities to roles and allocates individuals to roles. (Remember that we use the term role in a special sense; see Chapter 3.) A planning tool, such as Microsoft Project, is useful for handling the details, in particular the dependencies and allocation of tasks to individuals. To build an iteration plan, follow these four steps:
Now let's look at how an iteration varies from phase to phase. Iteration in the Elaboration PhaseThere are three main drivers for defining the objectives of an iteration in the elaboration phase:
The main driver to determine the iteration objectives is risk. You must mitigate or retire your risks as early as you can. This is especially the case in the elaboration phase, when most of your risks should be mitigated, but it can continue to be a key driver in the construction phase as some risks remain high or new risks are discovered . But because the goal of the elaboration phase is to baseline an architecture, other considerations must come into play, such as ensuring that the architecture addresses all aspects of the software to be developed (coverage). This process is important because the architecture will be used for further planning: organization of the teams , estimation of code to be developed, and product structure of the development environment. Although focusing on risks is important, you should keep in mind the primary missions of the system. It is good to solve all the difficult issues, but it must not be done to the detriment of the core functionality: Make sure that the critical functions or services of the system are covered (criticality) even if no perceived risk is associated with them. Let's assume that we have a current, up-to-date list of project risks. For the most damaging risks, identify a scenario in one use case that would force the development team to "confront" the risk. The following are two examples:
For criticality, make sure to include the most fundamental function or services provided. Select some scenarios from the use cases that represent the most common or the most frequent form of the service or feature offered by the system. For example, for a telephone switch, the plain station-to-station call is the obvious "must" for an early iteration. It's far more important to get this right than to perfect the convoluted failure modes in operator configuration of the error-handling subsystem. For coverage, toward the end of the elaboration phase, include scenarios that touch areas you know will require development even if these scenarios are neither critical nor risky. It is often economical to create long end-to-end scenarios that address multiple issues at once. For example, suppose that one single scenario is critical and confronts two technical risks. Try to achieve some balance and avoid scenarios that are too "thick" too earlythat is, scenarios that try to cover too many aspects, variants, and error cases. Also, in the elaboration phase, keep in mind that some of the risks may be of a more human nature, such as managing change, fostering a team culture, training team members , and introducing new tools and techniques. Simply reviewing them during an iteration tends to mitigate these risks, but introducing too many changes at the same time becomes destabilizing. The following are four examples of iteration objectives:
Iteration in the Construction PhaseAs the project moves into the construction phase, risks remain a key driver, especially as new and unsuspected risks are uncovered. But the completeness of use cases also becomes a driver. You can plan the iterations feature by feature, trying to complete some of the more critical ones early so that they can be tested thoroughly in more than one iteration. Toward the end of the construction phase, the main goal will be to ensure coverage of full use cases. The following are examples of iterations in this phase:
Iteration in the Transition PhaseThe main goal is to finish this generation of the product. Objectives for an iteration are stated in terms of which bugs are fixed and which improvements in performance or usability are included. If you had to drop (or disable) features to get to the end of the construction phase (the IOC milestone or first beta) on time, you can now complete them or turn them on if they won't jeopardize what has been achieved so far. The following are five examples of iteration goals in this phase:
Detail the Work in the IterationNow that we have objectively defined the pending iteration's goal, we can proceed to the detailed planning stage, as for any other project. After the scenarios or full-blown use cases to be developed (plus defects to be fixed) have been selected and briefly sketched, you must determine the artifacts that will be affected:
The next step is to identify in the Rational Unified Process the activities that are involved and to place them in your project plan. Some activities are done once per iteration (building an iteration plan), whereas others must be done once per class, per use case, or per subsystem (designing a class). Connect the activities with their obvious dependencies and allocate an estimated effort. Most of the activities described in the process are small enough to be accomplished by one person or a small group of people in a matter of a few hours or a few days. You will probably discover that there isn't enough time in the iteration to accomplish all this work. Rather than extend the iteration (and thereby extend the final delivery time or reduce the number of iterations), reduce the ambitiousness of the iteration. Depending on which phase you are in, make the scenarios simpler or eliminate or disable features. |