Mistake 2: Iterations with No Clear Goal


I have seen several instances where project managers simply take the total amount of time available for development and schedule the work across the entire period of time. They divide the schedule into equal segments of time and name them Iteration 1, Iteration 2, Iteration 3, and so on. This completely misses the point of iterative development. The content of the iterations should be determined partly by the phase of the RUP lifecycle (Inception, Elaboration, Construction, and Transition) and by the highest risks appropriate for the current lifecycle phase. For example, consider the following:

  • Inception phase: The iterations in the Inception phase should cover the following:

    • Is this project possible? Is it technically feasible? What business need motivates this project's execution?

    • Do we understand conceptually what the stakeholders want? Have we identified all the stakeholders?

    • Identify candidate architectures to accomplish the system's goals.

    • Identify requirements that are of particularly high risk.

  • Elaboration phase: Iterations in the Elaboration phase should focus on the following:

    • Which of the identified architectures is the best choice for the system?

    • Elicit and define the system's requirements.

    • Implement functional requirements that fully exercise the chosen architecture. This requires a small portion (about 20%) of the system's functional requirements to be implemented.

    • Implement any units of code that must be in place before the bulk of development is performed (such as common code and libraries).

    • Implement any other requirements that are particularly high-risk.

    • Demonstrate releases to stakeholders, and elicit and incorporate feedback received into the subsequent iterations.

  • Construction phase: By the time you reach the Construction phase, you should have eliminated or mitigated all the high-risk items on the project risk list. By this point, the developers are mostly "heads down," developing and creating periodic releases at the end of each iteration. Here are some suggestions for determining the content of iterations at this point:

    • First, focus on scheduling requirements for iterations that developers are not completely certain how to implement. In other words, schedule the most-difficult-to-implement requirements in the earlier iterations.

    • Also in the earlier Construction iterations, schedule requirements in which stake-holders seem to have particular interest. These are the features that the stakeholders will want to see first. They are also the most likely features to elicit change requests from stakeholders, because the implementation of these will be scrutinized the most.

    • Continue with demonstrations to stakeholders, and elicit and incorporate feedback.

  • Transition phase: By this point, the product is functional. The focus in the Transition phase should be on any adjustments required for the product to function well in its production environment. The system must be installed in its operational environment so that the users can exercise the system to ensure that it is fit for production. Defect reports may be received at this point. These should be prioritized and corrected in the Transition phase before the project is concluded.




Project Management with the IBM Rational Unified Process(c) Lessons from the Trenches
Project Management with the IBM Rational Unified Process: Lessons From The Trenches
ISBN: 0321336399
EAN: 2147483647
Year: 2007
Pages: 166

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net