文／Tathagat Varma 译／顾全

自古以来，那些地位尊崇的理念、宗旨和经验，和长盛不衰的经济、社会和情感的价值，都是由共同工作于团队中的人们创造的。就算某些艺术、哲学和科学领域的非凡成就，看上去是由那些单打独斗的卓越个人所作，我仍怀疑他们也一样有其他人助一臂之力，这些人无私奉献而寂寂无名（也许在幕后），都是作为团队而共同工作在一起。从大国混战、社会动荡、政治反抗、建立帝国、为自由抗争和建立国家并保卫边疆，到金字塔、泰姬陵、艾菲尔铁塔、自由女神像、悉尼港大桥以至伦敦眼摩天轮等诸多雄伟奇迹的创造，每一样都仰赖于团队协作才得以诞生与存在。当然，团队协作的范畴并不排除简单、俗世而日常的事务，它们虽然上不了报纸头条，却极为重要：平淡者如下田耕作，安排野餐以至家庭活动，都离不开团队。

团队协作既然对我们的日常生活有如此深刻的作用，我们很自然就期望团队的产出直接受其协作质量的影响。不幸的是，单凭良好愿望或是听天由命，团队协作是不会产生的，而很多时候根本就无法产生！团队协作的质量受很多因素的影响，比如团队成员个体的积极性，团队成员间的信任度，团队使命的清晰度，对目标的统一理解，资源的缺乏，团队成员间糟糕的沟通，等等。因此可以毫不奇怪地说，要让团队一拍即合，适当的投资是必需的。可是，尽管有最先进的流程和工具，团队的机能障碍还是频繁地严重影响团队的表现，危及它有效执行的能力。大多数软件经理缺乏相关能力去感知这些深层社会学问题的信号，也就无法处理其影响。对这些问题任何敷衍潦草的反应，都只会使其更难应付。

在本文中我分析了团队机能障碍的模式，这一模式由Patrick Lencioni在其基于业务情景的精彩寓言体著作《团队的五种机能障碍——领导力之寓言》中提出。在书中所称的模式中，他识别了五种影响团队绩效的机能障碍。这些机能障碍并非是全然独立的，而是互相关联，如后图所示般上下层叠。

也就是说，信任缺失导致惧怕冲突，而惧怕冲突又导致承诺不足，如此以往。虽然Patrick在探讨该模式时，借助于一个没有充分发挥潜能的业务团队，我倒发现这些理念放之四海而皆准，也适用于一个软件开发团队的情境。可能哪里也找不到像软件开发这样能凸显团队协作的效用和重要性的了。

软件开发是一项团体运动，有自己的公平竞争政策（“职业道德”），整套游戏规则（“流程”）和对团队协作的高度重视。软件开发流程，或者管理开销（以流程或组织认为合适的任何类型和份额而存在），或者更简单点的，比如统一的集成开发环境（IDE）、通用编码规范、配置管理工具……实际上任何东西的存在都为了同一个理由：让团队作为整体，大于其组成部分的集合。但是，我们也知道软件项目的失败率惊人地高，即便业内对于“失败”的构成及其真实统计数据没有共识，大家都心知肚明，失败率总归要比该有的高！就算偶有例外，可考虑到软件业雇佣的员工大都聪慧过人，如果在项目失败理由清单中名列前茅的是技术低能、粗心愚蠢或者有意破坏这样的原因，我也还是会非常奇怪。那么，为什么还有如此多的软件团队没能达成其预设目标呢？我相信在其他因素相同的情况下，软件项目失败中一个重大却尚未被足够重视的原因，就是团队的机能障碍。

团队流程决定了“工作的方式”，对团队的效力有很大影响。过去十年间，敏捷方法广泛流行，已经成了主流。维基百科对其定义为：

“……敏捷方法普遍推崇：一种项目管理流程，它鼓励频繁的检查和调适；一种领导哲学，它鼓励团队协作、自我组织和责任担当；一套工程最佳实践，它允许快速交付高质量的软件；一个业务方法，它把开发工作与客户需求和公司目标相匹配。”

