三年前,Yahoo! 开始实施敏捷软件开发;3 年后,Yahoo! 已经有了 200 多个开发团队在使用敏捷实践。 ADTmag.com 的编辑 Kurt Mackie 与 Gabrielle Benefield(这些团队的核心组织者之一)就Scrum 在Yahoo 中的应用情况进行了对话。
Benefield 首先谈到 Scrum 与敏捷开发的关系,她说道:
敏捷是由价值观和实践构成的一把伞,在伞下各种各样的方法和实践一起生活着。其中目前最流行的就是 Scrum。极限编程也很火,它和 Scrum 组合以后就会展现出无穷的威力……敏捷就像一张网,描述了这一切中的通性,它是价值驱动的,Scrum 就是这些方法中的一种。Scrum 是一个非常轻量级的框架,使用方便——而且不仅仅限于软件行业。
当被问到为什么选定 Scrum 时,Benefield 说:> ……如果你想使用一个轻量级、能很快取得巨大成效,且非常简单并可以用最简单的方式使用的东西,那就是 Scrum……Scrum 首先关注的是大量的协作、团队良好的工作,以及能清晰定义的优先级。然后,才加入工程实践……我们是非常注重实效的。你会发现有些人完全是照本宣科,纸上谈兵,但我们更倾向于把 [Scrum] 进行调整,让它适用于我们自己的环境,甚至于每个团队本身所处的独特场景。你要真正关心人们的需要。
Kurt 接着提问,“那听起来 Scrum 是会根据项目不同发生变化的,不过它自己总会有一些实践吧?”Benefield 答道:> 是的,没错。某些事情你是不想去打乱的,尤其是当团队刚刚启动的时候。比如说,我们每天有 15 分钟的会议,叫做“每日 Scrum”。整个团队在一起讨论从上一次会议到目前为止完成了些什么,今天将要做什么,现在有什么事情阻碍了自己的工作。
Kurt 又问到,“很多开发者喜欢在独立环境中工作,可在这样的软件项目中,这似乎就会成为问题。Scrum 是否只是一种保证人们积极完成项目目标的方式呢?”Benefield 认为:> 其关键点在于我们是和人打交道。这之前我们倾向于把软件开发过程浓缩成我们所使用的工具、复杂的过程追踪方法、检查列表和任务分配——“嘿,你来干这个; 然后干那个”,这些很容易令人丧失积极性。其实,人们是能够实现真正自组织的。比如,我们让团队来做计划。业务人员会走过来对你说,“这些是我们的优先级,这个是很重要的,这个是我们打算做的。”而团队将决定如何完成这些任务。这里没有传统的项目经理来指派任务——“这是你的任务,先做这个——你觉得多久可以干完?”——我们会说“你们要把这些任务干完”,然后大家会自己认领任务并互相帮助。你知道,“Scrum”这个词是从英式橄榄球里面来的,团队只有齐心协力才能得分。我一开始介绍团队时,总会让他们坐到一起,有时这很困难。他们会有抵制情绪,但过上一段时间,他们就会看到好处,沟通、反馈和一起工作所带来的好处。
谈到实施方式时,Benefield 强调:> “强制”是个很有意思的词,它带有很强的控制性——“你必须要这样干”。我更希望大家可以试着去理解它的益处。我们是.com 的行业,我们是一群非常有创新精神、非常聪明的人。让他们听命做事,其结果比侮辱他们还要糟。所以我们更喜欢解释做事情的理由和它背后的价值。Scrum master 是对该过程理解最透彻的人,他负责训练整个团队遵守过程。我正带领一个国际化的训练团队。我们会和其他团队一起工作来帮助他们启动,然后偶尔 参与一些项目会议进行检查。但是每个团队都是能够很好自适应的。我们在每个迭代结束后都有一个“回顾”,团队将一起审视自己的过程,指出哪些起到了效果, 哪些没有,没有发挥作用的部分是否需要调整。如果他们遭遇了失败,我们就会参与其中提供帮助。
Kurt 随后问到,是什么原因促使 Yahoo! 转向了敏捷和 Scrum 开发,Benefield 说:> 有些公司一起步官僚习气就很严重。可是,Yahoo 刚开始时规模很小、发展很快,他们最开始的做法非常敏捷,几个创始人坐在一间屋子里面开发软件。然而当规模扩大到某种需要更加频繁交流的阶段后,他们提出了使用传统的瀑布流程……但是在我们这种创业型文化中,它很难实现。我们的员工都很聪明,富有创新能力,他们习惯于时时刻刻提出自己的想法。瀑布流程对他们来说太古板太做作了,它降低了他们的效率。于是,团队中的一名工程师开始给大家布道,他说:“嘿,我们应该更敏捷一些”……所以在2005 年2 月,我们就启动了一个敏捷开发的试点项目。
随后Benefield 又谈到其在实施敏捷开发的过程中的一些心得体会:> …… 那些我曾参与其中的敏捷团队,尤其是那些对其进行过大量辅导的团队,他们的生产力很容易就提升了200~300%。有些团队做的尤为出色,因为他们真正地 实施了敏捷。某些团队可能由于没经过太多的辅导和训练,或存在系统性的阻碍,所以改进情况就不那么明显。但从整体来看——包括那些最差的情况——生产力的 提升幅度大约在35~36% 之间。综合所有情况考虑,这个估算还是相当保守的。
Kurt 又问道:“在敏捷 /Scrum 的世界里,变化是好事吗?”Benefield 坦然道:> 我们 的想法发生变化是很自然的事情。当你开始构建一个产品并看到一些结果后,你就会想做出一些改变。我们不会说“你不能改它”,我们是在拥抱变化。在互联网上 面,你不得不拥有快速变化的能力。举个例子来说,当我们搭建 Yahoo 邮件的大规模存储后端时,中途有一个竞争对手提供了容量更庞大的邮箱存储空间。我们 当时必须迅速做出响应,假如当时我们用的是传统的瀑布模型的话,我们势必无计可施,但最终我们成功地对抗了对手的威胁。在开发产品的过程中,我们曾一次又 一次面临这样的局面。
当其被问到开发中想法常常变化所带来的影响时,Benefield 说道: > 敏捷有着严格的纪律。对于类似所有的代码都有全方位的测试这种事情,我们是纪律严明的,所以你有勇气去尝试变化,理解变化所造成 的影响。这里不会出现那种所有人都在尝试自己念头的无序状态。我们允许团队进行自组织,各种想法从团队中源源涌出。但管理层和产品所有者对选用哪种想法来 实施有着最终决定权,会从业务层面上来制定优先级,因为他们对其了如指掌。他们从根本上控制着何时发布产品、发布哪些功能,而团队自己决定如何完成工作。
在最后,Benefield 以下面这段话结束了本次访谈:> 在 Yahoo,我们永远不会命令别人使用这个过程。我认为过程的优点要靠它自身体现出来,人们也应该有选择的自由。敏捷正在 Yahoo 中慢慢取得主导地位……我相信,随着时间的推移,为了能够在竞争中真正胜出,敏捷会是公司最佳的选择。
Jeff Sutherland 在 InfoQ 的采访中说过,目前已经有 10000 人成为了 Scrum Certified Master,估计全球的 Scrum 团队已经超过了 12 万之多,你的团队是其中之一么?你是否也有兴趣来实施敏捷 /Scrum,来保证你的竞争优势?欢迎继续关注 InfoQ 的敏捷和 Scrum 专题,我们会继续为你带来精彩内容。也欢迎加入 InfoQ 中文站读者讨论组,将你的实战经验、心得体会或是实践过程中遇到的疑难,一并与我们分享。
评论