[项目管理-31]：Scurm迭代周期的项目总结与项目计划

目录

前言：

第1章 上个迭代周期执行结果的报告

1.1 报告的业务部门

1.2 报告的内容

1.3 实际案例

第2章 新的迭代周期的新的项目计划报告

1.1 报告的业务部门

1.2 报告的内容

1.3 报告的案例

---

前言：

Scurm敏捷软件开发中，迭代的周期很短，1周或2周或1个月不等。在每个迭代周期的开始，通常需要进行迭代周期的项目汇报和新迭代周期的计划。本文就是探讨这个问题。

第1章 上个迭代周期执行结果的报告

1.1 报告的业务部门

不同的业务部门，都需要报告自己在上个迭代周期的执行情况。

在IT行业，业务部门通常包括：

（1）开发一部：如平台软件

（2）开发二部：如应用软件

（3）测试一部：如集成测试

（4）测试二部：如系统测试

1.2 报告的内容

（1）计划的项目task的完成情况（下图右边一图）

通过这个信息，可以看出：项目的任务是否an计划按时完成。

特别关注的是哪些无法按时完成的任务。

（2）实际人力资源的时间开销与计划预估的时间的关系（下图左上图）

• 计划预估的时间（还剩下多少工作量）  =》》》项目管理人员的输入
• 实际人力资源的时间开销（实际花销的时间）  =》》》项目任务的执行者的输入

通过这个信息，可以看出：任务计划的时间与实际的时间的偏差。

如果偏差较大，就要评估：计划是否准确，是否需要在下个迭代周期使得计划更加的精确。

（3）团队的人力资源的容量与分配到项目上资源的关系（下图左下图）

• 团队的人力资源的容量：除去休假、吃饭、休息等只有的人力资源的总时间，如一个人120小时/人月，10个人就是1200个小时。 =》》》职能部门的项目人力资源负责人
• 分配到项目上资源：已经把人员分配到项目上的时间  =》》》职能部门的项目执行负责人

通过这个信息，可以看出：人力资源的工作量是否饱满。

如果偏差较大，就需要评估：项目任务的时间计划是否合理，无论是任意过度加班或工作量不足，都是需要在下一个迭代周期进行调整的。

1.3 实际案例

 （1）Backlog Resource Allocation Vs Backlog Effort

• 蓝色的柱状图：项目任务实际执行时所花掉的实际人月数（已经完成的任务）
• 红色的柱状图：项目计划还需要的剩余的人月数（还未完成的任务），随着项目的执行，红色的状图图会被实际开销的人月数所覆盖。
• 黑色的折线：可用的人力资源（可用的人月数）

当折线低于柱状图时：表示人力资源富裕，实际的工作比可用的资源少。

当折线高于柱状图时：表示人力资源不足，实际的工作比可用的资源多少，需要加班解决。

（2）Capacity vs Planned Effort

• 项目任务计划的人月数（人头数）与团队可以提供的实际人月数（Capacity人头数）的比值。
• 项目任务计划的人月数（人头数）：由职能部门项目管理人员提供
• 团队可以提供的实际人月数（Capacity人头数）的比值：由职能部门项目管理人员提供。

第2章 新的迭代周期的新的项目计划报告

1.1 报告的业务部门

不同的业务部门，都需要报告自己在上个迭代周期的执行情况。

在IT行业，业务部门通常包括：

（1）开发一部：平台软件

（2）开发二部：应用软件

（3）测试一部：集成测试

（4）测试二部：系统测试

1.2 报告的内容

（1）人力资源与工作任务的分配计划

• 项目管理任务的类型：设计任务、开发任务、代码评审、故障解决、学习技能、项目协调。
• 需要的人力资源总数
• 分解后的项目工作或任务

（2）需要重点强调的项目任务

• 功能的变化
• 需要的来源
• ..........

（3）风险

• 标识该迭代周期预见到可能影响项目完成情况的风险
• 标识出风险应对的责任人
• 标识出分析应对的计划

1.3 报告的案例