在衡量公司内部人员绩效、制定评估方案时，我们应该注意哪些地方？针对软件开发人员的评估又有何特点？

赵日磊 知名绩效管理研究专家、盛高咨询顾问

http://blog.ceconline.com/BLOG_zerost_22.HTM

绩效管理当中，捡了芝麻丢了西瓜的现象相当严重，不妨先看看一些具体的表现，再思考背后的问题。

1、忽视绩效管理的理念，简单追求表格设计。到底员工的绩效是怎么来的？是管理者考核出来的，还是在管理者的支持帮助下，通过把员工的工作与组织的目标联系起来，由员工自己创造的？

2、忽视绩效管理对组织战略目标的贡献而简单追求职责考核。绩效考核到底是为什么服务的？是为监督员工的工作，还是为实现组织的目标？

3、忽视绩效管理的改善功能，而单独强调扣罚功能。作为管理者，你的作用是什么？你是如何理解管理这个概念的？是与员工一起，帮助员工成长，通过员工完成工作，还是作为员工的监工，他们不努力的时候就抽上一鞭子，训斥一通，以体现你作为管理者的威严？

4、忽视重要工作的考核，而简单追求量化。绩效考核到底要做什么？是改善工作还是走过场？是“电话响三声之内就接起”重要呢还是“电话沟通的质量”重要？

5、忽视过程沟通，一味强调填表打分。员工的绩效是通过管理者与员工沟通过程创造的，还是管理者打分判断出来的？

吕建伟（阿朱） CTO、《走出软件作坊》作者

http://blog.csdn.net/david_lv

一个成功项目的重要标志是：质量、过程管理。我们程序员从代码编码技巧，架构师从架构，项目经理从项目谈判技巧、项目需求调研与讨论、项目目标和范围界定，高层人员从运营模式，多个层面去改善质量和过程管理这两个核心点。

质量，有软件可交互性质量、软件代码稳定质量、软件性能质量、软件安全质量、软件可安装配置性质量、软件文档质量、项目文档质量、项目实施质量、项目培训质量、项目服务支持质量。过程管理，包含项目目标和项目范围的界定、项目多方协调、项目进度报告、项目进度控制、项目异常排除、项目验收、项目回款、客户满意度调查。

从通用定性方面来讲，项目经理来评估组内每个人的工作态度、工作方法、团队合作、客户沟通、计划执行、业务学习、经验总结。从每个角色来讲，项目经理能够量化评估的就是：项目业务功能设计变更和项目总体进度执行。因为项目功能多次变更、变更幅度大，就会剧烈影响开发、测试、文档、实施多个环节，也会影响到项目总体进度。而项目经理，承担着项目的整个总体责任，所以定性的更多，如项目协调、项目范围界定、项目异常排除、项目验收、客户满意度调查，都是通过项目经理的组员、上级、客户来多方面调查问卷评测的。能够定量的指标还太薄弱，这是需要大家一起积极摸索探讨的。另外，我在《走出软件作坊》一书中也谈到，国内目前大部分IT 公司以中小型私营企业为主，在绩效奖罚与考核上也无法比较好的对应，老板也会在利益与全局考虑之间平衡，所以一切都需要更进一步发展。

黄晶 校内网CTO

http://topaz.xiaonei.com/?id=85432256#nogo

对软件开发人员的考核，与所选择的开发过程有很紧密的关系。我们用Scrum比较多，每个项目都有Scrum白板，也有其他一些管理系统, 便于大家平时沟通。从开发的考核来看，通过这种过程的管理，我们在每个阶段或是每个产品的milestone坐下来看时，能很清楚地知道：做了哪些事情，有多少工作量，有多大难度。

对互联网公司来说，线上的运营很重要。开发质量是不是过关、责任心是不是足够强，只能通过在线的评判。因为我们自己去做压力测试也发现不了什么问题，所以我们通过追踪故障率、整体的可用性，来评判说开发人员做的事情是不是达到了对这个项目的要求。通过这些指标，统一给程序员有一个分级，然后具体会反映在各个方面。经常通过一些精神上、物质上和个人职业发展上的一些激励，来对做得好的人予以肯定。如果一些项目做得特别好，我们会对整个团队提出表扬，当然对团队的表扬会落实到每个人身上。比方让大家去庆祝一下，或者在适当的时间给一些激励。

