顾全谈研发团队Scrum实施经验

个人简介 顾全，eBay中国研发中心数据仓库(IMD)开发经理。作为eBay IMD在中国的第一个雇员，顾全在eBay DW项目的开发和架构的完善中做出诸多贡献。作为 eBay首批CSM和交易集市技术部门在全球的首个CSP，顾全领导了eBay首个Scrum实现，并正在推动整个组织的敏捷化。

敏捷中国大会是国内敏捷技术领域最高水平的大会。今年的敏捷中国大会（AgileChina 2009），以Pragmatic Agile为主题，参会者以高端开发者和技术管理者为主，融合管理和工程实践，推广全面敏捷之路。

   

1. 顾全你好，首先听了你精彩的报告，刚才听了非常好。刚才听了你报告之后有这样几个问题，希望你能解答一下，从你PPT里边看到你们现在团队里边用Scrum，有的团队现在比较疑惑是只采用Scrum，可是Scrum和极限编程这样的敏捷实践结合起来使用，就这个问题你有什么好的建议？

我曾经看到过一个调查的报告好像是VersionOne这家公司发布的，他们就说到大概有22%使用敏捷的这些团队，他们是使用了Scrum和XP的一个结合，我觉得这应该是一个很大的数目了，因为只用Scrum在他们的那个报告里面是49%，那么这两种的结合是22%。就个人感觉好像在这样的一个团队中其实Scrum它提供的的确就是一个框架，他是一个相对比较高级别的框架，那么你在这个框架中每天Day to Day的工作，大家在一起应该怎么样去做其实还是应该有一些更细节的工程实践。那么我觉得XP其实在这方面是一个非常有益的实践，与Scrum结合起来应该是非常有益的。我其实在日常的工作中也发现，虽然我们的团队没有实现XP的开发模式，但是你可以看到这个Team如果他开始慢慢逐渐的去真正拥抱敏捷的观念，他是可以开始有这种好像敏捷里边刚刚讲到的emergence这种东西。大家会自己去通过这样的一个观念去使用一些类似XP的东西，我们没有说强调他们一定要结对编程，或者我们没有强调他一定要TDD或者怎么样。但是很多时候，至少我们的Test可能是很早就加入到需求的理解等等这方面的一些东西里面，这可能不是很标准的TDD。那在结对编程那方面他们可能也不是一直坐在一起，但是大家所在的是一个很开放的空间，大家互相之间的面对面交流是非常多的，那么很多时候需求如何清晰化，大家都是有一个非常直接的交流，这个应该也是一个很好的现象。那么我觉得其实我个人的下一步，是希望能够在团队里把这两者真正更好的结合起来。

   

2. 另外从你报告里边提到团队使用敏捷之后，在很多方面取得了进步，但是有人比较疑惑，我是一个敏捷团队但是我做得到底好不好，到底做得哪方面比较好，就是有没有一个比较完整的指标来来衡量一个团队，一个敏捷团队是不是一个成功的团队？

我觉得这个的确挺难的，因为很多时候不是所有的事情都可以完全量化。我觉得可以有一些办法。比如说最终你还是要以这个结果来说话，以这个成绩来说话。那么其中很重要的一点就是你客户的满意度，你真正到最后，是不是给客户提供了价值，他们是真正使用的那一方。他们在日常的工作中自然就会知道这个东西是不是真的切合他的需要，或者你这个团队是不是足够敏捷能够去很快的响应他们的改变，一些enhancement，等等这样的一些需要。这些做好了，自然客户的满意度就提高了，这是最终你要看他的结果这一块。那么就团队本身而言，我觉得你可以通过比如说对团队士气的观察，可以发现他们是不是真的把这件事情当成自己的事情，他有个ownership在里面，他是不是的确能够享受工作的过程。因为我原来做一些跟其他的一些团队做有关Scrum的overview的时候，他们有的人也会问到这样的问题。他说好像敏捷起来之后，大家都是步伐比较快非常忙碌，那么你们需要加班吗？我说我觉得我们应该是没有加班的，而且我也不鼓励加班，因为我觉得这不是一个采取办法来压榨员工，这个更多的是要让大家乐在其中，能够把这个真正当成自己的一件事情，那么自然的，大家的士气也就提高了。

   

3. 那衡量整个团队他是不是成功的一个衡量标准，因为团队是很多员工组成的，具体到每一个员工，你认为有没有什么好的办法来衡量这个员工他自己的表现？

