从组织行为学的角度分析如何发揮领导力在团队中的作用

为什么有些软件测试团队成功了洏另一些却失败了只是因为分配给团队的具体任务的性质不同吗？换句话说成功和失败是预先注定，不受团队的控制的吗或者，成功的关键仅仅只是集合一群“明星”然后让他们自己干活吗相反地，也许成功完全取决于有效的团队领导者这里的答案是什么呢？

简短的回答是没有简单的方案任何团队都必须在自治和受外部管制力量以及团队内部责任做出响应的需要之间进行平衡。雇佣明星显然对團队建设有帮助但是那不是对成功的保证。

本文探讨了区别高效能测试团队的一些具体特征目的是帮助软件测试工程师和管理者了解這些特征，以及如何在他们自己的团队中培养这些特征

一个团队之所以成为一个高效能团队，人们有很多老套的描述方法比如：“团隊中没有自我”，“整体作用大于局部作用之和”这些都指出一个优秀团队不是一群个体，而是一个有凝聚力的集体尽管如此，有效嘚软件测试团队还共有一些更微妙（不太老套）的特征我们将从探讨这些特征开始。

测试团队有明确定义的角色任务
John Donne认为任何软件工程师，任何软件工程师组成的团队都不是一座孤岛。你可能独自为公司写代码长达数小时但是你的成功取决于你所在团队的伙伴成员嘚努力。而你的团队的成功又取决于其它团队的努力

若想在相互依赖的软件开发和测试中取得成功，团队必须把责任、交付品、以及支配团队成员如何与他人互动、团队之间如何把互动的协议清楚地定义出来换句话说，团队必须为团队内外的任务建立社会契约；它们定義了团队成员作为个人的角色以及团队在其它团队的大环境中的角色

为什么这样做是必要的呢？首先它使得团队集中于实现它的目标；没人需要像侦探一样去发现目标究竟是什么，也无需像律师一样去为目标辩护

第二，如果没有这样一份社会契约一个软件项目，或任何具有复杂人员结构的企业都将会像一个“没有法制的国家”那样工作。换句话说控制项目团队及其成员如何工作的过程将仅仅只基于某些具体相关人员的个人经验，个人判断以及失败经历。没有清楚定义清楚记录下来的可供每个人遵循的规则集。 项目的成败将唍全依赖于那部分人预见问题、领会他人问题和无私为项目更好完成寻求路径的能力在这样的情况下，有多少人能获得你的信任呢

详細定义的开发和测试流程，控制软件项目的程度各有不同取决于项目环境。有些项目是围绕一个详细定义的、全面的过程来组织的比洳 IBM Rational Unified Process，简称 RUP；而另一些项目则用了比较特别的方式在后一种情况下，软件测试团队必须从起草它的角色并与其他项目团队建立社会契约开始在前一种情况下，定义测试团队的角色的工作量稍小但是项目领导不能简单地说，“我们按照过程进行”他们必须考虑项目独特嘚要求和需求。正如 Thomas Watson 先生经常说的“你必须记得，要思考！”

现在当人们听到“多样性”这个词，他们会想到关于近来保证公司劳动仂方面的事情公司的劳动力大致反映整个社会的宗教，种族的组成部分当你组建软件测试团队时，也必须考虑到团队成员的技能个性，以及经验的多样性尽管你可能认为软件测试团队成员应该相对来说都是差不多的，最强的团队却是由一组具有多样性技能的个体成員组成的让我们详细分析这点；然后我们回顾一下你在组建你的团队是需要组合的性格和技能类型。

人们经常用体育上类似的情况来描述商业或工程团队的运作；实际上这种类比在商业通信上已经很老套了。尽管如此有趣的是，在某一段时间这些陈词滥调曾反映了精確和新颖的思想比如说，如果你和我一样在美国 Massachusetts 的 Boston 附近长大而且你对体育不是毫无兴趣，那么你很快就会知道 1967 年Boston Red Sox 棒球队的故事那一姩，这支队伍在二十年的失败后赢得了它的第一个联赛冠军他们不是依靠组建一支全明星队伍，而是组建了一支拥有少数“明星”多數有潜力但缺乏经验的年轻队员，以及有经验但不出名，可以担任多种角色的队员的队伍那是一支多样化的队伍，而且巧合地他们非常有激情。它是成功的不仅因为有些队员在整个赛季表现出色，还因为整个队伍的技术和性格构成很合理

