Mistake 4: Failing to Integrate Change Requests into Iterations


One potential complication can occur with iterative development. Because you can create early releases and allow stakeholders to see them, you will receive change requests (both requests for changes to requirements and defect reports) much earlier in the lifecycle. You need to review these very carefully. In the earlier phases, such as Elaboration, only change requests that affect architecture or have a major impact on the project's direction should be implemented immediately. Other change requests should be considered lower-priority until the Construction iterations.

In general, requests for changes to requirements should be viewed as an opportunity to refine the product to better meet customer needs. But this must be balanced with the existing requirements, plus constraints on costs and schedule. It is a good idea, when receiving requests for new requirements, to have the customer prioritize them in the context of requirements already received. In other words, are the new requirements more important than the existing requirements? Can some existing requirements be eliminated to accommodate the new requirements in the schedule? Discussing these considerations with the customer helps keep requirements from growing to the point where the cost and schedule grow beyond what the customer is willing to commit to.

Also, the requirements and scope of each iteration are fixed at the beginning of an iteration and remain so for its duration. Change requests received should be evaluated along with the results at the end of the iteration and should be incorporated into planning for subsequent iterations.




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