敏捷团队：去除隔阂 增进沟通

                      敏捷团队：去除隔阂 增进沟通

敏捷的“自组织团队”模式需要团队成员们具备新的技能——包括他们曾寄希望于项目经理具备的人际交往技能。对于正处于向“自组织”转变之中的团队来说，管理对帮助团队学习新的沟通和协作方式起到了非常重要的作用。但是要从何处开始呢？在不影响团队自组织转变过程的前提下，本文就如何传授新的技巧给出了一些策略，并提供了一些相关资源和材料，来帮助大家学习、开发新的技能。 

“很明显，这些就是开发软件的人……而且他们被忽略了。”
——Alistair Cockburn在《敏捷软件开发》一书中引用Gerald M. Weinberg的话。

 

敏捷对团队提出更高要求

对于将程序员视为难以沟通的一类人这样错误的陈词滥调，作者Alistair Cockburn提出了质疑，并说道：“程序员只不过是愿意就他们喜欢沟通的东西进行沟通，通常是他们正在开发的程序……他们不喜欢就自己不关心的东西闲聊。”而敏捷不同的是，它强调跨职能的团队构成和面对面的沟通，这会大大扩展与一名开发人员工作效率“相关”的、也是其所关心的范畴。

 

现在，除了保证所开发程序的优秀之外，开发人员必须要会使用客户的业务术语，要能理解与他们同处一室的团队成员的身体语言，还要学着给出建设性的反馈，并能与多种不同性格的人进行结对编程。敏捷的巨大效用，除了归功于生产效率的提升之外，还来自于成员在团队内外处理复杂人际关系的同时，仍能保证工作富有成效。

无论是比喻方式或者（最好是）真正的矮墙隔间，一旦它被去除，我们就不能再躲藏起来，等待经理、业务分析师，或者是技术写手来处理“人的因素”了。要想达到高生产率，团队必须进行自我管理，意味着要把人际交往，即所谓的“软”技能，逐步融入到团队的日常工作中。

我们应该训练谁？

人们很容易认为这样的训练应该让团队中更加成熟的成员、以职能更偏向“业务能力”的角色参加。其实不应该是这样的。在敏捷面前，大家一律平等：所有成员对团队产品成果的贡献相同；同样地，团队有可能被任何成员的行为影响或限制。Scrum实践者、教练Simon Baker提醒我们：单单编程的行为也是“一种社会活动，一次对话”，而且它会从人际技能的提升中受益：

对于成功的结对编程来说，高效的软技能与技术能力同样重要。进行结对的每个人都要能体察另外一个人的情绪变化，认真倾听并阅读他的身体语言；要能够表达自己的想法，并以建设性的方式表示不同意见，在不进行道德判断或倨傲不恭的前提下去说服别人；能够知道何时提供帮助，在寻求帮助时也保持谦虚的态度。有许多程序员在这些软技能上面备受困扰，真是遗憾。

那么，我们该如何修正我们的团队？

那么经理现在是不是应该接过“修正”团队和团队成员的重担呢？是不是每个人都必须把每件事做好？我们是不是应该训练每个人都可以承担所有的角色？对于自组织团队来说，这样的干涉反而会影响他们对新范式的采纳。要想让团队真正高效，教练的姿态也许更加合适：帮助团队判断他们应该如何分配工作，让谁接受多种职能角色的培训。目标不是要让大家的技能水平达成一致，而是为了提升效率，以及在给定上下文之中如何达到最高效率。对于跨职能培训，一位程序员这样写道：

我不同意改进弱点这样的论述，我更喜欢加强天分和了解弱点这样的说法。“了解你自己”并不意味着要学习所有的知识并让自己成为一把全能的“瑞士军刀”。

提出 “通才专家（generalising specialist）”一词的Scott Ambler表示了相同意见：

一个通才专家不只是一个通才（generalist）。通才只不过是个万事通，但是没有专长；而通才专家除了万事通之外，还精通其中一些学问或技能。二者差距很大。

传统上，培训计划隶属于绩效目标的一部分，以拓宽每个团队成员的知识面。但是实际上这些培训计划很少能够实现，而且管理层也无法提前准确猜测团队在未来的一年中需要什么样的技能。针对目前现实的情形展开培训会更加有效——但是一个经理怎样才能根据一些临时情况来知道团队需要什么样的资源和帮助呢？下面就提供了一个起点：让团队自己找到自己的短板

帮助团队寻找问题解决之道

帮助团队学习他们所需技能的一种方式，是鼓励他们发现阻碍前进之物，并支持他们寻找解决方案。对改进沟通方式的寻找应被视为一种实验，其他团体应用的流程改进措施也应如此：尝试，反思，学习，再次尝试。提供可以加速学习的材料：杂志、书籍、文章和播客录音等等。不过不要忘记时间也是资源：为他们提供指导、会议、上网的时间，或者让他们访问其他团队以找到解决方法，或者在接下来的迭代中添加一个“学习”任务。在寻找针对阻碍价值产生的问题之解决方案时，通过实际应用找到的解决之道，团队可以马上从学习中受益，这也是让培训起作用的极佳方式。

