Save our Scrum作者访谈

Gärtner: 早在2014年，在敏捷大会的午餐中，我们偶遇了一位大型出版社的编辑。我们突然想到出版一本跟Scrum自助有关的书籍。我们集思广益，为这个想法拟一个标题——然后我们想到了 Save our Scrum ，我们都认为这是一个有趣且有意义的标题。

Heusser: 我们从各个角度考虑怎样可以更好地帮助社区，一本有关测试的书籍？在整个交付过程中，我们都有充满了精力。Markus刚刚获得了认证的Scrum培训师；我也刚刚修读完精益交付公共课程。我们俩都看到企业在实施Scrum中挣扎奋斗着。一次又一次。部分采用Scrum的企业对其采取了妥协——也有些运行的很好。那些“运行的很好”的Scrum企业实际上是使一直存在的问题可视化！ （轻声笑） 。我们认为我们的人生经历和想法可以帮助到他们。我想到了船艇；我们谈论了大量的“火车事故”。我们想我们可以做一个航海主题，专注救生工具——不是抱怨烂摊子，而是帮助团队摆脱困境。这就是这个标题的故事，这本书的故事。基本上——我们看到很多公司在实施Scrum时都遭遇了失败，希望寻求帮助。

Heusser: 我们将这本书分为四个部分，读者可以根据自己的兴趣和需要选择。在本书的第一章节，我们用我们自己的语言和风格论述了“什么是Scrum”——但是我们的意图是要与 Scrum指导 相兼容。这一章节连同下一章节——Scrum的“为什么”都是由Markus完成的。在第二部分，我重点讨论了危害Scrum采用者的四种常见问题——旋风般的快速行动（Whirlwind）、压缩问题（Compression Problem）、裁剪问题（Tailoring Problem）、假设问题（Assumptions Problem）——和对应的解决方案。在第三部分，我们提供了“金点子”（nugget），针对特定问题和难题的简单答案。现在我们刚刚完成了第三部分；在第四部分，我们打算撰写一些有意义（不会让你觉得索然无味）的案例研究。除了“我们实施了Scrum并且它实在太棒了”，我们还将讨论了一些真实的让你无法脱身的困境，和团队如何摆脱他们。

Heusser: 它们大多数是故事，就像上面的微型案例研究，有些是建议、有些是立场——反对我们平常看到的常见的反模式。我们讨论了两种金点子，是关于任务和每周工作四十个小时。个人而言，我没有弄明白怎么回事。如果你能够使故事保持相同的大小并且计算每周完成的数量，或者至少计算工作成果（“点数”或者“速率”）的相对大小，那为什么还要建立 另一个完全不同 的测量系统呢，在系统内将故事分割成任务，然后计划以每周工作四十小时的方式完成任务？这个时间完全不能跟实际相匹配，因为总有意想不到和未记录在案的会议，最终你会使用模糊的东西比如“行政时间”（admin time）来凑足四十小时，要不然你会感觉很糟糕，试图改变行为或者评估方法，从而让它们相匹配。它们不会匹配成功的，所以请不要那么做。我们发现随着时间推移观察你真正完成了什么，在此基础上预测未来这种方式要比单纯的希望和梦想更切实际。

这是其中一个金点子的核心。这里还有一个，我仅仅是进行了剪切和粘贴： “ 我们不能那么做” 。

有时候你碰了壁。团队告诉你架构不能支持你们正在努力实现的事情。当你听到基于遗留软件改变商业策略时，你会觉得这个建议很诱人。

其它时候可能是软件问题。经常某个程序员，通常是初级程序员，说这个方法“太难了”，然后你就放弃了该特征。

这个时候，我们需要不同的意见。因为不同的程序员需求不同。但是你应该注意表达方式——不要询问他们能否完成，询问他们需要花多长时间。虽然这可能造成一种很荒谬的情况，一个单一的特性花费的时间比重写一个系统还长。但是没关系。只要你在台面上获得了一个数字，你就能够处理。

