录制于：

Bas Vodde谈Scrum在中国的发展及看板

受访人 Bas Vodde 采访人 滕振宇 发布于 2010年8月11日 长度 00:21:57     下载 MP3

领域

过程 & 实践

主题

敏捷实施 ,

看板 ,

企业级敏捷 ,

Scrum ,

精益 ,

敏捷技术 ,

敏捷

分享到

观看视频有问题？

概要
在本采访中，在中国导入Scrum的先驱Bas Vodde分享了Scrum目前在中国的发展现状，如何更加高效地实施Scrum，为何要废除绩效考评和职业发展，并对计划实施看板的团队给出了一些自己的建议。

个人简介
Bas对敏捷方法特别是Scrum指导工作有丰富的经验，他也是ScrumMaster认证培训师。Scrum之外，他也培训和指导团队的测试驱动开发（TDD）、回顾和敏捷计划等工作。现在，Bas在新加坡为一家小型的顾问咨询公司Odd-e工作，该公司致力于在亚洲进行敏捷与精益开发的培训与推广工作。Bas致力于Scrum的推广应用，特别是在大型企业和大型产品开发项目中。他与 Craig Larman合著关于大型敏捷开发的书籍《精益和敏捷开发大型应用指南：大型Scrum开发的思维与组织工具》及“Practices for Scaling Lean & Agile Development: Inspect & Adapt ”。他也是C/C++的CppUTest单元测试框架的作者之一。

关于会议
Shanghai Scrum Gathering是由Scrum Alliance赞助的Scrum上海聚会，已于2010年4月19日-20日在上海举办。这是Scrum Alliance官方第一次在中国举办的Scrum聚会。

大家好，今天我们在这里访问《精益和敏捷开发大型应用指南》(Scaling Lean & Agile Development)和“Practices for Scaling Lean & Agile Development”两本书的作者Bas Vodde先生。首先十分感谢您早晨的精彩演讲。作为在中国的Scrum先驱者，您见证了Scrum在中国的这几年的发展，从您的角度来看Scrum在中国的发展现状如何？

我曾经在诺基亚西门子杭州工作过几年，我们在几年前就引入了Scrum。从我自己的感觉来看，最初Scrum在中国的发展比较缓慢，而在印度要快很多。一个很重要的原因是在印度有很多的外包公司。当Scrum和敏捷在北美和欧洲获得比较大的发展的时候，欧美客户会要求这些印度公司使用敏捷的方法去交付软件，所以很多的印度公司开始使用Scrum。与印度相比，软件外包在中国的规模要小一些，因此在开始阶段中国要比印度落后。但是最近几年，这种状况有了很大的改变，市场上也出现了不少宣传Scrum并提供Scrum培训的公司。就像我在今天早晨的演讲(Scrum在中国行不通？)中谈到的，相对于其他很多国家，Scrum在中国的推行其实应该比较容易。

是的，我听了早晨的演讲，中国的敏捷导入指数相当高。

所以，我认为Scrum在不远的将来会有较大的发展。看一下中国软件业的发展历史，在最近四年中，越来越多在中国的跨国企业开始使用Scrum。他们在其他地方推行Scrum获得成功经验后，把它进一步推广到中国。从去年开始，从我了解的信息以及收到的邀请来看，越来越多的国内公司开始引入Scrum，比如华为。

他们的Scrum听说相当不错。随着越来越多的国内公司开始引入Scrum，您是否能给这些公司提一些建议，如何使得Scrum的引入更加有效？

首先应该切记不要为了适应中国国情而对Scrum做出改变。很多人会认为中国人不同，中国的文化不同，因此需要对Scrum作出调整。

您指的是“定制”Scrum吗？

是的，十分没有必要。我认为最需要改变的其实是管理风格，这将会很困难。因为中国传统的管理方式十分强调“命令和控制”。把这种管理方式转变成适合 Scrum的管理方式其实很不简单。所以我建议下很大的工夫去思考，怎样能够改变我们的管理风格，使之适用于Scrum；怎样去处理中层经理的问题，这些人通过传统的考评体系在传统的组织中获得提升，他们应该怎样去调整自身的行为方式，以及如何在Scrum组织中找到合适新的角色。从程序员角度来说，我认为包括国内的程序员在内的绝大多数程序员在测试驱动开发、重构、自动化测试等方面做得都很差，应该加大投入在这些方面进行教育。因为国内公司对软件开发的重视程度不够，公司不愿意在工程类实践方面做大的投入，我建议国内公司在这方面加大投入，教育开发人员。改变中层管理者的管理风格。

