对“计划”的一点思考

最近半年作了几次计划（开发计划、测试计划、设计计划、迭代计划等），现在却越来越没有头绪，计划这两个字对我也快变成梵文了。查了很多书和资料，感觉大多数说计划的文章都味同嚼蜡，不甚明了。看得最舒心的是joel说软件中的一篇对计划的说明，但是那篇文章太短，没能说太多东西。

下面是我总结的一点心得，抛砖引玉，希望对制定计划有经验的朋友能提供一些提示或参考资料，尤其是敏捷开发中计划制定的资料。



关于计划
稍微总结一下最近半年对计划的一些看法和心得。
本文不是完整的理论体系，只是从一些特定的角度对计划进行一些思考。这些思考都来自真实工作中我所遇到大大小小的问题。

0. 计划的目的？现在反而越来越不明白计划的目的了…………

1. 计划的四个要素，以及衡量计划优劣的标准

计划的四个要素是：时间、成本、质量、范围。
1. 时间：从开始执行计划到最终达成目标所消耗的时间。
2. 成本：人力、物力等方面的投资成本。简单情况下可以只计算对计划的直接投资成本。
3. 质量：执行计划后最终产出物的质量，质量的衡量标准以计划执行结束时客户方对质量的要求为准。
4. 范围：计划执行后最终产出物的范围，从客户的角度来看，范围是一个百分数。例如某软件预期完成10个功能，但最终只完成8个功能，则范围是80%

衡量一个计划的优劣，主要有两种方式：
1. 执行前衡量：三个考查点：
 是否有足够的细节。
 是否足够真实。
 结合本组织的历史数据，根据经验预测计划是否可以顺利执行。

2. 执行后衡量：计划执行结束后，考察以上四个要素。通常，好的计划总是能够平衡以上四个要素，达到最佳的投入产出比。而不良的计划可能会在时间、质量或成本方面出现较大的问题。


2. 计划的制定

制定好地计划，关键如下：
1. 制定有足够细节的计划。
2. 制定足够真实的计划。

2.1 细节
通常，高层只会提出一个目标，而计划必须指出为了达到这个目标，我们需要做哪些工作。因此首先需要进行的是将各种为了达到目标所进行的工作细分，然后将细分的工作串联起来，确保其能最终达到目标。如果有可能，尽可能让下层的执行人员参与工作细分。上层先将工作进行大致的划分，然后将划分后的局部块分配给执行人员，让执行人员亲自进行估计。执行人员细化工作任务，需要细化到最细的级别，然后进行反馈。注意这里只是将工作细分，不要引入时间约束和资源约束。
特别的，如果制定软件开发计划，最好能够有详细的（比如MSF中的）软件功能规格说明书或详细的设计文档，足够详细的功能说明书和设计文档，可以使人们更好地估计工作量，进而产生足够详细的开发计划。如果对“要做什么”都没有认识的话，毫无疑问该计划会缺乏细节。
另外，如果一个企业如果有自己的SOP，则该SOP也是制定计划时的重要参考资料，应以SOP为基础，结合具体情况规划具体的工作步骤。

2.2 真实
细分工作时，需要考虑到真实的工作方式。真实即“按照计划的要求办事”（听起来好像很简单，呵呵）。对“真实”的阐述详见下文的案例分析。

例如制定一个子系统界面部分的开发计划，参考下面例子：
计划一：画第一个界面、画第二个界面……测试
计划二：画所有的Table，画所有的Form，画布局，添加远程事件，联调测试……

很明显，计划一缺乏细节，与真实的工作方式关联很弱，这样的计划，只能称作里程碑。采用这种计划，我们只有在到达里程碑指定的时间时，才能发现我们的进度已经提前或落后。
而计划二的细节非常充分，在任何一点，我们都可以得知计划的执行情况。而且更严重的是，如果开发界面的真实过程确实如计划二所指，在最初就要由一个人画出所有的Table、Form和布局，那么计划一指出的开发方式就会严重阻碍工作的进行，因为计划一的开发方式与真实的工作方式有很大的冲突。

上文反复强调真实这两个字，因为我发现，如果以计划是否真的遵循现实中的工作方式为衡量标准，那么绝大多数计划都是不真实的。不真实的计划也可以达到目标，但是需要付出更多的成本或更长的时间，而且具有错误的指导意义。
有一件值得特别注意的事情是，当人们明白什么是真实的计划时，他们会拒绝写这种计划，即使它真的很有用。通常这是因为这样的计划会暴露他们的弱点，并且让他人了解他们工作的方式。在某些组织中，将自己的弱点和工作方式暴露在阳光下是致命的。但是，起码你可以制定自己的真实计划，并且只给自己看。

3. 计划的变更
在执行计划的过程中，不可避免的会有计划的变更。计划的变更非常重要，主要体现在以下几点：
1. 计划几乎肯定是不能符合实际的，对此要有坦然的心态。不断接受别人的意见，不断修正计划。
2. 客户方的需求可能会发生变化，此时就需要立即修正计划，以免到最后时刻才发现无法按计划实现客户已经变更的需求。
3. 己方的人员、设备等资源发生变化后，也需要立即调整计划。

楼主写的很好啊，感觉没啥可说的了。

敏捷开发计划嘛，远期计划战略一些，近期计划详细一些，例如每个迭代才定下个迭代的详细计划，但每个release初期大体有个发布目标。

测试计划的话，如果是功能测试，计划主要步骤，如测试脚本，如果是性能测试，这个要问gigix

设计计划，也要问gigix，我不知他怎设计的

