宁德军谈Rational研发团队敏捷实施和Jazz平台

个人简介 宁德军现任IBM Rational技术总监，硕士。十年如一日地致力于先进的软件工程最佳实践和软件经济学在中国的推广，成功进行了数十家国内外知名企业的软件生产力改进项目，公开发表了十多篇有影响的软件工程论文，在一些重要的专业论坛进行了数十场软件工程最佳实践的演讲。发表《奏响软件交付的爵士乐》一书，提出了软件交付2.0，分析了软件工程发展方向。

中国系统与软件过程改进年会，是由中国软件行业协会主办、中国软件行业协会系统与软件过程改进分会承办的在中国软件过程改进领域最有影响力的、规模最庞大的国际盛会，以专业、领先和规模庞大著称。

   

1. 今天非常高兴能有机会采访到Rational中国研发中心的技术总监DJ（宁德军），和我们来分享一下关于Rational和敏捷一些话题。那DJ你好，先给我们介绍一下你目前的工作吧？

其实我在Rational工作到现在为止已经有10个年头，在这10年里边，我们这个团队一直在做一件事，就是在中国推广软件工程的思想，或者最佳实践跟工具平台。这两个应该说是孪生兄弟，我们做任何事情其实先是有方法，有了方法之后，当我们按照一定的方法来做事，那我们需要提高效率。那提高效率的时候我们就想用工具来提高我们自动化程度，我们说要想工欲善其事，必先利其器，基于这个道理，所以我们在十年里边一直在做的一件事，就是提高我们中国的企业以及整个业界，对于软件工程最佳实践及工具的使用的水平，跟整个业界对这方面的一个认可。

   

2. 这是一件非常有意义的事情，我也知道你今天的演讲题目是一个“智慧的敏捷项目团队管理”，在这个演讲里主要会谈到哪些话题？

智慧的敏捷项目团队管理，其实为什么会讨论这个话题呢，在之前跟很多做敏捷的同仁聊的时候，大家都在谈，到底什么是敏捷，敏捷跟原来的包括我们所说的RUP，包括我们说的Waterfall，到底是对立的还是一致的。其实在我看来包括以及我们在一些实践中，得到有一个体会，其实敏捷有其最核心的思想非常棒的，但这个思想不是说，在某一天我们在睡觉醒来发明的，其实是一个演进过程，很多的思想在最早的RUP里面都有了。

敏捷最核心的我们看来最核心的有五个最佳实践，其中最核心的一个就是迭代式开发，还有两层项目规划，完了有持续集成，Whole Team，还有TDD。其实我们说这个迭代式软件开发，是我们RUP里最核心的一个基本方法，所以已经在很长时间以来，就有了这个最佳实践，只是在整个行业发展过程中，在这个实践点上，我们看到这个方法其实对整个业界来说，可能产生更大的价值，包括在RUP里边，我们也看到两层项目规划，也是在RUP里面非常主要的一个思想，一直发展过来的。所以我们在想，其实你们从RUP到敏捷，未来可能还有新的方法出来，整个的过程中，到底我们怎么能够把这些方法为我们所用，而不是我们去追求一些所谓的方法，其实那个方法对于任何一家生产企业来说，可能它很重要，其实从某种程度上我们的目的是高效的生产软件，而任何一家企业不是说，我做一个软件公司，我的目的是为了用好一个方法，那个是不重要的。