我觉得互联网团队不存在太复杂的管理问题，主要是激发每个人的潜能，就是让每个人都把工作当成他自己的事情来对待，都有很强的责任心，尽可能地尽他自己最大努力做到尽善尽美，这样的管理就可以了。

谢克人 新锐国际董事长

人员的评估是一个公司最核心、最谨慎的工作。人无疑是一个公司最宝贵的资产。所谓“因人设事”，讲的就是有合适的人，某个项目才能开展。没有合适的人，再好的项目也无法进行，再好的机会也抓不住。所以，对人的考核一定要谨慎。

如此慎重，是因为一个公司的制度只有80%左右的约束力，其他的要靠情感沟通。中国的管理理论比较落后，但中国人很早就懂得“人心”的重要。大到战争、国家的管理，小到一个大家族的管理，抓“人心”遍布每个环节。西方讨论“人”的重要性的理论汗牛充栋，各个企业也对员工非常重视。外企待遇好、尊重人、文化好，是中国人都知道的事实，能进外企工作是每个职场人的理想。这些都证明一个要成功的企业、一个要成功的团队必须慎重对待每个员工。

绩效评估往往意味着紧张、争斗、不公，给员工造成很大的压力，甚至造成彼此的不和，这是评估的最大忌讳。作为评估的一方首先要从正向的角度看待评估这件事情，将评估变成一次和员工沟通的机会，探索过去工作的不足，探讨如何改进。这样的话，员工即使评估结果不佳，也会心服口服，同时对未来充满希望。评估者还会有一个另外的收获，那就是在沟通中发现管理或项目设置的不足，这将对整个团队取得更大成就奠定良好的基础。

另外，设计一套科学、可操作、透明、公平的考核指标和程序，是取得良好考评结果的支撑点。这需要HR和相关部门一起讨论，慎重决定。

软件人员是必须将“心”和“工作”完美结合来考核的一群人的代表。创造性、学习能力、沟通能力、理解能力、逻辑思维等是衡量一个软件人员是否优秀的重要指标。这些指标在每天都会有不同的体现。所以，软件人员的考核首先要注意的是他们平时的表现，其次才是在重大项目上的表现。作为考核一方来说，要将这二者结合起来，并辅助另外的量性指标才能客观、公平地考核好一个软件人员。

（本文来自《程序员》杂志2009年3月刊）

本期封面报道：开发者的五项软实力

大局观、管理、沟通与协作、学习与思考、职业素养，对于成就你的事业和人生，价值绝对不可估量。本刊编辑部针对这5项软实力，发布了数百份调查问卷，采访了来自海内外的诸多杰出精英，希望他们切身的经验和体会，他们独到的洞察和解，能助你打通职场困境的任督二脉，在新的一年里大展宏图！

专题布局：

（1） 开发者的五项软实力

（2） 三人谈：青梅煮酒论软实力

（3） 具备大局观方能洞若观火——FreeWheel创始人/CTO于晶纯访谈

（4） 张亚勤：高科技人才管理的五个方程式

（5） 站在管理者的角度，让你走得更远——赛门铁克中国研发中心总经理许明专访

（6） 世界顶尖运动队教练的成功秘诀

（7） 软件开发者的软实力：沟通与协作

（8） Joel Spolsky：我的七个建议

（9） HR与猎头眼中的开发者职业素养

（10）从能力到素质——谈谈个人能力的系统性

（11）开发者的人品问题

（12）从性格看技术人员的软技能

月度关注：持续集成的力量

据说懒人推动了科技的发展，在软件开发领域，正确应用持续集成的力量，将使项目产生更多的自动化。

专题布局：

（1） 为什么要持续集成？

（2） 持续集成与配置管理策略

（3） 持续集成工具概述

（4） 大型复杂软件产品持续集成的实践与反思

高端视点

（1） 创新成就专用设备

（2） 基于需求的测试是软件测试的本质

（3） 创新是优秀产品的DNA

报道

（1） 最熟悉的“陌生人”Xen——开源虚拟化之父Ian Pratt访谈

（2） 构建中国“云”——电信业首吃螃蟹？

（3）携势先动，厚积薄发——走进北京国双科技有限公司

（4）两岸三地星光大典 群星闪耀齐聚微软——微软MVP Open Day活动纪实

程序人生

我的半张心灵地图

实践

（1）月度产品会的最佳实践

互联网企业的系统、产品和项目管理与以往的软件企业及产品有着完全不同的机遇和挑战，这些差异点，历来是一个备受关注的话题。从本期开始，本刊将以系列文章形式，分享淘宝网在大规模互联网系统研发方面的经验和实践。

