在敏捷宣言核心的四句话中，第一句就是“个体与协作胜于流程和工具”，在敏捷中，强调自我管理，团队对质量负责、对测试负责，这些也离不开协作。Lisa 和 Janet 在 2017 年给出的“敏捷测试定义”中认为：敏捷测试就是从开始到交付的协作测试实践，并支持高质量产品的频繁交付……。如果高度概括的话，敏捷测试就是协作测试实践。这些都说明，协作在敏捷测试中是非常重要的。

团队协作的五大障碍

团队协作包括团队精神、沟通技巧、人际交往能力、谈判与冲突管理、信息透明和组织的敏捷性等。敏捷组织本身已经奠定了组织敏捷性，而其每日站会就是一个典型的“信息透明”例子，每个人把昨天做过的、今天将要做的和遇到了什么困难等都向团队汇报，让每个人了解其他人所做的工作及其状态，你我进行开放式交流，极大提升项目的可视性。

谈到团队协作，其实不容易，会存在各种问题，喜欢以自我为中心、个人英雄主义，而且许多研发工程师不善于表达和沟通，也缺乏良好的人际交往能力，所以在软件研发过程中，团队协作的确是一个比较大的挑战。这里，推荐一本书《团队协作的五大障碍》(Patrick Lencioni 著) ，其主题是：来了一位新的 CEO 凯瑟琳，如何逐个突破团队协作的五大障碍，将一支涣散的团队打造成团结协作的团队，从而使公司销售业绩一路攀升。

那这五大障碍是什么？

缺乏信任。没有信任，任何一个团队都没法谈协作，因为信任是团队协作的基础，它很重要，但又很难做到。信任是比较常见的问题，一般人都不愿敞开心扉、承认自己的缺点和弱项，从而导致无法建立互相信任的基础。比如，开发和测试会经常相互不信任、喜欢“怼”：为什么这个 Bug 都测不出来？你是怎么测的啊？到底会不会测啊？懂不懂代码啊？

惧怕冲突。这里的冲突是指团队内部不同观点的直接碰撞、甚至是激烈的交锋。“惧怕冲突”比上面说的“怼”还要糟糕，“怼”至少能刺激对方成长，而这种你好我好、一团和气，有了什么想法喜欢藏着掖着，有什么质量问题往往一直存在下去，得不到解决。当面怕冲突，背后还有可能会进行人身攻击，非常不利于协作。

欠缺投入。由于缺乏信任、惧怕冲突，争论就会少，互相不愿意沟通，在协作、沟通上投入自然就会少，团队内部长期存在的深层次矛盾就无法解决，甚至越来越严重，进入恶性循环。

逃避责任，上述几大障碍的存在，自然会导致你我推卸责任、缺乏团队精神，团队成员都想将责任推得一干二净；谁表现得越好，反而越容易遭到他人的心怀怨恨，这样的结果使你我甘于平庸、丧失进取心，团队更加涣散。

无视结果，逃避责任后的结果，相当于无视团队的目标和结果，都不愿意为团队目标付出，没有信任的基础，也很难齐心协力、坚持不懈地致力于实现团队的目标。

所以，从协作管理上来看，要扫清协作路上的这五项障碍，比如，搞一些野外拓展训练（图 1）、适当聚聚餐，建立起信任关系；然后主动拿出一些主题，敞开心扉地去讨论和辩论。在辩论时，再加以正确的引导和必要的提醒，提醒某些成员注意沟通方式和善于聆听、对事不对人等。久而久之，沟通协作的气氛就建立起来了。同时，和团队一起制定明确的目标，更重要的是达成共识，有良好的绩效考核机制，奖惩分明，这样就能克服五大障碍，打造成一支协作的团队（图2）。

 

 

             

图1  这类游戏或训练可以帮助团队成员建立信任关系

             

图2  克服五大障碍，打造协作的团队

下面我就结合敏捷测试的实际要求，来谈谈测试人员如何与产品、开发等不同角色进行沟通协作，会涉及质量管理、冲突管理、团队精神、沟通技巧、人际交往能力等，目的是为了持续交付高质量的产品。

团队协作高于一切

对于团队来说，团队协作高于一切，只有团队协作，才能实现团队的目标，或者说，才能顺利且相对轻松地实现团队目标，否则即使能实现，也很累、很苦。这一点在敏捷团队中，是比较容易达成共识的，因为前面说过，“个体与协作胜于流程和工具”，这体现了敏捷的价值观，而且是第一价值观。并且，团队也是全职能的特性团队，强调团队对质量负责、对测试负责。有了这个共识，从文化和认知上，协作就没有太大障碍了，对吧？

不一定，每个角色容易从自身角度看问题，也就是“屁股决定脑袋”，比如我们很容易听到：

产品人员（PO）常说：客户的想法总变，开发不好沟通…

开发常说：产品需求总变、产品太强势，只做加法不做减法…

测试常说：需求变了都不通知、开发太霸道、测试的时间总被压缩…

现实中，人们很容易忘记敏捷宣言所提倡的“协作”，欠缺团队精神，没有从全局观点看问题。所以要有良好的协作，团队的每个成员都需要全局思维方式，摈弃“屁股决定脑袋”的思维方式，需要换位思考，多站在对方的角度看问题。

