作者：Alistair Cockburn
0 不可知和不可说
“完美的沟通是不可能的。”
0.1 解析模式
《画杨桃》
0.2 沟通的不可能性
扬扬眉毛所包含的信息是什么？
1963，香农，信息论，有约束的通道，沟通的语汇表。但真实世界的沟通没有约束。
0.2.1 内部重新组织
信息传递过程中，接收者接触到的信息模式不断变化，会触发重新组织。
0.2.2 触及共享体验
需要确认接收者正确接收并且理解了你的意图。
长期公事的人会形成共同的语汇、共享的经验触点，在这个基础之上沟通起来效率会很高。
0.2.3 管理不完美沟通
接收者与你差别越大，他能越过的沟通鸿沟就越小。你不得不回过头去解释那些基本概念，再向前工作。
写书的时候不得不假设读者有了某种程度的经验。如果假设读者有更多经验，就可以少写一部分。
根据需要，并且只根据需要进行一些沟通，来填补和缩小与接收者的鸿沟。
0.3 聆听的三个层次
遵循（following）、突破（detaching）和流利（fluent）。
守 Shu 破 Ha 离 Ri。
第一层的人需要详细和具体的规则。
第二层的人需要某些可用的技术，以及他们的例子和注解。
第三层的人需要了解存在的问题以及适当的指导范围。
类似的例子我们来看一下敏捷：
敏捷宣言处在第三层，敏捷框架处在第二层，而极限编程、TDD、结对等具体的实践，处在第一层。
1 创造和沟通的合作博弈
1.3 合作博弈
软件开发是一个（有资源限制的）创造和沟通的合作博弈。博弈的目标是交付有用的、可工作的软件。次要目标，即博弈的积淀，是为下一轮博弈做好准备。下一轮博弈可能更改或替换系统，也可能创造一个相关的系统。
"Programming is a social activity"
1A.4 重建软件工程
1968年，NATO软件工程学会议上提出了“软件工程”这样一个词汇。
2 个人
2.2
需要关注的五种失败模式是，人会：
- 犯错误
- 即使失败也要选择保守
- 创新而不研究
- 成为习惯的动物
- 不能始终如一
2.2.1 犯错误
人都会犯错误，这也是为什么会发明迭代式和增量式的开发
这样可以通过渐进式地呈现整体系统的现状，在增量进行的过程中，团队成员会检查工作习惯、项目质量，从而发现一些可以改进的地方。可以随时更改团队结构、技术或者交付物。
经理们总是希望开发团队不要犯任何大错误，当然也不要从项目中学习到任何新东西。
我们必须接受错误这一事实，然后使用过程来纠正这些错误。
2.2.2 宁可失败也要选择保守
2.2.3 创新而不研究
Not Invented Here。
2.3 以一些更好的方式工作
2.3.1 具体化
2.3.2 实物
2.3.3 在某些东西的基础上进行修改
2.3.4 观察和聆听
2.3.5 支持专注和沟通
2.3.6 工作分配要与个性相配
2.3.7 天赋
2.3.8 奖励要能保留乐趣
2.3.9 组合奖励
2.3.10 反馈
2.4 利用成功模式
- 善用四处寻找
- 有学习能力
- 具有可塑性
- 以工作为自豪
- 以贡献为自豪
- 有良好的公民意识
- 具有主动精神
3 团队的沟通与合作
3.1
3.1.1 延迟和机会损失成本
下面情形中，项目的开发成本在依次升高：
- 两个人在同一台电脑前结对编程
- 两个人在不同的电脑前，但座位距离很近
- 两个人坐在房间的两侧，互相看不见脸
- 两个人坐在临近的办公室，中间隔着墙
- 两个人在不同的楼层或者相邻的大楼里
- 两个人在不同的城市
3.1.3 渗透式沟通
团队成员所交换的既有业务信息也有技术信息。
3.2
3.2.1 沟通的形态
- 物理上的接近
- 立体感
- 嗅觉
- 动觉
- 触觉
- 听觉
- 视觉
- 适时地形态交叉
- 低延迟时间
- 信任和学习
- 使用共享且持久的信息源辐射
3.2.2 去掉某些形态的影响
- 只去掉物理的接近 —— 仍然需要出差协调很多东西
- 去掉视觉（使用电话） —— 失去图示和表情，失去把语言和动作连接的能力
- 去掉声音（电子邮件） —— 失去音调变化，适时调节节奏和传输惊讶、厌烦或者一些显而易见的感觉
- 去掉提问的能力（但可能恢复了上面某一种形态） —— 发送者就必须猜测接收者知道什么，不知道什么，想问什么，还要想出对于猜测的问题，适当的答案是什么。所有这些都没有反馈。
- 最后，去掉每一种形态 —— 得到的就是……纸。所以文档可能是沟通效率最低的一种方式。
3.2.3 利用各种形态
用录像来归档文档
3.2.4 黏度与跨越空间的沟通
白板和纸张是特别好的静态信息辐射源，各方都可以在上面书写，从而使它们成为共享的、有黏度的信息辐射源。