在 9 月 20 日举办的 ScrumChina Gathering Event 上，InfoQ 中文站的记者有幸邀请到 Bas Vodde 接受采访，采访的话题包括他与 Craig Larman 合作撰写的两本重量级图书，还有敏捷和 CMMI 的冲突。以下为文字稿。
InfoQ 中文站（InfoQ）：Bas，你好，请向 InfoQ 中文站的读者介绍一下自己好吗？
Bas Vodde（Bas）：大家好，我是 Bas Vodde，出生在荷兰，在几家软件开发公司中工作过，使用一些类似于敏捷的实践——当然，那个时候还没有出现敏捷软件开发这个名字，但我们的做法与之很类似。
InfoQ：可否举几个例子？
Bas：比如构建自己的持续集成服务器啊、测试驱动代码啊等等。然后 2001 年我来了北京，后来去了杭州，为诺基亚工作，几年后去了赫尔辛基，在 Nokia Networks 全公司范围内推行敏捷。
InfoQ：那你当时在公司里的职责是什么呢？敏捷教练？
Bas：唔……不，我带动着整个公司的变化，我们有教练团队，我跟他们一起工作。我参与过很多产品，小到 5 人团队，大到 400 人团队。
InfoQ：我记得你现在正在跟 Craig Larman 写两本书，都是有关“Scaling Lean and Agile”的，你们选择“Scaling”这个词，就是代表在你们在书中主要涉及的就是精益和敏捷在大型公司中的应用么？
Bas： 嗯，或者说，大型产品开发。从芬兰回来以后，我又来了杭州工作，跟一个 400 人的产品团队在一起，在我的推动带领下，整个产品都换成了使用 Scrum 做开发。后来去了新加坡，办了一家公司，www.odd-e.com，主要为大型公司、大型项目提供服务，敏捷训练、Scrum 培训、TDD 培训等等。
InfoQ：能介绍一下这两本书的内容么？
Bas：OK， 第一本书的名字是 Scaling Lean & Agile Development - Thinking and Organizational Tools，这本书的主要内容是怎样思考在大型产品中使用敏捷开发和精益开发，一些有关怎样为组织考虑，怎样在大规模团队中工作的概念模型，它涵盖的范围 有精益思考，系统思考等等，但也有一些具体内容，例如跨功能的自组织型团队、特性团队，还有些组织方面的东西，例如怎样构建组织结构，管理角色，职业规划 等等。世界上有很多上百人的团队都在使用敏捷开发，在中国也有。
InfoQ：那你在大型团队中推行敏捷的时候遇到过哪些困难，又是怎么解决的呢？Bas：这就是书里讲的内容了，哈哈。其实困难太多太多，最棘手的就是怎样搞定传统组织中的问题，怎样构建团队，提高开发人员的能力，怎样专注于开发而不是其他跟管理相关的东西，你也知道，尤其是在中国，很容易就光想着怎么去管理而不去想开发了。
InfoQ：那另一本书的主题呢？
Bas：Practices for Scaling Lean and Agile Development。这本书里面会讲怎么做计划、设计、测试，怎样协作，怎样多点开发，离岸开发，在一个庞大的代码库基础上怎样做持续集成，怎样处理 遗留代码，怎样做产品管理等等。这本书将继续阐述具体实践的话题，里面的内容都是来自于我们在实施中发现的行之有效的方法。
InfoQ：这两本书的写作进度怎么样？Bas：第一本书已经写完了，希望十二月可以上市，第二本差不多写完了，希望能够明年六月上市。
InfoQ：我确信这两本书会给读者带来很大帮助的。
Bas：希望如此吧~ 我们可是花了不少功夫来写的：）
InfoQ：我同样也希望它们可以被翻译成中文引进。顺便问一下，在实施的过程中遇到的种种困难，带给你什么样的感觉呢？
Bas：哈，感觉很爽。如果没有困难的话，这个世界可就乏味透了。你的工作就是找出阻力的来源，是什么造成了困境，你会从中成长。如果你不面对这些挑战，征服它们，最后你就会满心沮丧，无心做事 &*#@^(……
InfoQ：是的，要改变的东西很多，招聘、销售、绩效考核……
Bas：第一本书一共 350 多页，我们用了 50 页来讲组织中的变化，对我们的经验做了总结，但是这个话题实在太大，完全可以新起一本书，所以我们在书里没法涵盖太多的细节，我们也没时间，让我们期待下本书的到来吧：）
InfoQ：那么在开始在组织中推行精益和敏捷的时候，你一般都是怎么做的呢？
Bas：唔~~ 首先，他们既然请了我，那他们就已经下定决心要做实施了。那么接下来我做的工作就是了解情况，发起讨论，引入一些实践，讲解 Scrum，然后做回顾，对回顾中发现的问题做改进，再做回顾……
InfoQ：刚才在别的讨论组上，你还提到了 CMMI 跟 Agile 之间的冲突，能不能再多讲一下你的看法？
Bas：我认为 CMMI 一点用都没有。
InfoQ：呃……
Bas：CMMI 关注的是管理和组织，而不是开发本身。在 CMMI 的一大堆关键过程域（key process area) 中，只有一个是跟开发有关系的。大多数的 CMMI 实施都会带来很大浪费。
InfoQ：不过很多人也认为，即使组织中用了 CMMI，他们照样可以使用一些敏捷实践，例如测试驱动开发，持续集成等等。
Bas： 没错。我的意思是，CMMI 跟 Agile 在价值观上有冲突，而不是在实施上。我不知道 CMMI 的价值观到底是什么，但是看上去它们的价值观是过程重于人， 文档重于可以运行的软件。我不是直接从实施的角度去看敏捷，而是去看敏捷的价值观和原则，但是 CMMI 的价值观和原则是什么？我不知道，因为它们从来没有被记录下来。不过我敢打赌，如果它们被记下来的话，那肯定跟敏捷是冲突的。
InfoQ：哈哈，过程重于人，文档重于可以运行的软件……
Bas：所以，即使你满足了 CMMI 5 的标准，你依然可以使用 Agile；你用了 Agile，也可以过 CMMI 5 认证，但是我还是认为，二者是冲突的。CMMI……它不会关心源代码写成了什么样子，你们团队怎么协作，你是否雇到了恰当的人……
InfoQ：好的，非常感谢你能接受我们的采访。
Bas：多谢！
评论