我们来探讨一个案例。假设你有一个系统，需要用户ID和日期，如果用户在那一天拥有保险责任范围，那么就能够返回信息。系统速度不够快，大约需要耗时一秒钟。产品负责人希望能够实现在线查找，用户上传一个文件，包含100-10000个会员，在他们之间搜索，最终获得一个新文件，所有这一切要在5秒内完成。

最简单的实现方法是通读文件，创建一个for循环，将答案写到另一个文件中去——这需要花费一分钟至一小时不等。显然，这种方法行不通。

简单回答是“不能实现”，或者“处理过程可能需要一个小时”。

除了处理过程可能需要一个小时以外。你可以弹出一个窗口，提示代码正在处理，然后通过邮件发送结果。或者更好的是，创建一个不同的搜索函数，输入用户ID数列。所有的这些可能性都是通过沟通交流发现的。

简单回答能或者不能，会限制这些可能性。让你错过它们。

让我们将暖气开大一点。使用相同的系统，但是你希望提交claimCode和ProvideID，查询利益是否已经被覆盖。这基本上是索赔处理，你的索赔处理系统会做你购买的事情，并且索赔处理系统是通宵运行的。程序员甚至都不清楚所有的规则，规则很复杂。

如果产品负责人清楚所有的规则，技术人员可以创建一个程序进行查找，并宣称“现在，它似乎就是一个已经涵盖了的利益”（当然，如果前一夜索赔处理运行的保险范围发生了变化，那么协议就会取消。）

或者，公司可以向ERP供应商寻求帮助。

关键是向可能性敞开怀抱。“我们不能”将可能性排拒在外。我们是说——不要排拒任何可能性。允许人们进行探索。从审判中休息一下。让团队自组织，彼此间进行思想的碰撞。让思想互相渗透。

最后一个想法：如果有人说“不能”这么做，请不要放弃。问问为了实现这种想法，必须改变什么，然后问需求什么。答案可能是“一千万美元和一个新的索赔处理系统，一个系统的转换，和四年的时间……”

但是，答案也可能很简单。

Gärtner: 我共事的实施Scrum的人们的知识水平非常的宽泛。就拿我最近接触的一个客户来说，他们需要在医院外科手术室建设手术台，包括硬件、软件、和物理结构。我与当时的Scrum Master合作的非常愉快。他快速地掌握了Scrum背后的理念。当他们将整个团队领进一个房间后，我对这种正面的影响非常吃惊。当然，现在他们仅仅刚刚开始了他们的Scrum旅程，但是他们已经感受到它的魅力，比如渗透式沟通。我也激发了极端制造的一些灵感，但是目前而言，这一步似乎还不能被他们中的大部分人理解。

另一方面，我参与的企业曾经陷入他们当前的组织设计和组件团队的麻烦中。在那里，给客户演示的不同特征的计划发布一直是单调乏味的。我在汽车行业待过的九个月中，我逐渐意识到他们仅仅是局部最优化，因为他们自己放弃了希望。他们对他们所在的大型组织能够逆转形势放弃了希望，他们对获得更好的生活放弃了希望，他们选择优化能够立即产生影响的因素——这些因素包含了所有的缺点。

当然，我也看到过团队和管理者在实施Scrum时只做表面文章——我的解释是，我断言那是因为他们没有理解 敏捷的核心 。我看到团队实施为期三周的Sprint，突然停下来，花一周的时间准备下一个，仅仅是因为他们的管理者不相信在当前模式下能够准备下一个为期三周的Sprint。

在任何情况下，我至少会遇上一、两个人能够理解潜在的价值和原则。根据他们的影响力，他们可以开始拯救他们自己的Scrum实现。

Heusser: 大多数组织只有少数人可以参加为期三天的课程，每个人还有一个小时的介绍，或者阅读杂志或者阅读几篇博客。在大多数情况下，人们根据他们过去的偏见重新解读Scrum。命令和控制思想是如此的根深蒂固，以至于需要花费更多的时间实现自组织，并扎根。

