刚听说这本书的中文书名的时候，还以为是一本玄幻小说。看到英文名才恍然，《The Mythical Man-Month》，妥妥的一本管理类的图书。《人月神话》可以说是经典中的经典，问世多年以来，经久不衰，常被提起并热议。抛开译著都有的通病，语言比较晦涩之外，无论是实操还是成书逻辑，都十分经得起检验，毕竟从1975年开始到今天，已经接近40多年了。期间出了不少版本，每个版本都会有一些紧跟时代的小更新。说句题外话，如果英文足够好，还是建议去读英文原版。
理解本书，可以把“人月神话”这个词可以拆分成两个名词来看，即“人月+神话”，“人月”指的是每人每月的工作时间，软件工程规划时使用 “人月”这个单位来评估计划是否可以如期完成。而“神话”这个词则直接表达了作者的观点，即认为这种规划方式像“神话”一样是不可能，这也是本书最基础的论点，规划的方式错误必将导致整个项目工程失败。
这里面最明显的问题有三个：
第一，一个人一个月的产能，不可能100%发挥。工作中会有许多杂七杂八的事情影响，或者单纯是开发者个人的状态、心情，还有各种Bug错误拖延等等，让工时成果直接低于原本预估的一个月的工作量。
第二，工时无法叠加，两个人的一月，并不等同一个人的两个月，软件开发工作是有连续性的，做完 A 才能做 B，同一个月加入另一个人并不会加快工作进程，反而可能延缓。
第三，就算工作可以分割并行，整……
理解本书，可以把“人月神话”这个词可以拆分成两个名词来看，即“人月+神话”，“人月”指的是每人每月的工作时间，软件工程规划时使用 “人月”这个单位来评估计划是否可以如期完成。而“神话”这个词则直接表达了作者的观点，即认为这种规划方式像“神话”一样是不可能，这也是本书最基础的论点，规划的方式错误必将导致整个项目工程失败。
这里面最明显的问题有三个：
第一，一个人一个月的产能，不可能100%发挥。工作中会有许多杂七杂八的事情影响，或者单纯是开发者个人的状态、心情，还有各种Bug错误拖延等等，让工时成果直接低于原本预估的一个月的工作量。
第二，工时无法叠加，两个人的一月，并不等同一个人的两个月，软件开发工作是有连续性的，做完 A 才能做 B，同一个月加入另一个人并不会加快工作进程，反而可能延缓。
第三，就算工作可以分割并行，整……