高效团队开发

出版者:人民邮电出版社

作者:［日］ 池田尚史

页数:320

译者:严圣逸

出版时间:2015-7

价格:49.00

装帧:平装

isbn号码:9787115295941

丛书系列:图灵程序设计丛书·程序员修炼系列

具体描述

本书以团队开发中所必需的工具的导入方法和使用方法为核心，对团队开发的整体结构进行概括性的说明。内容涉及团队开发中发生的问题、版本管理系统、缺陷管理系统、持续集成、持续交付以及回归测试，并且对“为什么用那个工具”“为什么要这样使用”等开发现场常有的问题进行举例说明。

本书适合初次接手开发团队的项目经理，计划开始新项目的项目经理、Scrum Master，以及现有项目中返工、延期问题频发的开发人员阅读。

作者简介

作者简介：

池田尚史

DeNA软件开发工程师。曾做过IT顾问、程序员，从事过软件包开发、Web服务开发。Java的Web应用框架Play Framework 1的提交者。负责本书第1章~第5章，其中第2章的案例分析都是基于自身的实际经验编写的。

Twitter　@ikeike443

藤仓和明

想能（SHANON）基础设施工程师。负责公司内部基础设施及服务环境的安全保障，致力于推动应用部署的自动化，并基于这方面丰富的实践经验，完成了本书第6章。喜欢OpenVZ、LXC等容器型虚拟化技术。

Twitter　@fujya

井上史彰

想能（SHANON）软件工程师、QA工程师，现为想能信息科技（上海）有限公司总经理。开发经验丰富，致力于推动高效的自动化测试。负责本书第7章。

E-mail　[e-mail]

译者简介：

严圣逸

毕业于上海交通大学。8年软件开发经验，期间赴日本工作。现就职于想能信息科技（上海）有限公司，从事基于云平台的客户关系管理及各类营销自动化系统的开发，侧重于对持续集成、自动化部署、自动化测试以及相关的开源工具的研究。本书所介绍的即是译者日常工作中所应用的开发流程以及工具。

目录信息

