《人月神话》读书笔记

第一次接触到这本书是在本科软件过程管理的课堂上，当时这本书被作为推荐读物出现在教学课件的最后一页，光看这个书名，其实很难联想到这是一本软件工程专业书籍，“神话”带着一点传奇色彩，但当时并没有把这本书放在心上。当它再次出现在眼前时，是在最近的软件工程管理课堂，这本书被作为课后读物作业，于是就有了认真阅读它的理由。

现在想想，如果是在前几年看这本书，我可能对理解里面的一些内容想法感到困难，但经过过去一年在实验室做项目课题的经历，我对书中的一些问题与想法有了认同和自己的思考，比如软件工作量的度量问题，软件进度与交付时间延期的问题，再比如最近才开始了解的学习型组织的构建问题，等等。这本书是2002年出版的，其中涉及到的问题到如今还保持着时效性，足以说明这本书的经典，以及软件开发的困难性。

在本科学习软件工程这门课，我系统地了解了软件开发过程地各个阶段内容，就像瀑布模型——制定计划、需求分析、软件设计、程序编写、软件测试、运行维护，这个过程很容易理解，曾经以为这个过程是可以按部就班一步一步去实现的，但现在想想的确太过于理想化了，也就是书中提到的“乐观主义”，认为一切都将运作良好，每一项任务仅花费它所应该花费的时间。

“人月”，是估计和进度安排中的使用的工作量单元，诸如此类的工作量度量单位还有代码行数、功能点、用例点和故事点等，是依据项目、团队等因素的不同按需选择的。对于“人月”，从数据评估者的角度来看，可以根据自己大概需要花多少时间去推断出工作量的数值。“神话”一词由此而来，用“人月”作为衡量一项工作的规模是一个危险和带有欺骗性的神话。书中针对“神话”，主要提到了交流这个问题，参与项目的人数增多，虽然可以使开发模块化进行任务分发，但不可避免会产生交流沟通，新人员加入项目也必不可少进行培训，交流沟通和培训带来的时间成本是否可以抵消掉原有任务分解产生的作用呢？我认为是抵消不了的。我认为软件工程的问题有很大一部分是来源于人的问题，即人自身问题、人与人之间的协作问题、上下级人的管理问题，问题的影响来源也有很多，诸如个人的技能水平、领域经验、团队成熟度等等。所以，“人月神话”的确是一个“神话”，一个很不可靠的“神话”。

说到工作量单元，最近在研究软件度量指标这个问题，感觉非常令人头大。有效的度量体系是面向价值的，没有价值的度量就是给领导获得虚假安全感、满足控制欲的皇帝的新衣。度量的目的不是“控制”，而是改进价值交付能力。

还想说说比较有感触的“外科手术队伍”章节，这篇里面提到了一个问题，就是“如何在有意义得进度安排内创建大型的系统？”文中提到，软件开发团队可以按照“外科手术队伍”的人员配置来安排，使团队的完整性得到提高。在运作方面，主要注重一人分解多人支持，以提高效率和生产力。最近我新了解到一个概念——学习型组织，我觉得这和“外科手术队伍”的概念有异曲同工的地方。在学习型组织里，人们持续地拓展他们的能力，创造出他们真正渴望的硕果；那里滋养着崭新而广阔的思维模式；那里释放着集体共同的抱负；那里人们持续地学习，为了能够一起看清事物的全貌，即Mills所认为的“从个人艺术到公共实践”。

软件交付时间延后也是当下项目管理者比较关注的一个问题，管理者都希望可以防患于未然，提前预知风险的存在，而风险来自于方方面面，比如频繁的需求变更、进度表和预算不切实际、项目人员短缺、缺乏高层管理者的支持、缺乏技术平台经验……“祸起萧墙”章节就提到了进度问题，并提出“里程碑还是沉重的负担”，本是为过程改进服务的，却最后成为一项负担，我觉得这也是软件工程实践中很常见的一类无奈。

“没有银弹”这篇文章在表达了软件开发在根本上就是困难的这一想法，但同时又给出了“银弹的希望”，我对“专家系统”这一概念比较感兴趣，其是包含归纳推论引擎和规则基础的程序，接收数据和假设条件，通过从基础规则推到逻辑结果提出结论和建议。我认为就是将丰富、大量的历史数据与经验作为系统的输入，得到知识积累，用于之后的软件过程风险预测和软件过程改进。我觉得这是一件对软件工程领域很有意义的事情，并且已经有企业实践了这一想法，运用这个思想去提升软件开发效能，形成组织自己的一套专家系统，形成战略竞争。

软件工程管理课堂上，老师提到，软件工程是建立在计算机科学基础上的学科，研究的是怎么在做得出的前提下，做的快，做的好，这就是工程层面上的问题，也可以说是管理层面的问题。常常看似简单明了的东西，却有可能变成一个落后进度、超出预估、存在大量bug的怪物，很难去预知，很难去控制，不可能做到100%的可控、100%的安全。