其实在这次开大会的这个过程中，我也听到了各种各样不同的说法。我自己其实对于这个问题没有一个很好的解答，我没有说我确定是不是应该做个人的绩效考评，还是不应该做。但是我听到有两个我觉得大家应该能够达成共识的：一个就是说我们都是人，那人都有差异性，我们要承认这样一个差异性，他不是resource，那么这样不是说两个人就是两块电池他的这个电压就一定是一块电池的两倍，他不是这样的。那另外大家承认这个差异性，同时我觉得每一个人他可能不可以跟别人比。因为今天早上可能我们在听其中的一个讲座时也讲到，程序员他有比如说有新手、有熟练工，然后有大师这样的级别，有一些人可能穷其一生也没有办法达到大师这样的境界。但是不同的人对他要有一个不同的衡量标准，他是不是在自己的基础上有所提高，那么他提高的幅度是不是比别人更大，这个其实是很重要的。而不是说你一个刚毕业的学生就要让他和工作了十年的一个非常精通某种语言的一个开发人员去比，那永远是他没有办法比较的。但是他可以自己和自己比，他在这个Team中是不是得到了技能的提高，而且这个提高的幅度是不是很快，很大，这个我觉得是很重要的。

   

4. 那有的团队实施敏捷的时候可能会认为，比如说有的员工水平或者素质达不到标准，或者在实施的过程中遇到可能对员工表现比较差，像你刚才说的标准达不到这种标准，也没有进步，然后和团队其他员工合作也不太好，如果遇到这样的员工有没有什么比较好的办法？

其实我觉得这样的情况肯定大家都会遇到的，但是我觉得还是有内因、外因两方面。因为有的时候不能够只是指责说这个人本身他不好，你是不是给了他足够的或者是正确的引导或者支持，这也很重要，这是外因的因素。当然他内因他也需要有一个正确的一个态度，觉得最终还是态度决定一切，然后他还是需要真正能够理解在敏捷团队中的工作有哪些地方是和传统的方式是不同的，他如何能够真正融入到这里边。其实在我的报告里面我也讲到了很多时候大家都会要求这个人能够比如说能够在尽量完全、尽量最少的监督下工作，或者他是一个有团队精神等等这样，其实你不管在任何的团队中工作这些可能都是需要的。

   

5. 另外一个问题就是因为现在敏捷在中国实施，我们都知道还不是非常普及，中国的一些敏捷的开发社区认为一个主要的原因可能认为中国的开发人员素质不是很高，或者是其他原因。在你自己看来你认为中国的敏捷实施程度这么低有没有什么其他的一些比较重要的原因？

我觉得我们的素质并不低，因为其实有一个例子就是说我自己的团队里面大部分的员工他们都是相对比较新手的，或者不是有很多很多经验的，但是大家在这个Team里边真正做到了可以形成一个合力，大家可以有互相的帮助。这个Team不是一群人的简单结合，而且我觉得就是说其实更多的可能不是素质的问题，很多时候是教育的问题，或者是一些老的观念的问题，这个观念的确很难改变，很多时候。或者是这个人他一来了以后，他说这个Team有一个经理，有一个我的顶头上司，那么我应该如何表现，他不敢于表现自己那很有可能在很多方面他就落入了一个原来的那样一个循环里面去，他就很难能够在这个敏捷方面达到真正的一个程度，所以我觉得我们还是要大力推广敏捷的这种概念，让更多的人来了解它。

   

6. 中国有些公司或者团队想使用敏捷，但现在可能会比较犹豫是不是来做，或者如果做的话不知道从哪里开始，对这些公司或者团队你有没有什么好的建议给他们？

其实这个我觉得就采用敏捷本身的办法就行了，敏捷本身的办法也是说那个big bang，要开始，然后就所有人都一起全都开始了，从原来的一个东西完全都变成这样。当然这个改变是一定有风险在的，但是我觉得可以采取一些比如说像我们经济特区或者这样的一些方式，能够给他们更多的自主权，能够让这些团队尤其是那些自觉自愿他觉得这个东西对他们来说是好的，这个敏捷的理念对他们来说是make sense的，这样的一些团队能够自己先去尝试，然后真正用他们的结果来说服管理层这个东西的确是可以在我这里茁壮成长起来的，然后我们再一步一步的来。而不是说可能一开始就所有的人全面铺开，这样有的时候可能也不一定是好的办法。