「人月神话」中的「人月」是什么意思

in 转载摘记 with 0 comment

根据普遍经验,一个目标产品本身能有多大的代码量大致不会和预算的相差很多。当然也会有一些连代码量也估算不准的 leader。 通常会最终会将代码量分解到每个模块,并且根据程序员的工作能力来分配进度要求。如果一个人是屎山的创造者,他大可说:“为什么 XXX 这么简单的代码都完不成,耽误了多少时间”。


「人月神话」中的「人月」是什么意思

原文地址:百度知道,博主进行了整理与重新排版

人月代码产量

人月是工作量的计量单位 ,是项目所有参与者工作时长的累计,是最为方便计算成本的数据。是项目管理中常用的概念。

如一个项目前期投入 3 个人工作 2 个月,中间 2 人工作 0.5 月,后期 1 人 (0.33 兼职)工作 3 个月,那么工作量的计算就是:3 人 * 2 月 + 2 人 * 0.5 月 + 0.33 * 3 月 = 8 人月

在未完全模块化的项目里,一个计算项目时间的经验公式是 t = mm * sqrt(n) / n, t是时间, mm 是人月数, n 是团队人数。

人月是对项目成本估计的有效手段

在很多情况下,遇到进度失衡的时候,第一反应是增加人手。但是事实上增加人手的项目不到 10% 能准时解决。很多情况下,增加进去的人手并不能真正进入工作,因为模块已经无法细分一小块出来给新加入的人手。 又或者新加入人手熟悉现有代码结构的时候已经到达项目终止时间。

人月代码产量 本身就不是一个固定的值。我的最高写作时刻可以达到 1600 行/天。 真的就是 32000 行/月了么? 不! 更多时刻的代码产量在 200 - 300 行/天。也有很多一个算法就花费 1 天。 变得只有 100 行/天的情况。真正比较客观的状况,根据最近 3 年的状况,5000 行/ 3 月是比较客观的量。这是 C/C++ 的速度,是我的速度,其他程序员有这样的效率么?

真正能超过的并不多见。即使是这样的代码效率,也并不适合将计算进入商业产品的进度考虑。(个人完美产品和商业完美产品将在以后有写作欲的时候写) 因为很多难点并不是因为降低人月代码产量就能够攻克的。

时间分配

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

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

行动

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

总结

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


-EOF-

Responses