我说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的目标。