也读《人月神话》：没有银弹的软件工程

一、关于人月神话这本书

　　记得在上大学的时候，就经常听学长和老师讲起《人月神话》，但是却一直没有阅读。记得当时一听到这个书名，还以为是个神马科幻类别的书，结果是个软件工程方面的书籍。这本书是“图灵奖得主、“IBM360系统之父”作者Brooks写的，人们都说它颠覆了项目管理领域，是一本长久不衰的传奇经典，畅销了40多年。的确，在我们熟悉的豆瓣读书上面，它的评分达到了8.6（满分10分），不可不畏是一本好书。最近快速地阅读完后，按照我的老规矩，也需要总结总结，写一篇笔记来日后回顾之用。

二、什么是“人月神话”？

　　“人月”这个词英文原文是“Man Month”，代表一个人一个月的时间内能够完成的工作量，在软件开发项目管理中，常用来估算任务量，比如“这个项目需要多少个人月？”。很多时候我们或多或少都有过这样的经历，很多的项目管理人员总是希望通过增加更多的人手来加快软件工程的完成进度。比如，一个工作量为10个人月的项目，如果只有一个人做，需要10个月才能完成。于是，我们的项目管理人员认为，只要再加入9个人，那么10个人一起做，就只需要一个月啦。然而，实际情况并非如此，因此软件工程的各项工作之间，往往存在着一个前后继承的关系，完成了这一项，下一项才能开始。那么，加进来的人手呢，他并不能立即开始工作。所以，想要通过增加人手来缩短工程时间，其实只是一个“神话”而已。这里，就不得不提经常被拿来举例的一个例子，一个孕妇生一个小孩需要10个月，那么请10个孕妇来就只需要1个月啦？显然是不可能完成的任务。

　　而“人月神话”反映出的，就是软件开发在项目管理中所遇到的难题：管理人员因为盲目乐观，对项目开发过程中的困难没有充分的认识，在计算项目的工作量和交付时间上采用了错误的计算方法，忽略了细节对整体的巨大影响，而这很可能会导致项目延期。

三、如何处理“人月神话”的困境？

　　首先，作者建议，以小团队的方式开展工作。

　　这里不得不说，作者在当时提出了一个类似于外科手术团队的组织结构来开展工作。外科手术团队的奥秘就在于，它是以主刀医生为核心，其他像负责助理医生、麻醉师、护士等人都是为主刀医生服务的，大家各司其职、齐心协力，从而保证手术顺利完成。那么，反映到软件工程上面，就是以架构师或者高级程序员充当主刀医生的角色，而团队管理者充当副手或者服务人员，其他团队成员则分别负责单元代码编写，功能单元测试，文档管理，工具开发及技术支持等等。即使整个项目团队的人数庞大，但只要根据工作边界，将大家划分到一个个类似于外科手术队伍那样的小团队当中去，就可以保障在一定程度上的效率提升。

　　其次，要进行行之有效的沟通。

　　定期召开项目进度例会，对数据结构进行监督和全员反馈等等，都是常见的增进沟通的手段。而近年来流行的敏捷开发模式，例如Scrum这种敏捷开发流派，就特别倡导小团队的高频率的沟通，每个迭代（大概2周一个迭代）都会完整经历计划会议、每日站立会议、项目评审会议、团队回顾会议等，特别是每日站立会议，虽然一般只有短短15分钟，但是确是增进沟通的主要行之有效的方式。

　　此外，作者还在特别强调了两个点：

使用产品文档
“手把手带”的沟通方式

　　最后，要“防微杜渐”

　　关于“防微杜渐”，作者具体给出了几点建议：

在项目推进的过程中设立一些关键节点，作者称之为“里程碑事件” => 我所在的团队每天的站立会议都会设立“今日目标”，也就是一些里程碑，在每天下班时后看看这些里程碑事件完成了多少，如果完成100%那么久擦掉，如果没有就说明情况和问题，留到下一个工作日继续完成。
为项目设立一个专门的规划和控制小组
项目管理必须认清一个现实：“唯一不变的就是变化” => 我所在的团队经历过多次需求大改的情况，迫使我们每次修改都要面向未来考虑变化点和可扩展性
为了避免项目延迟和失败，要尽可能地提前集成测试 => 只有尽快集成测试，才能暴露前后端在对于backlog的理解上存在的问题，有没有完成AC（验收条件）

四、“人月神话”为何无法彻底解决？

　　“人月神话”中的一些问题，其根源在于软件工程本身的特性，是无法彻底解决的，这也是广大IT从业人士的共识。其原因归根结底有以下几点：

计算机技术的发展实在是太快了 => 想想摩尔定律到现在前后端的框架变化，我们时常感叹前一阵子学的东西现在又被淘汰了，是否要开始学习AI了？
软件研发本身的内在的特性也制约了软件工程的进展 => 作者用了4个词来概括这种特性：复杂性、一致性、可变性和不可见性。

五、改善软件开发根本困境的建议

　　虽然作者说到上面提到的这些困境是软件开发的根本困难，无法彻底解决。但是，它还是给出了三方面的建议，来尽可能改善这种困难造成的困境：

采用新技术 => 使用高级语言总比低级语言方便吧，使用.NET Core总比.NET Framework程序性能和跨平台好吧？
“快速开发原型”，然后再做“增量开发” => 其实跟我们的敏捷开发思想一致，通过在不断地迭代反复中堆成一个完整的系统，在精益创业中，也有一个MVP（最小可用产品）的概念，它提倡快速原型试错，快速获取市场反馈，然后再慢慢完成最后的完整的产品。
聘用卓越人才 => 这一点毋庸置疑，有了新的技术和敏捷开发，还需要合格的、追求卓越的程序员人才，这让我想起了ThoughtWorks这家公司，它是一个尊重技术，提倡敏捷并且积极追求卓业人才的代表性企业，Martin Fowler是其首席科学家，无数的咨询师走上了技术布道之路，敏捷开发，DDD，微服务等实践总结和分享雨后春笋般地出来，向ThoughtWorks致敬。