重读《人月神话》（3）- 什么是人月神话

和码说

于 2024-10-04 22:21:44 发布

阅读量483

点赞数 18

分类专栏：人月神话软件工程文章标签：软件工程

本文链接：https://blog.csdn.net/2404_87526689/article/details/142708349

版权

人月神话同时被 2 个专栏收录

3 篇文章 0 订阅

订阅专栏

软件工程

3 篇文章 0 订阅

订阅专栏

“人月”（Man-Month）概念，是指一名开发者在一个自然月内所能完成的工作量。理论上讲，如果某个项目的预计工期是十个人一个月（即十个人月）才能完成，那么人们往往会直觉地认为，可以通过让十个人同时工作一个月来达到同样的效果。

在本章中，作者进行的点题，也就是书名人月神话的出处。在本章中作者揭示了这种想法的误区。要详细了解什么是人月神话，需要对下面一个公式进行思考：

10人/月 = 1个人工作10个月 = 10个人工作1个月

在单纯的数字上，这个等式是成立的，但有点软件开发常识的人都知道这个等式是不成立的，因为有太多不确定的因素在公式的背后。

人月

在估计和进度安排中谬误的思考方式是使用的工作量单位：人月。

理想情况下人员数量与时间消耗之间的关系，即随着投入人力的增加，项目所需时间呈现递减趋势，这在割小麦或收获棉花的工作中是可行的；而在系统编程中近乎不可能，因为：

1、他们之间需不需要交流

2、任务次序能不能分解

人员和时间之间的关系——完全可以分解的任务

人员和时间之间的关系——无法分解的任务

子任务之间需要相互沟通和交流的任务，必须在计划工作中考虑沟通的工作量。因此，相同人月的前提下，采用增加人手来减少时间得到的最好情况，也比未调整前要差一些。

人员和时间之间的关系——需要沟通的可分解任务

如果任务的每个部分必须分别和其他部分单独协作，则工作量按照 n(n-1)/2 递增。一对一交流的情况下，三个人的工作量是两个人的三倍，四个人则是两个人的六倍。而对于需要在三四个人之间召开会议、进行协商、一同解决的问题，情况会更加恶劣。

人员和时间之间的关系——关系错综复杂的任务

因为软件开发本质上是一项系统工作——错综复杂关系下的一种实践——沟通、交流的工作量非常大，它很快会消耗任务分解所节省下来的个人时间。从而，添加更多的人手，实际上是延长了，而不是缩短了时间进度。

进度安排

针对时间进度安排作者从几个方面进行的阐述：

对估算技术缺乏有效的研究与应用：许多组织未能投入足够的时间和精力来发展和改进项目估算的方法论，导致估算常常基于经验主义而非科学方法。
估算技术隐含地假设了人与月的可互换性：这一假设忽略了团队成员之间的差异性和项目本身的复杂性，从而使得估算结果往往与实际所需的时间和资源产生偏差。
缺乏对自身估算的信心：由于对不确定性的恐惧，管理者倾向于避免做出长期规划或坚持既定的估算方案，这进一步加剧了时间安排上的不确定性。
进度跟踪与监督机制的缺失：有效的进度管理依赖于持续的监控与评估，但现实中，很多情况下并没有建立相应的机制来确保项目按照预期轨道前进。
盲目增加人力资源：当发现进度落后时，通常的做法是增加更多的人力，然而，如前所述，这并不总是最有效的解决方案。

除此之外，实际项目管理中还存在以下几个更为核心的问题：

忽视了人员与项目的匹配度：不仅仅是技能层面的匹配，更重要的是考虑到员工的发展潜力及其适应项目文化的能力，这样才能确保团队运作高效。
全局视野下的合理安排：项目计划制定者需要具备全面了解项目背景及目标的基础上，进行科学合理的资源配置和时间安排，而不是仅凭主观臆断。
项目计划的动态调整：随着项目的推进，外部环境的变化可能会要求计划进行相应的调整，这就需要管理者具备灵活应变的能力，及时作出必要的修正以保证项目顺利进行。
专业的任务管理工具：如今已有大量先进的任务管理工具涌现，旨在协助项目经理们更加有效地追踪和监督软件项目的各个阶段进展。一位出色的项目经理应当熟练掌握这些工具的应用，确保能够及时跟进项目中的每一个细分任务。

乐观主义

所有的编程人员都是乐观主义者。

系统编程的进度安排背后的第一个假设是：一切都将运作良好，每一项任务仅花费它所“应该”花费的时间。

针对盲目的乐观主义，历史的经验会告诉我们：

1、历史数据参考：利用过往项目的历史数据作为参考基准

2、分阶段交付：将大型项目拆分为多个可独立完成的小模块或阶段，并设定明确的里程碑目标。

3、风险评估与管理：在项目启动之初就进行全面的风险评估，识别潜在的问题点，并制定相应的应对策略。

随着任务复杂度的提升，任务不仅更难分解，还会产生更多的沟通需求，这往往会消耗大量时间。因此，在面对进度滞后的局面时，盲目增加开发人员未必能加速项目的完成，反而可能因沟通协调负担加重而进一步拖慢进度。这一现象也被称为布鲁克斯法则（Brooks's Law），它指出，在项目已经出现延期的情况下，简单地增派人手，不但无助于提速，反而可能导致项目更加滞后。这是因为新加入成员需要时间熟悉情况并与现有团队磨合，这期间产生的额外工作量有时会超过他们带来的生产力提升。

Brooks 法则：

向进度落后的项目中增加人手，只会使进度更加落后。（Adding manpower to a late software project makes it later）