重要的是什么呢，我要在最短的时间内，来开发出最好的软件，能够打向市场，为企业赢得利润，为我的员工创造福利，为整个人类社会创造福利。从这个角度来说，其实我们追求的终极目标是怎么来高效生产软件，那这件事，那站在这个角度来说，怎么看待敏捷，我为什么叫Smart Agile，我们可以看到敏捷里面有很多思想，有很多，敏捷是基于最佳实践的，包括RUP里面也是最佳实践的，在任何一个企业落地的时候，我们到底用那些最佳实践。这个时候我们用一种Smart的方式来选择，我把敏捷最基本的思想我们把它叫做一个拿来主义，就像鲁迅先生说的拿来主义，有很多非常好的最佳实践，但是针对某一个个体，某一个企业，某一个团队，什么是最适合你的？不一定所有都适合你，山珍海味很多，但是你不一定吃下去对你的身体有好处。所以说呢，针对一个个体来说，你要选择最适合你企业能够帮你最快最短的时间内，生产出高水平软件，实现这个目的，能够把这些最佳实践拿过来，应用到你的头脑里边，这就是所谓的Smart。

   

3. 但是这个像统一过程其实已经谈了很长时间了，现在敏捷方法出来以后，很多人一看到这两个概念，可能就是统一过程就是统一过程，敏捷就是敏捷，你认为这两者是对立的还是能够融合的？

我觉得它是一个业界，就是软件工程领域，一边发展一边演进过来的，应该说一个持续发展的过程，它俩是完全一致的，根本谈不上什么对立，为什么这么讲呢？就我们刚才说的，我们可以看到在敏捷里边，我们所谓的一些最核心的最佳实践，其实来自于RUP，他不是新发明的，就是来自于那儿。我们还会谈一个，就像我们敏捷有四个最基本的原则，我们说这个个人跟相互交互，重于我们说的工具跟过程，拥抱变更重于可能Fllow我们的Contract。那我们整个团队很好的协作，等等方面基于最佳的实践。那这个最佳实践我们可以看到其实很多时候，都在RUP里边，对RUP里面“最精华”的应用产生的一种结果。

从这个角度来说，我们可以看看在敏捷最佳实践或者敏捷核心的原则在说这件事的时候，他并不是说我们只要个体相互协作，而不要工具跟流程，它只说“重于”。所以从这个角度来说，敏捷是相对的。那相对什么概念呢？针对于你任何一个团队，任何一个项目，任何一个企业，什么样的“敏捷程度”对你来说是最好的，有可能就像我们穿衣服——我经常给别人讲开发过程，做一比喻，就跟我们穿衣服一样。什么样的过程最好，其实前几年我们有一个概念，我们叫合适的过程，或者合适的方法对你是最好的，合适就跟我们穿衣服，合适我的衣服，合身的衣服是最好的。你可以想象一下，如果说我穿姚明的衣服，会有一个什么样的感觉，那个不是衣服，是风衣，对不对？但是反过来说，如果姚明穿上我的衣服，那个感觉更差，对不对，那是一个，他穿我的衣服到他身上是一个马甲，或者撑的都撑开，所以说那不合适的东西，一定是不好的。

所以说敏捷的提出，从某种程度上它是个相对的，针对到任何一个个体，你是只用一些最核心的，我们说Agile的一些最核心的Principle，还是用更多的最佳实践，比如说我们谈到TDD，你到底用不用，在你团队用不用，这个取决于你到底要多敏捷，你的团队的复杂程度如何，你的项目的规模有多大，人员有多少。所以说我们说，是哪些要素来决定了一个团队的或者说过程的重量呢，我们有这么一个公式，其实一个团队越复杂，做的软件越复杂，团队越大，质量要求越高，行业规范，行业的法律法规要求越多，这个时候你可能要遵循的Process越多，流程就越多（流程越重就越不敏捷）。

那相反呢，你团队比较小，软件也没那么复杂，那这个时候呢，你可能要遵循的过程就是稍微少一些。那所以说，到底选用多敏捷，这个选择过程也是非常Smart一个过程，就像我们所谓的Smart Agile。我们说到底你要选什么样的过程，对你最合适的，所以说敏捷就是一个平衡点，敏捷就是拿来主义，你到底把什么东西拿过来，到底你把自己停在哪个点上，有多重有多轻，这个过程，还是回到我们刚才一开始的话题，这个过程是充满智慧的过程。

   