第1章　什么是团队开发　　1
1.1　一个人也能进行开发　　2
1.2　团队开发面临的问题　　3
1.3　如何解决这些问题　　4
1.4　本书的构成　　5
1.4.1　第2章：案例分析　　5
1.4.2　第3～5章：基础实践　　5
1.4.3　第6～7章：持续交付和回归测试　　6
1.5　阅读本书前的注意事项　　7
1.5.1　最好的方法是具体问题具体分析　　7
1.5.2　没有最好的工具　　7
第2章　团队开发中发生的问题　　9
2.1　案例分析的前提　　10
2.1.1　项目的前提条件　　10
2.2　案例分析（第1天）　　11
2.2.1　问题1：重要的邮件太多，无法确定处理的优先顺序　　11
2.2.2　问题2：没有能用于验证的环境　　11
2.2.3　问题3：用别名目录管理分支　　12
2.2.4　问题4：重新制作数据库比较困难　　14
2.3　案例分析（第1天）中的问题点　　16
2.3.1　问题1：重要的邮件太多，无法确定处理的优先顺序　　16
邮件的数量太多，导致重要的邮件被埋没　　16
无法进行状态管理　　17
直观性、检索性较弱　　17
用邮件来管理项目的课题　　17
2.3.2　问题2：没有能用于验证的环境　　18
2.3.3　问题3：用别名目录管理分支　　18
2.3.4　问题4：重新制作数据库比较困难　　19
2.4　案例分析（第2天）　　22
2.4.1　问题5：不运行系统就无法察觉问题　　22
2.4.2　问题6：覆盖了其他组员修正的代码　　22
2.4.3　问题7：无法自信地进行代码重构　　24
2.4.4　问题8：不知道bug的修正日期，也不能追踪退化　　25
2.4.5　问题9：没有灵活使用分支和标签　　26
2.4.6　问题10：在测试环境、正式环境上无法运行　　28
2.4.7　问题11：发布太复杂，以至于需要发布手册　　28
2.5　案例分析（第2天）中的问题点　　30
2.5.1　问题5：不运行系统就无法察觉问题　　30
2.5.2　问题6：覆盖了其他组员修正的代码　　31
2.5.3　问题7：无法自信地进行代码重构　　31
2.5.4　问题8：不知道bug的修正日期，也不能追踪退化　　33
2.5.5　问题9：没有灵活使用分支和标签　　35
2.5.6　问题10：在测试环境、正式环境上无法运行　　35
2.5.7　问题11：发布太复杂，以至于需要发布手册　　36
2.6　什么是理想的项目　　37
2.6.1　使用缺陷管理系统对课题等进行统筹管理　　38
2.6.2　尽量使用版本管理系统　　38
2.6.3　准备可以反复验证的CI系统　　38
2.6.4　将环境的影响控制在最小限度，并随时可以发布　　39
2.6.5　保留所有记录以便日后追踪　　39
2.7　本章总结　　40
第3章　版本管理　　41
3.1　版本管理系统　　42
3.1.1　什么是版本管理系统　　42
3.1.2　为什么使用版本管理系统能带来便利　　42
能够保留修改内容这一最基本的记录　　43
能够方便地查看版本之间的差异　　43
能够防止错误地覆盖他人修改的代码　　43
专栏　锁模式和合并模式 　　44
能够还原到任意时间点的状态　　48
专栏　基于文件和基于变更集 　　49
能够生成多个派生（分支和标签），保留当时项目状态的断面　　 49
3.2　版本管理系统的发展变迁　　51
3.2.1　没有版本管理系统的时代（20世纪70年代以前）　　52
3.2.2　RCS 的时代（20世纪80年代）　　52
3.2.3　CVS 的诞生（20世纪90年代）　　52
3.2.4　VSS、Perforce等商用工具的诞生（20 世纪90 年代）　　53
3.2.5　Subversion 的诞生（2000 年以后）　　54
3.2.6　分布式版本管理系统的诞生（2005 年以后）　　54
3.2.7　番外篇：GitHub的诞生　　55
3.2.8　版本管理系统的导入情况　　57
3.3　分布式版本管理系统　　59
3.3.1　使用分布式版本管理系统的5 大原因　　59
能将代码库完整地复制到本地　　59
运行速度快　　59
临时作业的提交易于管理　　59
分支、合并简单方便　　59
可以不受地点的限制进行协作开发　　60
3.3.2　分布式版本管理系统的缺点　　60
系统中没有真正意义上的最新版本　　60
没有真正意义上的版本号　　60
工作流程的配置过于灵活，容易产生混乱　　61
思维方式的习惯需要一定的时间　　61
3.4　如何使用版本管理系统　　62
3.4.1　前提　　62
3.4.2　版本管理系统管理的对象　　62
代码　　63
需求资料、设计资料等文档　　64
数据库模式、数据　　64
配置文件　　64
库的依赖关系定义　　65
3.5　使用Git顺利地推进并行开发　　66
3.5.1　分支的用法　　66
什么是分支　　66
什么是发布分支（release branch）　　66
克隆和建立分支　　67
提交和提交记录　　67
分支的切换　　68
修正bug后的提交　　69
合并到master　　70
向master进行Push　　71
分支使用方法总结　　72
3.5.2　标签的使用方法　　72
什么是标签　　72
新建标签　　72
标签的确认　　73
标签的取得　　73
专栏　避免使用相同的标签名和分支名 　　74
标签使用方法总结　　75
专栏　什么是Detached HEAD 　　76
3.6　Git的开发流程　　77
3.6.1　Git工作流的模式　　77
中央集权型工作流　　77
GitHub型工作流　　78
3.6.2　分支策略的模式　　79
git-flow　　79
github-flow　　82
笔者的例子（折衷方案）　　83
3.6.3　最合适的流程和分支策略因项目而异　　84
3.7　数据库模式和数据的管理　　85
3.7.1　需要对数据库模式进行管理的原因　　85
由数据库管理员负责对修改进行管理的情况 　　85
修改共享数据库的模式的情况 　　85
3.7.2　应该如何管理数据库模式　　86
版本管理的必要条件　　86
什么是数据库迁移　　86
数据库迁移的功能　　87
3.7.3　数据库迁移工具　　88
Migration（Ruby on Rails） 　　88
south（Django）　　88
Migrations Plugin（CakePHP）　　89
Evolution（Play Framework）　　89
3.7.4　具体用法（Evolution）　　89
规定　　89
SQL文件的执行　　90
开发者之间数据库模式的同步 　　91
一致性问题的管理　　93
3.7.5　数据库迁移中的注意点　　94
3.8　配置文件的管理　　96
3.9　依赖关系的管理　　97
3.9.1　依赖关系管理系统　　97
JVM 语言　　97
脚本语言　　98
管理依赖关系的优点　　98
3.10　本章总结　　100
第4章　缺陷管理　　101
4.1　缺陷管理系统　　102
4.1.1　项目进展不顺利的原因　　102
4.1.2　用纸、邮件、Excel进行任务管理时的问题　　103
4.1.3　导入缺陷管理系统的优点　　104
具有任务管理所需的基本功能　　104
直观性、检索性较强　　104
能够对信息进行统一管理及共享　　104
能够生成各类报表　　105
能够和其他系统进行关联，具有可扩展性　　105
4.1.4　什么是缺陷驱动开发　　106
缺陷驱动开发的具体步骤　　106
专栏　彻底贯彻缺陷驱动开发的情况 　　107
4.2　主要的缺陷管理系统　　108
4.2.1　OSS产品　　108
Trac　　108
Redmine　　109
Bugzilla　　110
Mantis　　111
4.2.2　商用产品　　112
JIRA　　112
YouTRACK　　113
Pivotal Tracker　　113
Backlog　　114
GitHub　　115
4.2.3　选择工具（缺陷管理系统）的要点　　116
专栏　缺陷管理系统的应用事例 　　117
4.3　缺陷管理系统与版本管理系统的关联　　118
4.3.1　通过关联实现的功能　　118
从提交链接到问题票　　118
从问题票链接到提交　　118
提交的同时修改问题票的状态　　119
4.3.2　关联的配置方法　　119
4.3.3　GitHub　　119
GitHub的issue　　119
Service Hooks　　120
GitHub和Pivotal Tracker的关联　　121
GitHub和JIRA的关联　　123
4.3.4　Trac/Redmine　　124
4.3.5　Backlog　　124
Backlog和Git的关联　　125
Backlog和GitHub的关联　　126
4.3.6　Git自带的Hook的使用方法　　127
4.4　新功能开发、修改bug时的工作流程　　128
4.4.1　工作流程　　128
A建立问题票　　128
B指定负责人　　129
C开发　　129
D提交　　129
E Push到代码库　　129
4.5　回答“那个bug是什么时候修正的”的问题　　 131
4.5.1　Pivotal Tracker的例子　　131
用记忆中残留的关键字进行检索　　131
检索　　131
通过问题票查找代码修改　　132
4.5.2　Backlog的例子　　133
检索　　134
4.6　回答“为什么要这样修改”的问题　　136
4.7　本章总结　　137
专栏　缺陷管理、bug 管理以及需求管理 　　137
第5章　CI（持续集成）　　141
5.1　CI（持续集成）　　142
5.1.1　什么是CI（持续集成）　　142
集成（integration）　　142
持续地进行集成就是CI　　142
5.1.2　使开发敏捷化　　143
瀑布式开发的开发阶段　　143
敏捷开发的开发阶段　　144
5.1.3　为什么要进行CI 这样的实践　　147
成本效益　　147
市场变化的速度　　148
兼顾开发速度和质量　　148
5.1.4　CI的必要条件　　149
版本管理系统　　149
build 工具　　149
测试代码　　151
CI 工具　　151
5.1.5　编写测试代码所需的框架　　151
测试驱动开发（TDD）的框架　　151
行为驱动开发（BDD）的框架　　152
5.1.6　主要的CI 工具　　154
Jenkins　　154
TravisCI　　155
5.2　build工具的使用方法　　157
5.2.1　新建工程的情况　　157
建立工程雏形　　158
依赖关系的定义　　160
执行测试　　161
导入Eclipse　　162
5.2.2　为已有工程添加自动build 功能　　162
5.2.3　build工具的总结　　163
5.3　测试代码的写法　　164
5.3.1　作为CI的对象的测试的种类　　164
5.3.2　何时编写测试　　165
新建工程的情况　　165
已有工程中没有测试的情况　　165
修改bug或添加新功能的情况　　166
5.3.3　棘手的测试该如何写　　166
和外部系统有交互的测试　　166
使用mocking框架进行测试　　167
使用内存数据库进行测试　　168
数据库变更管理和配置文件管理的测试　　169
UI 相关的测试　　169
棘手的测试要权衡工数　　170
5.4　执行基于Jenkins 的CI　　171
5.4.1　Jenkins的安装　　171
使用本地安装包进行安装　　172
5.4.2　Jenkins能干些什么　　172
5.4.3　新建任务　　173
5.4.4　下载代码　　173
5.4.5　自动执行build 和测试　　175
定期执行　　175
轮询版本管理系统　　175
专栏　 从版本管理系统进行Push 　　176
build 的记述　　177
5.4.6　统计结果并生成报表　　178
专栏　以JUnitXML 的形式输出报表比较高效 　　179
5.4.7　统计覆盖率　　179
覆盖率统计工具　　180
Maven Cobertura插件的安装　　180
专栏　Java 程序库的查找方法 　　182
Jenkins 插件的配置　　183
5.4.8　静态分析　　184
5.4.9　配置通知　　185
5.5　CI 的运用　　187
5.5.1　build 失败了该怎么办　　187
Subversion 等中央集权型版本管理系统的情况　　187
Git 等分布式管理系统的情况　　187
专栏　造成build 失败后的惩罚游戏 　　188
测试后合并　　189
5.5.2　确保可追溯性　　193
关联build 和提交　　193
关联缺陷管理　　194
5.6　本章总结——借助CI 能够实现的事　　198
第6章　部署的自动化（持续交付）　　199
6.1　应该如何部署　　200
6.1.1　部署自动化带来的好处　　200
细粒度、频繁地发布可以使风险可控　　200
能尽快地获得用户的反馈　　200
团队的规模可控　　201
6.2　部署的自动化　　202
6.2.1　部署自动化方面的共识　　202
6.2.2　部署流水线　　203
通过自动化加快部署速度　　204
任何人都能够实施部署是很重要的　　204
6.2.3　服务提供工具链（provisioning tool chain）　　204
6.3　引导（Bootstrapping）　　206
6.3.1　Kickstart　　206
Kickstart 的使用方法　　206
使用时的注意事项　　206
Kickstart 的配置示例　　207
6.3.2　Vagrant　　208
为每一位开发人员准备实体电脑比较困难　　208
使用虚拟机时的注意事项　　209
什么是Vagrant　　209
Vagrant的安装及运行方法　　209
6.4　配置（Configuration）　　212
6.4.1　不使用自动化时的问题　　212
6.4.2　Chef　　213
Chef的构成　　213
目录构成和文件配置　　215
node.json　　215
setup.json　　216
solo.rb　　216
default.rb　　217
virtualhost.conf.erb　　218
Chef的运行方法和运行结果　　218
使用Chef的优点　　219
使用Chef时的注意事项　　220
使用Chef的时间点　　220
6.4.3　serverspec　　221
什么是serverspec　　221
serverspec的安装　　221
测试文件的记述方式　　222
httpd_spec.rb　　222
git_spec.rb　　223
serverspec的执行方法及执行结果　　223
serverspec的优点　　224
6.4.4　最佳实践（其1）　　224
Vagrantfile　　226
default.rb　　227
6.4.5　最佳实践（其2）　　227
6.4.6　实现物理服务器投入运营为止的所有步骤的自动化　　229
6.5　编配（Orchestration）　　230
6.5.1　发布作业的反面教材　　230
6.5.2　Capistrano　　231
Capistrano的系统构成　　231
Capistrano的安装　　232
deploy.rb　　232
Capistrano 的执行方法　　233
6.5.3　Fabric　　233
Fabric（串行执行）的情况　　234
Capistrano（并行执行）的情况　　234
理解本地服务器和远程服务器操作上的区别　　234
Fabric的运行方法　　236
6.5.4　Jenkins　　237
主节点（master node）和从节点（slave node）的协作　　237
从节点的添加　　238
任务的添加　　240
任务的执行　　242
6.5.5　最佳实践　　243
结合Jenkins和Fabric　　243
6.5.6　考虑安全问题　　244
专栏　手动部署的例子 　　245
6.6　考虑运用相关的问题　　247
6.6.1　不中断服务的部署方法　　247
6.6.2　蓝绿部署（blue-green deployment）　　247
6.6.3　云（cloud）时代的蓝绿部署　　250
6.6.4　回滚（rollback）相关问题的考察　　251
随时准备好退路　　251
数据库模式的版本管理　　251
回滚的验证　　252
只更新代码的发布时的回滚　　252
数据库模式更新时的回滚　　253
6.7　本章总结　　255
专栏　PaaS的使用方式 　　255
第7章　回归测试　　259
7.1　回归测试　　260
7.1.1　什么是回归测试　　260
7.1.2　测试分类的整理　　261
支持团队的技术层面的测试（第1 象限）　　262
支持团队的业务层面的测试（第2 象限）　　262
评价产品的业务层面的测试（第3象限）　　262
使用技术层面测试的产品评价（第4象限）　　263
7.1.3　回归测试的必要性　　263
退化（degrade）的发生　　263
应该实现自动测试的原因　　263
7.1.4　回归测试自动化的目标　　265
7.2　Selenium　　266
7.2.1　什么是Selenium　　266
7.2.2　Selenium的优点　　266
自动化测试用例制作简单　　266
支持多种浏览器及OS　　266
7.2.3　Selenium的组件　　267
Selenium IDE　　267
Selenium Remote Control（Selenium RC）　　268
Selenium WebDriver　　269
7.2.4　测试用例的制作和执行　　271
Selemium IDE的安装和运行　　271
Selenium的测试用例　　271
什么是好的测试用例　　274
用Selenium Server来运行测试　　274
7.2.5　Selenium的实际应用　　276
测试页面是否有改动　　276
使Selenium测试稳定运行　　278
7.3　Jenkins和Selenium的协作　　282
7.3.1　关联Jenkins和Selenium的步骤　　282
7.4　Selenium测试的高速化　　287
7.4.1　利用Jenkins的分布式构建实现测试的并行执行　　288
Jenkins的分布式构建的构成　　288
分布式构建的配置　　289
7.4.2　Selenium测试并行化中的难点　　291
7.5　多个应用程序版本的测试　　295
7.5.1　应用的部署　　296
7.5.2　从版本管理系统下载测试用例　　296
7.5.3　用Selenium测试　　296
· · · · · · (收起)

