我们现在就开始产品的演示，在做产品演示之前我先做自我介绍一下，我叫李建刚，我是Telelogic 公司负责SYNERGY 产品。SYNERGY 产品是一个基于任务的配置管理工具，因此在这儿我可能做一个简单的调查，第一次听说“基于任务”这个概念的，在座的举一下手，有70%或者80%以前听说过“基于任务”的概念，有关基于任务这个概念就不要做很多介绍了。
第一，基于任务在SYNERGY 当中是怎样实现的？第二SYNERGY 这个产品是如何进行平衡开发的。我们现在有一个项目叫Cube1.0，这个项目已经正式发布了，这个项目是一个
很简单的播放器，我这儿有一个播放按纽，我一点播放按纽，有一个旋转立方体块，很迅速地旋转，Cube1.0 发布以后，迅速旋转，我播放按纽，再次按下的时候，这个项目会停止下来，这个项目已经发给客户了，没有经过严重的测试，可以说背离客户的要求，因此造成了非常严重的Bug，是没有基于任务的概念，通过配置管理的方式来组织实现Bug 的功能。我们成立了一个虚拟Team，这里面有4 位成员，这4 位成员承担不同的角色，角色有CCB 成员，同时Ted，任务是来定位缺陷，然后把这些缺陷分派给相应的解决人。Bob 是BuildManager，这个角色是定位用来帮助我们构建和组织发布的部门角色，Darcy 和Amie 是增加新功能的。
我们知道要修改这个Bug，我们必须创建一个新的项目，我们创建一个Cube1.0 的项目，很多软件公司一般是一个team 做维护的，在这个项目下面，我们刚才形成的那些角色和人员，他们是怎么分工协作的，首先Ted 是CCB 成员，因此中间我们会让Ted 提交一个CR 给Darcy，我们认为Ted 的权利非常高，可以通过开会、讨论，觉得这个事情应该由darcy 解决，同时我们分配一个任务给darcy，darcy 是一个逻辑工作单元，你有这个逻辑工作单元才知道过程的记录跟踪，你即将做的或者已经做过的事情。darcy 开始自己工作，他就要创建自己的空间，darcy 要从这些任务当中获取信息，darcy 会有一个任务列表，因为我们是基于任务的，而且任务是每个开发人员的工作单元，因此每个开发人员在工作的时候会收到一堆darcy，你可以分类、归类，这是你即将工作的要求。darcy 检出有问题的原文件cubeview.cpp 并且修改错误，然后darcy 完成当前任务，SYNERGY 建议你把darcy 和Change 完成，你得到的任务作为你工作的一个逻辑控制点，以你的任务作为你完成提交文件的逻辑控制点，因此我们在这里按照逻辑控制来提交一组文件。darcy 做完这件事，darcy 不负责发布，他只是完成任务。bob是负责发布，进行产品最终的管理，bob 收集darcy，看通没通过，如果我们以往基于文件，我们会警告darcy 有那些bug 修改了，会以文件的形式传送回去，bob 是收集darcy 完成的任务，bob 不去直接获取darcy 的这些File 任务，间接把这些跟文件相关的文件拿到bob 进行集成测试并验收，然后bob 创建新的基线。
是由ted 来提交这个问题，ted 是CCB 的一个成员，他把问题要分派给darcy，我们ted来做一个分派变更请求，这个问题是旋转的立方体，我们知道旋转立方体不能停止旋转，我们做一下描述，是变更请求，但是变更请求要分类型，是新功能，是新缺陷，还是新需求，当我们讲到什么是可以作为变更请求，我们认为它是一个缺陷，“严重程度”我们认为是“非常的严重”，我们决定这件事由darcy 来做，我们选择一个发布标识，优先级定为1，我们创建任务可以把CR 分解，离具体实践非常远，我们需要中间有一个桥梁，我们知道一个CR来的时候，有可能是一个人做，也有可能是多个人负责，在这里我选择“创建任务”，我提交CR 到SYNERGY/Change 里去。我们浏览一下刚才提交的变更请求信息，在提交变更请求的时候，一般情况下由我们软件公司CCB 的成员或者是质量控制部门来提交，同时我们也要知道在问题的汇总上，我们要经过CCB 的开会。
这是刚才我们提交的一个变更请求（见图），这都是我们的一些信息，darcy 来做这些事情，发布标识。同时我们看到Task 给这个CR 管理员，这个Task 是darcy 的一个工作单元，把有问题的项目拿出来做修改，他要回到我们的SYNERGY/CM 里面去，darcy 要做这些事情，他要看20：See CR3，这是darcy 的工作要求，你要开始工作，因此要选择出一个作为你的逻辑工作单元。我们把这个20：See CR3 设置当前Task。我们在做这些事情之前，先来看一下问题是什么，这是我们Cube1.0 发布出去的一个应用，这是一个旋转立方体，我点击播放按纽，大家看它旋转非常慢，同时最严重的是，我把它弹起来它不停下来，这是我们要解决的问题。为了解决这个问题，刚才我们创建了CR，同时把CR 分解到darcy 解决这个问题，这是Task 私人的工作环境，我这个工作环境是不受人家干扰的。有了自己私人工作环境之后，这些里面的项目数据都来自于1.0 项目的，都是基线的项目，这是人类所发布过的。我们darcy 就要把这个文件找出来，我们看到把有问题的文件摘出来的时候，大家注意这边的变化，这个摘出来的版本会跟当前darcy 关联，保证darcy 所拿出的文件不会变成一个孤立的或者说没有约束的文件。因此，这个文件跟task 关联上了，我们把这个文件进行修改，我们知道这个文件处在第几行上。这两个参数写错了，我进行修改，因为要做单元测试，你要检验修改是否正确，对我刚才修改的文件作一个bluid，我们来看一下darcy 是否修改了这个缺陷，旋转的应该很快。我们以往的工作方式，要把这个工作Check in，我们做单元测试要以一种逻辑关系或者一种逻辑控制点去组织，这样的话，我们以task 围绕的单元测试完成了，你把task 完成的时候，跟task 所搜集的文件自动Check in。darcy 做完了。第二个角色是bob，我们回到bob 的工作空间，我们进入bob 的SYNERGY 实验，SYNERGY 对project 进行工作，我们知道bob 需要在Cube1.0 XP 工作上进行校验，它的问题依然存在，bob 知道darcy已经做过这个事情，就把darcy 的拿进来，在SYNERGY 里，有一个非常重要的选择项，叫Baseline，我的这个项目来自于哪个基线，这里有一个task，all being used。bob 知道要去拿darcy 的，通过这个模板方式，可以确定你当前项目取自于哪个基线，所有darcy 完成的，我们看到cubeview.cpp1.1，还是原先基线的版本，这个时候我们做一下Update，大家看一看有没有变化？我们可以看到cubeview.cpp2.20，可以看到bob 把darcy 拿进来，他有没有去挑，有没有去找这些文件，因为他只关心这个业务的逻辑点。在bob 的工作环境里，已经把修改的拿进来了，bob 做一个校验，同时bob 把文件打开，我们点击一下，可以看到旋转非常快，bob 按下去又弹上来。说明什么呢？darcy 做得很满意，我们bob 接受这样的测试结果，我认为这样一个bug 已经被修改了，产品可以被发布。这是我想冻结中间开发状态要创建一个Baseline，就把当前bob Greating in Last 放进来，我今天创建了一个新的Baseline，把文件区分开，不再是配置管理的主要功能，而是配置管理的基本功能，配置主要功能是帮企业提供一个价值，这个价值就体现在软件资产属性所提供的决策。
如果你们想比较两个基线，这两个基线有关什么文件不一样，这个基线比那个基线少了100 个版本，有问题吗，你关心的不是这些文件上的差异，你关心的是这两个基线之间有哪些工作单元不一样，这两个基线有哪些真正的业务原因不一样，因此SYNERGY 在所有主流配置当中，帮助我们做这样的分析和业务决策的时候，是按照这么一个逻辑业务关系来做的。同时我们能够做到这样文件的比较，但是现在一些工具做不到按照这样一个业务逻辑去进行比较。
刚才创建Baseline 的时候，可以发现很多Task，我创建Baseline 是在上一个Baseline 可以构建的很多Baseline，这不是业务方式去组织配置管理，甚至把配置管理不认为会对我们的业务开发提供帮助或者提供决策支持的作用。但是SYNERGY 认识到这一点，这是因为我们站在ALM 的角度去看这个问题。
第二个单元，我会大家演示平行开发，平行开发有两个概念，一个文件开发的层面，还有一个项目的层面。我们很多软件公司有这样一个组织，专门一个team 负责bug 修改，还有一个team 围绕主干项目做。即使你在主干项目发现了bug，也不是你修改的职责，职责应该放到1.0SP 项目做。因此，我们看到第二个主干项目是为了增加新功能，这个项目永远是用来满足客户新要求。我要增加两个新功能，第一个增加Tooltip，我们经常用微软Office，darcy去做这个事情，另外是增加工具条可拖动功能，这个工具条是可以拖动的，这是arnie 来做的，现在darcy 和arnie 会产生平行冲突。工作顺序，创建Cub/1.1 项目来完成所增加的新功能。Ted 提交并且分派一个CR 给darcy，同时创建分派一个任务给darcy。darcy 得到任务之后，一样获得当前任务，检出有问题的原文件mainfrm.cpp，并且修改错误，darcy 完成当前任务。arnie，Ted 提交并且分派一个CR 给arnie，同时创建分派一个任务给arnie，arnie 获得当前任务，arnie 检出有问题的原文件mainfrm.cpp 并且修改错误，arnie 会得到平行版本冲突提示，arnie 完成当前任务，arnie 解决平行冲突并完成冲突任务。bob 是创建自己的工作空间，他要把darcy 和arnie 完成的任务以及Cube1.0 和bug 被修改完成的任务拿进来，进行集成测试并进行纷收。
我们看一下Cube1.0 的项目，有没有arnie、darcy 所需要的新功能，我们把鼠标放在上面没有浮动的提示，这是需要解决的问题。这是darcy 的一个新的任务，我们在这个任务里面还可以看到，你会发现有时候任务描述的不清楚，我们可以去看详细的信息，可以看到我的task 有哪些信息描述，我可以获得更多的信息，这样可能定位的更清楚的浏览。
我忘了做一件事情，SYNERGY 是基于任务的，它不允许存在孤立的文件版本，可能你忘了一个版本，SYNERGY 会告诉你选择一个Task，你要去不Creating 一个新的，增加浮动的工具。我们选择它，可以看到mainfrm.cpp2 号版本的存在，它是做浮动工具条的，同样我要做一个单元测试，我们把新功能已经做完了。darcy 现在怎么办？应该是完成这个任务，
元测试已经通过了，我们建议你还是按照单元测试完了之后，把你的单元测试的逻辑组织单位给完成掉。我们可以看到这边的变化，它就变成了integrate。arnie 做事情的时候，他需要一个Task，这个Task 也是从CR 过来的，它的属性里面有相应的Change Request，现在arnie也是做一件事情，我们把他设为当前的Task，我们把mainfrm.cpp 分出来，我们看产生了1.1.1，而SYNERGY 做到现在，很多东西都是显示版本数，分支、叶子、节点，那些数非常漂亮，但是很容易迷惑人，分支不应该成为配置管理工具的一个优点，而它已经是配置管理基本的工具。
现在arnie 来做他的新功能的修改，然后arnie 做一个单元测试，我们看一下工具条是不是可以移动，这是arnie 的工具，arnie 把Task 给完成掉了。完成Task，我们会有一个提示，mainfrm.cpp1.1.1 和mainfrm.cpp2 有平行冲突，我们先把任务完成掉，先保证增加新功能放在任务库里去，这时候可能他跟darcy 去讨论，把这些分支放在一起，我们有一个平行冲突的功能，我们要把1.1.1 和2 版本放在一起，我们知道SYNERGY 不存在孤立的、单个的文件，因此要创建一个新的Task，默认之后，既包括浮动工具条，也包含了可移动工具条，你可以把Task 跟变更请求关联起来，这个时候可以选择“变更请求”，我可以关联到“变更请求”上去，可以说这个Task 不是孤立的，这个Task 是有CR 关联的。SYNERGY 自始至终不会让你孤立的文件版本离开Task，这个时候我们还要做一个测试版本，要不断地测试，我们做一个Tooltip，arnie 做完了，arnie、darcy 都做完了，该bob 了，这个是bob 用来做1.1这样一个集成测试或者说进行收集工作的Prject，你把浮动工具条和可移动工具条做起来，这时候我们做一下收集，大家注意一下mainfrm 的变化，他可以把刚才Merge 的三号版本拿进来了，它已经具备一个新功能了，有Tooltip，还有MoveBar，新功能是满意的，然后我们回到这里面看一下，你把这些Task，所有跟我们新功能相关的Task 关联起来了，我们还要创建基线。我们怎么去获取别人的东西，两个项目的平行怎么是Merge 在一起的，其实两个项目的Merge 就是业务逻辑关系的Merge。Cube1.0 是darcy 做的，我们通过这样一个查询，我们找到一个查询Task 的方式，SYNERGY 帮助你查询，非常容易。我们知道这个Task 是解决问题的，我们就把Task 拿进来，作为在我这个Prject 内容上进行更新的内容。Cubeview还是以前的老版本，我们再做一次测试，我们看到它旋转非常快，并且可以MoveBar，我们可以看到平行项目的Merge 非常简单，就是通过Task 这样一个选择方式帮助我们管理人层面发现我们的问题。我们知道SYNERGY基于任务的方式已经帮助我们很好地组织这样的过程。
我都满意了，同样的我要把基线创建起来，我们选择这样一个项目作为基线，创建基线也非常简单，这里面有这两个基线，这个基线是用来增加新功能的，这个基线是修改Bug，我们可以作一个比较，它们之间的差异有哪些Task 是不同的，这里面我们以任务和变更请求方式去比较基线，把一个项目回收到前一个基线上去。做完之后还有什么工作没做呢？Ted要关心的是对我们的Build，我关心的是哪些新功能，在当前Bulid 里面有哪些是在这个Build里面存在的，比如cube/1.1 的时候，这次Build 里面有哪些新功能，比如你有100 个CR，有哪些CR 在这个Bulid 里面，有哪些CR 在另外一个Bulid 里面。我们也可以选择Format，在刚才我们那样一个Bulid 过程中，既包含了增加浮动工具条，也包含了让工具条可移动，还包含了Bug 的修改，这就是我们完整的一个报告，这个报告包含了哪个CR 关联到哪个Task，哪个Task 又关联到哪个文件。我们可以看到Ted 为自己所定义的缺省的CR 统计报告，在我每次登录之后都会刷新进来，Ted 很容易监视到项目信息。SYNERGY/Change 6.4a 做了很大的改造。