《人月神话》- 读后有感

/ 方法论

项目管理

人月神话 (The Mythical Man-Month)，第一版发行于上世纪70年代，作者 Brooks。

全书是作者根据当时已有的讨论及自身的经验，对软件工程管理领域相关知识进行了系统的阐述。

所以其实我们都是直觉经济学家，当我们说“畏难”的时候，其实我们畏惧的不是困难本身，而是困难所暗示的时间经济学意义

-- 《暗时间》

对于个人如此，对于项目更是如此。如果一个项目没有时间的约束，管理也就失去了意义。

针对项目管理中滞后的原因，Brooks做了精炼的总结。

项目滞后的原因

  1. 没有合理的估算
  2. 默认人月神话的存在
  3. 对自己的估算缺乏坚持和信心
  4. 缺少跟踪和监督
  5. 进度落后时，盲目增加人力

作者的解

  1. 合理配置团队人员组成，减少沟通和协作的成本
  2. 概念的完整性设计需要专制，实现和开发需要民主
  3. 通过文档的沉底，降低交流协作的成本
  4. 增量式开发
  5. 必先利其器，分配资源用于通用工具的开发
  6. ......

个人读后感

读后的感受，“这本书确实经典，不适合功利性很强的快餐式阅读者”。

全书的编写非常偏美式教程，有些地方很冗余，适合作为闲暇时的课外读本。

C语言1972问世，本书第一版发行于1974年。之所以特意查了下这个时间，仅仅说明这本书的古老。

文中作者所遇到困难、列举的事例，如今已很难体会或者说想象到。

但文中所提出的很多想法，如今看来很多都已经有了对应的实现。

思考

个人认为作者总结的滞后原因，如今同样适用。

没有合理的估算

由于时间、人员调整、需求变更等很多情况下，对于项目的实现往往没有做出合理的估算就定下上线日期，最后实施中发现各种问题无法实现或解决导致延期。

个人认为，无论何种情况下都需要给估算一定的资源。一个空泛的估算，最后无法落地就毫无意义。

关于进度，作者的经验是 1/3 计划、1/6 编码、1/4 构件测试以及 1/4 系统测试。

默认人月神话的存在

延续上面的规则，合理的估算就需要考虑到任务的拆分。对于有上下依赖不可拆分的任务，增加人手只会抬升协作沟通的成本。

因此往往会出现，一个人需要10天完成，2个人实际需要7天，3个人实际需要5天。 总人日 10 、 14 、 15。

如果继续按总人日不变，认为投入10个人一天就能搞完，这样必然会导致项目的延期。

对自己的估算缺乏坚持和信心

一个有职业素养的人，一般会对自己的承诺负责，需要坚持自己的判断，这是天然合理的。

但现实情况往往自己的估算会被打折压缩，也不可避免。

个人认为，对于估算一定要实事求是，对于不同的条件需要做出不同的调整，使得估算的结果能得到统一认可。

缺少跟踪和监督

对于当下来说，跟踪和监督是不缺的。更多的是，在跟踪过程中出现的风险如何提早发现和处理。

未知的风险可以由充分合理的预估来规避。

对于已经出现的风险，则需要及时的抛出，乐观的对待风险往往会导致影响的加重。

风险的解决一般都会采取增量式开发妥协，即先解决主要问题，次要的问题在迭代中解决。

进度落后时，盲目增加人力

作者对此提出了 Brooks法则：向进度落后的项目中增加人手，只会使进度更加落后

对于现有架构来说，Brooks法则并不完全适用，即适当的增加人力确实可以解决部分进度问题。

不能完全适用是应为增加人力的同时，带来新的工作量：任务重新分 配本身和所造成的工作中断、培训新人员、额外的相互沟通等。

如此可见，新增的人选很关键。 如果新增一个熟悉背景、经验丰富且经常配合的人员，则往往有事半功倍的效果。

经验

自顶向下 逐步求精

-- 《通过逐步求精方式开发程序》(Program Development byStepwise Refinement) 瑞士计算机科学家 尼古拉斯·沃斯

自顶向下设计
  1. 了解项目背景及自身所处上下文
  1. 全盘梳理需求
  1. 总体设计与分工（战略设计）
  1. 细节可行性设计（战术设计）
  1. 输出依赖设计
  1. 排期

对于一个有职业素养的技术人员来说，排期我们对客户的承诺，一般代表了一定可以兑现的时间

对于排期的原则

时间预估公式（PERT）

μ = (O + 4N + P) / 6

μ ： 任务的期望完成时间

O： 乐观预估时间。一切都顺利完成，实际发生概率小于 1%

N： 标准预估时间。最大概率完成的时间

P ： 悲观预估时间。一定能完成的时间，实际完不成的概率小于1%

  1. 开发 & 联调 & 测试 & 上线 等常规流程

本站文章除注明转载/出处外，均为本站原创或翻译，转载前请务必署名,转载请标明出处
最后编辑时间为: 2022-03-15