如果真的有效，团队自己的持续改进活动会产生一些需求，甚至能够给出一些策略上的建议。Esther Derby和Diana Larson的《Agile Retrospective： Making Good Teams Great》一书可以帮助团队开发这个很有价值的实践。

不过要注意：这种反应方式，需要团队具备发现问题、坦诚交流，以及知道去何处寻求帮助的能力。一个没有经验的团队可能会在一个重要的“人际问题”上受到羁绊，却仅将其视为一般的麻烦，而且无视其提出的警告。而且，在压力之下，当问题发生时，他们可能无法处于寻找答案的最佳状态，而是转而继续旧有的行为习惯。对一些团队来说，下面这些策略应该会有帮助。

形成解决问题的新方式

刚从隔间走出来的团队，如何以建设性和协作的方式开会的技能可能是他们最缺乏的。不妨带入一个外面的推进者，或者在团队内部找一个有天分的人，把他们训练成为ScrumMaster或是推进者。一个指定的推进者可以将团队从挫败感中带出，并找到解决方案。推进者要不偏不倚，并且不加入到团队的争执之中——他或她可以鼓励团队以更客观的方式来看待自己的人际交往问题，并将其视为团队成长过程的一部分。

推进过程可以让一些困难的交谈为人们所接受，并找出新的方式来进行交互和问题解决过程。例如：新的推进者经常只愿意待在不产生冲突的环境中，流连于团队内部，而忘记了要与利益相关者和团队以外的其他人彼此的期望值达成一致。又例如：一个外部的推进者可以帮助一个学徒试着与会议或是项目的发起人面谈，并与他们达成协议，保证所有的参与者都能将注意力置于真正的目标之上，并让团队以成功为导向。

团队成员倾向于从观察中学习来推进实践——他们还有可能要求进行培训。根据团队和所在环境的稳定性，这种推进可能是一个短期的过程，当团队逐渐进入自我推进的过程后，推进者就可以担负其他责任了。有时，一个新的“推进者”角色会为整个部门服务，开始训练其他推进者，或者在出现问题或隔阂时主持回顾活动，在像惠普和西门子这样的大型企业中就是这么做的。敏捷软件社区中有一些成员，包括Ainsley Nies，Diana Larsen和Esther Derby，他们都有从事类似活动丰富的经验，可以帮助其他人完成推进过程。

为何要等到问题出现之时？

在研究过很多成功的团队之后，Alistair Cockburn发现——暂时忽视人们的弱点——有三样东西我们可以一直指望：

1. 人们通常愿意成为“好公民”，
2. 人们喜欢采取主动，而且
3. 人们善于四处眺望

即使在问题出现之前，也要让团队成员知道人际沟通技能与编程技能同样重要。接下来，静静观察团队房间中发生的一切，倾听回顾会议中传递出来的声音——要记得有些团队要用稍长的时间来面对麻烦的问题，所以他们不只需要鼓励，还要有持续的支持。

要注意对小组动态或政治问题敏感的团队成员。可能有人只要“抬头观望”就能知道团队现在需要什么，有人像个好公民一样，承担提出关于人的问题的风险——这个人可能会让你感到讶异：“竟然是他！”。

例如：针对团队房间如何布置才能让每个人都全情投入，一个团队成员表示了他的担心。此时，经理可以为这个成员提供一些资源，让他有机会为团队的转变做出贡献，而不是经理自己来研究并进行改变。对于这个例子来说，Cockburn的书《敏捷软件开发》提供了一些关于如何让团队房间起作用的理论——还包括应该避免什么。下面是一种指导的方式：买两本此书，给那位成员一本，并与他进行几次会面，讨论如何将其中的材料应用到团队的实际情况中。

通过以提问、指导、建议和提供资源等方式给予协助，经理可为团队提供帮助，而且不影响团队在自我管理方面逐渐增长的自信。

资源来自何方？

想在网上找到“供极客专用的软技能”是很难的。该使用什么样的关键字去针对上百万个没有相关主题的博客进行搜索呢？哪些解决方案与敏捷的方法可以兼容？在敏捷社区中，针对管理、沟通和推进过程的书籍开始出现，要注意像InfoQ.com/Agile，AgileJournal这些网站上的新闻资源，像ScrumDevelopment、ExtremeProgramming、LeanDevelopment、Agile Management和LeanAgileScrum这样的敏捷相关的邮件列表资源。这些列表是资深的敏捷实践者们经常出入之地，而且也是新手们寻找正确的资源和指引的上佳场所。