读后感

书很赞, 文笔流畅, 逻辑很顺, 把 Rails 开发中工程化的东西讲得很清楚. 不过, 部分读者可能觉得太理想化, 比如没写过 Unit Test 的 Java 开发同学. 有些地方更详细一点就好了, 例如作者自己提出的 git 模型. 我到现在都不确定自己真正理解了作者的意思.

书很赞, 文笔流畅, 逻辑很顺, 把 Rails 开发中工程化的东西讲得很清楚. 不过, 部分读者可能觉得太理想化, 比如没写过 Unit Test 的 Java 开发同学. 有些地方更详细一点就好了, 例如作者自己提出的 git 模型. 我到现在都不确定自己真正理解了作者的意思.

书很赞, 文笔流畅, 逻辑很顺, 把 Rails 开发中工程化的东西讲得很清楚. 不过, 部分读者可能觉得太理想化, 比如没写过 Unit Test 的 Java 开发同学. 有些地方更详细一点就好了, 例如作者自己提出的 git 模型. 我到现在都不确定自己真正理解了作者的意思.

书很赞, 文笔流畅, 逻辑很顺, 把 Rails 开发中工程化的东西讲得很清楚. 不过, 部分读者可能觉得太理想化, 比如没写过 Unit Test 的 Java 开发同学. 有些地方更详细一点就好了, 例如作者自己提出的 git 模型. 我到现在都不确定自己真正理解了作者的意思.