4. 那如果说我们再具体一点，Rational这个工具，如果说有些企业想去采用它来去实施敏捷，你认为他应该是适合哪一类的企业？

这个问题其实问的很好的，原来有很多业界的朋友都认为，Rational在中国这么多年也好，包括实践了那么多很多我们的客户，都是一些非常知名的企业，企业规模很大。确实有很多同事就问我，他说Rational是不是能用在小团队？那对于谈到了Rational到底是干吗的，就Rational就像我一开始说的，两件事，可以再具体把它分成三件事，我们说我们在中国做得，或者在全世界做得是把业界最好的最佳实践，或者软件工程最佳实践总结出来，分享给别人，就是第一件事，就是所谓的方法；第二件事呢，基于这些最佳实践，为了使这些最佳实践能够更好的为企业服务，它需要有些自动化的平台去支撑它，所以谈到工具平台，这是我们做得第二件事；如果说有第三件事，其实任何一家企业，有好的方法，有好的工具，但你不一定成功，为什么呢？因为依赖于你对这些方法、对这些工具的使用的水平，那所以说我们团队还有一个任务，就是帮助我们的客户能够尽快的提高对方法的理解，提高对工具的使用水平，这样其实是一个目的，就帮他能够达到他的目标，他的目标有什么呢？尽快最好的生产出软件。

那所以说，从Rational这个角度来说，如果我们在做的这么几件事，我们可以看到，在中国，我们继续往下走，我们就会把我们所秉承这种思想，秉承的这种意念，包括我们所谈的Jazz 2.0一直会贯穿下去，把这种能够更好的为业界所服务。其实这个Rational做得事情我们清楚之后，那怎么能够把它跟咱们企业规模结合起来，其实从方法层面其实它是没有限制的，不管你大企业也好，小企业也好，从最佳实践的层面，我们都需要最佳实践，不管你很大的团队，很小的团队，为什么没有Agile？其实我们很多出发点是针对小团队需求，他没有被满足，因为这种方法针对小团队，所以说我们出了Agile。但是Agile是不是Only for 小团队，只为小团队，其实也不一定。那相反呢，RUP是不是Only for大团队，也不一定，所以我借此说一句话，RUP用好了就是敏捷，敏捷用好了，就是RUP。

那这个怎么来理解，还是回到我们刚才说的，从方法层面，这个更多的是讲了一个平衡的一个度，重量跟轻量级的过程到底你要选择什么样最适合你，所以从方法层面我们是不分大公司跟小公司；从工具层面，我们谈一谈为什么要选用工具，其实在我认为，工具是帮我们来提高我们自动化的，当你觉得在你的团队里边，不管你是大团队或小团队，当你觉得你这个团队在某一个环节上，由于手工操作已经降低了咱们的生产力，这时候其实我们就可以用工具。其实老祖宗为什么要用工具，因为他重复的做一件事情，这件事情他觉得可以改进，可以更加的高效，所以他发明了工具，工具是为了帮我们来自动化提高效率的。所以当我们用任何的方法，用任何实践的时候，最佳实践的时候，当我们需要自动化，需要工具的时候就可以用工具，不论你大团队还是小团队。

那举个例子，咱们说敏捷，持续集成是敏捷的一个最核心的最佳实践，但是想一想，所谓持续集成里边还有另外一个概念，非常紧密相关的，我们叫每日构建，你要想做到持续集成、每日构建，应该说有一个基本能力要做。如果说我们要每天做一个Build的过程，但是呢，这个Build的过程相对来说稍微复杂一点，你一个团队是不是能够容忍：有一个人每天花一小时，做这个Build的过程，其他人都在等着他，等他把这个Build做完。那这个话说回来，如果你每天花一小时，如果是一个人还好说，但是如果你们十个人每天花一小时做Build能不能接受？这时候，如果你要做Build，你就会想了，我是不是有一种方法能够把我的一小时的手工过程，把它自动化过来，所以说业界就产生了一些，我们所谓的持续集成（的工具），这只是持续集成这个自动化的一个构建的框架。它就是把你原来一小时的事情变成五分钟做完，原来只有少数人才能做的事情，因为Build其实这个过程很复杂，只要那些懂编译器，懂整个工艺构造过程，懂操作系统，懂整个环境的人才能做这个编译，但现在没必要了，我通过某一个工具、平台，它能够把整个过程简化，每一个人都可以做，点一个按纽五分钟搞定。