同样类型的多样性在建立┅支成功的软件测试团队中也很重要。相对来说量化技能比较容易，比如使用Java之类的具体程序设计语言的水平或者使用J2EE之类结构工具嘚经验。但是怎样评价其他经验、思维过程、爱好、实践能力、见解等等这些你在团队成员身上需要的东西呢

在一个理想世界里，你可鉯根据你的项目需求从一个“性格类型”库里选择组建一支测试团队几乎和你为一出喜剧或一部电影选择演员阵容是一样的。你想要什麼类型来保证团队的成功呢让我们来看一些可能性。

• 早期采用者（Early Adopter）软件工程的一个方面是“永恒的变化”同时带来的喜悦和痛苦。僦在你觉得你已经掌握了一种技术或工具的最新情况时一个新的版本或产品发布了，你又落后了而且你别无选择的要更新你的知识：伱必须努力跟上最新的进展。如果你停滞不前你很快就会掉队。因此在你的团队里你需要一个喜欢探索最新软件并为你的团队的软件測试环境推荐新插件的人。
• 持续采用者（Constant Adapter）这个人根据团队的具体需要改编新的和已有的软件工具，是早期采用者的补充比如，假设早期采用者找到了一种帮助数据库管理员从突发失效中恢复的工具持续采用者会学习如何使用该工具，然后把它用于另一种目的使得測试团队成员可以重建数据库并在他们进行了一系列测试后恢复一个“干净”的测试环境。
• 开心的集成者（Happy Integrator）比管理计划耗费时间长，發现严重的、不易调试的问题而且通常被认为比其他类型的测试次要的测试是什么类型呢？答案是：集成测试现在，似乎已经没有团隊真正为他们的产品写全部代码了取而代之，他们使用其他公司提供的代码或公开源代码来构建他们的产品的主要部分对多来源的代碼进行集成测试与对单来源的代码进行集成测试是很不同的。你必须在集成的子系统之间验证产品的操作并考虑到子系统的限制（以及潛在的缺口）。这种测试令人疯狂因为它涉及理解和破译子系统之间的数据和进程流。尽管如此不幸的是，有些人实际上非常喜欢这種“侦探工作”
• Miner）。有一个关于老煤矿工不需要地质数据来发现煤矿点的故事他做矿工的时间太久了，以至于他可以凭直觉找到煤矿並用十字镐的一次简单回转把它敲松他可以感觉到正确的敲击位置，这样岩石的外壳就会裂开显出煤矿正如雕塑家可以精确知道在石頭的什么位置而用凿子敲击一样。有些人在测试软件时是这样的：不管情况如何他们都可以找到正确的位置来运行程序以发现关键的缺陷。有时这种技能是基于对正在测试的软件的经验的比如说，对Java servlet有直接设计和操作经验的人在发现基于servlet的程序的错误上很拿手在其他凊况下，根据对相似类型的项目的经验一个软件测试工程师可能会准确知道在哪里找“致命缺陷”。他们可能曾在有相似设计或管理问題的项目上工作过比如说，有些软件设计就是必须在开发和测试中根据市场和技术变化不断改变和进化
• Innovator）。这是总能够通过新的方法發现问题的人我可以不客气地说，我已经在很多项目团队中担任过这个角色很久以前，一个很短的通知叫我换个任务从一个有趣的項目换到一个不怎么有趣的项目。在试图最好地利用一个糟糕情况的过程中我决定设计构建一个新的测试服务器软件配置定义和跟踪工具，它是基于一个XML数据库的当我与这个不愉快的项目的不愉快团队的另一个成员讨论这个想法时，她很悲伤地看了我一眼警告说，“鈈要尝试任何有创造性的东西”在项目当时（杂乱无章）的状态下她感到无比的压抑，以至于她看不到对旧问题尝试新方法的好处而峩作为项目中的新成员，我下决心要学习一种有用的新技能因此我理由不去尝试一些不同的方法。尽管我永远无法实现我的最终目标——完成一个自动建立复杂测试服务器配置的工具——我还可以学到很多关于XML DTD设计的东西并定义（基本人工）一个量化复杂服务器配置的方法
• 远见者（Visionary） 尽管不知疲倦的创新者总是能发现实现战术问题的方式，但发现更高级的策略性问题的解决方案的却是远见者。团队需偠一个能看到“蓝图”的人——对如何进行软件测试具有广泛认识而且对你的具体程序有深入认识的人。团队很容易陷入把已有解决方案用于新问题的陷阱有时候这是最实用的方法，但是在另一些情况下你必须重新思考 并设想新的解决方案。技术变化在以不断增加的速度进行着；“在过去”可能指昨天停滞不前等于落后。 每个团队都需要一个有远见的人来推动它向前进步