Heusser: 哦天啊，每个人都在询问我们这个标题的意义。这要从Scrum其实没有一个巨大的成功的普及率说起。Schwaber声称，差不多75%的组织“实施”Scrum时，没有得到他们希望得到的结果。Scrum狂热粉丝辩解道，如果人们 过份妥协，以至于都不能识别它是Scrum ，那么你就不能责怪Scrum方法。那些认为Scrum不够强大的人，比如可能是Lean或者XP的支持者，认为我们应该讨论一些其它的东西。很多我们非常尊敬的人认为，我们应该再写一些更加开放， 追求价值或者取悦用户的东西 。

我们可以看到，尽管公司对Scrum进行了大量的投资，但是仍然陷入困境。这种困境似乎是普遍的。当我在演讲中，在美国或者在欧洲，给出相关材料时，我往往会得到三种响应——处于瀑布式系统或者混乱商店（chaos shops）的人们、正陷入困境的人们、和已经陷入困境好几年的人们，并且目前已经渡过困境。目前来看，第一组和第三组比例最小。第三组倾向于认同我们谈论的议题，并且承认他们不得不努力解决困境。

我们希望帮助人们更快地转移到第三组，并分享我们获得的教训经验。环顾四周，我们并没有能够找到太多与之相关的Scrum文献。Tobias Mayer的People's Scrum可能是最接近的；大量的内容都是思辨性的思维试验。这是一篇很好的著作，值得阅读。我们发现在这些想法中，我们已经尝试过许多，并且已经有了结果。我们把我们的工作看成是一种跟进，一种howto指南，而非The People’s Scrum，分享寻求真理的态度，并能够意识不同的环境可能决定不同的反应。

另一件事（暂停），其实我不应该这么说（暂停）……我还没有在其它场合说过，真的。大多数的“Scrum文献”都是关于如何妥协。都是关于如何管理全局团队，如何处理多任务，或者将一个人分配给多个团队，如何处理依赖项，比如数据库管理员解决了标签问题，这样在每次sprint团队交付端到端的软件时，不需要包含它需要的一切。我不确定Markus是否同意，但是我认为这值得写一本书，内容是 “不要那么做” ——当然，你可以获得最佳的妥协建议，给你一个线球，上一垒（棒球），但是我认为世界可以从 停止尝试错误的事情 这种建议中获利。

Gärtner: 哦，我完全同意这一点。除了棒球的引用，因为我喜欢游泳，我认为还可以引用游泳。就像你试图将其中一条小腿以90度的角度指向水的外面，以这种方式游泳。根据我的训练，我可能可以做到这一点，但是我敢肯定不是每个人都能够做到，或者不是每个人都会强迫他们自己去做。

Heusser: 我说这么多啰嗦的话是想说，是的，Scrum需要拯救。我认为目前ScrumLand的现状不是我们所希望的，并且我们希望这本书能够帮助大家改变现状，即使不是为所有的Scrumland，至少也希望能够帮助到少数的读者。

Gärtner: 对我来说，这个题目的答案可以归结到我前面提到的人们。他们彻底理解了我们为什么实施Scrum的理念。有些人成功地在他们的工作场所起到了积极的作用。这些人不需要拯救。至于其他人，我想除了我们这本，还没有另外一本Scrum书，可以帮助他们，帮助他们拯救他们的Scrum。

Heusser: 我们要特别看重信誉。教练不会拯救团队；团队必须自我拯救。我们需要起到一种催化剂的作用；提供一些见解，分享一些故事，给出一些建议。最重要的是，我们需要提问，这样能够经常重新界定问题。

我曾经与一个团队共事，他们完全按照常规实施Scrum。结果并不是非常的糟糕，但是还是有一些摩擦；他们最终在第二个星期五“完成”了代码，测试人员将会花费整个周末用于测试，发现bug。因此，团队“未能”实现“sprint承诺”（现在我们称目标）。

没有人感到高兴。

