在CSSPIN2009上的大会发言-支持软件过程改进的工具和实践

11月的时候在csspin2009上的大会发言，主办方给整理的演讲记录，不过不对着PPT，估计很多地方都看不明白，作为自己的一个保存吧。

这几年一直在做这个事情：过程管理的工具，说起来我也算很执着了，不断改进，力争做到最好吧。

======================

支持软件过程改进的工具和实践

中科方德软件有限公司
软件工程工具与服务事业部，总经理 袁峰

2009年11月20日

袁峰：各位下午好！现在时间比较紧张了，所以我也不过多的介绍一些背景。我给大家介绍一下，中科方德我们在这块，有一个事业部，叫做软件工程和工具服务事业部。我们做了一款软件过程管理方面的工具Qone，类似IBM Rational的软工工具套件，但是我们相对来说更便宜，此外，我们也配合工具推出了一系列服务。我今天给大家介绍一下我们过去一年做的工作，可能大家会感兴趣。
我这两天查了一些关键词，我查“软件过程工具”查不到太多东西，我查“CMMI工具”，大家可以看到，这是查询到的一个贴子：我们公司做CMMI，效果不好，流程表面化……流程执行体系不好，没有工具。归纳一下就是CMMI实施效果不理想，缺乏自动化的流程执行体系。
这是另外一个帖子，说了工具的好处，比如说证据留住了，效率提高了等等，包括有度量的自动化。由于有了工具的支持，不需要大家去编数据和文档了。没有加班的现象。而通常的CMMI实施，一般在公司会引起大的轰动。这是他的一个观点。
另外我注意到一个观点，他提到这个工具是自己开发的，软件开发公司嘛，自己开发一个很easy。我总结就是，“没有枪没有炮我们自己造”，实际上是有枪有炮的，IBM的可能是炮，我们中科方德的是枪，我希望是AK47，呵呵。
有人认为工具不一定适用，工具有没有用？这是我在一个软件过程改进的论坛上查的，支持的观点比较多。这些道理比较清楚。也有一个贴子说：都在谈工具的好处，没有人说工具怎么用？给点实质的东西。我归纳一下：工具有适应面；不仅需要工具解决问题，还需要有一整套的解决方案，比如说过程规范。
中科方德我们这个团队做软工，其实是中科院软件所出来的一个团队，我们这么多年一直做这块，说实话也有很多其他的机会，做项目赚点钱，我们还是抵制了诱惑，我今天介绍一下我们的理解和感想。
我的大纲是这样：首先讲一下我自己的理解，简单说一下工具的现状和需求。然后介绍一下我们的工具，也介绍一下工具在我们自己内部的一些使用，工具要和规范结合起来，我也把我们的规范带来了。最后我想我们是乙方，是工具开发厂商，我跳到甲方的角度考虑，如果你想买工具有什么考虑？我们处在你的地位想一想，反过来看我们自己。
首先几个概念。第一现在的过程改进，在中国我们说过程改进就说CMMI，CMMI好像是过程改进的代名词，实际上不是这样的。
我们工具的全称叫做中科方德软件过程管理平台Qone，这个名字比较绕口。我春节看到一本营销的书叫做《定位》，说一个产品的推出，一定要跟人家熟悉的概念关联起来。我举一个例子，我们有一家客户，用了我们的工具，我们过去看，推得很成功，企业搞了很多宣传，我一看宣传材料，把我们工具的名字改一个，叫做CMMI集成平台。我问为什么改一个？客户回答：我们的部门比较多，我跟每一个部门说我们用Qone，大家也不知道Qone干什么的，我说我们用了CMMI集成平台，大家都知道是干什么的了。这对我是一个启发，这是有道理的。
但是反过来说，我们自己开发的初衷是不是要做一个CMMI集成平台？我介绍一下我的理解，不管是CMMI，还是ITIL，ISO9000，不同的模型、方法论，所关注的都是软件开发中一些共通的东西。我的代码需要做管理了，就有管理工具；我要做需求跟踪，需要需求的管理工具；再比如说缺陷管理，风险管理…… 我们认为对这些事情的管理，需要一些工具的支持，同时每个企业、每个团队都应该有自己的一套过程。
每个团队有自己的文化跟人员特点，导致这个过程特定的，是MyProcess，怎么定义这套流程呢？当年没有CMMI，一个较大的团队需不需要管理？微软这么大的团队要不要管理？也是需要的，也许无形中就契合了CMMI的要求。也有可能我们没有过多经验积累，CMMI有很多Best Practices的积累，我们根据这个框架，并结合我们企业的实践，制定我们的Process，反过来是符合这些模型要求的——具体是怎么一个先后关系并不重要。
以我们这个团队为例，我们曾是CMMI四级资质的一个团队（这个级别有一个有效期），我们现在不断做过程改进。我给大家看一眼，我们内部的过程规范，会有一些细节快过一下……
开发一个产品，你自己的产品，一定要自己用得好，才能给别人推，如果自己用不好给别人推就有点过分了。自己的狗食自己吃，我们自己的Qone从01年、02年开始我们一直在使用。Qone一开始是863科研项目的成果，我们不断地改进，我觉得这是我们自己的一个精神。而且我们的过程规范，也是完全和这个工具相结合的。
工具的现状，我们也查了，其实没有一个特别的专门的说是CMMI工具，或者过程管理工具。通常会说，配置管理工具，变更管理工具，缺陷管理工具，需求管理工具等等，有不同的工具。我们这几年在国内接触企业比较多，我们的客户情况比较了解。通常都会已经有一些工具，比如上了CC、CQ，或者已经上了Bugzilla、DOORS，就是这样一些专门的工具。
那么接下来的需求呢？我觉得可能有这样几方面，简单总结一下：
一、有些企业有一些自己特定的管理需求。比方说开发团队人很多，项目混乱，需要建立一个资源池，以及使用项目群进行管理。比方说成本管理等一些特定的管理需求，这是对工具的一个需求。
二、企业上了很多管理工具，各种各样的，有的是做项目管理的，有的是做缺陷、需求等等。但是他们之间的数据没有关联起来，所以是一个个信息孤岛，这些信息的整合能够提升更多价值。我待会儿讲一个具体的例子。
三、很多企业都提出这样一个要求，能不能有一个集成的整合平台？所有事情都在上面做，要让我把数据从这里拷到那里，手工去拷，肯定有很多不一致的问题，应该由工具来做，这是很切实的要求。这也是我们做工具的时候，一个努力和发展的方向。
首先讲一个例子就是需求和任务的关联。在我们的产品里面，有需求管理工具，有点像DOORS，现在被IBM收购的DOORS，但是我们跟DOORS不太一样，DOORS只做需求管理，我们把需求跟任务关联起来。这里给大家看几个例子，有两方面的关联：
一方面，比方说有一种开发模式叫做Requirement Driven Development，先把需求分包，跟着需求进行任务分配或者工作拆分，直接分成我们相关的一些工作安排。当我建立这种跟踪关系的时候，有相关任务数据在里面，对应的实际工作量怎么样？可以去做相关的分析。需求变更的时候，对任务的影响，可以为我的管理提供更多的决策支持。
另外是需求和工作产品的关联，这个是比较通常的，一般都会做。做了以后可以建立变更影响分析。和通常的分析工具不同，我们的工作产品，和配置库做关联，我们有一个接口，CC、CVS、SVN我们都支持。配置的一些变更管理，配置的流程管理和需求之间，需求发生变更，导致配置库里面做控制，这些工作我们都可以做，这是非常有意思的管理上后续可以做的事情。
有一些同行比较了解我们过去的工具，Qone这个工具，有些同行不是很了解，我简单介绍一下。中科方德这个公司时间不长，06年开始注册，但是工具的时间很长。因为软件所一个团队一直在做研究，目前有300多家用户，我们这个团队，不是讲我们公司，是讲我们软工事业部团队本身，现在有83人，我们不干别的，只干这个事情。应该是国内第二大团队，仅次于IBM。我知道现在国内的软件市场，实际上是很艰难的，我自己这两年也是受了很多的煎熬。
现在这个团队是我们一个很大的财富，分布在各地的技术支持有十多个人。还有兼职的，这些是能够给我们客户提供的。而且我们这样一个团队不断开发一些新的东西，我觉得这些是我们客户可以跟着我们进一步受益的。这是对我们历史一个简单的回顾。
这页片子是我们的一个大概的体系结构。核心包括了几个主要的模块，比如说项目管理、过程管理、度量分析、需求、测试等等。
那么外围，很多企业过去已经有了相关的工具，我们保护过去的资产，所以我们要和原有其他的工具做一个集成，现在集成的工具有CC、CVS、SVN、CQ、Project等等。包括我们数据也提供接口，我们有一个企业客户，问我们说，现在要求的数据太多，老让你们研发不好意思，能不能提供API给我们，我们自己做报表？我们说可以，我们很愿意，我们愿意让我们整个系统结构成为一个开放的，可以让大家自己去定制自己的需求，然后在上面工作。
我们的一个想法是，这个工具是一个灵活的，不依赖于，不局限于某一个方法或者理论，我可以符合它，但不是约束于CMMI，我可以符合ISO9000，PMBOK，GJB。
我们有这么一些主要的模块，有些是必选的，有些是可选的一些模块，比如说质量管理、过程管理、度量管理都是可以选择的。还有需求、社区，我们实际上是面向这个开发团队，需要的一些支撑开发交流的工具，这些工具都是我们现在和未来要开发的范围，细节我就不做太多介绍了。
这里可以看一下，像工作台，个人工作台，短信发送，有些地方是有这种应用需求的。我们在高铁大项目，科技部和铁道部里面同样有一个需求，就是我经常给各个总师发短信息开会，你们这个平台要支持，这个是客户和领导的需求，我们就支持。所以有一些实用的小功能。
项目管理这块我们做得比较细。从立项之后，项目所有的这些计划、拆分、任务报告等等，工作产品的管理、配置等等，全部包括在里面的。包括一些评审、审计这些都是对应我们过程改进做了一些功能。我们在座同行一看这个就比较了解了。度量分析这块是我们比较强大的一块，覆盖了95个指标。还有数据中心，刚才我举例子说的需求管理模块，还有一些其他的比如系统管理模块。
今天时间不多，我简单给大家过几个截图，这是我们需求管理模块的一个图，包括需求跟任务关联，变更的审批流程，可以自己定义，你希望你企业的需求，变更的时候有哪些角色进行审批，流程是什么样的，可以自己灵活定义。角色也是可以定义的，你可以自己定义，每个角色在系统里面的权限。
工作流的自定义，比如说我有一个会签流程，有一个请假单，等领导批，都可以通过邮件来支持，这块也是灵活开放的。高层的视图，高层关心的数据，通过dashboard做一些整合。由于我们现在有一些客户对安全的要求越来越多，做了一些权限变更的时候，留下日志，不能随便获得权限。
个人视图，过去有客户提到，你们的产品好是好，就是太大了，功能太多，我找不到。因为这个需求，一方面我们改进易用性，另外一方面我们把所有菜单配置权限放开，界面自定义也都做了，所有的首页界面可以自己界定。
我们的数据中心，你对哪些数据感兴趣？包括我刚才说的自定义菜单，各种配置管理工具、测试工具、需求管理工具等等，我们现在都支持这样的整合平台，包括一些数据灵活管理，要导出、出报告等等。
因为EPG很关心，我的过程要制定，要在企业、团队统一的发布，我们有发布的平台。另外还有评价，你可以打分，类似于评价体系。这是我们大概过一下，等会儿我有一个小广告。
IBM刚才发言的老总，IBM有研究院，对于国内大多数企业来说，可能没有这样的条件。但是对于我们来说，好一点。因为我们本身从软件所出来的，软件所本身是一个大研究院，我们还有一个研发团队在研究所里面为我们提供源源不断的支持。这里举一个例子，这是一篇最近要答辩的博士论文的题目：需求演化影响分析框架及相关技术研究。这是做什么的？我可以简单介绍一下，需求管理，为什么很多企业用不好？因为每一项跟每一项之间建立关联，手工建立关联，一旦变更的时候重新建立关联，虽然带来可追溯性，但是工作量太大了，导致很难用好。如果我们可以自动建立这些需求跟踪关系，不要做到全自动，辅助，我想价值也是很大的。我们所有的研究工作和我们实践结合的，所以在我们平台上做了一个实现，就是自动建立需求跟踪关系。这只是一个例子，是我们在研究的一个例子。
我们团队内部自己用的Qone，是不公开对外的，因为我们自己在上面开发一些小功能，所以不到我们产品序列里面，未来可能进入我们产品序列里面，这是我们做的一些尝试，希望跟大家一起交流。
因为今天时间很有限，我们在下周五在软件所办一个用户大会，欢迎大家去听，那个时候介绍更多。门外有展台，有兴趣可以去了解。
刚才谢耘老总也提到，在敏捷和规范中找一个折中点，一定要走中庸之道。我们做了一些尝试，我们自己的实践，可以给大家简单看一下，我们自己定的很简单，这是一些大概的过程，这么看比较简单。立项有什么流程？计划有什么流程？执行的过程中主要是报告体系……这是我们内部的模板，作为一个新的项目管理人员，可以在这里得到所有的信息。
时间到了，我说快一点，大家感兴趣的话我们可以下来详细交流。我是感觉每一个团队应该有这么一个规范，相关的东西应该很容易得到，同时用很好操作的方式告诉大家，这是我们的一个经验。
我刚才说了从乙方的角度来考虑，从甲方的角度来考虑，工具采购的时候选什么？刚才有人说自己是一个软件公司，自己开发得了，这是一种勇敢者的游戏，比较冒险。除非你希望一个团队长期专注在这一块。为什么？我这里分了一个利和弊，你自己开发有好处：完全符合自己要求。但是坏处你是不是真的打算长期做这么一个团队。比如说你的管理方式是不是未来不改变了？改了以后你的工具要不要跟着改？比如新的浏览器出来要不要跟进？等等……
我们中科方德，我们的工具是值得信赖的。我们在用户那里广泛使用，多年使用可以让大家放心，你不是第一个吃螃蟹的。我们在军方，通信金融交通软件等，各个关键行业的一些代表行业，都得到很多的应用。
另外我们现在已经建立了一个覆盖全国的分支机构，我们在各地都有一些技术支持，实际上我们是觉得一定要把服务放在第一位，如果有机会的话，我也希望可以给大家提供良好的服务。谢谢大家！