我说CMMI2.0之:策划PLAN

基本理念

1 凡事预则立,不预则废。无论采用什么方法管理任务、项目,都必须事先做计划。

2 计划包含了管理设计的活动,要定义项目组自己的过程。

3 计划要逐步细化,不可能在项目初期,就事无巨细的都计划到位,要随着时间的推移,项目的进展,外部环境的变化,逐步细化,调整计划。

4 计划要分层次。有阶段(里程碑)计划,有详细的日程表。

5 计划要经过了相关参与人的讨论、评审,达成一致后,做出承诺。

实践列表

PLAN

1.1

Develop a list of tasks.

制定任务列表

PLAN

1.2

Assign people to tasks.

为任务分配人员.

PLAN

2.1

Develop and keep updated the approach for accomplishing the work.

制定并保持更新完成工作的方法

PLAN

2.2

Plan for the knowledge and skills needed to perform the work.

策划完成工作需要的知识和技能

PLAN

2.3

Based on recorded estimates, develop and keep updated the budget and schedule.

基于文档化的估算,制定和保持更新预算和进度

PLAN

2.4

Plan the involvement of identified stakeholders.

策划所识别的干系人的参与

PLAN

2.5

Plan transition to operations and support.

策划向运维和支持的移交

PLAN

2.6

Ensure plans are feasible by reconciling available and estimated resources.

通过协调可用的和估计的资源,确保计划可行

PLAN

2.7

Develop the work plan, ensure consistency among its elements, and keep it updated.

制定工作计划,确保其元素之间的一致性,并保持更新

PLAN

2.8

Review plans and obtain commitments from affected stakeholders.

评审计划并从受影响的干系人处获得承诺

PLAN

3.1

Use the organization’s set of standard processes and tailoring guidelines to develop, keep updated, and follow the project process.

使用组织级的标准过程和裁剪指南,制定、并保持更新并遵从项目过程

PLAN

3.2

Develop a plan and keep it updated, using the project process, the organization’s process assets, and the measurement repository.

采用项目过程、组织过程资产和度量库开发计划并保持更新

PLAN

3.3

Identify and negotiate critical dependencies.

识别并协商关键依赖

PLAN

3.4

Plan for the project environment and keep it updated based on the organization’s standards.

基于组织级的标准,策划并保持更新工作环境

PLAN

4.1

Use statistical and other quantitative techniques to develop and keep the project processes updated to enable achievement of the quality and process performance objectives.

采用统计或其他量化技术,开发并保持更新项目的过程,以满足质量和过程性能目标的达成

通俗解释

PLAN1.1制定任务列表。

任务分解,列出所有该做的事情。

PLAN1.2为任务分配人员。

每个任务责任到人。

PLAN2.1制定并保持更新完成工作的方法。

选择开发方法,包括:

  • 选择生命周期模型,瀑布,迭代,还是增量?
  • 选择技术实现方法,是结构化方法、还是面向对象的方法,或是模型驱动的方法?
  • 是否需要将软件开发外包出去?
  • 是否要采用原型方法?
  • 是采用传统的开发模式,还是敏捷的开发方法?
  • 等等。

这是对项目或任务如何做进行顶层的、宏观的管理设计!

PLAN2.2策划完成工作需要的知识和技能。

这条实践是要求项目组思考:

  • 项目组成员有哪些应知应会?
  • 有哪些应知不知,应会不会的?
  • 如何获得这些不知不会的?培训、从其他项目组或部门抽调人过来、还是外部招聘?
  • 培训计划、人员配备计划、招聘计划

PLAN2.3基于文档化的估算,制定和保持更新预算和进度。

参考EST PA执行了估算,有估算的记录。

基于需求的优先级、任务之间的依赖关系等,对任务排列先后顺序,识别项目的关键路径。

分配资源给每项任务,识别项目的关键链。

关键路径是在资源无限的前提下,在活动图中,识别出来的完成项目的最长路径。

关键链是在分配了资源之后,由于资源有限,不能独占,而形成的完成项目的最长路径。

这2者决定了项目的最快工期。如果要想缩短工期,就必须要缩短关键链。

预算是对成本估算的审批结果,是管理者给出的成本上限,并且分配到时间上,即什么时间,投入哪些资金,投入在什么方面。

进度计划有阶段计划与详细日程之分。在敏捷方法中有发布计划与迭代计划,至少2个层次。

PLAN2.4策划所识别的干系人的参与。

干系人分为几类:

负责人

参与人

受影响的人

影响人

也有的公司采用RASCI的方式识别干系人:

A(A=Accountable):牵头人,领导人,布置批准任务的人。

R(R=Responsible):具体负责人,具体实施者,完成A布置的任务。

S(S=Support): 参与者,支持者,配合R完成任务的人。

C(C=Consulted):负责为各个相关的角色提供咨询服务。

I(I=Informed):被告知者,信息的接受者,与任务的关系最为间接。

在计划中要定义清楚谁参与,什么时间参与,做什么事情。要把任务责任到人。

在敏捷方法中是自己领用任务,而不是管理者分配任务。

PLAN2.5策划向运维和支持的移交。

开发向运维的移交活动如:

准备系统配置手册;

准备紧急情况应对方案;