书很赞, 文笔流畅, 逻辑很顺, 把 Rails 开发中工程化的东西讲得很清楚. 不过, 部分读者可能觉得太理想化, 比如没写过 Unit Test 的 Java 开发同学. 有些地方更详细一点就好了, 例如作者自己提出的 git 模型. 我到现在都不确定自己真正理解了作者的意思.

用户评价

这是一本带有强烈个人色彩和批判精神的作品，它似乎是作者对过去十年软件开发行业中大量无效“团队建设”活动的集体反思。书中对于诸如“团建活动”、“强制性的每日站会”等现象进行了犀利的解构，指出许多被奉为圭臬的实践，如果脱离了实际的工作场景和文化背景，只会成为徒增负担的仪式。作者的写作风格非常具有煽动性，他用大量尖锐的提问引导读者去质疑既定的流程。比如，他问：“你的每日站会真的在同步信息，还是只是在让最内向的人感到压力？”这种直击痛点的提问方式，使得阅读体验充满了一种“被挑战”的感觉。书中对“信任的量化”这一概念的阐述尤为精妙，作者认为信任不是一个模糊的形容词，而是可以通过团队成员对承诺的履行程度、对错误的坦诚度等指标来间接衡量的。对我来说，这本书的价值不在于它提供了具体的“怎么做”的步骤，而在于它教会了我“为什么要做”以及“为什么有些事情不做比做了更好”。它更适合那些厌倦了表面功夫、渴望从根本上重塑团队工作方式的领导者。

