我的人月代码产量分析-*o*

编写代码也已经数年了. 说到编写代码的能力, 只怕也不会有一大堆人超越我. 但是, 领导终究是领导, 始终会有没有学过管理或者尝试以流水线理论来主导软件开发的领导. 而且, 在国内, 这样的领导并不少见. 这些领导的共同只处在于: 目标产品是定下期限要完成的, 所有的东西是可以以人手定量的, 而人员配备"按照正常情况足够满足开发进度". 在这一前提下, 形形色色的变种会出现.

有些是不能明确说出功能列表的; 有些则是没有能力知道开发中可能遇到的障碍点在哪里的; 有些则不知道团队人员的真正能力的; ...; 更有些是集以上之大成的. 在有些时候, 我也是其中的一员.

说到这里, 要说一下人月神话. 我们所有的进度都是以 人月 代码产量来衡量的. 而增加"人"并不能缩短"月"的量.

一个目标产品本身能有多大的代码量大致不会和预算的相差很多. 这时我的经验, 当然也有一些连代码量也估算不准的LEADER. 我们通常会最终会将代码量分解到每个模块, 并且根据程序员的工作能力来分配进度要求. 在很多情况下, 遇到进度失衡的时候, 第一反应是增加人手. 但是事实上增加人手的项目不到10%能准时解决. 很多情况下, 增加进去的人手并不能真正进入工作, 因为模块已经无法细分一小块出来给新加入的人手. 又或者新加入人手熟悉现有代码结构的时候已经到达项目终止时间.

而人月代码产量本身就不是一个固定的值. 我的最高写作时刻可以达到1600行/天. 真的就是32000行/月了么? 不! 更多时刻的代码产量在200-300行/天. 也有很多一个算法就花费1天. 变得只有100行/天的情况. 真正比较客观的状况, 根据最近3年的状况, 5000行/3月是比较客观的量. 这是C/C++的速度. 是我的速度, 其他程序员有这样的效率么? 真正能超过的并不多见. 即使是这样的代码效率, 也并不适合将计算进入商业产品的进度考虑.(个人完美产品和商业完美产品将在以后有写作欲的时候写) 因为很多难点并不是因为降低人月代码产量就能够攻克的.

我本人目前比较倾向的时间分配,也是比较真实的时间分配, 没有难点的时间分配

20% 代码编辑

30% DEBUG

30% 文档

20% 保留时间.

这就说明即使在没有已知难点的状况下. 有20%的保留时间仍然有必要. 因为很有可能1个小小的数学逻辑就能让你忙上半天一天. 这并不是不专心, 而是疏忽导致的. 而且从来就没有人能避免疏忽. 而30%文档时间有时并不能完成很漂亮的文档.

了解了这个神话, 我们就可以采取主动行动.

1.首先, 不要低估任何一个产品的难度, 难度估计得高点总是没有错的.(我曾经犯过多次这样的错误) 这样, 在确定任务进度前争取更多的时间.

2.很显然, 既然有可能在任意时刻发生问题, 为什么不提前多干点呢? 很少有人愿意这样. 但是我的经验是一定要提前多干. 在最近的2个项目中, 都是提前很多时候完成了大部分的工作. 90%的东西完成了, 而产品交付时间则剩下1个月. 眼看可以轻松了, 却仍然忙着攻克最后的难点, 到了最后一天才真正完成任务. 险得很. 按照时刻表完成进度的程序员都一定会翻船. 不信! 哼, 随便找一个去看看. 我很自信这点的判断.

<<人月神话>>中有着好的程序员可能效率比糟糕程序员高10倍的可能性.在我的人月神话中确实有着好的程序员比糟糕的程序员速度快上10倍的例证. 当时团队中一天无法完成一个极度简单功能的PROGRAMMER.(不知到此人现在怎么样) 但是在人月理论中, 这样的人也照样要占着进度表的一条...

 http://sdd.ttcone.com/lu0/web/tips/20030305.html（抱歉，未找到出处和作者）