设计系统备份方法;

确定移交接口人;

密码权限移交;

基础数据移交;

对运维人员进行技术培训;

和运维人员并行支持一段时间;

运维人员确认测试报告、系统安装配置手册、应急方案等;

交接手续确认;

……

这些活动要有计划。

PLAN2.6通过协调可用的和估计的资源,确保计划可行。

资源包括人、软硬件工具、设备、开发环境、资金等。资源总是有限的,比如有些公司测试设备有限,不能给每个项目组、每个人配备足够多的样机,需要互相调配这些设施等。因此需要在估计的资源与可用的资源之间进行平衡,制定资源的使用计划,不要出现资源瓶颈而耽误项目的工期。

平衡的手段有多种:

详细排定资源使用的进度表;

减少对资源的需求;

寻求替代资源;

增加资源的供应;

资源不足时,外包任务或采购外部资源;

……

PLAN2.7制定工作计划,确保其元素之间的一致性,并保持更新。

工作计划包含了总体阶段计划、详细的日程计划、各个专题的计划,这些计划要彼此之间不能矛盾。比如,在开发计划中是1.1号交付第1个版本,而在测试计划中却是1月10号才开始测试,计划之间就存在不一致了。

PLAN2.8评审计划并从受影响的干系人处获得承诺。

任务的责任人等相关的干系人应该参与计划评审,可以评审任务识别的完备性、估算的合理性、进度的可行性、分工的合理性等,在大家达成一致的前提下,相关责任人对计划可行做出承诺。

敏捷方法有迭代策划会议,在迭代策划会议上大家一起做了估算,自己领用了任务,每个人领用的任务不超过自己的能力上限。

PLAN3.1使用组织级的标准过程和裁剪指南,制定、保持更新并遵从项目过程。

2级的组织不要求一定要有组织级统一的过程规范定义,3级的组织要有统一的过程规范定义了。即3级的组织做事的套路要基本一致。

本实践是基于组织级的统一的过程定义和裁剪指南,得到项目组自己的过程定义。这是在PLAN2.1的实践基础之上要求更高了,PLAN2.1是做了顶层的宏观的管理设计,这条实践是进行了下一个层次的,更细致的过程设计。

增加、删除、改变或选择方法、改变顺序、改变权限等,都是裁剪。裁剪的对象可以是过程、活动、度量元、文档、目标等。

PLAN3.2采用项目过程、组织过程资产和度量库开发计划并保持更新。

组织级过程资产包含了模版、方法定义、指南、检查单、典型案例、经验教训、历史项目的资料等。

组织级度量库中包含了组织级的生产率分析数据,工作量分布数据,历史项目的数据,过程性能基线,过程性能模型等,项目在做自己的计划时,可以参考之。

项目过程即在PLAN 3.1中裁剪自组织标准过程定义的项目组的过程。

PLAN3.3识别并协商关键依赖。

何谓关键依赖?

对项目的成败有重要影响的不同人之间的依赖关系。如:

关键路径上不同人承担的任务之间的依赖关系;

本项目组的成员对组织内非项目组的全职人员之间的依赖关系;

对外部采购的产品构件或服务的依赖关系。

关键依赖影响了项目的工期或质量等,典型的问题如:

关键路径上的任务延期了,造成了整个项目延期。

需要其他人配合的工作没有按时完成;

两人的工作存在技术接口,结果一方完成的工作不符合接口标准,导致链接失败;

供应商误解了需求,提供的产品不符合技术规格;

……

PLAN3.4基于组织级的标准,策划并保持更新工作环境。

组织级要定义环境标准,参见PAD3.6,项目组根据组织级的环境标准,定义本项目的环境定义。

项目的环境包括了办公室的大小、硬件设施,开发使用的软硬件工具,网络环境等。

敏捷项目通常都配备项目组成员的作战室,足够大的看板,搭建了持续集成与交付的软硬件平台等。

PLAN4.1采用统计和其他量化技术,开发并保持更新项目的过程,以满足质量和过程性能目标的达成。

PLAN3.1是在PLAN2.1基础上的更高要求,而PLAN4.1则是在3.1基础上的更高要求,2.1、3.1都是经验判断、经验决策,而4.1则要求采用统计和其他量化技术进行管理设计,以确保达成项目的目标。达到4级的策划要求计划的更合理,不做无用功,最大程度的减少浪费,选择了最优的过程、子过程、方法来达成项目的目标。统计技术指采用了回归分析、方差分析、假设检验、蒙特卡洛模拟等与概率分布有关的技术,其他量化技术则是传统的分析技术,如饼图、折线图、20-80分析等。此实践要求一定采用了统计技术进行分析。

比如:

我们对项目的工期进行了蒙特卡洛模拟,判断了达成项目工期目标的概率,如果概率比较低,我们增加了资源,或者裁剪了需求,或者细分了任务,增加了任务的并行性,缩短了关键链,提高了达成工期目标的概率。

再如:

我们根据历史的过程性能基线与模型,对关键工程活动的方法做了组合,从N多组合中选择了最优的一套方法帮我们达成项目的目标。

还可以:

基于历史的过程性能模型y=f(x1,x2,…),选择了最优的x的取值,帮我们达成y的目标。

(0)

相关推荐