Agile software development - the cooperative game - 笔记 - 3

本文是第三部分。

• 第一部分。
• 第二部分。

信息交换和流动

如果我们将软件开发活动看作是协作游戏，那么如果Kim知道一些Pat需要的信息，则项目的进度就取决于：

1. Pat需要花多少时间了解到Kim知道他想要的信息
2. Pat和Kim需要耗费多少时间和其它成本来完成对于信息的交流和转移

各种情况的开销

有六种不同的情况可以考量：

1. Kim和Pat在同一台计算机前做结对编程，这样的交互成本几乎为零。
2. Kim和Pat在相邻的位置上；Pat可以通过观察Kim知道他可能在找某些东西而他恰好知道 - 有一些发现问题的成本
3. Kim和Pat坐在两个背对的位置，只有Kim主动提出问题，否则Pat不可能知道他想要某些信息
4. Kim和Pat坐在一个有一堵墙隔开的相邻位置，Kim必须站起来，看看Pat是否在位置上，然后才能交互信息
5. Kim和Pat坐在不同的隔间，甚至不同的楼层，kim必须走过去看看，这时候Pat可能不在位置上！
6. Kim和Pat在不同的办公区或者不同的地方，他们的沟通和交互就很少能有效和及时

如果用需要花费的时间和精力为参考单位（ergo-seconds），那么上述不同情况的开销是递增的。项目成本的上升是和人们需要花费多少时间来理解彼此的想法是成正比的。

Osmotic Communication

写代码/阅读/学习的同事，我们随时提取周围环境中发生的谈话，利用背景噪音的模式，选取我们关心的内容随时参与讨论，对于不关心的则过滤出去。这种方式的沟通极大的降低了信息流动的成本。办公环境的部署过于分散可能有不提问题造成的潜在时间开销，信息传输的开销和人们无法在谈话中随时给出意见的额外开销。根据此理论，赞助物理分散的分布式团队需要三思而行。然而简单将所有人扔在一起也未必像相像的那样可以很好的解决问题。

人们在传递什么样的信息？团队个人的习惯偏好如何？不同种类的信息是否会相互干扰？很常见的做法是，将负责实现的程序员安排在大楼的一侧，而将负责需求分析和商业策略领域专家安排在另一侧；因为他们彼此讨论的话题往往形成很强的噪音。然而这种方式也有明显的问题：

1. 两者之间沟通的成本变高
2. 两个团体可能形成自己小的社区并进而对对方进行指责和抱怨

Cockburn的偏好是将一个商业专家安排在几个程序员的中间；如果做不到，那么通过其它的方式加强他们之间的沟通和理解，譬如定期的会议，审查等。Feature team的做法是鼓励跨只能的团队，用Feature的方式将各个领域的人聚集在一个团队，减少信息沟通的成本，加快信息的流动。

个人偏好也是个需要考虑的问题，譬如有的程序员就是喜欢自己安静的空间，不希望有很多的背景噪音干扰。还有些人对哪些人在自己的周围有强烈的偏好 - 如果某个高级的程序员由此选择离开，那么成本之高就变得无法接受。因此调整位置的时候，需要尽量考虑到个人的偏好。

信息辐射器

信息辐射器可以显示任何一个路过的人都可以看到的关于项目的信息；这样他们就不会专门跑过来问某些上面已经有的信息。这样做的好处有两点：

1. 辐射器上的信息总是随着时间的变化在实时更新
2. 人们花费很少的精力就可以注意到这些信息

白板墙可以作为很好的信息辐射器，而公共的Wiki或者Web页面就不是；因为人们不用什么力气就可以随时看到墙上的东西，而web页面需要人们动鼠标打开那个网址。

人们可以用辐射器显示：

1. 下个迭代的任务分解情况
2. 每天的任务完成进度情况 - burndown chart等
3. 自动化测试通过情况和通过率
4. 回顾会议的输出
5. 验收测试通过情况