瞧你这抓不住重点的。计划分两种，写给人看的，以及给自己做的。楼主这个讲的是第一类。

搂主好累，这样还来总结......

给你推荐：http://www.xp.be/xpgame.html
玩一玩，体验下XP的planning

我能上去。

俺说说给自己用的计划 应遵循的原则

1 要帮助自己尽快的完成工作 而不是妨碍工作 增加工作量.

2 尽可能让我们有成就感 不要总是打击....

所谓计划就是思考 想得到什么 如何做得到它.

如果定完计划后感觉工作比设想的少 说明计划定的有水平.

如果定完计划后异常郁闷 并不说明事情有多糟糕 工程有多艰巨. 而是你的计划有问题 你还没有思考出解决问题的办法. 做不了的事情还是少做的好 否则要承担责任付出代价.

我也浅浅尝试过敏捷的开发，当然是几个人小范围内的。CMM在我们公司才是又红又专的革命路线

我说说我做的xp计划：远期计划看的是公司的大计划，实际上就和没有差不多。近期计划会订得清晰一些，但都是里程碑式的计划。基本上都是这个样子：

========================================
本次迭代需要完成以下功能点：（12345点列一堆）

日期是
x年月日：完成a功能点（或其他形式划分的工作量单位），小集成测试
y年月日：完成b功能点，小集成测试
…………

资源是…………

========================================


我现在写计划书的水平就停留在这种层次上了，我所能做到的就像我上文中写的，尽可能多的添加细节，并且保证计划的真实性。感觉自己还处在最原始的刀耕火种阶段：对计划的分类没有概念，对各类计划的要点把握也不太好。实际上这两天我又有了新的想法，是不是任何计划都是里程碑式的，所谓详细描述执行细节的计划根本就不存在？因为不论是用什么方式（功能点，或者其他）划分工作量，也只能在在这个工作量单位结束后才可以和计划进行对照。

冰云兄或gigix兄能贴一下你们公司的计划吗？让我也学习学习吧，我一直挺感兴趣thought work这样盛行敏捷文化的公司计划是如何制定的
尤其是设计计划，这种高度不可重复的行为如何做计划？

最后再稍微总结下：
1.任何计划本质上都是里程碑式的
2.关键是选择正确（真实+ 细节）的里程碑
3.针对执行者制定可行的计划最重要，执行者不同，即使任务相同，计划应该也不同。
4.如何根据执行者的水平制定计划？....... 这个应该才是重点......

winterwolf兄咱俩可以好好讨论一下给自己做的计划  ，我想法和你差不多，计划就是思考想要什么，然后才是如何做到。
对于思考想要什么，我有点小小心得：

1.结合现实情况，这个最重要，不仅是自己的情况，周围人事的情况更重要，你接触到的人和事可以在很大程度上决定目标是否可行。

2.先详细列出现实情况，分门别类，最起码可以分：与工作有直接关系的和没有直接关系的。这个差别决定了我可以为目标付出时间的多少以及可以借助的力量和资源的多少。以前我都是自己在笔记本上写outline，最近换了mindmanager，鸟枪换炮了  先利其器还是很重要。把现实情况分析清楚了，才好说自己想要什么。

3.每周都更新上周的想法，主要是结合实际情况更新，哪些情况变化，就更新相关的想法。实际上我是每天都更新，用电脑比用纸笔方便得多，虽然纸笔不会突然崩溃.......

至于如何实现自己的希望，这个我现在还没有太多的心得，只有一条：尽量寻求他人的互助，以双赢的方式。尽量避免单打独斗。

winterwolf兄再说说你的想法吧

换句话说，你做的敏捷开发缺少了 对需求的评估 ，因此仅仅计划是无法做到项目的跟踪的。 

首先要评估每个story的大小，按照经验来评估。然后看执行情况，然后根据实际能够完成的情况调整。调整几次后基本上就能知道大概每个迭代能够完成的功能点数。然后嘛，你计划就会做的比较准确了

"winterwolf兄咱俩可以好好讨论一下给自己做的计划  D ，我想法和你差不多，计划就是思考想要什么，然后才是如何做到。
对于思考想要什么，我有点小小心得：

1.结合现实情况，这个最重要，不仅是自己的情况，周围人事的情况更重要，你接触到的人和事可以在很大程度上决定目标是否可行。

2.先详细列出现实情况，分门别类，最起码可以分：与工作有直接关系的和没有直接关系的。这个差别决定了我可以为目标付出时间的多少以及可以借助的力量和资源的多少。以前我都是自己在笔记本上写outline，最近换了mindmanager，鸟枪换炮了 D  先利其器还是很重要。把现实情况分析清楚了，才好说自己想要什么。

3.每周都更新上周的想法，主要是结合实际情况更新，哪些情况变化，就更新相关的想法。实际上我是每天都更新，用电脑比用纸笔方便得多，虽然纸笔不会突然崩溃.......

至于如何实现自己的希望，这个我现在还没有太多的心得，只有一条：尽量寻求他人的互助，以双赢的方式。尽量避免单打独斗。

winterwolf兄再说说你的想法吧 )"

是啊用软件就这点好 计划改起来方便. 但是感觉改动太多的计划不适合软件开发 倒是比较适合台独 霉菌的沙漠风暴 这类的东西.

考虑想得到什么 主要还是为了简化问题  尽可能绕开繁杂的细节.

至于如何做的问题 需要思考 从自己的经验看 流水账那样的计划不但没有用 反而妨碍我 使自己保守的忙的象个机器人. 其实这样没有创意的工作多半是没有价值的 或者是廉价的.