这是我们部门的整个闭环的一个流程。我们知道刚才大师也讲了需求肯定一直在变化的，整个的需求管理我们有一个自己的流程。我们这个系统更像一个办公系统，用户把需求入进来，我们大家要做分析、审批，要看，是不是合同内合同外的，是不是要做。如果确认这个东西要做的话，才会变成一个开发任务，才会进入我们的CQ。同样我们的产品发现了一些Bug，东软有一个产品叫Bug Base，到这么一个系统来进行管理，这个里面有测试用力，测试大纲，测试方案等等，如果发现Bug，并且确认之后也会找到CQ，会形成一个任务，找到开发人员做相关的工作。这个里面相当于有一个变更的流程。同样我们的项目计划，同样也可以通过集成的方式，找到CQ里面去，然后形成任务。换句话说，无论是需求也好，还是我们的计划也好，最后全部形成一种开发任务，这样的话，就形成了整个闭环的管理流程，这样的话数据基本上全部可以提出来，可以做相关的量化指标，对我项目的监控。这是一个例子，某个需求自动导入CQ。所有的这些需求必须有跟踪的，需求的来源，需求地基本信息什么样的，开发的状态、测试的状态什么样的，我们是面向客户的，还有一个现场的状态如何，最后测试是否通过，客户认可与否，从入口到出口是有一个相关的关系的。这是一个需求的处理流程，需求分析，然后进入开发，然后会导入，最后有一个操作，然后最后扭转。
这是一个演示，是PSM或者PM有一个计划，形成一个任务，会自动通过CQ导入到CQ里面去，形成一个开发任务分配给开发人员。这是一个Bug导入的，当某一个项目，发现了一堆的问题，发现人是谁，状态如何，已经确认的需要修改，它也会自动地导入到CQ里面去。我们知道CQ很强大，会提供很多的接口做这些事情。这是Bug处理流程，先是提交，然后待改状态的问题卡，如果问题确认之后，会返回到流程。当某一个Bug出现的时候，不是一两个工作人员可以做好的，当某一个需求被开发人员需要多个模块多个工作人员配合的时候，会产生这种子任务。换句话说，有一个任务关联，有一个副任务可以代替一个子任务，只有子任务关闭副任务才可以关闭，只有每一项都完成，最后副任务才可以都完成。
我们采用一种复合基线的方式管理Component。我们更好地更快地构建一个大的子系统，或者一个大的系统。第二一点，我们严格按照配置管理计划来建立基线。我们什么时候建立一个基线，什么时候建立一个基准。如果建立之后需要修改的话，必须提交变更申请。如果需求变了，后面一串全变了，然后待设变了，后来详设也变了，当你锁定基线之后，你后面的变更必须进行修改。我们做一些大项，如果发现这个问题对我的影响很小，需要改一下就可以了，但是这个改动对其他的模块和其他的子系统影响很大，当我锁定基线之后，它的变更必须发出申请，即使对大家没有影响，也需要告诉大家一下，我变更什么东西，大家看看这个东西是否有影响，我是不是要跟着变，是不是跟着改，如果需要的话，你这个改动对我是有影响的，我要跟着改。所以说变更申请不是增加工作量，可以使我们的工作更加制度化。变更申请也通过了，也修改了，最后修改之后要对基准进行变更。我们说有计划，配置工作，还有做变更管理，还要做审计。我们说审计的目的是确定这个产品是不是符合功能和物理方面的需求，第二要确定工件存储在已控制的库中，第三要确保工件和基线可用。我做了一个基线，我做了一个版本必须可用的。因为我们部门最后的实现，实际上QA和CM组织配置审计的，第二要严格按照配置管理计划进行配置审计，跟踪不符合问题的处理，更新不符合问题跟踪表。这是一个配置审计的一个记录。我们大家可以看到，基本上什么时间建立的，审计的内容，要不要修改，修改的建议是什么。这些都是需要做的。
我们把主要的几项内容讲完了之后看一下。我们刚才提到的我们做联通新一代的BSS项目。因为我们知道联通的需UCM的建设，是一个售前、售中的一个系统。把我们原先的很多系统融合成一个新一代的子系统。大家知道，一个150人到170人的团队作战，如果这个版本控制不好的话，将出现灾难。所以说有了这套很好的管理的方式，才能够保证整个版本是稳定的，是可靠的。举一个例子来说，比如说在这儿，本来在这个点准备要做一次上线，比如说0.8版，我们把它推到我们的生产系统，我们验证、测试，发现问题及之后要处理，然后要解决办法，还要很多的需求，我们在一个月内处理了700多个问题，我们不断地更新升级，不知道最后能不能控制住，我们4月15日正式上线了，我们封了一条1.0的基准，那么当我们把1.0和正式环境上面的版本拿下来的时候，是非常令我惊讶的，我们没有想到的是我们的配置库上的版本和我们生产环境几乎是一模一样的，我们以前不可想象的，我们也做过这种事情，配置库没有出错的概率非常小，几乎是没有可能的，为什么没有问题呢，实际上我认为不是工具本身的问题，而是你管理的问题，你只有管理到位，你才不会出现问题，否则的话，如果管理不到位，大家的意识不在配置库上工作，不做变更申请，最终这个版本肯定是否定了。所以说一个好的管理必须有一个好的团队，而且整个团队的意识必须跟的上，我们用三年的时间才可以走向成熟，就是大家管理工作的意识问题。整个的项目工作完全依赖于配置库，才能保证版本的一致，整个系统稳定的运行。还有我们提升了QCD的三个指标上，你要提高质量，你要降低你的消耗，你要按期地能够交付。那么提高你的生产质量，自然而然可以上来了。
在我的片子里面，基本上给大家做了一个简要的总结。基本上我们讲到了配置管理的最佳实践，一共有十条，这是大家公认的：在安全的存储库中进行工件的标识和存储；控制并审计对工件的变更；记录并跟踪变更请求；维护稳定、一致的工作空间、以控件为单位实施版本控制；支持对工件和构件的并行开发；设立并管理基线；使用活动来整合最低版本，尽早集成、持续集成；确保软件构建的再现性。
我们150人的团队，每天集成作战，最后版本没有出现问题。我们说工欲善其事，必先利其器，如果你没有管理好的工具，你最后落实下去的话，还是管不好，最后的上线还会出现问题。虽然说我们可能有一套好的管理思路，但是说有一套好的工具的话，更合适的。我们从2004年开始买，Rational是乙方，我们是甲方，甲方为乙方服务好，是天经地义的事情。这个BS项目配置管理工作的巨大成功，使我感觉到我应该好好的谢谢Rational，我向Rational和IBM表示真心的发自肺腑的感谢，谢谢大家！
(c111)
|
服 务 CIO 推 进 信 息 化 