大家想一想这个过程，其实这个过程是一个敏捷，敏捷是最佳实践吗，是持续集成，但是大家想象这个过程不需要工具行吗？那么自己给自己找麻烦了，那我为什么要每天花一小时做这个事情，我为什么不一星期做一次，当然这里边就是个平衡，当你如果要做到每日构建，每日构建有他的很多好处，他能够给我们团队带来清晰的我们的进展，能够很清楚地度量我们对项目的进度，他有很多好处，包括质量。但是话说来，它也带来了一些工作量，那你这样怎么做到平衡，工具其实也是一种帮我们能够做很好的平衡的一种方式，当我们需要工具的时候不要拒绝，为什么要拒绝工具呢。就像你该出去穿西装的时候，也不要拒绝穿西装，那你该穿运动装的时候，也不要拒绝穿运动装，只要合适就好。所以说从这个角度来说，Rational其实可以针对大团队和对小团队的，都是合适的，只要看你怎么来用它。去年Rational发布一个，不是去年了，应该是两年半之前，Rational推出新的Jazz平台，其实它就是专门针对我们未来的包括复杂团队，包括小团队，都能用的一个平台，为什么说它是可以这样，因为它上面都是基于组件式的，基于一个Component（的架构），这样你可以当你大团队的时候，你可以选用更多的组件，实施更多的过程、流程；当你小团队的时候，你可以选用比较少的，所以它是这么一个过程，裁减过程。

   

5. 它是可定制的？

对，就像量体裁衣一样。当你需要小的西装时候，你穿一个小的，需要大的时候呢，穿一个大的。

   

6. 关于Jazz这个问题我们待会再具体讨论一下。现在我们再具体讨论一下，就是你的研发团队里面的具体的一些敏捷的经验，我也知道你是Rational中国研发团队技术总监，也带领了一个非常庞大的一个研发团队，那么在你这个研发团队内部是怎么实施敏捷的？

这边我纠正一下，我是Rational团队的技术总监，但是研发团队其实不归我管，研发团队有另外一个我们高级的管理者，他叫Charlie Yan，但是我们是非常Close的合作伙伴。在研发团队里边，其实我们在中国有几千人，Rational这块其实有100多人，接近两百人。这个团队到今天为止，应该说基本上百分之七十几都是在用敏捷方法的运作，从整个IBM全球来说，我们是在两年半之前开始做敏捷转型，我们叫转型，因为敏捷不仅仅是一个方法，它其实涉及到很多企业文化的部分，团队整个协作的文化都会改变。这也是很多企业为什么做敏捷会失败的原因，我觉得它会有些文化的改变。

   

7. 和文化有冲突。

IBM是两年半前开始做敏捷转型，所以他整合速度非常快，我们在一年前就达到了50%的项目，已经转到了敏捷上。那在今天有百分之七八十了，Anyway，可能一年之后，五年之后都不会所有的项目都变成敏捷方式，因为像我们说的，你合适就好。有一些项目特别的大或者复杂，他可能不太适合敏捷或者他做那种类型不太适合敏捷，那么这样的话，就把适合做敏捷的就用敏捷方式来做。那为什么我们会说会这么快的速度来推行敏捷呢？其实敏捷给IBM带来非常多的好处，那在一年前我们统计的数据，我们在实施过敏捷之后的想法，我们的缺陷率，就质量提高了百分之十几个点，我们产品按时发布率也提高了百分之十几个点。

