敏捷教练第二章（二）

2.4 Building Agreement（建立共识）

当你作为新的参与者被介绍时，可以看出你是否被团队中的任何人接受。一些团队成员可能对这个变化很热心，但是有些人可能持怀疑态度。帮助揭示不同观点的技术是逐步的接受，可以从Facilitator’s Guide to Participatory Decision-Making中学习到

对于建议的行为，不是问团队成员一个简单的YES或者没有进行投票选举，从支持到阻塞，你可以建立一个阶梯级别。在一个活动挂图上画下来，然后让团队中的每一个人用标记来表明他们的支持度。这些使得你能够分出是全身心的“YES”还是冷淡的不关心，是强烈的支持，还是微弱的支持。

 

 

使用阶梯图能表明什么时候缺乏一致性。一致性非常重要，当有人不同意这个行为时，他们不可能热心的去执行它。有时，你可能认为，没有一致性也值得向前一试，在时间盒范围内的形成的变化，这个团队在下一个回顾时会重新进行评估其价值。但是，如果这个导致了很多消极的意见，要试着找出团队中每个人能够接受的新的解决办法。

Using Gradients of Agreementby Rachel使用阶梯共识

我在一个研讨会上，对测试方法使用阶梯共识。我了解到，团队中的开发人员使用结对编程，但是他们对自动化单元测试不是所有人都那么有热情。一些开发人员原因安装CI服务器，在check-in后进行自动化测试。我认为，不是团队所有人都支持这个。事实上，团队没有一套所有开发人员都能跑的测试框架。我画了一个梯形图，列了下面可以改变的目标，然后我让团队成员投票

A 自动化测试用应该每天运行

B自动化测试应该在check-in之前手动运行

C 自动化测试应该在check-in之后自动运行

团队中的成员都强烈支持观点A.然而，对于观点B和C是比较混杂的，表明他们还没有进行足够的操作。我们谈论了一些大家的关心点，主要是关于自动化测试的时间，然而，团队对观点A有一致性，所以会后的事情是，团队需要建立一个每日构建和测试例行化。

通过使用阶梯共识，我能看出团队最支持的观点，团队避免浪费时间安装大部分人不需要的软件。在团队准备开始使用CI进行自动化测试之前，已经花费数月了。

使用这个方法在团队中建立共识级别。如果你没有地方去画共识图，你可以使用1到5投票来代替画图，伸出一个手指头代表不同意、然后到5个手指头逐级代表更支持。不管你用什么方法来找出不同的建议，要认真地找出背后的原因。

2.5 Hurdles（障碍）

下面可能是你将会遇到的障碍

Emotional Outburst in a Meeting（会议上感情爆发）

如果有人在会议上由于冲突而导致情感爆发，建议你叫暂停，然后给他镇静下来的时间，使他们能恢复平静。在你暂停会议期间，花点时间去和这些人交流，是什么原因使得他们混乱。如果你决定继续开会，不要假装什么事情也没有发生。承认感情已经进入高潮，检查整个团队是否能继续会议，或者引起混乱的问题应该先被解决。

Liz Says. . .Don’t Put People in Boxes

有很多模型可以用来把人在水平上或者类型进行分类。模型是很有用的，帮助你决定如何有效地向团队展示信息。一个很好的开始是使用Dreyfus学习模型，Andy Hunt 在Pragmatic Thinking and Learning有介绍：RefactorYour Wetware

   还有其他的模型

Myers-Briggs types_

• Thomas-Kilmann conflict modes†

要注意不要只使用一种模型，这会阻碍你评估这个人的独特性和不同性。学习更多的模型，帮助你使用不同的方法看待同一个行为，让你有更好的方法去评估人的行为

 

Lack of People Skills

经常的，你会发现，在软件开发中的人，更喜欢自己工作，和别人交流起来很困难。察觉到，人们有不同的交流方法。你需要和这些人更直接的交流，给他们更多的空间。

Cultural Differences（文化差异）

在不同的文化中，不同的事情被认为是有礼貌的，举个例子，Liz是新西兰人，一些英国人认为她做事情太直接了。你可能会发现，在不同文化中长大的人，说YSE有不同的含义。有的说YSE是意味着：我在听这个事情，而不是意味着：是的，我已经明白了你说的话。一些风俗习惯可能会更感觉舒服，这些更容易被敏捷团队所采纳，反之，有一些可能非常明显的文化等级。

帮助团队更好地适应不同的文化，例如容忍模棱两可和个人主义。做好这些的一个方法是，和团队一起探讨文化的多维性。

2.6 Checklist（检查）

l  深入倾听、理解团队面临的问题，建立信任。对和你谈话的人，给予全部的关注，然后问一些问题，来检查你是否理解了他们所说的内容

l  当给予反馈的时候，把看到或者听到的和感觉到的分开。给一些你遇到的特定的例子，而不是给一些泛泛的说明。告诉他们你看到的或者听到的，然后问他们对于事情的解释。然后大家一起努力想处理下次遇到该问题要采取的主意，

l  如果冲突发生了，要确认所有的人都说出了自己的观点。不要介入去解决团队的每一个冲突，否则，他们可能会把你当做冲突调停人，而不是学习如何相处。

l  使用共识阶梯去揭露对于变化的支持度。这个会让团队找到是大多数不支持或者少数不支持