我有另外一个问题，今天您在上午的演讲中也提到了，您期望废除绩效考评和职业发展方向，那您有没有更好的方案？

我认为我们其实已经熟知这些解决方案，因此我们的问题不是去寻找新的解决方案，而是怎样引入这些已知的解决方案。通常情况下绩效考评不是一个好的解决方案，因此我一般都会建议公司不要继续绩效考评。不幸的是这在绝大多数公司都是不可能的。因此他们必须要寻找一种不同的绩效考评的方法去平衡。有几种方法，一个建议是绩效考评应该尽量针对团队而不是个人。因为团队是共担责任的，而绩效考评是针对个人的，这两者之间本身就是互相冲突的，某些情况下甚至会导致团队的分裂。除此之外，我们可以让团队给自己设定目标，然后让团队给自己做绩效考评。可能听起来会觉得如果给自己考核，大家都会给自己好评。但是从我自己的经验来看，与让别人来考评相比给自己做考评反而会更加公开，公正。

如果这样的话，我们怎样把团队的绩效与个人的绩效、工资和职位挂钩？

我不会把绩效与工资及升职挂钩。从我的经验来看，尽管绝大多数公司表面上都有这样的规定，但是最终的升职和加薪的决定通常也不是由这个流程决定的，而是由某个大老板拍脑袋决定的。其实有很多种方法来解决涨工资的问题，比如您可把奖金指标交给一个团队，让团队自己去决定如何分配。

这听起来十分疯狂。

听起来确实是一个疯狂的想法，但是在一些以团队为中心的公司正在使用这种方式，而且确实有效。另外一种方法是把绩效与工资脱钩，采用一种基于能力的工资评价体系。在做工资考评的时候，可以去评估这个人的技能和经验等等，而不是那些指标、以及不停变化的目标。我经常开的一个玩笑就是就像在敏捷宣言中我们说“相应变化重于遵循计划”那样，你可以想象传统组织关心的是员工是否遵循一年或者六个月前设定的计划一样。但是很少有组织去衡量一个员工在市场情况发生变化的时候的适应能力。职业发展道路的想法其实更加有趣，当然这仅限我个人的观点。我觉得职业发展道路这个说法十分可笑，员工应该为自己的未来负责，而不是期望公司去设计一条发展道路从而变成一个“超级”经理。在我工作过的多数大公司中，我很少见到有人真正按照预先设计好的职业发展道路去发展。因此给我的感觉是职业发展道路在某种程度上变成一个公司对员工的欺骗手段。公司给员工承诺或一个可以预见的未来，但是如果你去做一下实际调查，很少有人会按照这样设计好的发展道路去发展。

因此这就变成一种虚幻的假象。

是的。人们这样认为是因为大家都觉得公司应该负责每个员工的职业发展。但是我一向认为员工应该为自己的未来负责，在他最感兴趣的领域内学习，成长。以我个人在公司内部的发展经历来看，我从来不知道“该”哪个方向发展，我总是不停学习我最感兴趣的领域，然后在这个领域找到新的角色。

审查和调整。

是的，审查和调整自己的职业发展。

接下来我想谈谈您的书。我知道您的第一本书已经有了中文版，您的第二本书也已于二月份在亚马逊上架。能跟我们分别介绍一下您的两本书么？

