解读极限编程的十二大原则——计划的制定

 

计划的制定：包括客户选择的项目大小、程序功能的优先级、各个版本的合成和发布日期。

曾经听说过一个关于项目经理的笑话：接手一个项目，领导问项目需要多长时间，我们的项目经理拍拍脑袋说出一个时间节点。领导说这个任务很紧张啊，能不能快一点（再加上一些威逼利诱的话^%$#^%^$#^），项目经理继续拍拍脑袋说出一个时间节点……就这样一番讨价还价，终于领导满意了，临走关切的问没问题吧？项目经理拍拍胸脯说请领导放心。项目经理回来找到技术骨干，把项目时间节点一说，拍着骨干的肩膀说，兄弟，靠你了！项目开始后进度一再拖延，迟迟不能完成交付，项目经理着急的拍着大腿，怎么办啊~~~~最后，项目失败了，项目经理拍拍屁股，走人！

       作为项目经理，几乎是很难能够按照自己的意见确定一个项目计划的，为什么？这里面有多种原因，上司总是会用市场需求等等原因来要求项目周期尽可能的短，而项目经理又不能拿出一个很有说服力的数据来证明项目就应该有这么多的时间。于是项目时间节点的确定就完全变成了菜市场上的讨价还价，上司尽可能的压缩，项目经理尽可能的给自己留余地。

       当项目经理的时候，我就碰到过这样的情况，项目刚开始的筹划的时候，领导满口答应派给我的人力资源到了项目开始运作的时候居然都没有到位！怎么办，安排新人吧，领导说人数满足你的要求了，我听得差点吐血。新人需要培训、需要磨合，这些不花时间么？！其实很多人都知道在开发过程中并不是1+1=2这么简单的道理，活干不完了，加班！还干不完，加人！人越堆越多，效率却越来越低，为什么？因为开发需要沟通，沟通的成本随着人员的增加会成数倍的增大：两个点用一条线，三个点要用三条线，四个点需要六条线，五个点需要九条线，六个点需要十五条线……我不敢往下数了，当一个团队到了10个人的规模沟通的工作就很可怕了。

       以前做行业软件的时候，公司会把软件模块按照功能点列出来，然后针对每个功能点在不同的技术实现方式下需要多少人月估算出来（当然这需要历史项目的积累）。然后在跟客户谈合同的时候根据用户选择的功能点制定出人月，进而得出报价。在很多软件公司都是这么做的。而我们公司现在也正在向这个方向努力，将来的软件也会像物料一样进料单，也会有成本，现在的IT部已经开始做探索工作了，他们的软件现在都是按照组件为原则进行划分，建立部件。将来理想模式就是用户如果需要我们的软件，那么只需要在产品结构树上选择部件，就可以组成“料单”，我们的开发人员就可以根据这个“料单”进行组合。同样，我们的项目经理就可以根据这些信息估算出软件报价和项目人月数了。当然，所有这些梦想实现的前提是这些软件部件真正做到了组件化，接口真正做到了可以灵活改变。

       目前的项目大多数是“背靠一堵墙”进行时间计划的，这一点在目前竞争激烈，以占领市场为前提，以生存为目标的大环境下是很难改变的。那么我们作为“底层”人员是不是就放弃了呢？其实，我倒是觉得越是在这种情况下，越能体现敏捷开发、极限编程的优势。不管我们身处项目的哪个岗位、什么角色，我们都可以以自己微薄之力，从自己开始进行改善。

       我们可以抱着积极的心态去参加项目计划的制定，虽然我们不能推倒那堵大墙，但是我们可以让每一次项目计划的同行评审会议变得更加实际、更加有意义。我们用短短的两个小时认真的分析出各个功能点的人月，分析出功能点的优先级别。即便是经过分析，我们需要的时间远远多于公司的要求，也应该有勇气去发出不同的声音。我想，也也正是敏捷开发理念中提到的四个原则之一：勇气。因为我们知道计划永远赶不上变化，所以我们要做的是调整态度，勇敢地去做好准备迎接变化，自然，迎接变化不是光凭勇气，还要有各种具体的、实际的工作，这些工作就包含在我们接下来要解读的其他原则中。