《人月神话》读书笔记之四

本周继续阅读《人月神话》，本周度过的部分是第十章和第十一章（“提纲挈领”和“未雨绸缪”），如下是对该两章的感想。
1、提纲挈领

提纲挈领一章描述的是经理与文件的关系。做者一开始便给文件作了定性：文档的某些部分包含和表达了一些管理方面的工做，其准备工做是集中考虑并使各类讨论意见明朗化的时刻，其跟踪维护是项目监督和预警的机制。

做者经过“计算机产品的文档”、“大学科系的文档”和“软件项目的文档”，来阐明文档如何展开上述工做。

咱们能够看到，全部的文档都包含的项目是如下几个：目标、机构分类、技术要求、时间表、预算。这几项几乎包含了一个工程中全部的管理要素。

文档的必要性在于它的三个具体角色：书面决策、沟通渠道和数据基础与检查列表。第一项使得工做规范化、工做目标清晰化（目标、机构分类、技术要求），第二项使得决策被团队成员所知晓，而第三项则可让经理对项目所处的状态有一个大体的了解（时间表、预算）。

 

2、未雨绸缪

未雨绸缪的英文是“Plan to Throw One Away”，所以这个中文翻译不太恰当。实际上这一章讲的是，应该实行实验性开发，而且随时作好丢弃本来成果的准备，而不是把第一次开发所得的产品提交给客户去使用。

实际上对于大多数项目，第一次开发的系统颇有多是太大、太慢或者是难以使用的，且新的技术和概念的产生极可能使已有的系统开发出来就已通过时。解决办法简单粗暴——从零开始，设计一个更灵巧、方便、小巧的系统。可是实际上，在开发以前，这些问题是没法获得解决的，毕竟项目经理不能未卜先知。

所以，这个问题变成了“是否抛弃原型，亦或将原型直接发布给客户？”，对此，做者的结论是“为舍弃（变动）而计划，不管什么时候，都必定要这样作”。

如何变动计划系统呢？做者描述的很少，而惟一被强调的一点是：使用高级语言和自文档技术，以减小变动引发的错误。

变动引发的问题，最大的一点就是BUG，而维护系统、修复BUG的过程，被做者形象地称做是“前进两步，后退一步”，由于维护系统消除BUG之时，会以20-50%的概率引进新的BUG。而解决方式则是，使用能消除、至少是能指明反作用的程序设计方法，且尽量使用较少的人员和接口。