迭代开始时准备的迭代规划只能在当时已知的内容中选择。这里将在要求的全部能力(功能和非功能的需求)以及以前的迭代中遗留下来的变更请求的基础上进行增加。然后项目经理就可以确定迭代的资源和日程安排。允许缺陷应该纳入迭代规划中 -
可以隐式地记入分配给工作产品的生产工时中,或者可以显式地记入特定的活动中。建议采用后面一种方法,而 Rational Unified Process 中包含的任务使之成为可能。
虽然修补工作的优先级是由变更控制管理员指定的,但项目经理还是可以在决定何时进行修补方面行使一些自由规划的权利 -
但一般情况下,应该尝试在发现缺陷的迭代中更正缺陷,而且对于在迭代开始时规划的资源,这么做也应当是可行的。迭代结束时难免会留下一些(已发现的)未修复的缺陷(因为迭代必须在规定时间内完成),但是如果要认为某个迭代是成功的,那么就不应该有很多很严重的缺陷或者它们因为其他原因而有很高的优先级。
但是基本不能允许意外出现的、非琐细的扩展请求。如果当前迭代中批准了这样有重大改进的变更请求,那么项目经理就几乎必须要重新规划了 -
要么将一些规划好的功能推到下一个迭代,要么找到额外的资源进行变更。通常情况下,这样的改进请求会推到下一个迭代,甚至更后面的迭代中,然后再当作正常的迭代规划周期的一部分。
|