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

独自编程可能会提高编码效率（主要技术是复用），但在团队中，由于沟通问题造成复用率下降，编码效率往往不高。回想起来，复用技术由来已久，可以说C++取代C的主要目的就是为了提高封装和复用。但即使是在存在已久的公司和团队中，极少有团队拥有自己的可复用库。所以，造成复用率低的主要问题不在技术，而在其他因素。
我们从这个线索可以分析出，现在的团队极有可能受益于“松结对编程”，也就是由师傅（高手，复用库的主要编写者）带徒弟（新手），由于松结对编程中师傅要指导徒弟的设计（前关键点）和代码审查（后关键点），尽管共同编码的时间很短，但却足以避免徒弟困惑于“有没有轮子？”“轮子在那里？”，更不会“重复发明轮子” 。而师傅同时负责底层库和上层应用的编码，又会保证“没有多余的轮子” 。
技术、团队、过程三者同时存在才能催生极高的复用率。反观业界复用率低的现状，缺少的显然不是技术，而是类似“松结对编程”这样的利于形成和推广复用库的团队及过程模型。
CSDN：从博客上，你曾经多次提到参与和管理CCTV数字电视条件接收系统，这个项目给你带来了什么不一样的体验？
【【CSDN博客之星】专访陈勇：敏捷开发现状及发展之路】陈勇：这个项目我参与时间最长也是感受最深的项目，其质量水平、技术架构、团队模式都有可圈可点之处。
首先是质量水平。团队鼎盛时期曾达到35人，平时大约有25人左右，但测试人员一直只有2个。考虑到这个产品对质量的要求，以及参与研发人员的实际工作年限平均只有2年左右，就可以发现这不是一般的团队能做到的。全员的质量意识和质量文化可以说起了关键作用。开发人员都以编写高质量代码为己任，而不是把缺陷留给测试人员解决。
其次是技术架构。由于团队的人数开始较少，编码数量不会很多，所以整个产品对复用的要求很高，充分利用了面向对象等技术。我本人的主要编程技能多数是在这个阶段学到的。
最后但也是最重要的是团队模式。一两个高手编写高质量的代码或先进的技术架构不足为奇，但一个年轻的、在一年内从5个人成长到25个人的团队要做到这些就有些困难。当时起到决定性作用的是部门经理的关宏超。作为团队中的顶尖技术高手，他主动手把手地教大家编程技术，建立质量意识，又在后期完善了师徒制度也就是1-3-9团队的雏形。后来直接受到他指导的四、五个人成为了25人团队里的骨干，而我们学到的不只是他的技术，还有他管理微观团队的方法。
在后来的很多团队中，我都实践和完善过这些质量、架构、团队管理方法。但在这个团队中的收获是系列博客中提到的“松结对编程”的最早起源。
AUP（统一敏捷过程）的重要性和实施性
CSDN：请介绍下你正在策划的AUP是什么，进展如何？是否已经找到与敏捷的互补方法？
陈勇：AUP是敏捷统一过程的起源。与CMMI相比，敏捷开发覆盖的范围相对较窄，很多内容都处于“不涉及”“不关心”的状态。但这些内容中有一些不但是软件企业不得不做的事情，而且如果处理不当，极有可能伤及敏捷开发“涉及和关心”的内容。
例如，早期计划，老板拿出三张字迹模糊的A4纸问：“这些需求要多久能开发完？”这个在敏捷开发里边的确“不涉及” 。但如果大家没有答案，而老板被迫接受了客户提出的“3个月必须完成”的期限，但假设实际需要6个月才能完成，敏捷开发期间会发生什么？我们是否还可以让“开发人员自己估算任务？”是否还有心情“自动化测试并持续集成”？估计很多敏捷开发实践都在压力下烟消云散了。

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

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