那大家可以想像，如果说我们的这个缺陷的比例，缺陷降低了十几个点的话，咱们可以算一笔帐，如果说一个缺陷，你修复它，把它整个生命周期你消耗的成本，是一千美金的话，那如果说假设IBM每年，我们部门每年是有，假设的数据，这是我们做一个Assumption，假设是一万个，那这10%意味着什么？意味着10%，一千个，一千个你想想每个是一千美金，你想想是多少钱？那是100万，那100万美金给这个团队带来的一些其他的生产力提高也好，什么也好，那把这100万投到正规的地方，应该产生的效果就会正负两方面，一方面是降低，一方面是他把这个钱用在更需要的地方，提高了他整个生产力，这个的前后效果差距就非常之大。

所以IBM是在通过切身的实践体会到了这些最佳实践的或者敏捷的一些好处之后，他才开始推进敏捷转型。但是我们也在看，其实在整个推行的过程，我们也在用Smart的这种方法，我们其实并不是说照搬敏捷拿过来，我们就用敏捷四个最基本价值观，12个Principle，把它端过来，我们全用上，其实不是这样的，其实我们也在看，基于IBM这块土壤，什么东西是最适合我们，我们把他用在我们这个土壤里边，目地是产生效果。就像我们刚才说的，能够提高质量，提高速度，这是我们的目的。

   

8. 在你们整个的敏捷的实施过程中，有没有遇到一些问题，或者有没有一些经验，可以和我们的读者进行分享？

其实我昨天刚刚从（研发团队）那边过来，我也问了一些我们的具体做一线的开发人员，因为他们是敏捷的实践者，当我问他的时候，我说敏捷带给他们的一些改变是什么，他们回答我的第一个问题是，用敏捷之后他们觉得更累了，这是很多团队都有这个感受，用敏捷之后不是很轻松，而是更累了。那我就问他，我说为什么会用敏捷之后你会更累了呢？他说两个方面原因，一个方面原因是我们整体的效率更高了，原来我们这个团队，一年可能只做一个项目，或者说十个项目，但今年我们生产力提高20%，我们原来如果说只做一个项目，我们今天可以1.2个项目。那么我们如果10个项目，我们可以做12个项目，生产率提高了，也就说我们的生产率提高的同时，是我们带来一些工作量的增加，所以说大家觉得蛮累。

但是另外一方面，带来的是，他说每人的责任心，每个人的责任心增加了。因为在敏捷这个团队里边，存在一种文化，我们叫自领导，自组织，所以说他做很多事情是主动的，他不是被要求做什么，而是他主动去做什么。他给我举了个例子，他在每天，因为他每日都有每日的，他叫Daily Scrum，他有站立会议，站立会议上每个人都会说，我今天做什么，或者说我昨天做什么，我今天要做什么，有什么样的东西阻止了我做我的工作。那他就在说，你想每天我们都要跟团队说一下，那作为任何一个Team Member，你做任何一个工作都是透明的，那么我们当然不好意思我们这一天做的东西很少了，因为我们在一个团队里边，我们是每个人都要有面子，我们每个人都要发展，那我们不能跟他们说，我今天好像只写了这个一页文档，上了两趟厕所，他总归不好意思讲，总之要把效率体现出来，所以说每个人责任心更强了，不是说我被要求，是我自己要把自己的这些事做好。

   

9. 实施的过程中有没有遇到一些不好的东西？不愉快的地方？

这个确实还是来自于文化的改变，在实施的过程中很多，一开始的时候，有的人认为是工作量增长的过程。你想如果你原来每天只工作八小时，现在你工作十小时，你愿意吗？这肯定是一个压力或者说一个不好的方面的影响，其实每个人都不愿意加班，每个人都想有更多的时间陪家人。那所以这个时候我们就要来看，尤其是在实施敏捷，任何团队实施过程改进的时候，有一个曲线，一开始的时候，团队的效率会下降，不是会提高，当团队文化转变过来的时候会对方法，对平台转变过来之后，他的效率会提高，所以在那个谷底的时候，那时候冲突就非常大。

