【CSDN博客之星】专访陈勇： 敏捷开发现状及发展之路

原文出处：http://www.csdn.net/article/2013-03-05/2814348

以下是文字拷贝，与原文相同，留作备份。

摘要：敏捷这个含着金钥匙诞生的“霹雳娇娃”是软件开发行业的救星，从头到脚、从里到外无不闪着金光，透着与众不同。但国内少有团队能真正理解其精髓和奥秘。为此，社区之星第15期采访了敏捷开发老兵陈勇。他站在企业管理者的角度来讲解敏捷开发并分析的字字珠玑。

陈勇，16年软件研发、管理及咨询经验，擅长在实际环境中应用敏捷开发实践。具有丰富的工程技术与项目管理实践经验，从程序员、项目经理、CMMI/敏捷咨询师、事业部总监、副总经理等各种技术与管理岗位获得的一手经验，令其可以站在企业管理者的角度，以更广的视角来理解敏捷开发，并能配合和推动非研发部门协作推广敏捷。

个人工作经历：

• 1995年毕业于南京航空航天大学自动控制系，后获得清华电子与通信工程的工程硕士学位。
• 1995-2001年，曾在某研究所、清华同方等企业从事编程和项目管理工作，参与过国庆阅兵直升飞机指挥系统、CCTV数字电视条件接收系统等项目的研发工作。
• 2002-2006年，主要从事CMMI的过程改进工作，供职单位包括普天、亚信等软件研发企业，以及英普信、斯福泰克和DNV等咨询公司。
• 2008年，在泰克赛尔任中国区的咨询总监、事业部总监、副总经理等职。
• 目前就职于IIOM国际外包管理协会，担任咨询总监，并领导团队开发“火星人”敏捷开发管理工具。

  国内缺乏敏捷思维

  CSDN：请问你是如何接触到敏捷开发的？又是什么吸引你如此专注于敏捷开发的？

  陈勇：2000年，我接触到最早期的XP（极限编程），在一些团队中进行多次尝试后，总结出许多敏捷实践的方法，比如代码审查、松结对编程等。

  在几年后的CMMI咨询工作中，感觉国内的研发现状普遍不适合直接使用CMMI的标准，反而更适合使用敏捷或偏向敏捷开发的方法。CMMI是美国国防部对其供应商的选择评判标准，带有大量的军工、大型制造业的影子；而国内软件更多的是MIS、OA、金融、电信这些更加平常的软件，还有许多需要灵活变化的网站和网络应用，与CMMI的很多假设前提都有很大的距离。

  在最初的时候也是希望兼顾各种方法，曾经同时开设多达13种培训课程，但后来放弃了。原因之一就是，尽管管理一个软件企业的知识体系有很多，但应该有一个较为一致的思路贯穿其中，才更加利于企业及其团队的理解和应用。

  不过，尽管方向和课程收缩为只有一个敏捷开发，但所包含的内容却扩大到包含整个企业及团队管理所需的所有内容。比如下面还会细谈的FPA（功能点分析），实际上完全不是传统敏捷开发关心的内容。

  CSDN：在你为不同公司和团队提供敏捷咨询的过程中，你认为最困难的地方在哪里？

  陈勇：最大的困难应该是中国企业在研发管理方面普遍“胆子很小”，缺少探索精神，期待现成的答案。

  敏捷开发出现并传入中国已经有10年历史了，两个被问烂了的问题还是没有答案：“什么是敏捷开发？”“我们适合什么敏捷开发？”在这种情况下，企业应该清醒地认识到国外没有答案，权威人士也没有答案，培训师和咨询师也没有答案，答案一定是自己找出来、实验出来的。

  基于这一点，我会尝试在课堂上尽量少讲概念，而是多讲自己的实践及其启发，希望企业接受“敏捷无有定法”以及“最佳方法需要自己找”的概念，有多少个企业就有多少种敏捷开发。企业应接受的是敏捷开发的思维方式和可选的实践方式。

  CSDN：你觉得什么样的产品或应用，比较适合敏捷开发？

  陈勇：互联网及相关的产品或应用比较适合。敏捷开发的出现与互联网应用的兴起是同一时间，这不是巧合。无论敏捷开发最早出现在哪里（实际上来自于日本制造业），但最终发扬光大的原因是与互联网应用对“拥抱变化”“快速迭代”的相同价值观的追求。

  敏捷强调快速灵活反应

  CSDN：自从敏捷概念从国外引进国内后，敏捷开发和敏捷测试就很火，但有人认为敏捷测试就是一个大忽悠，你是怎么看待这个问题的？

  陈勇：可能是因为敏捷测试被炒得太火，有喧宾夺主之嫌，所以才有此说吧。我个人认为，敏捷开发（“开发人员”的开发）和敏捷测试都不是敏捷的主角。相反，“敏捷需求”才是敏捷开发的主角。毕竟敏捷开发的最终目的是交付客户价值，而开发与测试都只是手段而已。

  在开始转向敏捷开发的时候，很多企业都会选择看板（用于增强团队管理的透明度，偏向“开发”）或持续集成（用于快速验证产品，偏向“测试”）作为最早采纳的实践。但长期而言，应该认识到这些工作不过是过程而已，目的仍然是交付价值，也就是完成正确的需求。

  CSDN：敏捷方法在中国实施起来相对有些困难，由于它导致项目管理原有模式的改变，以致公司往往不愿意引进这样的开发模式。您怎么看待这个问题呢？

  陈勇：这个问题有两面性。一方面，多数企业对变革结果的不可见性都心存警惕。其实从做CMMI的年代这个现象就存在已久了，比较好理解。

  另一方面，敏捷开发过于“强势”，对于团队模型、角色、开发方法、测试方法乃至术语都与以往方法大相径庭，令企业和团队感觉如果转向敏捷，革命在所难免。其实不然。以Scrum Master这个角色为例，实际上原来的Project Manager就处于非常接近Scrum Master的位置，两者的主要区别是某些工作方式的差异。因此可以令Project Manager吸收对方工作方式中“领导而非管理”“协调而非跟踪”等概念，形成“PM2.0”即可。

  CSDN：还有一些团队已经在实践敏捷开发，但团队中往往无法很好的理解敏捷的本质，导致技术上标榜敏捷，团队在开发上还沿用老的开发方式。对此种现象，你有什么的经验可谈？

  陈勇：造成这种情况的主要源头往往不是企业或领导，而是开发人员自己。很多开发人员之所以力挺敏捷开发，是因为敏捷开发带来的负担小，不像其他方法需要写大量文档，遵循大量的过程。听起来似乎这个想法会促进敏捷开发的推广，但其实不然。如果“负担小”是终极动力，那么敏捷开发中一些必要但相对困难的改善也会因此而被当作负担扔掉。

  敏捷开发的发展之路

  CSDN：你认为国内的敏捷开发何时能成为主流？敏捷开发的未来走向是什么？

  陈勇：个人感觉或许这个时间点始终都不会到来，包括现在如日中天的Scrum也不会成为主流。由于企业的领域、价值观、现状的本质差异，导致不会有一个像Scrum这样被“精确定义”的方法能普遍适用。CMMI的推广过程其实已经见证了这一点，尽管它比Scrum复杂很多。

  相反地，极有可能出现类似过去XP的情况：Scrum及其他方法中的各种实践会被打散，不是重新编排，而是被企业零散地选择性采纳，最终形成“四不像”研发过程。在这个过程中，对企业现状熟悉、方法论深入理解、灵活应用的高级管理人才将起到决定性作用。

  目前，Scrum、XP、CM、FDD、ASD、DSDM等哪类敏捷开发方法使用最多？

  陈勇：参考VersionOne的报告，可看出Scrum的应用占比最多。不过，“只应用Scrum”和“完全应用Scrum”的企业都不多，反而是“应用Scrum，但是……（又称ScrumBut）”的企业居多。以前这被认为想尝试Scrum但又裹足不前的状态，但未来正如前一个问题所说，极有可能成为广泛接受的情况。唯一的区别是，“裹足不前”会被“灵活应用”所取代。

  松结对编程极益于技术复用

  CSDN：你博客中更新的“松结对编程：L型代码结构”的系列文章。请问你最初写作想法是什么？该系列文章又能为读者带来什么？你近期计划写哪些方面？

  陈勇：最初写这篇文章是因为前段时间在做代码和功能点统计时发现，我们的编码效率居然是国外业界先进水平的3-4倍，也就是只需要1/4-1/3的代码就能实现相同数量的功能。（注：文中所指的“功能点”是国际标准功能点Function Point，具备相对一致的定义和可横向比较的规模。文中“国外业界先进水平”是ISBSG的注释，他们指出凡是能做代码和功能点比较的公司都非等闲之辈，其数据代表了业界20%左右最优秀公司的水平）

  独自编程可能会提高编码效率（主要技术是复用），但在团队中，由于沟通问题造成复用率下降，编码效率往往不高。回想起来，复用技术由来已久，可以说C++取代C的主要目的就是为了提高封装和复用。但即使是在存在已久的公司和团队中，极少有团队拥有自己的可复用库。所以，造成复用率低的主要问题不在技术，而在其他因素。

  我们从这个线索可以分析出，现在的团队极有可能受益于“松结对编程”，也就是由师傅（高手，复用库的主要编写者）带徒弟（新手），由于松结对编程中师傅要指导徒弟的设计（前关键点）和代码审查（后关键点），尽管共同编码的时间很短，但却足以避免徒弟困惑于“有没有轮子？”“轮子在那里？”，更不会“重复发明轮子”。而师傅同时负责底层库和上层应用的编码，又会保证“没有多余的轮子”。

  技术、团队、过程三者同时存在才能催生极高的复用率。反观业界复用率低的现状，缺少的显然不是技术，而是类似“松结对编程”这样的利于形成和推广复用库的团队及过程模型。

  CSDN：从博客上，你曾经多次提到参与和管理CCTV数字电视条件接收系统，这个项目给你带来了什么不一样的体验？

  陈勇：这个项目我参与时间最长也是感受最深的项目，其质量水平、技术架构、团队模式都有可圈可点之处。

  首先是质量水平。团队鼎盛时期曾达到35人，平时大约有25人左右，但测试人员一直只有2个。考虑到这个产品对质量的要求，以及参与研发人员的实际工作年限平均只有2年左右，就可以发现这不是一般的团队能做到的。全员的质量意识和质量文化可以说起了关键作用。开发人员都以编写高质量代码为己任，而不是把缺陷留给测试人员解决。

  其次是技术架构。由于团队的人数开始较少，编码数量不会很多，所以整个产品对复用的要求很高，充分利用了面向对象等技术。我本人的主要编程技能多数是在这个阶段学到的。

  最后但也是最重要的是团队模式。一两个高手编写高质量的代码或先进的技术架构不足为奇，但一个年轻的、在一年内从5个人成长到25个人的团队要做到这些就有些困难。当时起到决定性作用的是部门经理的关宏超。作为团队中的顶尖技术高手，他主动手把手地教大家编程技术，建立质量意识，又在后期完善了师徒制度也就是1-3-9团队的雏形。后来直接受到他指导的四、五个人成为了25人团队里的骨干，而我们学到的不只是他的技术，还有他管理微观团队的方法。

  在后来的很多团队中，我都实践和完善过这些质量、架构、团队管理方法。但在这个团队中的收获是系列博客中提到的“松结对编程”的最早起源。

  AUP（统一敏捷过程）的重要性和实施性

  CSDN：请介绍下你正在策划的AUP是什么，进展如何？是否已经找到与敏捷的互补方法？

  陈勇：AUP是敏捷统一过程的起源。与CMMI相比，敏捷开发覆盖的范围相对较窄，很多内容都处于“不涉及”“不关心”的状态。但这些内容中有一些不但是软件企业不得不做的事情，而且如果处理不当，极有可能伤及敏捷开发“涉及和关心”的内容。

  例如，早期计划，老板拿出三张字迹模糊的A4纸问：“这些需求要多久能开发完？”这个在敏捷开发里边的确“不涉及”。但如果大家没有答案，而老板被迫接受了客户提出的“3个月必须完成”的期限，但假设实际需要6个月才能完成，敏捷开发期间会发生什么？我们是否还可以让“开发人员自己估算任务？”是否还有心情“自动化测试并持续集成”？估计很多敏捷开发实践都在压力下烟消云散了。

  这些都促使我们思考：在敏捷开发的范围之外，应该有哪些过程与之配套？

  AUP的定义

  AUP（Agile Unified Process）也就是敏捷统一过程尝试解决这个问题。当然，解决方法不是形成一个更大的精确定义的过程，而是从Unified这几个角度来形成“兼容性”标准。

  所谓Unified有两方面，一是拥有具体可操作的方法直接与敏捷互补，另一个是至少兼容；各个过程之间数据应该衔接复用，不能各用一套说法。

  例如，网上经常有人提到UML中的Use Case和敏捷开发中的用户故事，并争论谁好谁坏。那么，两者有没有可能融合？毕竟敏捷开发很少提到复杂需求的组织结构，也缺少关于“敏捷设计”的方法，而UC正好做这两个工作。这些工作不是可有可无的，在一些领域如银行、电信等需要对业务进行深度分析的行业，这些工作不可或缺。既然如此，是否其中一方略作变化，就可能让两者兼容？

  又如敏捷开发中有一个由来已久但难以推行的“故事点”的概念。尽管故事点是用来做估算和生产率度量的，但却不能做跨项目的横向比较，也从未见过基于故事点的企业级生产率报告。

  那么何不参考功能点分析中对Function Point的定义？毕竟围绕FP现在已经出现了5个国际标准，全球有多达6000认证的功能点计数专家（中国只有两位），度量结果可以跨项目、跨企业乃至跨行业比较，度量数据数以万计，很多国家的政府软件开发项目报价都采用功能点，这与故事点的尴尬境界截然相反。AUP实际上是开放的Agile，欢迎一切能与Agile进行Unify的Process，而不是封闭、总是想与其他方法一争高下的Agile。能争的就争，争不过的又说不涉及，这不是开放的敏捷心态。
  

  AUP的建立过程及当前的进展

  在选择所有可以兼容的Process的过程中，要坚持Agile的原则。这并不代表Agile的原则是普遍适用，而是AUP只是一个基于Agile的价值观的过程的集合，比如轻量级、短周期迭代、重视客户价值、拥抱变化等。如果要做与此价值观不符的项目，比如大飞机软件的研制，那么请选择其他过程。

  现在能比较容易引入AUP的非“传统意义”上的敏捷方法包括：功能点用于早期估算和生产力度量，故事树作为宏观需求模型，139团队作为宏观团队模型，松结对编程作为微观团队模型，L型代码结构作为团队和代码的交互模型，UML作为设计模型。

  当然这不只是说所有方法都向敏捷兼容，相反地，在很多方面敏捷也要做一些修正。比如用户故事的定义和组织方式必须修订，否则就很难与功能点和UML兼容。

  CSDN：你是怎么分配一天的时间的？闲暇时，喜欢做些什么来放松自己？

  陈勇：每月除了外出培训时间外，每天都会投入大量时间编程开发“火星人”敏捷开发平台。

  另外一个常规投入则是写博客。不过我写博客不是任务，而是有感而发，因此多数博客内容都与近期我们自己的开发活动有关。这一点从最近的L型代码结构系列就能看到。

  闲暇时主要是陪家人，看美剧学习外语，偶尔外出看看电影。

  希望CSDN能成为中国原创研发思想的阵地

  CSDN：你在学习或工作中，是怎么接触到CSDN？CSDN对于你的工作或学习有什么影响，起到过什么帮助？有没有故事可以分享？

  陈勇：2001年左右就接触了CSDN，那时候经常在BBS回答C++问题，也顺便看自己不懂的问题。我还记得当时有一个很好的帖子提到程序员的四个境界，分别是“编写可用代码、编写高质量代码、编写精美代码、编写思想深邃代码”四个级别，这个帖子对我们当时的团队影响很大。后来我们对质量、技术架构的高要求，可以说是对这篇帖子的响应。

  中间曾有一段时间不再编写程序就比较少上。后来再次回到CSDN的时候，已经是从事敏捷开发的咨询工作了。也就是最近看到比较经常写敏捷开发系列文章的阶段。

  CSDN：你对CSDN有什么建议，以及你对CSDN的未来有什么期待？

  陈勇：非常希望CSDN能成为中国原创研发思想的阵地。

  这里说的原创研发思想，还不等同于原创文章。限于中国的研发水平，尤其是开发语言和技术都源自国外的现状，包括原创文章在内的文字和学术，基本都是学习、翻译、阐述国外的思想。而我们国内则是一向缺少原创思想。

  但实际上至少有两个方面，国内不并不比国外落后。或者说，大家算是平行发展，没有直接的继承关系。

  一个方面是广义的“产品管理方法”，比如银行、电信、互联网。中国的银行、电信业的规模远远大于多数西方国家，因此对于酝酿全新的架构、研发方法都有足够的土壤。互联网行业更是如此，百度、QQ、淘宝、Weibo这些产品都是世界级的，网络游戏市场也空前繁荣（欧美日本更倾向于开发单机或基于硬件的游戏），这些都对于我们研究和创立自己的产品管理方法奠定了基础。

  另一个方面是广义的“团队管理领域”，涵盖团队模型、计划与监控方法等诸多内容。敏捷开发也属于这个方面。东西方文化的差异令很多国外的管理模型来到中国后就水土不服，但却很少见到中国人自己拓展或发明自己的研发管理方法论，甚至是个别变通实践都鲜有耳闻。曾经有一个敏捷开发人士说过：“我们都尝试敏捷开发10年了，每次引经据典都还是10年前某某老外说的那几句话，不能不说是一种悲哀。”

  这在很大程度上说明我们在软件研发领域的不自信。凡是国外流传进来的思想都认为是经典，凡是自己思考出来的方法都担心是山寨。其实不然。任何一次成功，无论产品领域多么特殊，人员水平多么高或低，在偶然之中必有必然之处，如果深入思考挖掘，都有值得分享之处。

  在我自己写的博客中，松结对编程，139团队，功能点与用户故事的结合，L型代码结构这些内容都是提炼于自己参与的项目，在独立思考并在与其他个人、团队和企业交流后逐步形成的结果。与其对多年尝试仍然水土不服的方法念念不忘，不如观察思考身边的成功案例，思考其背后隐藏的潜在规律。

  未来非常希望CSDN及其他社区关注国内原创研发思想的产生与发展。这不是鼓励封闭思考或不鼓励借鉴，而是说与我们实际的人口基数、产品与项目数量相比，能沉淀的东西实在太少了。如果能吸引读者充分参与讨论、创新、思考、沉淀，CSDN一定会越发展越好。

  陈勇 CSDN ID：cheny_com 博客地址：http://blog.csdn.net/cheny_com