Because the iterative process is highly dynamic and adaptive and is meant to accommodate changes to goals and tactics, there is no purpose in spending an inordinate amount of time producing detailed plans that extend beyond the current project horizon. Such plans are difficult to maintain, rapidly become obsolete, and are typically ignored by the performing organization after a few weeks. These plans try to be very predictive and may use "inch pebbles" rather than milestones. Moreover, software development is a creative activity, not just a production activity or an administrative process with a more or less fixed workflow. So it is hard to commit to a plan before you actually know what it is that you are planning. In an iterative process, two kinds of plans are recommended:
The Project PlanTop management and external stakeholders are rarely interested in the details of who is doing what and when. They are interested in the final product. Therefore, they are primarily concerned with the release date, any milestones along the way, when major decisions must be made, and where they can get visibility over the progress, scope, difficulties, and resources of the project. The project plan is a coarse-grained plan, and there is only one per development project. It acts as the overall "envelope" of the project for one cycle (and maybe the following cycles, if appropriate). The project plan includes the following:
The project plan (usually one to two pages) is produced very early in the Inception phase and updated as often as necessary. The plan refers to the Vision Document to define the scope and assumptions of the project. This project plan is a section of the more encompassing Software Development Plan (see Section 4.2 in the RUP template). The Iteration PlanAn iteration plan is a fine-grained, time-boxed plan; there is one plan per iteration. As the iteration plan focuses on only one iteration, it has a time span small enough that it provides team members with the insight to do the kind of detailed planning that they are familiar with: a plan that includes the right level of granularity on tasks and successful allocation to various team members . A project usually has two iteration plans "active" at any time:
While the team is executing the current iteration plan, the project manager is writing the plan for the next iteration. The project manager needs to be far-sighted and able to quickly modify this second plan late in the current cycle so that the team can have a viable plan for the subsequent iteration, even if there are some changes brought about by late-breaking news. If some new discovery arrives late, the project manager needs to react in such a way that the team is not left at the starting gate because there is a "planning gap." The iteration plan is built using traditional planning techniques and tools (Gantt charts and so on) to define the tasks and help allocate them to individuals and teams . The plan contains some important dates, such as major builds, arrival of components from other organizations, and major reviews. It defines objective success criteria for the iteration. It is made up of RUP activities, or sometimes aggregates of activities such as the workflow details. Since the activities are uniquely associated to a role ”and the individuals in the team may be competent to play specific roles ”the plan will tie to the resources. Simple projects may just use a list of "things to do." You can picture the iteration plan as a window moving through the project plan (or phase plan), acting as a magnifier (as shown in Figure 12.2). Figure 12.2. Project Plan and Iteration Plan. The project plan is a coarse-grained plan that acts as the overall "envelope" of the project for one cycle. The iteration plan is a fine-grained, time-boxed plan, one for each iteration (from Kruchten 2000a).
The iteration plan is a separate artifact in the RUP and is not maintained beyond the duration of the iteration. |