这本书的叙事风格非常独特，它更像是一本由资深项目总监撰写的、充满行业内幕的深度访谈录，而非传统意义上的理论书籍。作者似乎是从他过去几十年管理失败和成功的经验中提炼出来的血泪教训，语言直白且不加修饰，充满了真实的案例和令人拍案叫绝的洞察。我尤其欣赏其中关于“跨职能协作”的部分，它并没有停留在传统的流程图讲解上，而是聚焦于“权力结构”如何影响信息传递的速度。书中有一个案例，描述了一个看似完美的分工协作小组，最终因为高层对不同部门的KPI设置不一致，导致资源争夺和内耗，最终项目延期。这个例子让我醍醐灌顶，明白了技术层面的优化往往抵不过组织架构上的微妙失衡。这本书的行文节奏把握得很好，时不时穿插一些幽默的自嘲和对行业内流行的“敏捷神话”的批判，读起来一点也不枯燥。它要求读者有一定的行业背景知识才能完全领会其中的精髓，对于刚入行的新人来说，可能需要结合其他入门书籍一起阅读，但对于中高层管理者而言，这无疑是一剂强效的清醒剂，能帮你重新审视那些你习以为常的“最佳实践”是否真的适合你的团队。

我发现这本书在探讨“技术债务”与“团队士气”之间的关系时，展现出了极为细腻的笔触。很多关于团队效率的书籍都集中在如何管理任务和时间，但《高效团队开发》却将视角拉回到代码库的健康状态和架构的清晰度，并将其与工程师的日常满意度紧密挂钩。作者提出一个颇具争议性的观点：一个充满技术债务的项目，其团队的“心智负担”远高于加班本身带来的疲惫。书中详述了“修复型工作”如何不断侵蚀团队的创新时间，并提供了一套基于“价值流管理”的视角来识别和优先处理这些债务。这种跨学科的融合让人耳目一新。此外，书中对“异步沟通”的推崇也值得关注，作者详细对比了同步会议的隐性成本，并给出了一套非常实用的工具栈和文化建设指南，用以支撑一个主要依赖书面和记录的沟通模式。总体而言，这本书的深度在于它敢于触碰那些常常被管理者忽视的、与“工程实践”紧密相连的“软性”问题，是技术管理者提升团队“内功”的必备读物。

