沟通第一

原本以为作者会遵循《软件工程》的内容进行展开或细化，可刚读了第一页我就彻底改变了原来的看法：作者根本就没有受那些条条框框的思想束缚，相反，他以一种独特的视角总结了实际开发项目中提高效率的种种方式。对于我这样一个没有什么大型项目经验，更没有项目管理经验的普通coder来说，没有什么资格评论该书，能做的只有根据自己的理解，总结作者的实际经验...

规范书并不一定规范，尽量通过其他方式进行补充调整，比如“走廊会议”、“委员会议”，以及两者的结合。

对于Bug的修改，开发者进行bug修复前，要先做详细的记录。并要保证有3双眼睛（即代码改动者本人和另外两个开发者）同时审查每一次的代码改动。

对于已经标注的“延期”的bug，本来是应该到下一个版本再进行修复，因为当初在项目的进行过程中，产品的相关团队对“哪些Bug对我们的客户影响最大，因此必须在发布之前修复”作了判断，但这种判断在产品没有真正发布之前是无法验证的。但一旦产品已经投入使用，客服反馈的bug信息通常是实际中对使用影响较大的，所以必须及时修复。

开发人员在没有规范书的“空闲”时期，可以根据需要对那些“丑陋”的代码进行重写或重构。但要注意一点：要保证有足够的“单元测试”来防止引入大量的新Bug。

开发人员在“空闲”时期还可以做的事：
1、分析bug
2、为部门开发一些工具
3、尝试把项目经理的设计变成原型程序
4、学习新技术
5、跟研究人员交流，为开发下一版本做准备
6、有必要的话，撰写一下专利申明或白皮书
7、反思职业生涯，提早行动

不要在选择编码风格上浪费时间，只要在项目中确定统一的风格即可。

关于会议方面：
1、混合会议是低效的，每次会议最好有一个明确的主题或目的。
2、这样以来，每次会议根据不同目的，可以邀请不同的参会人员（而不用“全军出动”）。无须参加某次会议的人员，可以通过email等方式了解会议情况。由于会议的持续时间跟参加会议的人数是直接成比例的，所以这样可以很好提高开会效率。
3、会议之后，项目经理还需要做的：发送一个email给会议可能影响到的人，内容包含一个对会议所做的决定、共享的信息或者收集到的想法的简短总结，并列出接下去的安排。

尽量逐渐停止写那些没有实际意义的规范书，最好组织专门的“功能小组”，让各个部门更靠近，让他们之间沟通更方便。因为这样做可以更快地得到更高的质量，并且留下较少的未完成的工作。

对于那些必须要写的规范书，应该保持以下特点：
1、内容简单，易懂，并且容易维护。（比如使用UML绘制图表）
2、对于要实现的功能，必须要有能够验证它的测试方式。
3、要确保规范书随时都可以修改，直到团队认为它不需要再改为止。
4、集成质量检查，减少节次（需求、设计、问题），每一节次中对设计进行完整描述。

最后，用我自己最直接的感受总结一下：项目开发中，沟通要放在第一位！

这个准确来说并不算书评，应该叫“读书笔记”更好一些
评论不敢说，体会和感想有空可以再写一下
我感觉学东西，先总结下重点比较重要:)

这篇算是笔记，刚又写了篇感想:P
关于第三章的一点感想

写的很不错，支持一下！

  写的好！支持！