当然，团队也有自己的问题。将要完成的故事并没有实现最初的使命。邮件不能被发送出去。开发人员会说“哦，不，这仅仅是将邮件提交到邮件队列，并没有执行队列”——当时我们称这个故事为“在提交按钮上发送邮件”。

这里的“拯救”并不是单一的。它是一系列，在我到达现场之前，他们已经开展了一些相关工作（我的同事，Matt Barcomb和Lanette Creamer也加入了这个团队）。长期来看，我们设置了工作进展期限（这样就不会在最后一天测试故事时发现其不能交付而抛弃故事），故事的启动不仅仅依照验收标准，还要重点关注目标，而且，最终我们放弃了sprint的整体思路。这支特定的团队负责一些类似seventy systems的维护工作。一个“大型”的微项目通常由五或者六个故事打包而成。每个产品中部署故事的均值可能是1.5，中位数可能仅仅是1。同时当我开始将点数1、2、3、5和8分配给故事时，我们还得远离斐波纳契数列。当我给团队分配的故事点数是1、2时，可能这个任务都不值得分配点数。如此团队可以计算故事，或者速率，并且可以预测他们能够完成什么，而不是看着一张列表，认为我们可能可以在两个月内完成。

这意味着生产力估算将作为一种责任转交给项目管理者。团队不得不执行可预测的，项目管理者可以预测团队可以交付多少成果。在这个过程中，需要构建、学习和适应大量的代码工艺工作和测试基础设施。

总括来说：疯狂的最后期限消失了，疯狂的加班消失了。同一天内，团队能够移动任意一段经过测试可用、可部署特性中的代码。批处理大小越来越小。会议越来越少，而花在人们喜欢的事情（解决业务问题）上的时间越来越多。

这是生活变得越来越好的一个案例；从混沌过渡到Scrum甚至“Scrum plus”大约需要一年半的时间。这个速度比我共事过的其它团队要快速的多。他们确实感受到了持续改进的意义（如果你感到困惑，你可以适时地进行回顾和规划。当人们希望对某事进行回顾时，他们会将其粘在墙上。当数量达到六个时，我们就会召开回顾。或者你也可以召开紧急回顾。一支二十人的团队，我们通过减少每次sprint会议的“神圣日子”可以释放一个人一年的工作量。）

Gärtner: 我记得几年前我曾经接触过一个客户，我刚刚从个人失败中恢复过来，试图成为七个团队的Scrum Master——希望你不要这么尝试。他们中有一个团队已经实施Scrum一段时间了，但是他们感觉作用不大。我主持了他们的回顾会议，参与并帮助他们的Sprint规划，说服他们开放Sprint评审。经过两个Sprint，团队参与了Sprint评审过程，看到了他们害怕的产品经理是如何在利益相关者面前解释决策的。仅仅通过开放Sprint评审，团队和产品经理之间的关系得到了改善。短短的几个月内，我就可以将更多的责任移交给团队，并且从那时起，他们已经能够维持计划的进度。这种特定的团队就需要拯救，并且我也注意到了这一点，同时还需要在合适的时间寻求外援的帮助。

Gärtner: 我和Matter很早已经加入驱动测试社区，社区原则之一就是“任何实践的价值都取决于它的环境”。当然，在某些环境下，我们应该关注商业价值。另一方面，我也看到过很难把握商业价值的环境。最近有一个培训学员告诉我，他们正在研究一种产品，但是要等到两到五年才能最终货币化。在那之前，他们有充足的资金，但是团队完全不知道那时什么才有价值。在这样的环境下，很难关注商业价值。

在这种情况下，我使用Scrum寻找有价值的事物，然后转而关注它们。

另一个案例：手术台团队遇到一个挑战。在他们第二个Sprint，他们发现在当前参数下不能实现手术台的物理建设。为了实现物理建设，不让它们互相冲突，他们只能做出一些权衡。他们可能会降低提升高度，他们可能会拒绝一定水平度的横向翻转，或者减少X-ray的自由度。因为这些代理来自不同的市场，主要是美国、欧洲、和亚洲，因此他们肯定会带来严重的不好的影响。一些权衡会扰乱美国市场，其它的也会扰乱其它市场。最终，团队决定权衡美国市场。在Sprint评审期间，负责美国市场的产品经理对这个决定非常的苦闷。但是团队还是成功地向利益相关者阐述了权衡的目的，仅仅经过两周，人们就发现他们已经完成了很多老方法需要花费数月才能完成的东西。