这本书的结构布局非常严谨，采用了“问题提出—理论剖析—实证研究—实践案例”的经典学术论证模式，但行文却保持了极高的可读性和流畅性，可以说是理论深度与实践指导之间达到了一个微妙的平衡点。它对“高效”的定义进行了重构，不再局限于交付速度，而是强调了“可持续的交付能力”。书中引用了大量来自不同行业（包括制造业、金融业和高科技领域）的案例研究，这极大地拓宽了我的视野，让我意识到团队协作的普适性原则。最让我印象深刻的是关于“知识共享机制”的章节，作者没有推荐昂贵的企业知识库软件，而是重点阐述了如何通过设计工作流程本身来自然地促进知识沉淀，比如如何将“代码审查”转化为“导师辅导”的环节。对于那些需要向更高层级汇报团队效率和产出的人来说，这本书提供了丰富的、有数据支撑的论据来证明投资于团队健康和技术基础的重要性。它不是一本轻松的读物，需要一定的专注度来消化其中复杂的模型，但其带来的长期回报是毋庸置疑的，它提供的是一套系统性的思维框架，帮助你构建一个能够自我修正、自我优化的组织实体。

拿到这本《高效团队开发》时，我满心期待能找到一些立竿见影的工具和技巧，毕竟现在项目节奏越来越快，如何让团队协作更顺畅是所有管理者头疼的问题。然而，这本书给我的感觉，更像是一次深入的哲学探讨，而不是一本操作手册。它花了大量的篇幅去探讨“什么是真正的协作”，而不是“如何进行协作”。书中引入了许多关于组织行为学和心理学的前沿理论，比如“心理安全感”的构建，以及不同沟通模式对团队绩效的隐性影响。我发现作者对“冲突管理”的论述尤其深刻，他没有简单地将冲突视为负面因素，而是将其视为团队成长的催化剂，强调了高质量的、建设性的争论对于创新至关uating的重要性。阅读过程中，我不得不频繁地停下来，对照我目前团队的实际情况进行反思。比如，书中提到，很多团队的低效并非源于技能不足，而是因为团队成员之间存在着“默认的假设”，这些假设阻碍了信息的自由流动。这本书的优点在于其广博的视野，它帮你搭建了一个宏观的认知框架，让你跳出日常琐碎的会议和邮件往来，去审视团队文化的根基。但坦白说，对于那些急需在下周一的站会上立刻应用新方法的读者来说，这本书可能显得有些“虚”了，它更多地是提供了一张地图，而不是具体的驾驶路线。

head-first风格很好的书，满满的一线经验．就是感觉作者花了太多笔墨写之前的CVS,现在的话应该是标配了吧

明了

软件开发团队方法和工具科普类知识。

方方面面都讲到了，看完之后对这方面有更深刻的了解，同时作者还力图照顾到细节，虽然说这似乎不必要。

走马观花看了一遍，适合知识普及和工具选型。