活动:
|
目的
|
|
角色:项目经理 | |
频率:该活动由项目经理在要求作出授权的变更时执行 | |
步骤 | |
输入工件: | 生成的工件: |
工具向导: | |
更多信息: |
工作流程明细: |
迭代开始时准备的迭代规划只能在当时已知的内容中选择。这里将在要求的全部能力(功能和非功能的需求)以及以前的迭代中遗留下来的变更请求的基础上进行增加。然后项目经理就可以确定迭代的资源和日程安排。允许缺陷应该纳入迭代规划中 - 可以隐式地记入分配给工件的生产工时中,或者可以显式地记入特定的工作包中。建议采用后面一种方法。而 Rational Unified Process 包含能使这种方法实现的活动。
虽然修补工作的优先级是由变更控制管理员指定的,但项目经理还是可以在决定何时进行修补方面行使一些自由规划的权利 - 但一般情况下,应该尝试在发现缺陷的迭代中更正缺陷,而且对于在迭代开始时规划的资源,这么做也应当是可行的。迭代结束时难免会留下一些(已发现的)未修复的缺陷(因为迭代必须在规定时间内完成),但是如果要认为某个迭代是成功的,那么就不应该有很多很严重的缺陷或者它们因为其它原因而有很高的优先级。
但是基本不能允许意外出现的、非琐细的扩展请求。如果当前迭代中批准了这样有重大改进的变更请求,那么项目经理就几乎必须要重新规划了 - 要么将一些规划好的功能推到下一个迭代,要么找到额外的资源作出变更。通常情况下,这样的改进请求会推到下一个迭代,甚至更后面的迭代中,然后再当作正常的迭代规划周期的一部分。
变更请求被审查,项目经理根据请求的类型、优先级和严重性,决定它应该在哪个迭代中得到解决。如果变更请求将推迟到较后的迭代中,项目经理只需重新规划将来的迭代(在“软件开发规划”中),这样现在就可以了解变更请求带来的影响,而且可以尽可能早地开始获得资源的活动,以避免后面出现让人不愉快的意外。
项目经理决定组织的哪个(哪些)职位应该负责实现变更。
变更请求应该已经包含要求的变更的大纲描述(因为变更请求已经进行了分析并得到了核准)。这一步骤将该描述细化,清晰地陈述需要做什么、需要生产什么。
项目经理与负责变更请求的人员磋商后将变更请求中的工时和其它资源估计细化成确切的规划估计,期望负责的人员能对此承担责任。
如果要在当前迭代中实现变更请求,则项目经理将在与负责人员磋商后设定工作的起始日期和期望的持续时间。
如果必要的话,就修改当前迭代规划,对于将来迭代的任何影响都应该在“软件开发规划”中反映出来。作为重新规划的结果,项目经理可能必须调用“活动:处理异常和问题”,使项目状态符合新规划,特别是如果当前迭代受资源短缺或者规划的功能要推后到后面的迭代中的影响。
工作单规定要做的工作、日程安排、职责等等,这些工作单由项目经理分发。工作单中指出预算工时所根据的工作包(用工作细分结构表示)。
Rational Unified Process
|