每年一次的“加速提升你的效率（Accelerating Your Effectiveness，即AYE）”会议，其目的就在于专门帮助软件实践人员和管理层学习更好的人际技能。它是在2000年的时候由一小组咨询师发起的，其中包括已经为管理层和软件开发者提供有价值的资源长达25年的杰拉德?“杰瑞”?温伯格（Gerald“Jerry”Weinberg）。（温伯格已经撰写了多本书籍，包括1971年的《计算机编程心理学》——这也许是第一本将编程视为个人和团队活动的书籍，1997年的《质量软件管理，第四卷：预测变化》——专为关注和擅于处理软件变更的人士所准备。）

AYE会议由少数软件思想家领袖所主持，在这个与软技能相关的、一年一度而且丰富多样的4天会议中，许多资深的实践者会分享他们这一年职业生涯中的亮点。通过与人实际交流的方式学习这些技能能够得到最好的效果。不过如果实在无法派人参加，那么会议的网站也是进行网上研究一个不错的起点。在网站上的会议内容涵盖了演讲者关于自组织团队和小组的经验，以及他们往年的文章和演示，也包括下列2007年的内容：

• Dale Emery的“重写抵抗的故事”
• Esther Derby的“点对点的反馈”
• Johanna Rothman的“说服管理层改变团队上下文不是个好主意”

此外，在敏捷联盟每年的Agile200x系列会议上，有许多非常实用的、关于沟通和推进技能的议题。虽然参会要收费，但议题的提案和摘要是免费的，而且这会指导你去寻找这些一些人，他们对于一些话题的思考会对你的团队有帮助。这还仅仅是研究的开始：通过找到这些人的博客和发表的文章，你一定能够发现更多起到帮助作用的作者和教练。

敏捷联盟的文章库也是一个很好的地方，有许多关于沟通和推进技能的文章分散在下列分类中：自组织、关于沟通，还有关于人。

嗯，也许当我们有更多时间时，再……

时间总是不够用的。但时间不是我们唯一可以用来完成更多工作的依靠。Schwartz和McCarthy提醒我们他们所提的“个人能量”是一种可更新的资源：

通过一些略带欺骗性的简单仪式，组织可以帮助雇员定期补充他们的能量，让他们在身体上、感情上和心智上都得到恢复。这些仪式包括：以特定的间隔让大家得到短暂的休息；对他人表示欣赏；减少干扰；对于能够让人们能够更好地工作和休息的活动，不妨多花些时间……让你的雇员们有系统地复原他们的个人能量，这一定能够对组织直接产生有益的效果。

他们引用了Wachovia 银行的例子：参与了“能量复原”计划的人，相对于对照组来说，他们在借贷上的年收入要多产出13%，而在存款方面的年收入多20%。

Scott Ambler，在谈到敏捷单一来源（Agile Single Sourcing）时提醒我们：“在敏捷软件开发中，要尽量保持轻装前进，想达到此目的，最佳的方式就是用最好的工件（artifact）来记录信息。”

有些专家只知道如何使用少数几种工件来记录信息，如果团队由这样一组专家组成，就很有可能在多个不同的地方得到同样的信息……如果人们都是通才专家，他们都有一种或几种特长，而且还对整个的软件生命周期有大体的了解，他们就可以使用多种工件，从而不会产生在多个地方记录同样信息的不良状况。
实际上，这已经超出了工件的范畴：通过适时、有效的讨论，或者仅仅是与适当的人协商，团队当前的文档有多少可以被抛弃？不受人的因素困扰的团队可以更好地协作，更快做出决策，并减少“浪费”的文档和沟通。

所以，如果你有很多事情要做……你现在敢于承担不提升团队个人能量和沟通效率所带来的后果么？如果你真的“没有时间”，问问你自己是不是在管理一个踏上“死亡之路”的项目，是不是该重新调整一下了。（另一种方案，有人听杰瑞?温伯格推荐这样的策略：向绝望的借口的守护者——圣犹大祈祷。）

慢慢来

有了这些策略和资源之后，还有非常重要的一点要记得：要允许团队和个人在需要的时候自己去“拉”来需要的资源，来构建他们的自信；而不是由管理层向他们强制“推”行！最后以隐喻大师——Dale Emery的话作为结尾：

……“你可以把一匹马领到水边，但是你不能强迫它喝”，这意味着“我们这些聪明的变革专家可以告诉人们我们的好主意，但是我们不能强迫他们采纳这些主意。”
这常常让人们觉得很郁闷，我们这些聪明的变革专家无法让人们采纳我们非凡的主意，这好像是特别令人沮丧的事情。
看看下面的建议：试着把一匹非常口渴的马领到水边，看会发生什么。如果马很累了，把它领到荫凉之中，提供一个可以躺下来的柔软的所在。如果马饿了，给它干草和燕麦。如果马什么都不需要，那就随它去吧。