而且，团队协作还依赖于之前说的信任，依赖于团队归属感、责任感等。马斯洛需求理论告诉我们，人们既有对安全感的需求，也有对归属感的需求，问题是 安全感和归属感本身就存在矛盾。安全感让我们容易在心理上封闭起来，提防他人发现自己的弱点；而归属感则需要获得团队的认可，需要我们敞开心扉，展现彼此的善意。现实中人们往往过于追求安全感，才导致团队无法建立信任。因此，良好的团队协作需要团队成员刻意的练习，不断磨合、不断改进，才能达到较高的水平。

根据微软公司的定义，仅达成共识还远远不够，团队精神有以下 6 点：

• 制定团队共同的使命和目标

• 传达“成功必须依靠团队合作”这样坚强的信念

• 营造团队中的归属感并将你我团结在一起以实现共同的目标

• 鼓励团队成员互相帮助、互相尊重、互相信任

• 使每个人都觉得自己的工作很重要，有成就感

• 与团队成员分享责任、胜利与成功、团队品牌等

达成对质量及其管理的共识

这里谈到了“制定团队共同的使命和目标”，在敏捷研发中，“使命和目标”可以理解为“尽早、持续地交付价值给客户”，这没问题，但还不够，团队需要对这个“价值”也要达成共识。越能解决客户的问题就越有价值，那么越能让客户愉悦、越能让客户满意是不是也越有价值呢？而质量就是客户的满意度。那么这里的“价值”等不等于“质量”呢？因为质量、价值都是相对于客户而存在的，即使不能说它们完全相等，但也有很强的关系，从敏捷测试的角度来看，团队必须就“质量”达成共识，认识质量的价值。

对质量达成共识还不够，更重要的是在“质量管理”上达成共识，日常研发活动中自然伴随着质量管理，如果没有达成共识，会容易产生冲突。在敏捷中，我们希望团队有这样的质量管理共识：

• 把事情一次做对是效率最高的

• 质量是构建起来的，不是测试测出来的

• 缺陷预防比发现缺陷更有价值

• 质量由客户来评判 胜于 质量由已有的标准 / 规范来评判

• ……

 

这样的团队不仅会重视需求评审、设计评审、代码评审，而且会更重视写好用户故事、设计好架构、遵守代码规范等，开发人员有“代码即艺匠”这种强烈的意识。这时，测试人员指出产品需求定义不清楚、代码不规范等问题，产品和开发人员就很乐意接受，不会出现之前所说的灵魂拷问，也不会再出现相互恶怼的局面。如果在质量及其管理上，团队内部没有足够的共识，关于测试的良好协作显然是不可能的。

沟通的技巧

仅仅达成共识，就没有协作上的问题了吗？显然不是，协作还受绩效考核、责任分工、沟通技巧、人际交往能力等诸多方面的影响。就像前面所说，在奖励机制上，要奖励团队而不是奖励个人，把你我的利益捆绑在一起，激发大家一起履行监督质量的责任。惩罚也类似，比如上线时出现了遗漏的缺陷，虽然要了解问题产生的根源，适当追究某些个人的责任，但整个团队也要受到惩罚。分工及其职责要明确，在第 7 讲中已经交代了专职测试人员和开发人员在敏捷开发中合理且具体的分工。

最后侧重讨论一下沟通技巧。

首先要有勇气（敏捷的价值观之一），向产品、开发不断地反馈质量问题，有了之前的共识，勇于站出来提醒质量的风险，不会太难，千万不能视而不见，更不能给高层的主管打小报告。

其次，要有情商（情商比智商更重要），要注意方式方法，比如在需求评审时，发现了需求的问题，不要说“我认为这个地方是不对的”，可以这样说“假如我们是用户，在某个场景下，如果碰到这种情况，我们大概会这样处理，而不会那么处理，对吧”；设计评审也一样，尽量不要从自己角度看问题，而要从性能、安全性、可靠性等角度出发来指出问题，或者说：根据我们上次性能测试的结果，有一个类似的问题，所以这样的设计也很有可能会有性能问题。

虽然团队对质量负责，如果团队之前对质量不够重视或对需求评审、设计评审等不重视，指望团队自然好转，其实是不可能的。作为质量的守护者，测试人员自然要承担起建立质量和测试方面协作的主导责任，在沟通协作上，不怕困难，积极主动，一次不行两次，两次不行三次……持续地影响团队，最终会帮助团队建立良好的质量文化。

在需求、设计、产品等评审（Review）会议上，我们也需要有更多的投入，事先准备更充分些，在会议上就能提出更多的问题或疑问，从而体现出自身的价值，让这些评审会成为沟通协作的主要平台。反过来，产品、开发人员看到测试人员的表现，在测试计划、自动化测试框架设计和脚本设计等评审会上也乐于提出更多的问题。这样，即使有更多的争论，都自然而然地加强了团队的沟通与协作，更快地实现团队的使命和目标。

好了，这一讲就到这里，也意味着软技能的分享暂时告一段落，下一讲将进入硬技能，我将分享《持续交付与持续集成意味着什么》