热空气理论应用

很多公司都意识到在咖啡机旁边放一些白板或者宣传栏的益处。人们可以在停下来聊天的时候注意到这些公开的信息。但是还有一个重要的地方不能漏掉的是，我们要尽量确保这些东西在视线之内，或者可以被清晰的听到。人们在讨论某些东西的时候，可以在身边随手可得的白板上写下自己的设计思路和想法，快速的和对方沟通。

任何一个项目团队都应该力求减少发现和传递信息的整体开销。这意味着随时发现并加速信息的流动和交换，利用Osmotic Communication的好处，注意潜在的问题和限制，最终减少成员之间信息交换的成本，搬开座位安置不合理造成的障碍。

跨越沟通交流的沟壑

为了提高沟通的效率，我们需要提高信息的发送方和接受方在可能存在沟通障碍的时候能够尽最大的可能跳过这些障碍的可能性。双方应该能以最快速方便的方式提供反馈，并尽可能地消除可能存在的希望表达的意识偏差。人们在沟通的时候，很可能使用语言之外的其它方式来表述意图(可能是积极的但也可能是消极的负面反馈)，如

• 距离上的疏远或者靠近
• 空间感觉和反应(视频聊天就在这方面缺失了空间信息)
• 人身上的体味对方是否习惯或者反感
• 肢体上的接触
• 声音语调的变化
• 肢体语言
• 提问回答的热情程度
• 是否有其它方面的干扰
• 相互之间的信任和愿意从对方学习的情绪
• 是否使用共享的信息辐射器来共享常见的信息

上边这些因素和机制利用得当能够极大的提高沟通的效率。反之，移除其中一些，人们就不得不用

• 电话 - 无法从物理上解除对方
• 电子邮件 - 没有声音
• 单向的沟通

如果这些机制都没有被很好的利用，就会出现文档作为沟通的主要方式。因而好的项目领头人会推荐如下这些实践：

• 将所有人丢在一个会议室里边
• 保持每个团队的短小精干
• 多用白板表述意图，而不是负责的绘图软件
• 办公区的白板和咖啡角随处易得

当然这些warmmer communication方式仅仅使用于传递想法和真正沟通的时候。传统的cooler communication方式仍然在其它一些场合发挥着重要作用。如果一个高级设计人员在会议中始终占据着发言权和白板，那么系统自组织性的丧失就会很快让沟通变得更加的困难。邮件的允许人们发送之前仔细审视的特点更容易让人们澄清他们真正表述的观点 - 如果这些观点需要慎重的思考的话。

团队即社区

一个团队即时一个社区，每时每刻都有很多信息在流动；但是每个团队个体成员可能有不同的兴趣和目标，有自己的专长和侧重。在一个高效的团队中，成员通过pull的方式提取自己感兴趣的信息，反馈给其它成员。人们根据整个团队的方向来协调这些信息的讨论和流动；因此整个团队需要保持一致的方向。

小幅度改进

只需要让每个人改变一个小小的方面 - 这些方面很可能对他个人而言是无足轻重的，最终也可以带来很大的整体效应；因为每个人都向着共同的目标改进一小点，所以每个人对变化的感受都是很细微的，但是因为人们对其它密切相关的同事贡献出他自己的想法，而不是各干各的，最终整个团队的效率会得到巨大的提升。

为了达到真个团队大方向上的一致，开发人员和项目利益相关人需要讨论和定制每个成员都需要认可的整体决策，这也同时要求很多决定必须是团队整体的承诺而不是经理们的个人意愿。在项目发展的过程中，优先级可能发生巨大的变化或者调整，这个时候，所有人必须被重新集中起来沟通这些变化，确保所有人都知道并且同意这个变化。

冲突和纪律