上述这些带来的对团队和个人的赋权，达到了迄今我们在软件业所见过的最高程度。我将其看成流程改进中的又一重要进步，它将决策权从经理下放到被赋权的自指挥团队，因而使团队协作在其中扮演比以往更重要的角色。但是，敏捷不是一个社会学流程，它是软件开发中一种面向团队的哲学，虽然有团队社会学的痕迹，但若是武断地来看，就很容易忽略这一点。

考虑到敏捷原则正逐渐成为业内开发流程的事实标准，我分析了敏捷实践如何应对软件团队的五种机能障碍。让我们从金字塔底部开始一一展开。

信任缺失

“第一重机能障碍是团队成员间的信任缺失。这实质上源于他们不愿在团体中轻易受到攻击的心态。团队成员如果不对其失误和弱点真正地开诚布公，就不可能打下信任的基础。”

一个团队远不只是一群乌合之众，不管其中的个体如何能干。每个团队成员摆上台面的，都是独特且经常互补的技能，而这些技能的全体集合，帮助团队达成其目标。在一个由各种“劳动分工”方式创立的传统团队中，其成员间存在强大的攀比压力，没有机会发展“基于弱点的信任”。团队成员在过往绩效表现可持续的基础上受到“信任”。但是，在现代行业中，不可能假设或期望任何人具备所有所需技能，在任何状况下都能成功。据Patrick所说，互信团队中的成员们，能够承认他们的弱点和失误，请求他人的帮助，接受对他们职责领域的质询和评价，做出负面结论前先假定他人无辜，承担提供反馈意见和帮助的风险，欣赏和发掘他人的技能和经验，集中时间和精力于重要问题而非勾心斗角，提出和接受道歉时毫不犹豫，对会议和其他集体工作的机会满怀期待。

敏捷鼓励适应性的软件开发，它大量依赖于对过去绩效的反馈来改善未来的表现。敏捷鼓励所有利益相关者——开发者，业务人员，赞助人和客户——之间面对面的沟通和互动。它还鼓励频繁（通常每天进行一次）的进展更新，以及迭代结束时对过去进展状况和未来改善之处的反思。这种定期的开放沟通和反馈可以成为非常有效的信任建设活动。

敏捷团队通常都较小，团队成员具备互补的技能和任务，而非多人同时拥有互相竞争的技能和任务。他们也高度自治，允许以民主方式做出决策，而不是被客户和管理层强加没有合理论据和逻辑思考的指示。团队自己负责承诺，同时小型团队都位于单一地点，这中气氛可以让团队成员互相依靠，从而达成承诺。特定的实践，如结对开发，其根本理念是尽早查出软件缺陷，而不是以缺陷数据判定个体成员的绩效，这有助于更深入地发展信任关系。为此，团队的生产率指标“速率”，不是归功于个人，而是归功于团队。所有这些做法，都极有可能在团队成员间建立信任。

惧怕冲突

“无法建立信任是有破环性的，因为第二重机能障碍——惧怕冲突——就是由此而定调。缺乏信任的团队无法展开无需多虑而充满热烈激情的想法辩论，他们退而求诸云遮雾罩的探讨和小心谨慎的说辞。”

进行富有成效的冲突，这是一种能力，而该能力会因缺乏互信而受损。大家唯恐提出不同意见被视为反团队行为。这最终变成了一个自我挫败的问题，因为对冲突的惧怕不仅损害了团队的决策力和进展，也加深了业已存在的信任缺失。团队需要进行富有成效的冲突。在Patrick看来，进行有成效冲突的团队，能够开展生动有趣的会议，提炼和开发全员的想法，迅速解决实际问题，尽量减少勾心斗角，挑明关键主题进行讨论。