那团队说，哎呦，用敏捷还不如不用敏捷，那怎么把这个过程度过去呢？这个里面我们所谓的Scrum Coach就起到很大的作用，他在给他看一些，就分析一些原因，为什么工作量增加？工作量增加是因为我们的效率不高，还是我们整体生产力提高了，还是因为你责任心提高了，还是因为我们一些无用功太多？当他发现自己所有的工作都是产生效果的，被别人认可的，被团队认可的，而且对自己的Career发展都是非常有好处的，所以说这就接受了。你想他如果在这个团队里边，这个举个例子，他做敏捷过程中，我们现在每个Developer，他在做这个开发同时，那他还要看社区里边有些人问问题，就像我们很多人累了，或者今天比较忙，就算了，不去看社区。

但是他们认为，他们是敏捷的践行者，他们有这个义务去帮助别人，所以每天会抽一点时间去回答社区里边的一些问题，这个是一个额外的工作量。但是这个对他们的Career发展确实非常有帮助的，他时间长了，他在这个业界修炼自己的水平，那他以后会走的更远，其实IBM是一个宽带职业发展，他今天是个Developer，明天可能还是个Developer，但他的水平、能力已经安全不一样了。这就是个人的一个修炼过程，所以IBM你做技术会做得很深，即使是你是一个做开发，他的这个级别可能比老板高，工资可能比老板高。

   

10. 敏捷实施起码说有一个地方，比较好的是，把员工的积极性或者潜力都发挥的更大。

对，其实在十几年前的时候，我那时候在另外一家外企曾经做过一个项目，当时做那个项目的时候---后来那个项目是成功的，但是做项目整个过程中却有很多人，是非常的、这个应该说非常的慌张，或者说对项目没有信心，为什么？他看不到项目的状态，不透明。但敏捷团队带来一个很好的好处，不但每个人得到尊重，而且你做得所有的事情是透明的。所以这块就谈到敏捷另外一个讨论比较多的一个话题，敏捷是不是用工具，所以这就是我们非常多的一个话题，敏捷是不是用工具。那所以这块又回到我们刚才敏捷更崇尚的是一个团队的协作，团队协作以及更关注的是我们说，成果，敏捷强调的是我们Workable的软件----能够工作的软件，它重于你一堆的文档，这是它基本的原则，那怎么能够做出Workable的一个软件？

所以说从这个角度来说，我们说敏捷在实行的好的时候，你就应该把一些你所不关注的管理的工作，协作的工作，或者说是必须为了管理我们要做的工作，交给工具去做，把我们的重点放在践行敏捷带来的好处上，而不是那些工具可以替代的一些工作上。所以从这个角度上说，我个人认为其实IBM最大的成功，在IBM这么大一个企业，这么大一个研发团队，迄今为止你看敏捷给我们带来的好处很大，其实他为什么能够做到这一点，就是很大程度上，依赖于IBM有个Jazz平台，那个Jazz平台就解决我们刚才所说的，包括你团队的，我们说一个软件开发团队，最基本能力配置管理，变更管理，最基本的团队协作，最基本的需求管理，包括我们的User Story，包括我们的这个Agile的Planning，就敏捷的计划，包括这一个平台，他都做了，所有的人对整个项目都是透明的。

包括今天你到Jazz.net上，Jazz是社区开发的，你到Jazz.net上你能够看到Jazz这个软件开发的状况，你只要注册你就能看，所以他不仅仅对团队透明，对我们的用户，我们其实就是最终用户，我们可以作为对他的Fans也好，或者这个体验者也好，去用Jazz，那这时候你可以到网站上去登录到网站看到Jazz这个项目现在又在做哪些功能、他的状态是什么样，在什么时间会发布。

   

11. Jazz是一个非常好的平台，但是目前在国内好像他的声音并不是非常大，给我们简单介绍一下Jazz在国内的现状。

