任务:安排和分配工作
此任务描述了将经核准的变更请求并入开发进度安排所要完成的所有操作。
用途
接纳在迭代中产生的对产品和流程作出的核准变更(缺陷、增强)。
关系
角色主要: 其他: 辅助:
输入必需: 可选: 外部:
输出
主要描述

迭代开始时准备的迭代规划只能在当时已知的内容中选择。这里将在要求的全部能力(功能和非功能的需求)以及以前的迭代中遗留下来的变更请求的基础上进行增加。然后项目经理就可以确定迭代的资源和日程安排。允许缺陷应该纳入迭代规划中 - 可以隐式地记入分配给工作产品的生产工时中,或者可以显式地记入特定的活动中。建议采用后面一种方法,而 Rational Unified Process 中包含的任务使之成为可能。

虽然修补工作的优先级是由变更控制管理员指定的,但项目经理还是可以在决定何时进行修补方面行使一些自由规划的权利 - 但一般情况下,应该尝试在发现缺陷的迭代中更正缺陷,而且对于在迭代开始时规划的资源,这么做也应当是可行的。迭代结束时难免会留下一些(已发现的)未修复的缺陷(因为迭代必须在规定时间内完成),但是如果要认为某个迭代是成功的,那么就不应该有很多很严重的缺陷或者它们因为其他原因而有很高的优先级。

但是基本不能允许意外出现的、非琐细的扩展请求。如果当前迭代中批准了这样有重大改进的变更请求,那么项目经理就几乎必须要重新规划了 - 要么将一些规划好的功能推到下一个迭代,要么找到额外的资源进行变更。通常情况下,这样的改进请求会推到下一个迭代,甚至更后面的迭代中,然后再当作正常的迭代规划周期的一部分。

步骤
将变更请求分配给迭代

变更请求被审查,项目经理根据请求的类型、优先级和严重性,决定它应该在哪个迭代中得到解决。如果变更请求将推迟到较后的迭代中,项目经理只需重新规划将来的迭代(在“软件开发规划”中),这样现在就可以了解变更请求带来的影响,而且可以尽可能早地开始获得资源的任务,以避免后面出现让人不愉快的意外。

分配职责

项目经理决定组织的哪个(哪些)职位应该负责实现变更。

描述工作和期望的输出

变更请求应该已经包含要求的变更的大纲描述(因为变更请求已经进行了分析并得到了核准)。这一步骤将该描述细化,清晰地陈述需要做什么、需要生产什么。

预算工时和其他资源

项目经理与负责变更请求的人员磋商后将变更请求中的工时和其他资源估计细化成确切的规划估计,期望负责的人员能对此承担责任。

设置日程安排

如果要在当前迭代中实现变更请求,则项目经理将在与负责人员磋商后设定工作的起始日期和期望的工期。

重新规划

如果必要的话,就修改当前迭代规划,对于将来迭代的任何影响都应该在“软件开发规划”中反映出来。作为重新规划的结果,项目经理可能必须调用任务:处理异常和问题,使项目状态符合新规划,特别是如果当前迭代受资源短缺或规划的功能要推后到后面的迭代中的影响。

分发工作单

工作单规定要做的工作、日程安排、职责等等,这些工作单由项目经理分发。 工作单中指出预算工时所根据的活动(用工作分解结构表示)。



属性
多次出现
事件驱动
正在进行
可选
已计划
可重复
更多信息