（2）以人为本的敏捷组织

德鲁克曾反复强调：现代高科技企业，“知识工人”是最重要的资产。软件开发组织更是如此。敏捷强调“个人和交互胜过工具和过程”，那么敏捷组织应该如何做到以人为本呢？

（3） 基于MOSS和SSRS创建高性能商务报表站点

（4）Rails性能优化之路

本文从缓存、内存、数据库、页面、多线程、服务器等方面介绍了性能优化中的实践经验，并提出“更近、更快、更少、平衡”四大实践原则。

（5）有效的测试者

当系统复杂性不断增加、代码行数越来越多之后，对应的测试用例数目飞速增长，面对这样的状况，测试人员怎样才能做到快速、准确、高效？且看本文作者的心得体会。

VSTS团队兵法专栏

协同实施，制胜之道

——Visual Studio Team Architect团队的敏捷软件开发(3)

一分钟先生

技术人员如何应对工作中的冲突？

架构

架构师接龙：盛国军VS.栾义来

技术

（1）NoSQL的模式

过去一两年，一些用于存储大规模数据的数据存储机制逐渐成形，它们与RDBMS模型相去甚远，被统称为NoSQL。提炼出各种NoSQL方案背后共通的技术原理，有助于更深刻地理解它们对应用程序设计的内在影响。

（2）微软UI自动化测试的技术演变（上）

Windows平台的桌面开发技术，从最原始的Win32 SDK，发展到.NET WinForm， 一直到今天的WPF和Silverlight，发生了翻天覆地的变化，相对应的UI自动化测试技术，也随之演变。

（3）三维GIS的困境与出路

自Google Earth发布以来，三维应用系统很快得到业界青睐，但同时也有很多质疑其“花架子”的声音。到底三维GIS有没有出路？要解决哪些问题才能走向成熟应用？作者以Realspace GIS的真实实践，告诉你一个成功的解决方案。

（4）REST不容易？数据共享网络与AtomPub协议

REST风格有其优越性。但作者在开发中却遇到了一些难以解决的挑战，有些是AtomPub的问题，但有些却是采用REST风格的Web服务API所共有的。

调试之剑

在调试器中品味计算机系统的睡眠过程（中）

移动专栏

OPhone应用的网络连接管理

产品报道

（1） IBM Rational推出下一代项目及组合管理解决方案

（2） 做人人都能用的BI

评论

漫谈IDE

更多精彩内容，敬请期待1001期《程序员》！

9月7日，谷歌中国新的管理团队集体亮相参加新闻发布会。新的管理团队中，在Daniel Alegre的团队中，现负责谷歌大中华区销售业务的全球副总裁刘允博士将主管谷歌大中华区商务及运营，杨文洛博士负责谷歌在中国工程与研发方面。

Daniel Alegre为Google（谷歌）全球副总裁，负责谷歌在整个亚太地区的销售和运营业务。此前，他是主管谷歌拉丁美洲销售的副总裁。加入谷歌之前，Daniel Alegre先生曾在贝塔斯曼媒体公司工作七年，在线上和线下音乐及数字业务领域担任过多项重要职务。Daniel拥有哈佛大学商学院工商管理硕士（MBA）及哈佛大学法学院法学博士学位。

刘允博士为Google（谷歌）全球副总裁。刘博士2008年1月加入谷歌，担任谷歌全球副总裁，主管谷歌在大陆、香港和台湾的销售和运营。在加入谷歌前六年，刘允博士一直担任韩国SK电讯中国区首席执行官。加入SK电讯之前，刘允博士曾在美国FreeMarkets公司及新加坡电信公司担任高级管理职务。他于2006年获得“中国信息产业年度经济人物”的称号，2007年获得了“蒙代尔世界经理人成就奖”的荣誉，2009年荣获“十大中华经济英才”特别奖。

Google（谷歌）研发总监杨文洛博士，将主管中国的工程与研发。他于2007年3月加入谷歌，负责谷歌在中国和亚洲的搜索及基础架构领域的研发。杨文洛博士在图像/视频处理、数据存储和压缩等方面成绩卓著、蜚声国际。杨文洛博士拥有普渡大学电气工程学士学位和普林斯顿大学电气工程博士学位。

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

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

在本文中我分析了团队机能障碍的模式，这一模式由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期杂志。）