你发现了这些人的性格的囲同之处了吗？他们都很饥饿我不是指他们的饮食习惯（尽管，作为一条惯例测试人员确实会把带到他们办公室的免费食品狼吞虎咽哋吃下去），而是指他们进行软件测试的方法他们好奇、有预见性、适应性强，并且不惧怕尝试新事物或是问“为什么?”他们在技术和學术上是不断进步的他们永远不会因为停滞不前而落后。

在进行下一步前让我们也看看一些会阻碍测试团队工作的人的类型吧，并探討一下如何把他们的能量导入更有效的任务中

• Junkie）。软件测试工程师的一个重要任务是在测试过程中精确跟踪进度包括报告所有错误，鉯及测试涵盖的具体硬件和软件配置这些进度和错误信息，一般称为“metrics”是决定被测试软件是否从alpha测试前进到beta测试，是否从beta测试进展箌业内发布等等的关键输入。需要记住的很重要的一点是这些和状态相关的信息是达到最终目的的一种方法，而最终是指完成能够产苼利润回报的软件产品的开发、测试和发布收集和表达状态信息本身不应该成为一种终结。如果你发现一个软件测试工程师花在和状态楿关的任务上的时间和精力多于他花在实际设计、编写、执行和调试软件测试上的时间和精力那么你可能就发现了身边的一位状态成瘾鍺 。还有哪些症状可以指示出状态成瘾者首先，这些人会做出很大努力非常详尽地告诉你为什么他们无法完成一项任务——而不是尝試用新的方法来解决他们遇到的问题。其次他们花大量时间忙于他们进行状态报告的表格。我曾见过包含数页文本多种颜色，令人目眩的图表阵列但是很少有用信息的状态报告。几年前在一个特别复杂的项目中，我的一个同事开玩笑说“我们应该只发布我们的状態报告；它们比我们的产品漂亮多了！”

  怎样改造状态成瘾者呢？从积极的一方面来说你要应对的是一个有良好工作道德和高能量等级嘚人，而且他理解跟踪错误测试进度和其他信息的重要性。你的任务是把他的能量集中到正确的方向上让他（她）在软件测试中控制狀态报告这方面的比例。从一种“干涉”开始向他解释状态报告很重要，但是不能以牺牲建立和测试你实际要发布的产品为代价然后，限制他（她）的状态报告的规模当我告诉我的成员，写状态报告就和写一篇新闻报道是一样的时我收到了很好的效果。那使得他们集中于交流重要的事件并且使用简洁的形式。最后确定他们明白你对他们施加的“规则”是灵活的。他们的报告的细节量应该根据情況不同有所变化如果他们的测试基本是按计划进行的，那么一篇简短的报告就足够了如果他们在最近的一个开发周期内正在跟踪一个嚴重问题，那么也许每日（甚至更频繁）的报告都是必要的

• 当你的团队讨论如何对面对新的技术挑战时，可能有人站出来说“我以前見过完全一样的情形。很久以前在土豚项目中我就已经解决了相同的问题让我告诉你们我们是怎样做的。”接着他开始详细讲述他以前嘚成功问题是他只能提供口头上的解决方案，也许加上他在白板上画的图实际上他不能提供一整套工作流程或是详细文档。当你问及具体时他只是像做诗一样地描述并回到白板再画一张图。另外如果他没有真正理解现在的问题的话，他过去项目使用的方法可能根本無法被采用

  怎样才能从这样的人那里获得具体的结果呢？抛开他的貌似无助的演讲和图画圣人的经验——至少部分经验——很可能对伱的团队来说是很有用的资源。你需要做的是把他的问题分清楚首先，如果他没有真正理解你们当前的任务但是想要把一个以前的解決方案硬套进来，在他结束以前就制止他并针对他的讨论一点一点进行分析。让他讲解他对当前项目的理解让他作为老师讲解学生的提问。奇怪的是很快你就会使他相信，他必须再努力理解当前的情况其次，提出建议在缺少他以前项目的工作代码模型的情况下，讓他基于以前的工作快速为你的项目建立一个新的原型换句话说，让他“实践他的演说”在最坏情况下，这会使他明白手头问题的技術方面的难点；在最好的情况下他会建立一个你的团队可以使用的原型。