其实我们首先谈一个观点，Jazz希望给我们带来的是一个我们叫软件工艺演进过程，而不是一个革命，为什么说我们要是演进过程呢？其实在Jazz平台提出之前，我们所谓的软件交付，也就说那个时代，我们很多企业已经投资了很多软件工程的工具跟方法。那所以说呢，当他在有一种新的包括敏捷方法过来，包括Jazz平台过来，他要考虑的是，我如何能够基于我原来的这个投资，能够进一步提高我们水平，而不是把我们原来那投资Cut掉，来引入一套新的。从这个角度来说，确实一个新的包括敏捷，包括Jazz，过来之后，他要看，这个Jazz我如何能够把他很好的运用到我的团队里边，如何能把这个演进过程做得更加的平滑，使我们所谓的那个引进那个影响，我们那个曲线那个谷底能更浅一点，这个宽度能够更窄一点，时间能够更短一点，影响更小一点，所以这个他要考虑的问题。

基于这样，我们现在想象一下，如果说你是企业的老总，所以你要看Jazz，所以你首先要看研究一下Jazz的应用场合，如何来切入我们这个企业，所以一定是有一个研究或者说等待的一个时间，那现在呢，可以说今天我们有很多企业，正在引入Jazz，而且我们已经在中间已经有一些客户，已经成为我们Jazz的应该是铁杆用户，而且他们用的非常好，包括现在我们可以请客户到我们的最终用户里面可以去参观，他们已经真正的把Jazz融入到他们的企业文化里边，融入到他们企业开发平台里面，实现演讲过程，把Jazz为他们企业服务。

所以这个过程我们回答你刚才问题，所以为什么这个过程看着慢了一点？其实这个慢的原因是我们很多企业需要的是一个演进，演进需要有一个结合，包括文化的结合，包括工具层面的结合，那这个过程是我们花一点时间，但是我们能够看到两年前跟今天，我们Jazz已经其实这个进步是非常大。这个从这个确实有很多的客户已经在用Jazz。

   

12. 我也了解到你曾经出版过关于Jazz平台的一本书，里面也提到一个很好的概念就是软件交付2.0，能不能在这里给我们简单介绍一下它的概念以及它和Jazz的关系？

为什么提出这个概念，这个回过头再看看，在原来我们做了十多年的软件工程的最佳实践跟工具推广过程中，我们客户面临的一些挑战是什么，今天中国做软件的，包括全世界做软件的，都面临很大一个挑战，就软件1.0的时代面临的挑战是什么呢？也就说原来整个业界是从不成熟到成熟的发展过程，那他在做不成熟的时候，就像我们在建立一个团队，做一个软件，做软件过程中我们发现，原来做一个软件我们需要有基本能力是配置管理，所以他就开始，使用一些工具，建立一个配置管理的方法，我们把这个能力打造出来。

在某一天配置管理已经有了，原来我的需求管理还挺弱，我还要打造这块能力，所以他又把需求这块能力建立起来。他又过了一段时间配置有了、需求有了，他发现原来我项目管理也是非常重要的，所以打造项目管理的能力，慢慢的一步一步走，你就发现，这些企业呢，建立的一个一个能力，包括需求，包括架构，包括开发，包括测试，也包括配置管理，变更管理，也包括我们的项目管理。但是问题来了，所有这些事情你想想，我们是为了一个目的，咱们想想是什么目的？生产软件吗，做那些事情都不是我们目的，但是生产软件，软件是一件事，这时候你想我们把我们的管理数据放在这么多不同的工具里面，每个工具所用的方法流程可能也无法很好的对接，所以就形成了我们所谓的一个一个的竖井，这个竖井里边的流程是不统一的，工具是不统一的，数据是无法打通的，你看到的信息也是无法沟通互联的，在整个软件开发生命周期，也没有一个完整的最终性，这个不是我们要的。

