读《人月神话》所感所思

Posted 2020-07-29

　　近日，读了老师推荐的《人月神话》，深感项目开发的艰辛。《人月神话》这本书最开始的版本是1975年的，四十年过去，当下看来书中有些观点依旧适用，而有些观念已经过时。以下列举看过这本书之后两个印象十分深刻的观点：

• 　　 “人月是危险和带有欺骗性的神话，因为它暗示人员数量和时间是可以相互替换的。”

　　诚然，这个观点至今还是毋庸置疑的。

　　人月之所以是危险和带有欺骗性的，原因是人们混淆了工作量和项目进展。根据Brook 法则，向进度落后的项目中增加人手，只会使进度更加落后。向软件项目中增派人手从三个方面增加了项目必要的总体工作量： 任务重新分配本身和所造成的工作中断；培训新人员；额外的相互沟通。

　　“人月”问题似乎只能在项目开始时进行有效预防，而在项目开发过程中进展一旦落后，再高效的的解决方案也还是会使预期效果打折扣或者预期耗费时间增加。预防“人月”问题，关键在于建立细致的项目开发日程文档，落实好项目进展日志。一天一天的进度落后比起重大灾难， 更难以识别、 更不容易防范和更加难以弥补。一旦文档具体到开发人员们无法自欺欺人时，开发人员们才不会明日复明日，而是提高效率完成所规定的工作。

　　从一开始便杜绝项目进展落后问题的出现，需要的不仅仅是详尽的日程规定，更加需要开发人员们高度的热情和积极向上的乐观精神。这就要求开发团队有合理而高效的激励机制。激励机制的建立主要从两个方面考虑：物质层面和精神层面。　　

　　物质层面：

• 　　　　　　　薪酬奖金：对于工作突出的个人，可以适当提高薪酬，发放奖金或者奖品。

　　　　　　  　　　　　　　　

 

　　精神层面：

• 　　　　　　　　目标激励：确定适当的目标，诱发人的动机和行为，达到调动人的积极性的目的。
• 　　　　　　　　尊重激励：管理者不重视员工感受，不尊重员工，就会大大打击员工的积极性。
• 　　　　　　　　荣誉和提升激励：对于一些工作表现比较突出、具有代表性的先进个人，给予必要的荣誉奖励。
• 　　　　　　　　淘汰激励：可采用处罚方式，即利用带有强制性、威胁性的控制技术，来创造一种令人不快或带有压力的条件，以否定某些不符合要求的行为。

　　另外，团队成员之间应该以尽可能多的方式进行相互之间的交流：非正式、常规项目会议，会上进行简要的技术陈述、共享的正式项目工作手册等等。如此，才可以确保开发工作能按时按需完成，不会半途而废。

 

• 　　瀑布模型的错误的！

　　作者在《人月神话》出版后的20年，指出自己在75年的书中，瀑布模型是错误的。

瀑布模型（图片来源于百度）

 

　　它的基本谬误是它假设项目只经历 一次 过程，所有错误发生在编码实现阶段，因此它们的修复可以很顺畅地穿插在单元和系统测试中；并且假设整个系统一次性地被构建，在所有的设计、大部分编码、部分单元测试完成之后，才为闭环的系统测试合并各个部分。

　　在需求不断变化的开发过程中，瀑布模型的思想显然不适用。与此同时，作者还提出增量开发模型更佳。因为增量开发模型思想是渐进地精化。

 

增量开发模型（图片来源于百度）

 

　　　增量开发模型的优点是，在所有时刻，开发者都拥有一个可运行的系统，所以可以很早开始用户测试，以及可以采用按预算开发的策略，来彻底保证不会出现进度或者预算的超支。对于大型系统开发来说，增量开发模型确实是比瀑布模型更优的选择。但是，增量开发模型也存在缺点。虽然增量模型的灵活性可以使其适应需求变化的能力大大优于瀑布模型，但也很容易退化为边做边改模型，从而使软件过程的控制失去整体性。

 

　　《人月神话》的一开始便把软件工程比作是焦油坑，诚然，软件工程这个焦油坑还会在将来很长一段时间内使开发者们举步维艰。面对软件工程这样将持续很长时间的问题来说，关键在于不断地学习与开发和利用新工具。如何提高软件开发的效率将会成为信息技术时代的关键问题之一。