软件项目发展历史<人月神话>这本书好
原因在于，有些任务是无法分解的，存在先后顺序。无法同步进行。
增加人手，增加的是沟通成本，相互牵制。可以分解的任务就可以通过增加人手来加快速度。但是不能分解的任务，增加人手只会增加开发时长。打个通俗比方，怀孕需要12个月，增加人手，也不能加快时间。
作者赞赏的是，小型精干的技术团队是最好的。沟通成本低，开发效率高。
厨师煎一个蛋，需要5分钟，而顾客期望2分钟。怎么都达不到，2分钟的办法是，把火开大可以快速点（类似于软件加班，多投入人），蛋会烧掉。
已经延期的项目增加人手，会更加延期。分配任务，培训新成员的成本。
这方面的坑，前人遇到过了。
困难的预估不足。这是我们的问题。
做项目，任务的评估时间忽视了软件开发的特点，我们往往凭着直觉来评估周期。增加人手不能解决问题。
我们自己做的时候，不会这样。等到位置变了，就想当然了。
这本书里面提到一个经验，调试和测试的时间花费是最多的。比开发写代码要多得多。
现在看来是这样，有时候为一个bug，调试，定位问题，耗费长时间。
建立一个组织架构，不要强调头衔。
具体的办法为：
1，叫负责人，而不是叫总监。叫法会造成心理的隔阂。负责人强调的是身上的责任和担子。将会促使人去干实事。
2，提供技术和管理两条发展路线。级别要一样，不应该有待遇差别。办公室的位置要一样，不要刻意显示地位差别。否则，技术人员都挤着想做管理(不安心钻研技术，因为级别和待遇低)，而管理人员则显得自己地位的差别，技术人员的话语权就低了。
管理能获得更好的待遇（薪资、受尊重程度，各种权利和荣誉）。那么管理将会务虚不务实了。
3，技术人员向管理的转换，要以调动的名义，而不要以晋升的名义。这种调动时，待遇不要跟着变化，而应该不要变。
作者观点是：
对于一个广泛使用的程序，维护成本是开发成本的40%甚至更多。而且据发现，系统的用户数越多，发现的错误越多（我们想想windows常年打补丁进行更新）。
为什么会这样？用户数多，他们熟练使用旧功能后，就会使用新功能。于是就会发现新功能那些不容易察觉的问题。
修复bug，往往会引入新的bug。经常出现这样现象：前进两步（修复和完善两个地方），后退一步（引入一个新的缺陷）。
读到这个观点，程序员是不是深有共鸣？
我想，更关心的是如何解决这个问题？
……………………书中笼统而过解释了一下
为什么缺陷不能更彻底地被修复？首先，看上去很轻微的错误，似乎仅仅是局部操作上的失败，实际上却是系统级别的问题，通常这不是很明显。修复局部问题的工作量很清晰，并且往往不大。但是，更大范围的修复工作常常会被忽视，除非软件结构很简单，或者文档书写得非常详细。
其次，维护人员常常不是编写代码的开发人员，而是一些初级程序员或者新手。
作为引入新 bug 的一个后果，程序每条语句的维护需要的系统测试比其他编程要多。
理论上，在每次修复之后，必须重新运行先前所有的测试用例，从而确保系统不会以更隐蔽的方式被破坏。实际情况中，回归测试必须接近上述理想状况，所以它的成本非常高。
显然，使用能消除、至少是能指明副作用的程序设计方法，会在维护成本上有很大的回报。同样，设计实现的人员越少、接口越少，产生的错误也就越少。
……………………
作者已经帮我们归纳原因了，那么我们可以根据原因，依据自己项目中实际情况做改进。
原因：
1，修改系统的人不熟悉原来的系统。比如他是系统的新手。比如系统的维护人员，由于他并不是之前开发这个系统（功能）的人员，于是不熟悉系统，修改就会造成麻烦。
不熟悉，改了具备后会影响到哪个环节。
2，缺少评估修改系统后，产生的影响。大系统，修改功能，评估时间做足够点，重点不要放在评估开发时间上，放在修改局部造成哪些方面会影响。不要走形式。
3，系统缺乏必要的文档说明。造成接手的技术不知道来龙去脉，那么为了应付上级任务催促，就只能先改好再说，但是改了后出现问题了。
归纳对策
1、减少开发系统人员的波动。现实中这的确比较难，实际上根源并不是人员波动(因为人员不波动是理想状态而已)，而是人员波动后造成的衔接故障问题。只要解决这个根本性问题即可。一个国家主席会有任期，没有不散的筵席。怎么保证国家政权的平稳过渡，有选举制度，按流程走。
2 、详细的文档，避免混乱。古代的经验，今天的人怎么继承的。靠的是古人的文字记载。
作者的观点：
杰出的设计人员应该与杰出的管理人员一样重要，受到的回报要一样，不仅仅是薪资待遇，要在认可方面一样：办公室规模、安排、人员支持等方面。这样才会有更多回报。
良好的设计人员和卓越的管理人员都是稀缺的。卓越的管理人员，绝不会比良好的设计人员更加迫切。
之所以那么重管理，那是传统的工厂活，因为是机械式的干活，不需要很强的创造力。而当面对高级人才的时候，这些高级人才往往是自我驱动型，对他们的管太多会造成情绪不爽的。
如何解释小型团队带来的好处。
维护系统比开发系统的成本更高。如何才能做到这样。
有些开发任务是没法拆分的，拆分后，反而效率不高。需要投入沟通时间，培训成员的时间。
这本书提出一个观点，成员多交流，定期交流，这样才能知道需求有没有偏差。
作者建议的几种搭配：
产品经理和技术总监是同一人。
产品总监总指挥，技术总监当其左右手。
技术总监总负责，产品经理做左右手。
为什么要这样子设计呢？好处是什么呢？
知道正确的办法。很多事情要回报。
老板的目标，如何培养人才，使得技术和管理人员可以互换。
提供两条晋升路线的办法，为什么存在一些社会性障碍。
为技术和管理人员建立相同薪资容易，建立相同的威信则需要很多措施。
项目经理的职责之一就是协调大家按照一致的方向前进。他的重要不是做在决策，而是沟通，沟通使得大家保持一致方向。
文档是作为沟通的渠道，让大家想法达成一致。文档减轻了沟通障碍。
只
有以文档记录下来，大家的分歧才会明朗，矛盾才会突出。因为文档往往是精确的，可以沟通的(相比口头语而言)。这里文档有个细化到什么程度的问题：什么事
情需要文档，什么事情不需要文档。我以为，重大或者关键性的决定口头说是不准确的，沟通看起来快（相互马上知道），但是要接地气实施目标困难。会出现沟通
偏差，误解，白做。
达到无为而治的情况。
的确是屁股决定脑袋