团队保持紧密一致不意味着不能有冲突发生。一个团队中几乎没有冲突发生也是不正常的，因为这很可能意味着大家可能更愿意保持沉默不再说出自己的真正想法。当人们向团队中的其他人掩盖一些信息的时候，潜在的开支就默默地急剧上升。人们需要在正常的冲突中讨论出最优的方案使得各方一致满意；这样的结果恰恰是更有利于最终问题的解决。

良好的社区纪律需要人们用对他人有益（当然间接对自己有益）的方式来共事。它需要成员

1. 按时参加会议
2. 回答别人提出的问题，如果知道答案的话
3. 不烦于提出注意到的状况
4. 遵从整体的编码规范/传统
5. 使用一致的代码库

这些要求对一些编码规范不满的程序员通过协商的方式定制出共同认可的编程风格 - 虽然个人可能不认可当前的规范，但是通过协商得到稍微看得过去的规范也比完全没有强。当然，这些纪律需要尽可能在正常的工作时间内实施，而不是通过加班来延长工作时间。

团队建设

好的团队建设最好的方式是通过一些小小的成功来实施，不管是多小或者多大的成功。混乱的大规模团队建设活动在很多情况下可能仅仅是浪费钱财。真正的团队建设可以通过

1. 使团队正在凝聚在一起 - 譬如让物理上分散的团队能尽量经常见面，通过共同的工作取得一些进展，然后不时将这些人放在一些社交活动中。
2. 产生成绩 - 这样可以产生和传递正能量，消除恐惧和不信任感。

团队文化背景差异和协作

团队的沟通和交互需要更多的采取协作而非合作的形式。协作意味着人们通过频繁的交互和沟通达成一致意见，而合作则意味着通过分工/各自独立工作/集成的方式来达成目标。不同的文化背景可能对这些方面有不同的假设前提，不过敏捷方法论的做法是尽可能得通过协商达成一致。

具有多个领域特长的专家（譬如精于项目管理和设计倾听的程序员）可以在不同的对象之间充当翻译，以便提高不同的专业人员之间的沟通效率。每一个人都需要更多的联系实践和倾听的技巧：不管对方的看法多么的疯狂和颠覆，先那样听，然后再决定是否要反对，因为那些疯狂的论断可能在另外一个价值体系里边确实司空见惯的常识。

视团队为生态系统

一个软件项目的建立同时也创建了一个新的生态系统，这个系统由特质各异/文化背景相左的个体组成。观察这个生同系统的要素，我们可以得到

• 办公室的墙壁成为隔离的壁垒，公共的空间提供交互场所
• 特性各异的个体好比不同的物种
• 每一个具有不同特性的个体的工作方式极大得影响着整个生态系统

每一个项目团队都是独一无二的，原则上并没有太具体的原则和实践可以误差别地施加于你的团队。

• 只有团队中的人才可以决定什么样的方式在那个特定的环境中工作的更好 - 调整环境来服务你的团队
• 如果团队中一些人有很好的方法学知识，他就能很好的回顾和反思他观察的并逐步改进 - 发现每个人的长处，找到一个最好的方式以便发挥各自的优势
• 视每个团队的方法实践为一种新的建设，没有一种现有的办法可以不经修改完全适用

关键的团队自身需要通过不断的反思来自适应，逐步改进工作的方法，并逐渐找到更优的方式。

Ken Auer的程序员办公室

这是一种典型的值得参考的办公环境：

• 一个大的用于编程的房间，中间是结对编码区域，四个长桌子围成长方形，人环座四周，长的一侧的桌子允许两对人工作，短的一侧允许一对，这样可以容纳最多12个人结对
• 编程办公室的四周靠墙壁的地方放置用于私人空间的编程工作 - 人们可以再这里创建私有的空间来做一些不受打扰的思考工作
• 编程办公室的南边是接待室和销售人员办公室，设备和浴室也在这一块儿空间；接待室在中间相隔，实现动静分离
• 编程办公室的西边是厨房和与之相隔的更远一点的会议室
• 西南是图书馆和客户办公室，图书馆在中间做一个动静分隔的作用

待续。