第一本书叫"Scaling Lean & Agile Development: Thinking and Organizational Tools"（注：精益和敏捷开发大型应用指南）。这本书的概念性比较强。第一部分介绍的是思考工具。它是关于敏捷思想以及如果在组织内使用敏捷思想。具体包括系统思想、排队理论和精益思想。第二部分是关于组织工具，具体包括组织在导入敏捷中所要经历的各种变革，比如建立一种以小团队为中心的组织，按照功能划分团队，以及相应组织结构的转变，当然也包括绩效考评、职业发展、头衔等等。第二本书还没有中文版，但是在不久的将来将被翻译成日语和韩语。第二本书叫做"Practice for Scaling Lean & Agile Development"。与第一本书相比，这本书更加具体。第一本书更多的是理论，关注的是组织级的问题。第二本书深入探讨各类实践，比如大型项目敏捷开发中测试管理、怎样做计划、怎样管理需求、怎样划分需求。划分复杂的产品需求本身就是一个很大的题目。如何处理产品经理与团队之间的关系；多地点开发、离岸开发。另外还包括合同、如何做敏捷软件外包等等。

软件外包在中国是一个很热的话题。

是的，软件外包在中国和印度都是很热的话题。中国和印度有越来越多的公司开始引入或者被客户要求使用敏捷或者Scrum来管理软件开发。所以敏捷的合同和传统合同也不尽相同。

听着相当不错，您是否有计划把这第二本书翻译成中文？

是的，其实这本书的中文版正在翻译中。只不过这本书实在太厚了，大约有600页。

确实很厚，您知道我们什么时候能够买到中文版吗？

这个我还不确定。我觉得最早也要到明年早些时候。

还要等好久。

是的，但是你当然可以去看英文版。

显然，我是要去读英文版的。接下来我想谈一下看板。您觉得看板是一个方法论吗？它跟Scrum的关系是怎样的？

看板是一种新的敏捷方法，不幸的是它取了“看板”这个名字。因为这个名字很容易给人误导。在敏捷社区中看板受到的关注越来越多。以我自己的观点，不幸的是很多人对看板的理解有误。很多美国和英国的看板支持者宣称与Scrum等敏捷方法相比，看板更容易引入，因为很容易就可以把传统的企业中的流程映射到看板过程中。他们倡导一种渐进式的转变而不是像Scrum等敏捷方法所提倡的那种革命性的转变。

那您是不是认为看板更加容易引入？

从那个角度看，确实是的。但是不幸的是，就像“看板”这个名字所暗示的，大多数人会认为引入看板就是在白板上用卡片来进行管理瀑布流程中的不同阶段。这不是一件好的事情。以我自己对看板的理解，看板要复杂得多。

不仅仅是那个可见的“看板”。

是的，要比“看板”和可移动的卡片多得多。

您对国内希望尝试看板的团队有什么样的建议？他们应该关注那些方面呢？

我想第一个问题会是“看板是否适用于你们的项目？”就像Scrum并不适合所有项目一样，看板也不可能适用于所有的项目。关键是考察您自己的项目情况。如果您的项目十分“瀑布”，而且您希望控制发布。看板可能是一个不错的选择。如果您的项目更像是一种软件产品开发。就像我自己在做的嵌入式产品开发中，频繁的发布产品基本是不可能的，再就是那种大型的软件开发，看板也不太适用。我个人还没有见过大型产品开发中实施看板的成功案例。我见到的更多的看板项目都是那种维护项目。如果您的关注点是产品维护，您需要的是对缺陷的迅速反应，迅速解决。Scrum通常不太适合于这种类型的项目。因为您很难在Scrum计划会议中去预测将会什么样的缺陷，而且通常也不需要整个团队共担职责去解决问题。所以看板对这种类型的项目会更加适合。

您是指对于那种运行以及支持类的项目，看板会更加有效，是吗？

是的。再就是对于那种需要频繁发布的产品。比如建一个网站，从获得需求，到实施和发布，这一切都必须在很短的周期内完成。通常这种项目用看板也会比较合适。关键是了解您自身的项目状况，确定您的组织可以经受怎样的变革。根据这些情况去决定使用看板还是Scrum还是其他。我不会因为看板是目前最新、最热的、最流行敏捷方法而去引入看板。我更不会因为不想引入Scrum而去引入看板，这些都不是引入看板的好理由。

 

采访人 滕振宇 具有多年敏捷实践经验以及丰富的带队经验，正致力于帮助国内团队导入敏捷方法以及思维。

1. 返回顶部

   Scrum...

   发表人 ! HideHai

   恩。。我们就在执行Scrum...蛮不错！

   回复