文章插图
说到这里, 要说一下人月神话. 我们所有的进度都是以 人月 代码产量来衡量的. 而增加"人"并不能缩短"月"的量. 一个目标产品本身能有多大的代码量大致不会和预算的相差很多. 这时我的经验, 当然也有一些连代码量也估算不准的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://www.boraid.com/darticle3/list.asp?id=12900
【<<人月神话>>中的"人月"是什么意思?】
推荐阅读
- 灵异电话……真的存在？如果存在…跪求号码
- “天使”的英文怎么写？
- 有关于穿越的电视剧或电影
- 关于“耿直”
- 赚钱 请问在那里有可以在网上“打工”的工作？？细说下，谢谢！！
- 张敬轩—只是太爱你 这首歌歌词的意思是什么啊！
- 中国神话故事 中国的神话故事
- 想要一个月租最便宜的电话卡……我不打电话……不发短信……流量可用可不用！在宜宾……现在用
- “屠苏”是什么意思
- 林俊杰写的一首歌！开头是“等不到天黑…”歌名是什么呢？