敏捷要求团队全员都参与到估计与计划、情况更新和回顾会议中去。Scrum中每日站立会议的发言，是针对团队而非任何经理。团队的进展公开透明，非常容易识别进度落后（这可能危及团队兑现承诺）的团队成员，而下一步并非申斥其进展缓慢，而是要施以援手，必要时进行建设性的争论来找出解决问题的办法。因为“基于弱点的信任”这时已经建立，所以团队成员珍视健康的冲突，而无需惧怕斥责。

承诺不足

“健康冲突的缺乏是个问题。第三重机能障碍保证会因此出现，那就是承诺不足。如果团队成员没有在热烈而开放的辩论过程中广而告之他们的观点，就算他们在会议中掩饰争拗，也罕能接受最后决策并承诺于中。”

不难想象，互不信任的团队成员是不愿共同工作或分担同一承诺的。Patrick认为：能做出承诺的团队，能够明晰方向和优先级，围绕共同目标匹配整个团队，发展从失误中学习的能力，抢在竞争者前利用机会，毫不犹豫地前进，也对改变方向毫无踌躇或负罪感。

敏捷最强的一点在于，它是一个面向团队的方法，其中每件事务都由团队主导和负责——从同意冲刺工作清单、工作量估计、衡量和追踪进展，直到最终交付。敏捷团队中没有个人的承诺——一个敏捷团队的进展和成功完全由其兑现的团队承诺来衡量。敏捷也非常重视从过去的经验、尤其是错误中学习，并采取特定步骤来加以完善。回顾会议流程的确立，就是要确保在每轮冲刺和最后项目结束时，从团队得到这些反馈。敏捷还注意鼓动团队成员拥抱不确定性。传统的软件流程对如何处理高度不确定或者快速改变／进化的问题有着严格的限制，而绝大部分人可能都把参与这样高风险的项目当作是职业坟墓。然而同样真实的是，就算最后项目失败，这种项目本身多数都是能够发展事业的工作，具备大量的学习机会。通过敏捷实践，进行短期计划、逐个解决问题，从而降低了失败或重大返工的风险，这有助于一个团队从如此不确定的情况中获得最佳结果。因此，团队当然感到更有信心去承担这么有风险的事业，而且就算中途无可避免地需要改弦更张，敏捷也能毫不困难地拥抱这些改变。

逃避担责

“由于缺乏真正的承诺和认同，团队成员发展出了第四重机能障碍：逃避担责。没有对于清晰行动计划的承诺，即便是最专注和最有驱动力者，也经常在同伴的行动做派与团队效益背道而驰之时，踌躇于是否出言提醒。”

不担承诺的团队可能在责任担当上表现欠佳。信任缺失时，团队成员经常向个人目标努力，而与团队目标南辕北辙。他们经常倾向于只对自己那部分工作承担责任。可以预料，会有很多相互指责，或是将错误归咎于外因的情形。但是，责任和担责相伴相生，就像我们要求团队自我指导和对其赋权那样，我们也同样程度地要求他们担起应有的责任来。根据Patrick所言，互相问责的团队保证了绩效低下者感受到改善的压力，团队成员毫不犹豫地质疑他人的工作方法以图迅速发现潜在问题，在统一的高标准上建立互相尊重，并避免围绕绩效管理和惩治行动而产生过度的官僚主义。

敏捷关注团队全员参与计划和追踪等项目的方方面面。另外，敏捷团队较小，于是整个团队都了解其各个成员几乎每天的绩效情况。虽说其理念不是要对个人施加负面压力，但绩效较差者在此情形下还是会受到大量的攀比压力，去提高其表现。当然，敏捷团队的其他成员会提供各种帮助，但不是要惩戒（或容忍）表现较差者，而是要保证团队努力工作并倾尽所能兑现承诺。另外，虽然敏捷是一种团队方法，它并未削弱关键成员的重要性。与任何团队环境一样，关键成员很容易获得尊重和同事的仰视，这种尊重有助于团队树立模范典型（在小型敏捷团队中很容易发现他们）。

漠视结果