如果从软件开发管理的能力上来说，我们要求的是这种软件开发过程我们能知道，我们能看到整个团队能够很好的协作，我能看到整个的状态，在需要Report的时候，能看到报告，但是你想想那个数据都放在那些散落的不同的地方，一个一个数据放着，我们怎么提高我们的生产力，我们怎么专注我们的软件生产过程，花了很多Effort，再把那些事情搞定，这是1.0面临的问题，我们想如何来解决这个问题，吸取1.0的经验，我们说2.0。2.0是什么呢？2.0强调，第一个我们所谓的合适的软件过程，从过程角度来说，我们不强调多大多小，从过程这个角度，所以说2.0提供我们的首先是一个，基于一种组件式的（架构），包括方法，包括工具，能为我所用。我需要的时候，我就把这个最佳实践做一个Component的方式，嵌入到我的团队的开发流程里边来，但我需要一个管理能力的时候，你把一个Component拿过来，嵌入到我们的开发过程。

需求管理是一个很Component，开发是一个Component，配置管理是一个Component，项目管理也是一个Component，但我需要把这些Component一起构建在我的生产线上，这就连成一个真正意义的生产线，在这个生产线上我的人能够很好的协作，2.0是以人为核心的，我的人能够很好的协作，整个流程是互同互联的，全生命周期是有追踪能力的。那最重要最重要的一点，我这个平台是可大可小，未来可以扩展的，今天的投资，明天不会完蛋。而且呢，能够解决1.0那个竖井的问题，所有的信息是存在一个地方的，所以说我们可以憧憬一下2.0带来的好处，我是一个开发人员，我是整个过程的一个主角，我需要的是什么，一个工具，我就把这个工具拿过来，放到我这个开发环境里边，我需要两个工具，把两个工具放到我开发环境里边。

但是我在做事情的时候，我不被其他的东西干扰，但是我要能够跟团队里的其他角色能够很好的互通互联，我做的事情他们能够看到，他们做得事情我能看到，我们Follow一个流程一个生产线，所有的信息在一个地方存储，没有竖井。这个时候我们真正的是一个软件工程生产线的概念，就真正打造出来了，其实我们一直在追求一个目标，就是软件工程化生产，软件生产线，这生产线在1.0时代已经有，可能会有一个生产线存在，但是有更多的竖井。那2.0时代呢，我们有生产线，是真正意义的生产线，没有竖井，这个就叫2.0。

   

13. 这是一个美好的愿景。

今天已经实现了，基于Jazz已经实现了。而且你看我们在你要Jazz.net你能看到，我们团队是跨全世界不同区域的，所以说我们Jazz这个产品我们叫RTC（Rational Team Console），Jazz这个名词来源于就说我们从爵士乐团队获得一些灵感，我们看爵士乐团队里边每个人都很专业，大家在一起一合，这是个很好的一个曲子出来了，非常美妙的音乐。那这时候大家想了，这个团队有什么样的东西在把这些人很好协调在一起呢？是有一个谱子，是一个，曲是有曲谱的，大家按照那个谱子在弹。

那我们软件开发团队里边有个过程，在Jazz平台上这过程是有智能的，是内置在里边的，它可以是敏捷，也可以是RUP，也可以是你自己定制的一个过程，同时整个团队基于这个平台，那些协作能力，Web 2.0那些能力都已经在里边构建了，他能看到你的团队的状态，他也能看你的状态，大家能够很好的协作。就跟我们说的就跟那个Jazz，就跟那个团队一样，你能够看到你的伙伴做得事情，你能够看到那个谱子，大家在按那个谱子在做就是一个美妙的音乐，完了他第一个产品Rational Team Console，它是个音乐会，为我们开发团队提供的音乐会的场合。所以说你看我们Jazz开发那个团队，他的人在美国，在中国，在印度，但是在虚拟世界里边，他就是一个音乐会的舞台，Jazz构造的一个能力。

   

14. 很形象的一个解释，感谢DJ接受我们的采访。

谢谢！