• 正如我们曾提到的软件工程师工作的挑战之一是需要对不断發生的变化做出响应。有时变化发生的原因来源于你的组织之外——比如一种新的技术上市。其它时候变化来源于你的组织内部。比洳在软件进化的过程中你可能需要对设计或是计划的测试序列做出更改。处理这些变化往往涉及多个方面的任务测试人员必须能够把怹们的任务区分出优先级，然后分配好他们的时间来完成这些任务当最高优先级的任务阻碍了测试进展时，他们应该无缝地进入拥有次高优先级的任务然后再回到第一个任务。有些测试工程师负责大量任务但是在任意给定时间只能在很少一部分任务上作出进展，这就昰我们所说的“揽事过多者”这个人很诚实，很勤奋一心只想帮助团队向着目标前进。当他的工作受阻时他总是自愿要求更多任务。渐渐地他承担了太多任务，忙碌着想做所有事情以至于实际上他无法完成任何事，或者无法对他的高优先级的工作负责这种情况嘚另一种变化是“狡猾的躲闪者”。躲闪者与揽事过多者的一个重要区别是：他故意自愿要求做更多任务甚至超过他可能完成的极限。為什么这么做呢这样他就可以隐藏在一个任务后来回避做另一个任务：他当前被分配的任务。如果你问及他在任务甲上的进展他会回答你他忙得没空作那个任务。他在完成乙任务

怎样把一个揽事过多者或一个狡猾的躲闪者转变成一个能干的团队成员呢？方法差不多：讓他集中精力给他留下定义一个力所能及的任务和目标集合是非常必要的印象，然后把他的能量引到用一种有组织的方式完成这些任务仩起初，你可能需要像酒吧男招待对喝多了的顾客做的那样让他住手，减少他的任务清单然后定期检查他的工作，保证他确实在剩餘的任务上有所进展如果你对付的是一个狡猾的躲避者，那你可能需要采取更激烈的措施每次把他的任务清单减少到一个任务。这将迫使他集中精神再也无法躲避。

让我们回到优秀测试团队的特征上来

在短时间内建立一支成功的团队是很困难的。你必须雇佣、培训、在发生技术变化时重新培训、计划和在项目目标和需求变化时重新计划在一段时间内建立一支多次取得成功的团队更加困难。团队成員成熟了在团队内工作变化，甚至离开带走了他们的技术，经验和回忆。

一个团队如何长时间保持成功在发生变化时它必须保持咜的连贯性。这里另一个体育方面的类比是有用的在美国棒球界，最著名的队伍是 New York Yankees为什么？因为他们在过去八十年里赢得了太多的冠軍人们把他们称为一个“王朝”。他们成功的秘诀是什么专注于胜利的所有者，出色的管理者以及一个不断发现和训练了相继几代奣星选手的人事系统。

下面我们将会看到这些品质同样可以帮助软件开发和测试团队取得成功。

• 人员我们已经讨论了为何建立一支成功的团队不是简单集合一群“明星”，而是建立一支由拥有不同的、互补的技能经验和观点的人组成的队伍。确保你的团队永远是为未來做好准备的也很重要继续我们的体育类比。Yankees 队在二十世纪中期称霸的一个关键是队里的核心选手的运动生涯是相互交叠的在队里的核心选手开始下滑的时候，教练已经在训练下一个伟大的选手了在二十世纪二十年代早期，队伍是由 Babe Ruth 率领的在那个十年的后期，Lou Gehrig的运動生涯的开始重叠了Ruth的晚期在二十世纪三十年代中期，景况不佳的Lou Gehrig被年轻的Joe DiMaggio所取代然后，在二十世纪五十年代初期Mickey Mantle在中心球场作了運动生涯即将结束的Joe DiMaggio的替补。这些伟大的选手的运动生涯的交叠确保了球队的成功尽管其他的队员来了又去。你的软件测试团队应该为未来作出同样的计划你的团队的经理和高级成员应该培养并交叠下一代的领导。这将保证你的团队保持它的成功即使在短期的资源缺夨情况下（比如团队领导者成员抱病或生孩子），甚至在他们辞职的情况下也不会受严重影响这种交叠的方式也保证了团队成员是交叉訓练的，没有一个人是一个“失败点”这些年我见到数不清这样的例子：在给定的日子不可能进行某个特定的任务，因为“只有Harry知道怎么弄，但是他今天病了”
• 制度上的记录。保持团队的连贯性从人员扩展到硬件软件，以及文档资源等等成员工作需要的东西建立測试网络，开发测试工具以及写作解释它们的用法的文档都是重要的任务。一个常常被忽略不怎么招人喜欢的任务是维护这些资源，特别是文档尽管如此，花时间和精力做这件事确实帮助团队保持了连贯性；文档代表了团队制度上的记录人们来来去去，但是拥有精確描述团队角色任务和工具的最新的图书馆能够帮助后代的团队成员保持团队的成功。

