后关键点），尽管共同编码的时间很短，但却足以避免徒弟困惑于“有没有轮子？”“轮子在那里？”，更不会“重复发明轮子”。而师傅同时负责底层库和上层应用的编码，又会保证“没有多余的轮子”。
技术、团队、过程三者同时存在才能催生极高的复用率。反观业界复用率低的现状，缺少的显然不是技术，而是类似“松结对编程”这样的利于形成和推广复用库的团队及过程模型。
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认证的功能点计数专家（中国只有两位），度量结果可以跨项目
