1. 好，大家好，我是InfoQ的编辑鲍央舟。今天我们请到的是Thomson Reuters的Jame Wu，James你好，首先能不能简单介绍一下你本人和你的公司？
我自己，我是一开始在电信行业做，我做过开发人员、做过项目管理、也做，电信行业叫做质量和流程改进，电信业对于这个质量还是要求蛮严的。然后我在2007年加入Thomson Reuters，大概就是这样子。至于汤森路透是这样，汤森路透现在应该是全球最大的专业信息提供商，很多人提到路透会想到路透社，但是路透社只是我们很小的一部分，大概只占我们每年2%左右的营收收入，更主要的是这些企业这些数据，金融、健康、税务、医疗等等。
2. 听说你们公司现在在使用敏捷开发，能不能简单给我们介绍一下你们当时引入敏捷的一个背景是什么，也就是说你们在什么情况之下想到了要引入敏捷这样一个做法？
说到敏捷很有趣，其实我自己不信敏捷这个概念。我是做流程改进或质量管理，但是我自己不信敏捷也不信CMMI这些大的这些概念，我的观念是说任何只要对公司对我的团队有用，能够帮助公司节省钱，能够帮助公司提高产品质量，那我就用，当时引入敏捷也只是为了帮助我们的团队解决问题。
可以举一个例子，比如说我们经常见的一个问题，我们做一个大的平台，这个平台到最后在集成的时候也发现有很多的接口方面以及其他方面的问题，那由于我们有些产品要发布到全球不同的这些交易所。可是每次发布是个特别痛苦的过程，在发布的时候他们会发现很多以前没有遇到的一些问题。你知道为什么会出现这种情况，是因为很多在前期在开发在测试阶段的问题没有被发现出来，那么一直到了发布阶段，到最后阶段的时候呢，所有的问题在最后就能显现。为了解决这些问题时候，我跟我们这些开发经理这些供应经理去聊的时候，那我说那我们来试一下持续集成。我们在一开始引入敏捷的时候不是为了说我要做敏捷，而是说我为了帮助我的团队解决问题。
5. 除了持续集成你前面提到的，应该是慢慢一步一步的引入了更多的一些敏捷的实践，为我们稍微介绍一下你们更多引入敏捷的一些实践吗？
其实我们现在主要的起步，我刚才说是为了解决问题，我们现在见到最大的问题，第一个就是在产品发布的时候有很多问题出现。那另外一个呢，我们越来越发现这种传统的瀑布模型很难适应我们现在很多新的产品，还有老的产品升级方面的要求，在这个基础之上，我们就引入Scrum，我们现在主要集中在这两个方面，我知道在敏捷还有很多其他的很好的技术，比如说TDD，比方说Pair Programming，我们还是说先拿到一些我们认为能够解决问题的。
6. 所以你们还是先是持续集成，然后再是逐渐引入Scrum这样一个管理框架？
比方说Scrum我自己也有一个开发团队，做公司内部的这些一些工具，一些内部的这些数据库的开发，那我们在一开始就使用Scrum，我的开发人员他们都说，这个东西很好，他们觉得特别被Motivate或者是被激发，他们觉得自己成就感也很大，自己可以控制好多的东西，他们觉得他们自己在控制这个产品，不是我在控制这个产品。那这个方法，在过程中他们会更多的去跟这些我们内部的这些客户去沟通，不仅仅是沟通，同时也向人家去卖我们的产品，整个过程包括我，包括他们发现说Scrum这个方法，真正的说是照比以前的这些传统瀑布模型要好的多，我可以在一个月内就给他一个原形，然后在两三个月内这个东西就上线，然后所有人都说这个好，因为他们已经试用过原形，这对于以前传统瀑布模型，我大概三四个月给他东西，或者他想要的，这是很大的一个改变。
我说一下我们另外一个研发中心的例子，我们在曼谷有一千人，他这个研发中心建的比北京要早，那么在几年前曼谷研发中心他们就开始尝试敏捷。他们是一个很好的学生，他们会把很多的敏捷实验全部拿到公司里去实验，那么他们会发现里面存在很多的冲突，最大的冲突在公司的产品管理上使用的还是瀑布式的模型，我相信现在很多公司的产品管理还是瀑布式模型，很容易用来做这种风险的预测，还有这种财务上面的一些预测，还有投资回报的分析，但是这种产品层面的瀑布式的模型和这种底层这种开发人员操作的这种迭代式模型会有冲突，最典型的说公司架构现在不允许说，我们内部的这些Business Analyst，就是我们的需求开发人员和我们的这些代码编写人员坐在一起。那他们也没有一个很紧密的一个关系，是说这个人要把所有东西负责到底。那势必会产生说，当这个开发人员他们自己想做敏捷的时候，他们找不到这些做需求的人帮助他来Verify，来Validate这些所有的Requirement，这个冲突很大。
8. 所以没有办法做到End to End，点对点，从客户端来到客户端回去的这个回路？
很难做到，我们现在也很难做到，所以说这也是为什么我们在北京，我们引入敏捷也好，或者引入敏捷这些实践也好，那是解决每一个点的问题，我们希望说，我们不断解决一点一点小的问题，慢慢的会影响更多的人，他们会相信说，持续集成也好，Scrum也好，或者这种迭代开发也好，会真正帮他们解决问题，提升他们的生产力，然后改进他们的质量。
其实公司层面是没有什么对策了。我们公司的文化是很好的，做事情都可以去试，那我们在北京这边，我们在试的方法就说我们也用敏捷的这些实践，我们帮助这些团队这些部门经理解决问题，他们从里面受益之后，他们会把这个方法推荐给他在英国在美国的同事。那另外呢，我自己一直困恼的一个问题，我问过很多这些做咨询的业界人士说，你怎么样去衡量说敏捷给你带来的效益，几乎没有人能回答我这个问题。所以呢，我们自己在摸索，说怎么样我向人家证明说，我用了这些敏捷的实践，我真能给公司创造价值。
那比方说我们现在正在做的，我们一边使用敏捷，我们一边使用Lean 6 Sigma。那Lean 6 Sigma会帮助我们更好的来收集我们在做敏捷过程中，我们花费的成本，我们得到的回报。那比方说，我讲持续集成刚才那个例子。那我们帮助一个团队做持续集成，他以前产品发布的那个流程得花大概12个小时左右，那现在他最终发布只不到两个小时，所有的这些部门经理包括其他的这些他的老板会看到说，原来持续集成真的可以帮我节省这么多的时间，那么他们会相信。
10. 所以你是以数据说话，不在乎一个大的概念，是敏捷还是Lean，还是6 Sigma，或者说把它们结合起来使用，只要说对你们真正有效，而且可以看到一个可见的效果，那你就可以把这个继续推广开来？
是这样子。其实把这个展开说，是说我们对于不同层面的人，不同的人群是有不同的侧重点的，那其实对于底下的工程师，工程师是最直接的，你说你每天Daily Stand Up Meeting，然后你做持续集成，自己写一些自动测试的脚本来测试，他们每天能看到好处，他们自己这种主观的感受会让他们接受这些实践，但是呢，对于坐在上面那些拿着钱的这些老大们，你要对他们说得是说，我做这一个，我可以给公司创什么样的价值，节省多少成本，你对他们一定要用数字去说话，所以说我们在公司层面上，我们来推动这些改进了，就不仅仅是为了引入敏捷，那我们一直用这个方法。
我有几个小的例子，但是不同公司的情况不一样，大家可以自己来看。先说数据分成不同层面，我们在整个北京研发中心的层面，我们使用的是平衡积分卡，那我们使用平衡积分卡来整体的向外面来看说北京这个研发中心我在这段时间内，我的产出是多少，我产生的缺陷是多少，我花的成本是多少，人家会看到说当你所有的这些产出在往上走，可是你的缺陷还是很少的情况下，人家会相信说，你在北京研发中心做得事情是有道理的，这是第一印象。那接下来呢，对于每个个别的案例，比方说我们说持续集成，比方说我们有更好的Scrum的方法，那我们就用Lean 6 Sigma的方法收集这些数据，然后把这些数据做成单独的案例去呈现给这些Manager去看说，你来看说你用了持续集成，你用了Scrum，你的Cycle Time缩短了多少，你的Defect减少了多少，那么就是两个方面了。
12. 那你们公司有专门这些人或者资源来专门收集这些数据吗？
是有的。对于平衡积分卡在我的部门专门有人做这件事情，收集全公司的数据，然后从里分析产生这个报表，那么对于每个个别的案例，其实我们现在，因为是6 Sigma的方法，那我们在每一个项目里边，我们都会培养这个Greem Belt，那这些Green Belt他会自己在做这个项目的时候，他会来收集这些数据，然后把这个汇报拿出来，最终我个人还是觉得说这种全员质量管理是比较有效的，每个人都有这个Sense，有这个想法，有这个感觉是说我一定不断的改进我做的事情，而且我一定知道我花了多少成本得到多少回报。
我们可以倒退十几二十几年前，我们当年看UML很多人在追捧，RUP，然后CMMI很多人在追捧，概念炒上去，很多公司就全盘照搬过来做。但是事实上对公司没有那么多的好处，我想做公司就是一个在商言商的一个过程，我在做这件事情，我一定知道花多少钱，得多少回报，那不管它是CMMI，不管它是Agile，或者是RUP，只要你觉得它能够解决你当前的问题，那么我就用。不要因为这个概念好就去把他拿过来用，也许你一点问题都没有，你引入一个新的方法反而造成新的麻烦。从我角度来看，我给大家建议是说，如果你有痛苦的地方，你有觉得不舒服的地方，你经常被你的客户追着跑，有些地方一直是你头疼，那么你引入一些新的方法来试试，那么敏捷很多方法应该是适合的。
谢谢！
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
