感受：
此书主要面向的是软件团队的管理、构建、工作方式、经验等方面进行说明，适用于初期或者成熟的软件团队，不太适合个人修炼。
由于我还没有正规的参与到软件工作室的软件开发，没有经历过与他人合作进行并行开发，也没有测试经验，因此很多知识都只是作为了解，没有感受到醍醐灌顶的感觉。不过作为积累知识，希望以后能用到。
书中提到了很多方法、工具，并且特色之处在于有一个“如何开始”，这样就防止了读者在看了书后不知道怎么下手去做，是一个比较好的地方。从中我也了解到了很多软件开发中比较专业的工具与过程（如CI），还是有所收获吧。不过我觉得有一定团队开发经验后再来看此书，会收获更多。
笔记：
第一章 绪论
1、习惯性优秀
在人生中，我们应该选择优秀的一些习惯，我们要刻意去培养它，使得其成为自己的习惯。让自己习惯性优秀，那么就会获得成功。“我们每一天怎样度过，一生就会怎样度过”。
在软件开发的过程中，应该习惯采用良好的习惯，比如说构建自动化测试，使用CI，版本控制等等，这些习惯可以保证我们的软件质量、个人效率等。
2、在对别人提出自己的建议的时候，都需要充分的向对方说明你这提议的理由，并且说明采用这种技术后会对你的产品直接有什么好处，不能说因为别人用你就用
第二章 工具和基础设施
1、代码寄存库
对自己的代码，需要进行版本控制，保存代码。可以采用源代码管理器（SCM）或者版本控制系统（VC）。一般可采用CVS,SubVersion等，都是开源免费的。
在使用的过程中，要养成习惯，将所有的文件都放在SCM中。
2、在构建（Build）软件的过程中，需要采用自动构建脚本进行构建。因为如果人为的每步去构建的话就会不时的漏掉步骤，浪费时间。所以用自动构建进行构建。
同时，采用脚本进行构建，也可以统一团队构建方式，使得每个人都可以在自己的机器上构建，而不是在有的人机器上可以成功，有的人不行。
构建的方式有很多，对于特定的语言，有Ant(面向JAVA)，NAnt（面向.net）等等，也有通用的脚本，如Ruby、Python、Perl。但是通用脚本语言不是面向构建系统，建议采用特定语言。还有现成的构建系统，如Maven，Maven2
3、自动构建产品，可以保证在每次修改之后，若出现问题可以及时的知道。这种系统称为持续集成（CI）。现有的开源CI工具有CruiseControl。
在CI中，可以集成编译、自动测试，并且可以将结果通过RSS进行发布通知。
4、在开发的过程中，需要使用问题BUG跟踪。采用问题跟踪，不仅可以积累经验，还可以当有人遇到该问题时，查询是否已经发现了该问题，并且知道该问题将会在什么时候解决。
跟踪系统不仅可以为产品生成问题列表，还可以为开发人员生成任务列表。跟踪系统可以使用Bugzilla，JIRA等等。
5、在跟踪问题的同时，还可以跟踪特性。为不同的特性设置不同的优先级，可以生成任务列表。同时可以防止突然间有的新的创意，可以依据特性表判断新的创意是否需要写进去。
6、在选择工具时，最好选择使用开放格式的工具，如XML或者纯文本。
第三章 实用项目技术
1、任务清单
采用任务清单，来安排每周和每日的工作，采用优先级顺序，可以把握重点，提高效率。
在采用任务清单的时候，需要将任务清单公开，使得你的经理看到，让他指点一下，不仅可以完善你的清单，而且可以让经理有成就感，提升你的形象。同时要指定优先级，时间估计，可测量，并且保持活跃。
2、在团队中可以后技术领导人。这种人可以由项目经理担任，位于技术人员和经理之间，保护团队，安排工作，并且沟通上级。
每一个人都应该以技术领导人的要求来要求自己。
3、每日例会
每日例会，不仅可以随时修正团队的方向，同时还可以提高团队沟通，让大家都了解全局等，时间不能长，一个人两分钟。
保证简短、力求具体、列出问题，但不要解决
4、代码审查
需要经常审查代码，不要过段时间才统一检查。检查的时候不需要全部检查，可以只检查部分代码。审查人员由高工担任，可以轮流。
经常审查代码，可以及时发现问题，并且避免了最后一起检查需要花费长时间。
只审查少量代码，一两个审查人员，经常审查，不审查不发布
5、代码变更时，需要向团队发送代码变更通知。可以让大家看到你的工作，同时也能让别人了解你改了什么，如果他有更好的方法，则可以提出来。
用电子邮件发布，列出审查人员名字，列出代码改变目的，写出差异部分
第四章 曳光弹开发
1、曳光弹开发（TBD），是软件开发的一种方式。将软件进行分层，将不同的层之间用接口进行通信。将不同层分配给不同的人做。有点类似于MVC（模式-视图-控制）。
2、总线数
指只有当损失的人员达到这个数，项目才会失败。一般要尽量增大总线数。曳光弹开发是增加总线数的方法，相邻两层的人员知道对方的操作，必要时可以替代。避免了“大牛”的存在。
第五章 其他问题
1、当你提交了一个作品时，别人运行时出现了问题，而你没有。这个时候你不能争辩，毕竟客户只关心他使用的时候有没有问题。你需要找出原因，选择是自己修复代码问题，还是委婉的向客户提出要修改他的配置。
2、如果要使客户满意，就要经常向他演示原型系统，这样他也会随时给你提出意见，不要等到最后客户才说不满意。
3、遇到另类的不服管教的开发人员，记录他们的所作所为，然后以不服管理为由将其辞退。
4、怎么让你的经理满意
使用任务清单，并且请经理提出意见，并一起商量优先级。让经理掌握你的进度，可以以邮件的形式，或者每日的报告。报告中不要说很多，只要说结果。如果确实需要说明详细过程，可以用两分，一个简单，一个详细。
5、作为一个经理，必须要有自己的威信，采用各种方式得到团队认可，推进实践。
一个船长如果翻过船，将很难再受命上船
第六章 建议阅读的书
1、精通正则表达式
2、人月神话
3、死亡之旅
4、Programming Ruby 中文版
5、应用极限编程：积极求胜 （XP）
6、敏捷软件开发：使用SCRUM过程
7、版本控制之道：SubVersion/CVS
8、领导力21法则
9、高效能士的七个习惯
10、人性的弱点
11、人件
原文：http://www.cnblogs.com/ren-jie/p/5296839.html