因此，是否专注商业价值？当然，但是什么才是商业价值呢？它是否能够预料到美国市场？真的很难讲，尤其是当你面临一些工程问题，和权衡交易时。当然，软件也一样。

Gärtner: Scrum是最小的一个框架。它试图保持专注。例如，它根本没有阐述跟开发实践相关的任何事情，因为它试图使其适用于各个领域，而不仅仅是软件开发。例如，有些人在教育上使用Scrum，有人在硬件开发上，和建造汽车中。所以，你可以有意识地根据你的环境，添加东西到Scrum。

当你添加的东西跟Scrum价值和原则不一致时，实践它们就会带来问题。这时人们可能正确实施Scrum，但是参加Sprint回顾会议的都是Scrum僵尸（Scrum zombies）。他们的方法并没有问题，但是添加的实践破坏了Scrum的整体理念，因此没有得到他们想要的结果。

Matt ： 我看过一个客户的回顾笔记，他的回顾完全以责备为中心。“Bob的代码有异味”（我敢肯定Bob那天不在现场），“Sally不能按时完成任务”等等。除了“更加努力地工作”没有一个是具体行动项目。你可能会辩解这是一次回顾，但是这是“book Scrum”，里面涉及哪些是对的，哪些是错的，应该改变什么等等，当然，它也给出了答案——但是，都是废话。他们的组织充满了命令和控制思想，充满了恐惧。如果人们不知道一些值得重视的事情，那么他们就不会知道想法是糟糕的，或者他们会觉得低人一等。神奇的是，笔记中每个新的想法都是糟糕的想法！我感到很震惊！（笑容）。

Gärtner ：简单来讲，Scrum有三大主要角色，三个主要构件，和五类活动，其中有一类活动不需要召开会议。当然还给Scrum Master、开发团队成员、产品负责人分配了一些职责。自组织的组织逐渐在产品待办事项、Sprint待办事项和产品增量中发挥作用。有一个Sprint规划会议、每日Scrum会议、Sprint评审、和Sprint回顾。为了准备下一次Sprint的产品待办事项，我们需要花时间优化待办事项。这就是机制。

当你抛弃这些，试图单独执行机制，很大可能会以Scrum僵尸告终。人们会无精打采地参加会议。这不是我们希望激励的空间，当然也不是我们希望读者创建的空间。

如果你超越机制、Sprint、会议、角色、构件，你需要意识到在通用结构后面隐藏着更多的精华，并且看起来这些天大家已经搞明白通用结构。Scrum是建立在经验过程控制的基础上的，并从中借鉴了三大纪律：透明、检查和适应。Scrum同样还借鉴了Takeuchi和Nonaka的工作，一篇来源于1986年哈佛商业评论的文章“ The New New Product Development Game ”。那时，Takeuchi和Nonaka在日本考核成功的产品——比如计算机、打印机、复印机、汽车、以及面包烘焙机——并且他们发现他们关注的企业生产成功产品所花费的时间要比那些依赖跨职能、自主、自组织的团队要少。

通过察觉Scrum背后的核心，获得错误的精华。或者换种说法，用同一种方法，却期待不同的结果。我想这是当时大部分Scrum采用者失败的原因。

Heusser: 当我和Markus在Agile Conference上讨论这个话题时（前一年），我与参加会议的非教练人士、贡献者进行了交流。他们都说他们正在实施“ScrumBut”、“ScrummerFall”、“Scrum-Ish”，“使用Scrum作为一种模型，从中获取理念”，或者，可能是“Scrum Jemina”。当团队在现有流程的基础上召开会议时，他们会称其为Scrum。他们所有人。没有人在写“book Scrum。”

