很多企业都会选择看板（用于增强团队管理的透明度，偏向“开发”）或持续集成（用于快速验证产品，偏向“测试”）作为最早采纳的实践。但长期而言，应该认识到这些工作不过是过程而已，目的仍然是交付价值，也就是完成正确的需求。
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的主要目的就是为了提高封装和复用。但即使是在存在已久的公司和团队中，极少有团队拥有自己的可复用库。所以，造成复用率低的主要问题不在技术，而在其他因素。
我们从这个线索可以分析出，现在的团队极有可能受益于“松结对编程”，也就是由师傅（高手，复用库的主要编写者）带徒弟（新手），由于松结对编程中师傅要指导徒弟的设计（前关键点）和代码审查（