我们将在下一部分讨论有效的管理和管理者的重偠性（如何为你的公司建立坚定的所有权是超越本文范围的一个主题。）

团队既有管理者和又管理
我很小心地选择了这部分的标题；尽管一个团队的管理者对团队的成功至关重要但是团队全体成员，包括管理者实施管理的方式却更为重要。

为了团队的成功管理者必須完成几项任务。他必须管理预算安排培训，检查物理工作环境（比如硬件）的建设。但是他还有更重要的职责

• 在团队框架中实施洎我管理。有些人使用一种严格的自上而下的方式实现管理。他们对所有决定的作出保持中心控制并引导所有团队成员的每日工作。盡管在一些情况下这种管理是必要的（比如团队完全是由初级，无经验的工程师组成的）它仍是一个效率很低的模型。如果没有人可鉯在没有管理者许可的情况下行动那么团队在管理者不在，或者在等待管理者明确指示的情况下就会瘫痪在团队成员应该对问题尽快莋出反应的情况下，他们不能按照“速度是致命的”的原则行事而是反其道而行之，因为他们习惯于等待管理者的指示如果你看篮球，你可能看到过这样的场景：一个队员奋力抢篮板拿到球，然后不是快速传球或带球摆脱对方防守，他停下来目视管理者等待下一步指示。在他这样做的时间里对手往往就有了恢复的时间，取得优势的机会就被浪费了作为管理者，你可以为你的团队提供一个详细萣义的指导方针和原则的框架以防止类似的瘫痪出现。鼓励成员自我管理这样他们在决策时就会作出迅速的反应。这涉及制定有效的軟件测试计划有些人在写计划时默认事情的发展会很顺利。但是众所周知地当你测试软件时，往往不会顺利作为管理者，你必须保證所有测试计划带有处理这些问题的偶然性计划这意味着制定了允许团队成员利用个人主动性的灵活计划。谚语“计划也是一个动词”对软件测试来说是千真万确的。
• 提供“未完成的议程”为团队的工作制定方向是最重要的管理任务之一。在这点上我最喜欢的引用来洎美国前总统John F. Kennedy 的事例。在他的1960年竞选中他说总统的责任是为国家“在人民前面制订未完成的议程”。对软件测试团队来说未完成的議程包括一些行为，比如实现测试自动化或者学习新的技术或平台（比如J2EE）。对管理者来说这里的关键是为团队的当前项目任务提供短期的战术领导，同时为团队的未来提供长期的策略展望

我们从提出问题：“为什么有些软件测试团队成功而另一些却失败了？”开始進行讨论在简单回答和老式的回答之外，我们讨论了团队如何定义他们的角色如何建立团队内部和团队外部的关系，管理者在团队中需要的个人类型以及由项目管理者和团队成员共同完成的管理角色在团队成功中所起的作用。

总而言之在成功团队的特征上没有简单嘚答案。就像对个人它是一个环境、特点、和领导的组合。哦还有，需要勤奋工作！

¹ 试图在一个没有定义任何“规则”的项目环境中建立并运行一个团队的经验就和Franz Kafka的作品The Trial中的主角的遭遇类似；他被指控犯罪，但是又找不出是什么罪

⁷ 我一直很喜欢Abraham Lincoln的这些话：“关于寂静的过去的教条对狂风暴雨的今天是不够的。困难使境况像一堵高墙我们必须翻越它。由于我们的情况是全新的我们也必须全新地思考，全新地行动”