“无法互相问责给第五重机能障碍创造了生长条件。在团队成员将其个人需求（如自负心理，职业发展，或者表彰奖赏）甚至于其小团体的需求置于团队总体目标之上时，漠视结果就产生了。”

团队中没有互信，或者大家只顾埋头自己的进展，团队就经常会在兑现承诺时出问题。可是，不能一贯专注于“整体结果”，就不可能交付好的软件。Patrick描绘了一个专注于整体结果的团队，它留得住有成就感的雇员，减少了个人主义的行为，急切地同甘共苦，从个人利益服从于团体利益中获益，并避免人心涣散。

敏捷倡导具备跨职能知识的个人与业务人员密切合作，“通过尽早和持续交付有价值的软件来使客户满意”。敏捷原则寻求围绕自组织团队中受激励的成员来建立项目。其意图是最终交付团队之承诺，而它侧重团队成员间对他人技能的相互依赖，所要求的代价只是对个人傲慢与偏见的压制。进一步说，短期频繁地交付可工作的软件，有助于减低重大失败的可能性，而每个让团队向目标进一步迈进的迭代都是愉悦之源。最后，团队回顾的实践能够帮助它“反思如何才能更有效，随之调整优化其行为方式”。当团队的低层次机能障碍消除了，就有了互信的坚实基础，和对团队承诺的负责担当，这让团队始终关注于整体结果，而无个人追求其私心杂念。

结语

敏捷方法正在帮助软件组织改善其绩效。敏捷2008大会上发布的一份近期调查指出，敏捷团队的上市时间加快37%，生产率提高16%。敏捷实践在明确追求“发现软件开发的更优办法”之余，也微妙地应对了团队机能障碍的方方面面。敏捷实践虽不直接要求人们改变其行为方式，却有助于克服一些最普遍的团队机能障碍，从而为团队绩效打下了坚实基础。

 

1. 团队为何失败, http://www.kenblanchard.com/img/pub/ignite_volume11_2006.pdf
2. 团队为何失败, http://www.asq.org/learn-about-quality/teams/overview/tutorial.html
3. 梦之队为何失败, http://biz.yahoo.com/special/greatteams06_article2.html
4. 业务团队失败的五大原因及你的对策, http://www.actionplan.com/att/SidSmithart.doc
5. 团队为何失败, http://www.7stepsahead.com/articles/WhyTeamsFail.pdf
6. 项目为何失败…以及你的对策, http://www.stellman-greene.com/blog/wp-content/uploads/2007/06/why-projects-fail.pdf
7. 计算机/软件项目为何失败, http://www.theagilerecruiter.com/3.html
8. 软件项目为何失败，而你如何令其成功, http://www.projectsmart.co.uk/why-software-projects-fail.html
9. 敏捷软件开发, http://en.wikipedia.org/wiki/Agile_software_development

作、译者简介

Tathagat Varma, PMP®，六西格玛黑带，经认证的ScrumMaster、精益（Lean）专家、改善（Kaizen）专家，NetScout班加罗尔工程公司的总经理。他自从1998年开始就试验和学习迭代增量式开发（IID），目前正在软件开发业中努力理解和糅合供应链管理、精益生产和六西格玛的原理。他主持名为Manage Well的博客，撰写关于在日常软件开发中简化管理的观点。可通过Tathagat.varma@gmail.com与其联系。

顾全，eBay中国研发中心数据仓库(IMD)开发经理。历史学科班出身，澳洲计算机硕士，工作于数据仓库行业多年。08年CSM认证后成为Agile的坚决拥护者和热心传播者。作为eBay IMD在中国的第一个雇员，顾全在eBay DW项目的开发和架构的完善中做出诸多贡献。作为eBay首批CSM和交易集市技术部门在全球的首个CSP，顾全领导了eBay首个Scrum实现，并正在推动整个组织的敏捷化。即将在AgileChina 2009大会上作名为《eBay研发团队Scrum实施经验谈》的演讲。

（本文来自《程序员》杂志0908期，更多精彩内容敬请关注0908期杂志。）