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

这些都促使我们思考：在敏捷开发的范围之外，应该有哪些过程与之配套？
AUP的定义
AUP（Agile）也就是敏捷统一过程尝试解决这个问题。当然，解决方法不是形成一个更大的精确定义的过程，而是从这几个角度来形成“兼容性”标准。

文章插图
所谓有两方面，一是拥有具体可操作的方法直接与敏捷互补，另一个是至少兼容；各个过程之间数据应该衔接复用，不能各用一套说法。
例如，网上经常有人提到UML中的Use Case和敏捷开发中的用户故事，并争论谁好谁坏。那么，两者有没有可能融合？毕竟敏捷开发很少提到复杂需求的组织结构，也缺少关于“敏捷设计”的方法，而UC正好做这两个工作。这些工作不是可有可无的，在一些领域如银行、电信等需要对业务进行深度分析的行业，这些工作不可或缺。既然如此，是否其中一方略作变化，就可能让两者兼容？
又如敏捷开发中有一个由来已久但难以推行的“故事点”的概念。尽管故事点是用来做估算和生产率度量的，但却不能做跨项目的横向比较，也从未见过基于故事点的企业级生产率报告。
那么何不参考功能点分析中对 Point的定义？毕竟围绕FP现在已经出现了5个国际标准，全球有多达6000认证的功能点计数专家（中国只有两位），度量结果可以跨项目、跨企业乃至跨行业比较，度量数据数以万计，很多国家的政府软件开发项目报价都采用功能点，这与故事点的尴尬境界截然相反。AUP实际上是开放的Agile，欢迎一切能与Agile进行Unify的，而不是封闭、总是想与其他方法一争高下的Agile 。能争的就争，争不过的又说不涉及，这不是开放的敏捷心态。
AUP的建立过程及当前的进展
在选择所有可以兼容的的过程中，要坚持Agile的原则。这并不代表Agile的原则是普遍适用，而是AUP只是一个基于Agile的价值观的过程的集合，比如轻量级、短周期迭代、重视客户价值、拥抱变化等。如果要做与此价值观不符的项目，比如大飞机软件的研制，那么请选择其他过程。
现在能比较容易引入AUP的非“传统意义”上的敏捷方法包括：功能点用于早期估算和生产力度量，故事树作为宏观需求模型，139团队作为宏观团队模型，松结对编程作为微观团队模型，L型代码结构作为团队和代码的交互模型，UML作为设计模型。
当然这不只是说所有方法都向敏捷兼容，相反地，在很多方面敏捷也要做一些修正。比如用户故事的定义和组织方式必须修订，否则就很难与功能点和UML兼容。
CSDN：你是怎么分配一天的时间的？闲暇时，喜欢做些什么来放松自己？
陈勇：每月除了外出培训时间外，每天都会投入大量时间编程开发“火星人”敏捷开发平台。
另外一个常规投入则是写博客。不过我写博客不是任务，而是有感而发，因此多数博客内容都与近期我们自己的开发活动有关。这一点从最近的L型代码结构系列就能看到。
闲暇时主要是陪家人，看美剧学习外语，偶尔外出看看电影。
希望CSDN能成为中国原创研发思想的阵地
CSDN：你在学习或工作中，是怎么接触到CSDN？CSDN对于你的工作或学习有什么影响，起到过什么帮助？有没有故事可以分享？
陈勇：2001年左右就接触了CSDN，那时候经常在BBS回答C++问题，也顺便看自己不懂的问题。我还记得当时有一个很好的帖子提到程序员的四个境界，分别是“编写可用代码、编写高质量代码、编写精美代码、编写思想深邃代码”四个级别，这个帖子对我们当时的团队影响很大。后来我们对质量、技术架构的高要求，可以说是对这篇帖子的响应。

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

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