所以每个人都对其进行了裁剪。

但是我认为在做出经过研究和考虑的决定时， 妥协的Scrum原则 跟真实了解制度力还是有区别的，因为妥协的Scrum原则太难做到，或者“在这里不起作用”。前者会导致“ScrumerFall”；第二种更可能导致类似“ScrumPLUS”的成果。书中的很多案例，尤其是案例研究，都对其进行了深入的研究——当前版本的Scrum指南建议：尽管可能实现部分执行Scrum，但是建议保持角色、构件和会议“不可变”，“因为变化后的结果就不是Scrum了”。因此放弃Sprint，团队“实施的就不是Scrum”。

我倒没有觉得这是一件很重要的事情，因为Scrum指南会随着时间而改变。当你在前一周“实施Scrum”时，使用的还是“Sprint承诺”术语，突然发现术语变成了“Sprint目标”，难道你就不是在“实施Scrum”了吗？我认为这对我没有意义。我在意的是你是否了解权衡，是否是因为检查和适应（“Scrum Plus”）而执行的更好，或者你是否是因为“政治现实”而妥协。

Gärtner: Craig Larman的“我们做X，但是……”导致的成果往往类似ScrumBut，从中我学到我们应该将问题从“但是”转向“和”。如此一来，“我们在实施Scrum，但是我们跳过了回顾”就会变成“我们实施Scrum，目前我们还不知道如何在每次Sprint有效地开展回顾。这就是我们派人参与培训，获取经验的原因……”。当使用Shu级别“但是”陈述时，就会开始产生问题。通常我发现当使用Ri级别“和”陈述时,同时从他们为什么没有实施特定的事情，或者不再这么做了，和他们未来规划来看，往往可以得到丰硕的实现。这就是成功的Scrum和需要拯救的Scrum之间的区别。

Heusser: 目前有很多的‘休克疗法’。打开开关，突然发现每个人都在‘实施’Scrum。当你想到这点时，你发现这是一件大爆炸的、大批量的、不可逆的事情。这是非敏捷方式实现敏捷化！是的，因为缺乏更好的术语，因此我使用类似“敏捷化”（go agile）或者“实施敏捷”（do agile）之类的术语。我不确定禅宗短语，比如“敏捷是你的一部分”（Agile is something you be）是否有帮助，抱歉，我跑题了。

Gärtner: 如果你在大型项目上尝试休克疗法，可能会使车轮脱落，人们也会继承旧的习惯。也许你会保持站会和sprint，但是失去了其它。这很可悲。另一种可能，为了实现软件的交付，它将花费你三到四个sprint。目前，很多公司都在开展为期两周的Scrum现场培训课程，从而让团队明白——将六个月（或者十二个月）的项目缩短到两周发布到生产环境是很难实现的。对此有两种解决方法：你可以拨动钟面到十一，做为期一天的sprint。直到sprint四，你什么都得不到，但是至少才周四，此时教练可能还在。我的建议是开始训练，然后，当项目允许的时候，与团队开展回顾，询问团队接下来他们想做什么。每次小块地添加Scrum。大多数情况下你需要切分故事，其它的留给团队——在你的可及范围之内。

Heusser: 正如我所言，随着每周添加新成果，目前我们快要完成金点子章节。当我们完成这一章节时，我们将会做一些关联映射，并将它们整理到章节里，因此，如果你正为测试困扰，那么你可以参考测试章节。之后，我们打算刊载案例研究——但是，这些很难实现。因为虽然我们很多朋友有很多好的想法，但是他们签订了保密协议；有些员工在得到许可刊载故事时，却面临很多的繁文缛节，以至于他们不愿意尝试。我相信，我们至少可以加入四到五个简短的案例，并且它们会很有趣，并且值得你阅读，它们都是真正的困境，和解决它们切实可行的方法。

Gärtner: 是的，我们在金点子这一章节有点慢。我们希望这篇采访能够帮助我们。:)