目录
前言:
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)风险
- 标识该迭代周期预见到可能影响项目完成情况的风险
- 标识出风险应对的责任人
- 标识出分析应对的计划