《人月神话》读后感

Posted 2020-07-28

      这个学期选择软件冲程这门课我受益匪浅。在这段学习的过程中读完了一本人月神话则是我认为最有价值的经理。

      在软件领域中,很少能有像《人月神话》一样具有深远影响力和畅销不衰的著作。作者布鲁克斯被誉为“IBM System/360之父”，他曾是这一系统的项目经理，后来在设计期任360操作系统的项目经理。由于这一工作，他与Bob Evans和Erich Bloch 1985年曾获美国国家技术奖。Brooks博士早期曾担任IBM公司Stretch和Harvest计算机的体系结构设计师。1999年，他还荣获美国计算机领域最高奖图灵奖。

      看完此书后，我发现人月神话无处不在，其实在我们做软件工程来说，此书 已经渗透进去了。本书作者为人们管理复杂项目提供了颇具洞察力的见解，既有 很多发人深省的观点，也有大量的软件工程实践。大型编程项目深受由于人力划 分产生的管理问题的困扰，保持产品本身的概念完整性是一个至关重要的需求。 《人月神话》探索了达成一致性的困难和解决的方法，并探讨了软件工程管理的其他方面。 

      在刚刚进入软件工程学习时，老师就和我们说了一些关于“软件项目开发的完成与增加人员的问题”，这句话听起来通俗易懂，道理很简单明了，但实现起来却遇到了相当大的困难，这也是我在阅读完成《人月神话》时最大的感受。全书的第二章说的就是人月神话的关系。“一切都将运转良好”在软件工程中是不适用的；完成工作的人数与时间是不能进行简单的互换的，因为沟通需要额外的成本。我想这种问题的出现主要是就订单项目而言，因为人员的增加主要是因为客户所要求实现的东西并没有在计划的时间内收到满意的答复和应得的功能与效益。所以项目开发人员不断的增加，本书作者布鲁克斯得出的结论是显而易见的：“向进度落后的项目中增加人手，只会使进度更加落后”。如果不想加班，不想削减功能，不想推迟发布日期，那么唯一的方法还是只有加人。加足够的人。而且不要逐步加入，一定要一次性加入。要小心的是，新加入的人可能对原来的组织造成冲击，或者对原来的设计有不同意见，特别是我想如果如果有比较强大的设计者时就要当做新组建了一个团队。重新交流，培训新人，就设计达成一致，继续向者目标前进。这也是造成项目延迟的原因之一。软件开发的多少人参与和完成时间不成正比，过多的人参与并不一定能缩短开发时间。如战争，部队多，人多并不是关键，更多需要武器的先进，战术，兵多后方便的补给就得多。如是参与软件开发的人增加，软件的花费将提高，刚参加这需要时间了解项目，给软件管理带来了不协调。在我们实际进行软件开发的时候，各个成员之间要做好沟通协调，一个人开发软件虽然完整性会很好，但是效率太低；相反，团队开发虽然效率很高速度很快，但是如果各个成员之前没有很好地团结协作，各自为战，那么最后的结果也一定不会尽如人意。

      书中还有一个让我印象深刻的观点是：要保证一个项目的进度被大幅度推迟，制订进度表很重要。进度表由里程碑和完成的时间组成。里程碑必须具体、明确、可界定。某一里程碑要么到达，要么没有到达，不应该是80%到达的。而我的经验是，制订进度表非常重要，而且要求制定者有很强的技术背景，这样才能对可能碰到的问题和可能花掉的时间做出更准确的估计，我们这次的项目中出现了burn down图的正斜率，希望通过学习和锻炼再也消失不见。

      以上就是粗读《人月神话》的一点感受，好书，以后有时间一定再细细品读。