有人说，实践敏捷的根本不在于敏捷本身，而在于理解敏捷背后拥抱变化的基因。确实，使用敏捷，那么你就应该知道为何敏捷。如今，国内很多敏捷团队没有真正的了解敏捷的精髓，也说明了为什么在使用敏捷的过程中并没有真正的“敏捷”。所以，不但不能真正的解决传统开发的一些问题，反而新增加了更多的问题。因此，51CTO记者采访了具有17年软件研发、管理咨询经验，擅长在实际环境中应用敏捷开发实践的专家陈勇老师，为网友们解读敏捷在开发实践及管理中的一些问题。
陈勇，17年软件研发、管理及咨询经验，擅长在实际环境中应用敏捷开发实践。具有丰富的工程技术与项目管理实践经验，从其程序员、项目经理、CMMI/FPA功能点估算/敏捷咨询师、事业部总监、副总经理等各种技术与管理岗位获得的一手经验，令其可以站在企业管理者的角度，以更广的视角来理解敏捷开发，并能配合和推动非研发部门协作推广敏捷。
工作经历：
- 曾以技术骨干和项目经理等身份，组织和承担开发了国庆50周年直升机编队指挥系统、空军一基地GPS数据源系统、清华同方CCTV数字电视条件接收系统、航空材料研究院无损检测系统等项目，并在其中某些项目中实践敏捷。
- 曾在清华同方、普天集团、亚信科技等企业担任EPG骨干、组长；曾在斯福泰克、DNV ITGS等机构担任CMMI/敏捷咨询师。
- 曾在中国系统与软件改进年会 、中国软件技术大会、敏捷中国大会、MPD等国际国内会议从事敏捷演讲、翻译或主持工作。
- 在任泰克赛尔软件公司中国部门的咨询总监、ALM事业部总监、副总经理期间，主管敏捷研发管理工具的市场、销售、支持与咨询活动，在盛大、金山、腾讯、汉王科技等知名企业深入推动其工具应用与实施活动。
- 当前正在作为产品经理、架构师带领一个小型团队，从事“火星人敏捷开发在线服务”的研发工作。很多课程与咨询中的最佳实践，均来自于其之前及当前参与的实际项目的一线实践。
以下是采访内容：
记者： 在使用敏捷当中，很多人都是看中了它的成本控制，能够降低在项目开发中的浪费，但是往往适得其反，不但没有降低，反而增加了开发成本，那么在成本控制这块您怎么去理解？
陈勇：看看清楚敏捷开发对成本的控制，先要看之前的方法有何问题，比如瀑布模型。
对瀑布模型而言，有两个地方控制不好成本：
一，瀑布模型中，如果项目签的需求太多而价格太低，往往在中后期会通过工时统计等发现入不敷出，但由于普通模型这时候正处在编码末期或测试前期，因此很难就此停下，或删除某些次要功能继续开发（因为在晚期删除功能往往成本很高）。
对这个问题，敏捷开发解决得比较不错，也很容易实施。渐进式交付使得“随时”停止开发并进行发布变得可能。
但要注意如果优先级排序不当，也可能会面临“重要的功能还没有开发，次要功能却开发了不少”的尴尬境地。
另一个问题是提前交付可以换回一些款项，但并不能彻底解决成本超支的问题。这时候应该配合类似功能点分析这类的方法来解决。也就是早期用功能点报价；中间如果通过计数发现由于需求蔓延、变更等原因导致需求的总量上升了，那么乙方有权要求追加款项，或删除某些次要功能。这种听起来不可思议的想法，在某些国家如芬兰、澳大利亚都是很普遍的。可能我们会抱怨说甲方不赞同或不理解这种过于“偏技术”方法，但如果连乙方都不赞同不理解，就不能单方面责怪甲方了。2012年底中国刚刚推出了基于功能点的软件成本估算相关的国标，试点领域是政府软件开发。虽然现在还没有对阶段性付款提出方案，可以已经可以看出未来的大趋势一定如此。
二，瀑布模型中，如果需求变更比较频繁，初期付出众多工作量的需求、设计常常被不断返工，进而又引发编码返工，造成成本上升。
敏捷开发解决这个问题的方法很简单：减少早期对需求、设计的投入，尽量早让产品“可运行”以便让客户提出反馈意见。
不过这个方法极其容易被“用过头”，比如有些团队可能放弃了必要的需求和设计，导致由于蛮力编码造成编码混乱而不断返工，整个产品则像一个没有骨架的沙雕一样难以
做大。
正确的方法是：在渐进式开发、渐进式交付的同时，做渐进式需求和设计。我们要避免的是需求和设计返工，而不是需求和设计活动本身。因此对大中型产品而言，应该保证每个阶段的编码之前都有简单设计用以保证编码的正确性；而被客户确认后的功能至少要“后补”需求和设计，以备未来回溯。这样既避免蛮力编码返工，又能避免推翻设计的返工。
记者：做到敏捷开发，每个团队都要经历一个转型期，那么在转型期还需要每个团队根据自身的不同，找出合理有效的解决方法。一般如何去处理这个问题？
陈勇：这是培训和咨询过程中最常见的一个问题，也是最难回答的。有几个步骤可以帮助找出合理有效并适合团队的方法。
一、对有效性进行定义和评价
完全量化管理可能做不到，但“半年后，我们希望能每月发一个可交付版本”或“把总体测试时间降低一半”这类明确个别定义还是可以找到的。当然不同团队首批目标不同，首批要实践的内容也不同。但有了目标，就可以防止团队借口“项目特色”，言敏捷之名行混沌之事。
二、阶段性检查和推进目标
前几个迭代往往离目标很远，很容易忙了半天才发现走偏了。这时候可以设置某些临时目标来作为“路标”。比如，假设某团队经常处于“很多活都在干，但没有一个干完了，因此也不能交付”的状态，而几个月后希望做到“当月计划功能的交付比例达到80%”，那么可能需要这样几个路标（实际工作不只如此）：
第一个月：实现任务的看板管理
第二个月：实现基于故事的看板管理
第三个月：当月计划功能交付比例达到50%
第四个月：控制在制品数量在2N-1以下（N是团队人数，此目标即“同时开工的工作量
不超过2N-1个”）
……
第N个月：当月计划功能交付比例达到80%
在这个例子当中可以看到，如果一上来就直接设定“当月计划功能交付比例达到50%”之类的度量数据，可能不但很难达到，甚至可能由于没有看板管理而不能度量。
三、同时选择超过一个团队进行试点
敏捷开发的试点过程千变万化，如果只找一个团队试点会有问题。如果失败了，大家会以为敏捷不行；如果成功了，大家会照搬经验。
所以最好的方法是让若干个团队各自基于自己的目标进行试点，如果其中有多个取得成功，大家会意识到原来成功的方法有很多种，就能灵活应用在自己团队中进行实验和推广了。
四、需要对“商业目标”与“一线实践”有很深入的理解
做到这一点非常困难，然而偏偏这一点又是成败的关键。
经常见到很多团队或成员一拥而上开始试点某个局部实践，有时候是Scrum中的扑克牌估算或每日立会，有时候是XP中的自动化测试或结对编程。但做了一段时间，由于没有目标，尤其是没有那些让团队听了之后就不会放弃的目标，很快就坚持不下去了。
要培养商业目标意识很难，甚至很多从业之前没有做过高级管理职位的敏捷培训师或咨询师都不具备，更不用说普通一线工作人员了。一种做法是让高层比如部门经理来宏观协调敏捷的实施，而不要完全自下而上。高层经理的职业特性保证了他们会潜移默化地关心最终实施的效果胜过实践本身。说起来，“效果胜过实践”本身就是敏捷宣言中“可工作软件胜过繁杂文档”的现实体现。
五、要注意敏捷开发的生态系统问题
刚才提到尝试个别实践经常失败，一个原因是因为缺少目标只关注实践，另外一个则是忽略了与此实践相关的生态系统。
比如每日立会，看起来非常简单，但实践起来困难重重。比如为什么我要告诉别人我的进度？为什么我要告诉别人我遇到的困难？谁因为什么原因会提供帮助？……这些潜在的问题，都需要相应的团队模型来解决。敏捷开发生态系统就是用来描述各种活动之间的关系的，这个在我的“敏捷开发生态系统”系列博客中有较为详细的描述。
#p#
记者：敏捷过程中有一个我认为最重要的部分是需求拆分，您能谈谈如何进行合理的拆分吗？
陈勇：需求拆分是个业界难题，在敏捷开发领域是如此。尽管每个敏捷流派对这个问题说起来都头头是道，但是要说谁有一个过目不忘的好方法，还真没有。
真正解决需求拆分问题的关键有两个：拆分后的颗粒度如何控制，拆分后的需求结构如何表达。前者可能问得比较多，因为多数程序员都要关心；后者只有产品经理会关心，所以显得不太突出，但对大产品和持续开发的产品而言则是个关键问题。
一、颗粒度问题
这个问题在敏捷框架下基本无解。
但在功能点分析（Function Point Analysis）中是一个基本概念。FPA通过对软件中的“业务数据”以及对其进行的“业务操作”为基本单元建立了颗粒度的概念，进而建立了规模的概念。这些概念的应用成熟度、推广程度、数据积累量（公开的在10000个左右，在咨询公司手中但非公开的在50000个左右，实际使用量不可估量）都远远超过敏捷开发或其他体系提出的方法，包括“故事点”。而且“业务操作”的概念非常接近用户故事，也包括如减少依赖、完整交付客户价值等描述。
下面举一个例子来看功能点到底是什么。这里将略去功能点中对数据、操作的复杂细节分析过程，而只说大概。
假设在一个OA系统中需要管理“用户”“角色”“权限”这三种业务数据，那么他们就是业务数据；而对他们分别进行的“增删改查”就是业务操作。比如“新建用户”“列出所有用户”都是业务操作。“业务”这个词在这里是相对于“技术”而言的，比如“新建用户”对客户而言是一个容易理解、认可的操作，而且客户管理员会告诉我们：
“是的，我现在每天都在新建用户，因为最近正在招人”而不会说“是的，我最近每天都在数据库表中新建记录，还会同步更新联系人数据表，因为最近正在招人”，虽然后者也的确发生了，但却不是客户日常工作的内容。
更神奇的是，“新建用户”这个操作，在无法获得更多细节的情况下，可以假设工作量为4人天（在OA系统中，其他系统有调整因子）；而统计还表明，“用户”及所有与之相关的操作如刚才说的“新建用户”以及其他“删除用户”“列出所有用户”“编辑用户”……的总工作量（从需求到部署）大约是40人天，也就是2个人月，即使暂时不能确定到底有多少个操作。而“用户”“角色”“权限”及其所有操作完成的工作量自然就是大约6人月。尽管每个数据或操作的时间可能会有出入，但总体规模则误差不大。
这得益于大数定理及众多统计数据的分析结果。本段内容的详情可在Google查询“nesma”（一个总部在荷兰的世界第二大功能点组织），这个简化体系称为“Indicative Function Point”（指示性的功能点），在其网站上有荷兰语和英语介绍。
如果对用户故事的定义（而非“业务操作”的定义，因为后者更完善、严格）略作约束，则可以迅速与功能点中的“业务操作”兼容。兼容的结果有两个，首先是很容易把握颗粒度，其次是功能点与工作量的比例关系极佳，可以迅速推知工作量。
二、需求结构问题
在敏捷开发中有一个不完善的答案：Product Backlog 和 Sprint Backlog。前者是整个产品的待开发项，后者是当前迭代的待开发项，两者内部都按优先级进行排序。
这个答案对项目经理（可以模糊理解为Scrum Master）和开发人员足够用了，因为他们主要关心时间上的开发问题，也就是现在让我做什么，什么时候要的问题。但对产品经理（可以模糊理解为Product Owner）而言，时间是一个维度，空间则是另外一个维度。
所谓空间维度，就是系统-子系统-模块-大需求-小需求……之间的关系问题，这完全不是一个一维表格能解决的。由于敏捷开发主要是一线开发人员和项目经理发明并推动的，所以空间维度一直被忽略。但这是需求分解过程中一个绕不过去的问题，因为人们不可能面对一个一个一维表格回答这个问题：“我们所有的功能都包括在这里呢吗？哪部分还略显粗糙希望继续分解？这些大需求包含哪些小需求？”
在UML中的答案比较完善，“用户 - Use Case”（人-功能）很好地把一批相关的功能联系起来。虽然只是非常简单的表达，但比把几个毫无关联的故事按优先级排在一起，或把几个密切相关的故事相隔十万八千里放置还是进步不少。UML中的模块则是一个更宏观的需求“目录”。
FPA虽然没有需求关系表达，但如果把“业务数据 - 业务操作”作为一个树形结构，很类似把UML中的“实体 – Use Case”作为一个树，形成“数据-功能”的关系。不过，这个体系没有提供更宏观尺度上的需求结构问题。
由于功能点、UML中的模块用例等概念都是有严格、确定化的定义的，所以分解的过程井然有序，很少出现“这个还要继续分吗？”“这样分是不是颗粒度太粗糙”之类的问题。我们自己正在做的项目需求就是借用FPA的业务数据-业务操作作为主要分解关系，上面再加上我们自己定义的子系统-模块两个级别形成了一个“故事树”。这个故事树比我之前所做过及所见过的任何其他方法表达的需求结构更为清晰。因此敏捷开发应该吸取或者配合这些方法，至少是其中的一部分思想来完成需求分解。
很多时候我们会觉得引入较为严格的定义会“有限制太难做”，但其实更难做的是“无规则无限制”下自由发挥。
记者：敏捷开发中需求拆分之后，任务应该怎样分工？
陈勇：即使都是使用敏捷开发，任务拆分和分工的方法也会因行业、产品的特点而有所不同。
在纯软件或技术相对单一的产品中，需求拆解到4天左右（也就是前面提到的“一个业务操作”的规模）就可以分下去或领取了，因为人们比较容易估算4天左右的工作量，也容易跟踪。在这种情况下，如果一个人同时负责几个“业务操作”，应该分解为多个任务来完成，而不是一个。因为这些业务操作可以独立完成并交付，合在一起不但不能持续交付，也会使得进展不透明。但再进一步划分没有必要，因为再划分就不能独立交付了。“独立性”是FPA中对业务操作的一个约束条件，如果按照FPA的概念来划分任务，会自动满足独立性。
在复杂环境比如嵌入式研发（涉及软件、硬件、工业设计团队）或游戏（涉及软件、美术、脚本、策划团队），需求不能直接当作任务分下去，需要做进一步的分解。这里的分解目的是把不同工种的活分配下去，对其跟踪的过程则可增进各部门配合时所需的透明度。
也有一些团队喜欢把任务分解到短至1～2小时的时间。本人没有与这样的团队进行深入探讨以了解其这样做的动机及收益是什么，但要注意“更小的任务”不等于更敏捷。我们经常说敏捷开发有利于项目透明，但要知道透明的主体是“项目外部的人”，比如产品经理、高层领导；而开发人员本人，或者小团队的若干个人之间，任务和进度本来就是透明或半透明的。因此把详细技术细节翻个底朝天并贴在白板上很可能不但于事无补反而添乱，不如把有限的管理时间用在“对外表达需求的完成情况”或“各部门的进展及需要什么相互配合”上，也就是我们之前说的两种情况。
总之，对任务的分解应该本着“需要”与“必要”的原则。不能因为想“更敏捷”而采用“更小的任务”。
记者：Sprint会议是实践scrum中最重要的事件。您认为Scrum会议在团队中应如何进行的？
陈勇：要做好计划会，应该先建好团队模型。
计划会是少有的团队齐集一堂进行的活动，无论团队模型是怎样的，都应该有助于大家以集体的力量完成计划，并完成计划的任务。
因此，一些看上去很敏捷的团队模型或做事方法，很可能是很难鼓励大家做到这一点的。比如：所有队员都是平等的；大家在会上投票取平均值作为估算结果（还有一种做法：会上不需要估算，会后领取的人自己说了算）；会后大家主动领取任务；领取的任务大家互相不干涉，自己愿意怎么做就怎么做……这里边存在什么问题呢？
第一，“所有队员平等”的团队互助的动力从哪里来？人们一定会说：都是在一起工作的同事，怎么会没有互助动力？我们曾经在一个团队实施代码审查，而且是我之前多次提到的那个最好的139团队，很快发生一次事故：一大段4000多行但包含4000多个常数的烂代码逃过了检查者的眼睛进入了代码库，并最后引发客户现场的Bug。当询问代码审查者为何让明显存在问题的代码通过检查？代码审查者很无奈地说：“我刚来不久，虽然我觉得这些代码有问题，但我感觉大家都说他（编写者）是个高手，我也就不想说什么了。其实我本人也觉得这些代码有问题”。这件事情促使我们后来形成了139团队，就是形成层次团队，由师傅来审核徒弟的代码，出问题师傅负责。这不是说所有团队一定要如此，而是说不能简单地把互助建立在“雷锋精神”上面。
第二，集体估算的目的何在？很多人认为是领导放权发扬民主，所以投票+平均值就体现了这一点。但如果一个人估10人天，另一个人估计1人天，结果到底是多少呢？总不能真的是5.5人天吧？所以估算的目的其实是想知道有没有更快的方法，有没有人在走弯路……如果为期一天的计划会耗费整个团队10多个人天，但却避免了上百人天的弯路损失，就算真正物有所值。我遇到的单个任务的最大差异是20人天比0.5人天，很可惜他们不做敏捷开发也不做估算，是任务接近尾声的时候被偶然发现的，只用了0.5人天就重写了。在一个139团队中，一般师傅要和徒弟用敏捷估算扑克估计每个任务的工作量；如果刚才这个任务出现在139团队中，师傅不会取值（20+0.5）/2，而是通过与徒弟讨论，让徒弟学会如何用0.5人天来完成这个任务，因为徒弟浪费的时间最后要算在整个师徒小组身上。如果不是139团队，也要找到类似的人们参与争论和坚持自己正确见解的动力。
第三，剩下的“主动领取任务”、“互不干涉”等，也要进行相似的分析，不能因为“看上去很自由很敏捷”就采纳。提出这些实践的团队可能与我们所处的情况差别很大，未必能拿来就用。我曾经用过“自由领取任务”，那是在10年前的一个假期里边，我邀请自己关系很近的两个老部下来帮忙做一个软件；一些零散任务就被单独拿出来，谁先做完手头工作就自由领取，其中一个人领取了8个中的5个之多。但在之后的每一个项目中，我都会先想一想，团队是否允许我再次采用这个实践。
团队模型理顺了，计划会所需的共同计划、集思广益、团队协作才能做好。
记者：在敏捷开发方法中，Scrum和XP我个人认为比较常见，您能介绍下Scrum与XP的最大区别在哪里？在实践中Scrum与XP只取其一，还是两者都取，或者全都抛弃？
陈勇：Scrum主要是关于需求和项目管理的，而XP则主要是技术管理。
Scrum中关于Product Backlog的全部及Sprint Backlog的形成过程、评审会大部分，可以理解为需求管理内容，包括需求开发，分解，描述，排序以及进展跟踪的过程。而估算、每日立会、燃尽图等内容则属于项目管理。
XP则主要是技术管理问题，不过其结构不明确，不好分类。
这个差别也可以解释Scrum为何易于推广：因为其整个体系很清晰。比如在我的培训课程中有一个贯穿始终的练习，用三个需求的描述、分解和估算过程来演练Scrum。这个练习能从第一天上午10：00左右开始，断断续续穿插于培训中，一直持续到第二天中午；要用一个练习把所有或者只是大部分的XP实践串联起来则几乎是不可能的。另外Scrum宣贯起来也不需要大的技术革命，主要是人员职责的重新描述，部分管理活动如计划、跟踪的引进，因此门槛很低。不过反过来，由于缺少实际的技术改进，若只得其皮毛而没有利用团队、过程的变化来真正促进开发，那么Scrum失败的概率也很高。
Scrum在商业运作上也更成功。这应该归功于Scrum的发明者是项目经理或更高级别的人员，而XP则主要是一线员工，甚至说是Geek们不为过。Scrum推出了认证的Scrum Master和Product Owner两种认证，由于体系相对完整，认证课程目标听众的收入也相对较高，所以推广起来比较容易；多数咨询师更容易理解Scrum的理念而非XP的，也使之得以快速推广。
不过长远看来，团队，过程，技术三者密不可分。Scrum覆盖了前两者中的一部分，但如果没有持续集成、自动化测试等方法的支撑，迭代交付将很难完成。所以，未来应该会有并存的需要，即使不再以当前的两个名字存在。
#p#
记者：拙劣的度量指标会产生严重的后果，敏捷度量指标也是一个很有争议的问题，以您的经验如何去解决这个问题？
陈勇：有多个层次的指标可供衡量，下面从基层到高层一层层剖析一下。
一、基层度量
对最基层活动而言，一般所有度量均不用于个体考核，而只是用于改进。比如个体的缺陷率、工作完成量、按时完成率等。
之所以这样做，原因是不希望面向个体的考核破坏了团队中原本用来提高生产率的团队协作。团队协作可以消除个体错误，通过共同估算让高手的技能流向新手，等等。如果个体考核让人心有挂念，会产生问题。
不过一个不可回避的问题是：不管你们敏捷开发怎么说，但财务终究要把绩效奖金（假如有）发放到个体而非团队的账户上，怎么知道谁应该发多少呢？在一个10个队员且关系互相平行的团队里边，的确没有办法知道，因此也不得不面向个体考核，并最终不可避免地毁掉团队协作。
但在一个139团队里边，答案比较简单。139团队，就是1个项目经理，带3个高手（师傅），每个高手再带3个新手（徒弟）；师傅全权负责自己及3个徒弟的工作，从进度，设计到质量；师傅会选择关键时间点与徒弟碰头，以便用最少时间解决最大的问题（这种活动称之为“松结对编程”，在我的“敏捷开发松结对编程系列”中有详细描述）；师傅对徒弟的代码进行代码审查；平时徒弟有问题会师傅。在这样一个团队中，项目经理收入最高，师傅次之，徒弟最低。薪水相对固定，如果位置没有变化，无论自己一个人多编码了还是帮别人太多导致少编码了，都差不多。因此要想拿到高薪，不是在短期内多编写几行代码或关闭几个Bug，而是看长期：新人先要达到独立工作能力，然后帮助团队扩张也就是自己带徒弟成为师傅，最后成为可以独自担当一种业务的人也就是项目经理。在这种团队中，人的收入增长不是通过内部竞争，而是通过内部协作做到的。
因此它是一种兼容敏捷团队精神的个体绩效考核方法。
二、外部度量
正如前面所说，外部度量是为了让团队对外透明而做的度量。有这样几个原则：只做外部看得懂的度量；只做外部有人看的度量；尽量少做度量。
典型的外部度量是给PO也就是产品经理所作的用户故事的完成情况的度量，比如白板上处于完成状态的故事的数量。这里说故事而非任务，是因为对产品经理而言，任务完成没有意义。
生产率也经常是一个被度量的内容，但现在尚无好的方法。有些团队经常使用“故事点”来做度量，方法是：先挑选一些以往的故事作为典型故事；为每个典型故事分配一个点数（一般是当时完成此故事的天数）；每次估算新故事时查先看更像哪个典型故事，然后再根据难度差别为新故事设定一个点数；实际完成后，点数/天数=生产率，也就是实际完成点数的速度。这个方法看似有效，但因为大家对典型故事的熟悉程度差别很大，典型故事也很难选择，导致实际使用的人很少。另外一个问题是不同项目的典型故事和点数是不通用的，因此无法做比较。好不容易做了一个想对外发布的生产率，却无法横向比较只能自娱自乐，显然存在问题。未来，这个问题可能会被功能点生产率解决，但现在还没有看到有人尝试。我们自己做了一些宏观尝试，但没有每个迭代都做。
此外还有一些度量，但取决于实际的需要。比如在线运行的网络游戏，会度量迭代交付周期长度（直接影响响应时间，因此一般越短越好）。这些度量不全是明确量化的，但公司上下都能说出一个大致的数字来，因此也算是度量。
三、业务运营与收入度量
既然敏捷开发说是“交付客户价值”而非文档或代码的，那么一定能改善营收或其他运营指标。
比如市场占有率，每日点击数，平均在线人数，每活跃用户收入……等等，这些营收应该都是做敏捷度量的人所需要关注的。Scrum设置了PO来收集、描述、排序最重要的需求，又安排团队在自组织下高速生产出来，通过评审会后交付给客户。因此如果这一切都是真的，没有理由在实现敏捷开发后业务营收不变或下滑。当然可能很多因素制约了企业的营收情况，但如果既不度量也不关心，直接来一句“由于情况很复杂，因此企业营收与研发没有直接关系”，显然只能被作为自我否定和消极逃避的借口。
现在有些团队如网络游戏和搜索引擎公司，已经把这些数据引入了开发团队的度量中。但一般不做绩效考核，而是让大家知道最近我们的研发在市场上的实际反馈如何。
四、内部创业
任何时候想度量的时候都要问：为什么要度量？答案是：度量的目的是为了改善目标。
那么如果说企业的终极目标是盈利，而却有一种方法不需要度量就能提升盈利，那么应该怎样？当然就不用度量了！目标永远比方法要重要。
比如现在网络游戏团队普遍有一个政策：20%的营收归项目作为奖金。一般这个数字从几十万到上亿的规模，而团队往往不到100人。他们不在通过繁杂的绩效考核系统中的度量项发放奖金，而直接把收入变成开发人员的动力。这种方法跳过了所有繁琐的度量过程，直击问题实质，是一种不度量而改善目标的典范，可以理解为敏捷开发“可运行软件超过繁琐文档”这种尝试弱化中间过程的思想的产物。
当然，即使不能“内部创业”，也一样能做到类似的效果。比如降低程序员的基本工资，代之以把公司产品销售的一部分钱拿来做奖金。程序员自然就开始关心客户需求，尝试理解客户到底要什么不要要什么，尝试自觉改善质量防止客户流失，尝试自己带徒弟以便让团队成长进而增加产品竞争力……很多效果是通过度量都难以进行改善的。
最后这个问题的答案，其实回到了问题的本质：敏捷开发提出的目的，其实还不是敏捷宣言中的那四句话左侧的部分（个体与交互，可运行软件，客户协作，响应变化），而是通过这四点来帮助企业提高营收。因此，敏捷开发的度量，换言之敏捷开发要改善的地方，不能只是一线工程实践，而应该是“客户价值”的改善，也就是营收的增加。否则敏捷开发就可能长期处于基层游击队活动，在敏捷热潮过去之后，被证明又是一个重过程不重结果的空架子而已。
记者：您是否能谈谈在项目中，敏捷测试人员的职责和技能要求？
陈勇：关于这个问题，有趣的是：“测试活动”比“测试人员”在敏捷开发中出现的频率更高。原因就是敏捷开发中提倡跨职能，也就是所有人都对开发、测试负责，从测试活动的目标的转变上就能看出来。
传统认为，测试人员是帮开发人员找Bug的，这是个误区。其实，开发人员才是负责找Bug的，尤其是自己找自己的Bug。打个比方，如果我们在自己家里忘了钥匙放在哪里了，一定不会把家里翻个底朝天，而是会尝试找自己以前习惯放钥匙的地方；但如果让一个客人来找，就不那么容易了，因为客人不熟悉家庭环境，也不熟悉我们放钥匙的习惯。家庭环境就是软件，而钥匙就是Bug，测试人员则是一个不太熟悉家庭环境的客人，开发人员才是那个放钥匙的人，尽管他暂时“忘了放在哪里了”。而且长期而言，只有开发人员才能改变自己的习惯，比如在墙上钉个钉子，习惯性地把钥匙挂在上面。我们在一个项目中密集实践过代码审查活动，在短短27天时间里，通过每天花费半小时观察、记录、分析自己的缺陷，个体缺陷率降低了一半之多。而且好的习惯和规范一旦固化下来，以后无需花费额外时间也能在一定程度上保证代码质量，可谓一劳永逸。
找bug的活被抢走了，传统测试人员怎么办？有两种出路，或者说“职业生涯规划”，都比原来传统测试人员更有前景。
一、有开发经验的测试人员应该转向“开发测试”
“开发测试”是游戏领域的一种工种，对应的是完全不需要对开发有了解的“黑盒测试”，我们可以把它的定义扩展一下用在这里。开发测试在开发活动中主要负责自动化测试、持续集成、回归测试等用于快速保证产品质量的活动。
为什么叫“快速保证产品质量”而不是“发现Bug”呢？因为开发测试程序的人其实不应该是这里的开发测试，而是开发某个功能的开发人员本身。正如之前所说，具体的功能开发者更清楚功能是什么，可能有哪些潜在的问题，如何验证最好……所以开发并第一次执行（为发现缺陷而执行）的是开发人员；但如何让众多测试用例自动地全部或有选择地再次运行，如何保证更高的运行效率、如何准备自动集成环境，则是开发测试人员的工作。
如果有可能，个人感觉最好不要设置全职的开发测试，而是视实际情况由不同的开发人员兼任。这样更容易平衡工作量、保证开发与测试的衔接有效性。
整体上这个出路偏向开发人员多一些。
二、“没有开发经验”的测试人员应该转向“产品经理”或“专业测试人员”产品经理不说了，因为出路很窄。这里说说专业测试人员。
有很多时候我们觉得原来的测试人员不就是“专业测试人员”吗？其实不然。很多测试人员不过是看看说明书，点点鼠标，填填Bug而已，很难说上“专业“二字。
个人感觉对测试人员而言，“专业”有两重含义。第一，对所在领域的质量问题和解决方法有深入理解。比如特定的软件，可用率是首位的（比如网站，允许瘫痪但不能总瘫痪）还是故障率是首位的（比如飞机，不允许故障）。Windows经常死机，但是恢复速度很快，用起来也很简单，这在家用软件中就是可接受的“高质量”标准；但用作服务器，可能就有点问题。如果不理解这些就开始测试，结果肯定是事倍功半。第二，对测试方法论应该有深入理解。软件仿真，持续集成，灰度发布……这些都可以称为测试方法论或质量方法论。“专业测试人员”用这些方法论指导前面说的“开发测试人员”进行测试，是一种很好的工作方式。
我曾经在松结对编程与139团队系列博客中多次提到一个23个开发人员加2个测试人员的团队，其中两个测试人员就是专业测试人员。尤其是其中的测试经理，会定期基于业务的需要向我们提出测试要求，而我们则帮她编码实现。这种搭配方式最终促成了产品的高质量，它现在正运行在国内60%以上的数字电视台。
这里的“没有开发经验”被打上了引号，是因为我无数次听到有人说“我没有开发经验，也不懂开发”，但这个人可能是与开发人员共事很多年的资深测试人员。其实，与相对论相比，开发更像是外语，就是外国乞丐学多了也能学会的东西。因此实在不能用技术壁垒作为借口，要做好可能很难，但要了解的确不难。要做好测试这个工作，不去侧面了解和理解开发，是很不现实的。
记者： 在敏捷实践的过程中是否一定要使用一些敏捷工具？能否推荐一些您认为比较好的工具？
陈勇：因为我自己也在开发一个敏捷工具“火星人”，所以就不直接推荐工具了，呵呵。不过下面可以介绍一下一些一般原则：
一、一定要选择适合自己行业领域的产品
有些产品可能是为大型制造业、银行、电信等开发设计的，那么尽管也叫“敏捷开发”产品，但里边会带有很多大型产品设计中所需的元素，比如UML，Portfolio Management（可以理解为大团队或多团队的管理）等内容。这并非像有人说的他们在“挂羊头卖狗肉”，而是在特殊行业实施敏捷所必需的适应。反之，简单的电子白板工具往往反而不适合在这些行业应用。
通过翻阅供应商提供的客户清单可以有所了解，而产品的主要功能和主张的方法论也能提供一些线索。这些资料往往印刷在宣传资料或发布在网站上，公开且不易被轻易修改。
二、根据“数据持久性”选择产品
所谓数据持久性，就是指数据要保存多久。如果是电子白板类产品，产品选型可以稍微“随意”一些，因为电子白板上的东西多数零散、颗粒度较小，很少需要几个月之后还要查看。所以可以大胆尝试这些产品。其他比如计划管理的工具也比较容易更换，毕竟完成了的项目的计划被访问的次数和必要性会迅速下降。
而对于需求管理、缺陷管理等产品，尤其是前者，则需要慎重选型。视行业的不同，这些产品可能需要考虑到未来3～5年乃至更长的数据保存问题，所以需要慎重一些。另外这些产品往往跨多个职能部门，选型时需要多方同时协调。
三、未必一个公司只用一个产品
All In One是每个公司的梦想，不过却不现实。我培训或咨询过的一些大型电信企业，其涉猎的领域之广往往令人惊讶。有家公司在做计费系统、BOSS系统（业务和运营系统）的同时，还在做移动互联网软件甚至游戏。前两者对需求遵从性、成本控制的控制是核心，因为它们往往涉及甲乙方合同；而后者则对创新性要求更高，喜欢“拥抱变化”。
这种情况下管理层应该深刻理解不同领域的管理要点。比如甲乙方项目中，“谁在做什么”这类任务细节往往是重要的，因他它能保证所有人都有活干，防止空置资源的浪费；对完成功能的多少的掌握也是重要的（最好使用功能点），因为它能表征进度。但在移动互联网软件中，“现在我们在做什么”“什么时候这个功能能做出来”“这个功能做出来反馈如何”才是重点。
由此可见，领域要求不同，方法论就会不同，管理工具自然也可能不同。除了一些简单的白板软件“都能用”之外，复杂产品很少能适应如此巨大的差异，甚至说也不应该适应所有领域使用。
在这种复杂情况下进行选型的时候，领导层或领域专家应该给出自己对管理的核心需求，然后再放手让团队进行自由选择，只要验证核心需求被满足就可以了。
