Mark Levison最近写了一篇博文“光用Scrum是不够的”，是旨在揭示各种敏捷模式的系列博文中的首篇文章。截至目前，他已持续在Kanban Portfolio View和Portfolio Management上发表了多篇系列博文。

系列博文内容详尽且富有启发性。其内容涵盖了对多种敏捷模式的分析讨论，均附有示例说明。

Mark说，Scrum只是建立一个体系的起点，当与其他有效的模式一起实施的时候，它可以很好地发挥出作用。

Scrum是一个用来发现问题的工具，而不是用来解决问题的。

仅凭Scrum并不能解决任何问题。你的团队和组织中的伙伴们需要拥有坚持到底的工作能量。Scrum实践发现，人们在没能成功地解决问题时会丧失动力，并对整个Scrum形成一个坏印象。

Mark还分享了在面对无计划的工作以及不稳定团队时实施Scrum的困难之处。

Scrum要求能够对至少两周时间内的工作内容进行稳定规划。Scrum团队也能处理计划外的工作，但当计划外的工作超出了团队常规基础能力的50%，此时Scrum将不再适用，而丰田Kanban则会是一个更好的选择。技术支持就是一个明显的例子，对产品提供电话/邮件支持意味着随时可能收到新状况和问题的反馈，所以支持团队星期一拟定的计划熬不过星期二的午餐时间。

Scrum是帮助建成高性能团队的工具，因此实施Scrum需要拥有稳定的团队。如果客户还没有稳定的团队，那我们首要的工作就是帮客户组建一个稳定的团队，否则大部分的努力都将付之一炬。

InfoQ就Mark的系列博文对其进行了采访，并就其观点进行了探讨。

InfoQ：您最近写了一篇文章“光用Scrum是不够的”。您写这方面话题的文章的动机是什么？

Mark：作为一个咨询顾问和培训师，我在工作中看到许多不同的公司尝试使用Scrum。他们通常在个人团队水平上取得了巨大的成功，但在试图超越时却陷入了困境。

许多团队在清除自身障碍上做得很好，但在解决更多的系统问题上，却无法做成。他们要么没发现问题所在，要么，在很多情形下，他们没有解决问题所需的权力/控制力。这很伤人，因为Scrum已经揭示了问题所在，但问题却没能得到解决。

比如说，客户的产品负责人正陷入挣扎。他们懂得如何有效地区分事情的重要性，他们正试着在着眼于处理具体客户问题的短期需求和产品的长期需求之间实现平衡，因为他们知道，如果没能解决好长期问题，过不了两年，他们的产品在市场上将变得无足轻重。然而他们把几乎所有的时间都花在执行短期项目上，对于Scrum不能解决这个问题他们感到很沮丧。Scrum确实已经识别出了问题，但他们需要使用其他模式来解决问题。

类似的，在工程实践中也存在着问题——Scrum并没开出具体的实践药方。Scrum是中立的。Scrum被设计用来处理各种各样的问题——从软件开发到硬件开发，再到市场营销等等。结果，Scrum没法就解决某一个问题给出具体的实践方法。实践一直在不断发展且将继续保持演变，由于Scrum没有指明该如何进行实操，这使得Scrum对实践的变化保有开放态度。Scrum的联合创始人Jeff Sutherland就经常提到，在软件开发领域，只有当你同时采用了现代的/有效的工程实践，比如TDD/BDD、重构、CI、结对编程和ATDD，这时Scrum才能发挥作用。有太多的Scrum团队，可能超过半数的团队，每次在冲刺的末尾都拿不出一个真正可迭代出口的产品。当然，一开始每个团队都会出现这个问题，但从长期来看，他们应在每个冲刺结束时做到真正的可迭代出口（更好的，应做到在一天内多次迭代出口）。没有实施有效的工程实践方法的团队将无法完成每一个冲刺，更不用说一天内多次的要求。这并不是一个Scrum问题——这是一个工程问题，超出了Scrum自身的能力范围。

我所看到的组织最常纠结于以下两个问题，其一，他们认为Scrum会解决问题但显然它没有。另外，Scrum在识别问题方面是无价之宝，但只拥有Scrum并不足以解决问题。

InfoQ：那些只使用Scrum的组织，您觉得他们面临什么样的挑战？

Mark：只使用Scrum的组织并不是很多，Scrum是设计用来帮助开发团队变得更有效率的。市面上有许多关于Scrum静默性方面的研究，这是个好东西，因为你可以从中找出那些能和Scrum一起良好协作的工具。当和客户们一起工作时，我推荐使用组合看板，不过若客户不喜欢使用组合看板，也没关系，可以使用其它方法来配合Scrum。我们为这个系列选择了一幅插图，画的是一串齿轮与位于中心的Scrum相互咬合着。为了让整个系统有效地运作，需要更多的部件而不仅仅是Scrum。Scrum仅仅是一个起始点。

InfoQ：您建议使用看板来管理组合对吧？为什么您选中的是看板呢？在组合层面上使用看板能获得什么有益效果呢？

Mark：看板是一个用来理解系统中的工作流的工具。有鉴于此，看板在大尺度场景研究以及系统级问题分析方面是个优秀的工具。看板只包含简单的很少的规定：工作可视化；限制正在进行的工作；改进流程。只包含少量的简单规定使它非常适合用于清晰地识别出存在于多团队之间的真实问题。例如，在公司里围绕着问题做短期考量，通过使用组合看板发现，大多数的团队工作是在最后一刻才被了解到，而且这些工作都不在待办清单上。这让我们有机会去展开一个非常有挑战性的讨论话题，到底当前是发力留住一小部分客户更好，还是应致力于替换掉产品中的过时技术。当然，不存在正确的答案，但至少，使用组合看板让问题更清晰了。

InfoQ：您有推行并最后取得成功的实践案例，以您的经验来看，一个包含了多种敏捷方法的优秀的结合体是怎样的？

Mark：我不再把各种敏捷方法视为一个个彼此互不相同的实体。更多地，我把这看作为一系列的设计模式——Scrum即为面向开发团队的一系列的模式；而极限编程则是围绕工程实践又加入了一些新的模式，Crystal在个人安全感上有所增加。当我们把它们看作是一系列的模式的时候，它们形成的具体结合体就不会像理念和实施方法那样，拥有那么多的形态。和客户一起工作时，如果我发现有人心存忧虑，员工们不愿意分享自己的想法，那么下意识地，我会去建立安全感。为了建立起稳固的安全感，我们可以先发起一个安全感了解会议，大家先各自写下自己的想法，再汇总起来，最后标出重点或开展多轮投票。当碰上代码根基已经变成一大坨烂泥的情形时，我会给出许多可用于处理历史代码的方法。一旦我们用这样的方法来审视世界——持开放和积极响应的心态去面对出现在眼前的情况，无论它是怎样的独特，把我们的注意力从具体的方法转到仅仅聚焦于“我应该怎样做，才能在当前状况下做得更好？”设法指定出一套方法组合，不管这是否适用，都违反了Scrum的原则。

InfoQ：大多数组织都是从推行Scrum开始它们的敏捷转型之路的。您认为组织应该在什么时候考虑在实施Scrum的同时推行其他的方法？

Mark：没有一个放之四海而皆准的完美的实施阶段和实施时间。在组织觉得自己能够这么做的时候，就可以开始实施了，然后不断扩展下去。正如你所说的，大多数组织一开始是让几个开发团队应用Scrum。他们要么想用一些方法来可视化组合（比如组合看板），此时他们将迅速地步入组合管理，要么在其它情况下，工程问题在开发团队层面上更为重要，这时他们会开始改进工程实践，所有这些都取决于他们最大的痛点所在。所以，实施的顺序事实上取决于组织当前所感受到的痛楚之处以及执行变革的人的能量。

InfoQ：对于按照公司的规模来决定如何组合各种方法和实践，您怎么看？

Mark：既然我们使用的方法基于模式和原则，那么几乎不用做什么改变就能适用于大公司。大的公司里，有更多的开发团队，所以开发团队的组织形式的重要性提升了。另外，大的公司里面，在跨开发团队和平台方面存在更多的依赖性问题。但即使是在最大规模的组织内，简化平台和应用以使开发团队拥有更大的独立自主仍然是十分重要，Spotify模型就是此类趋势下的一个例子。

具体到每个组织，它们所需要（或者不需要）的东西各不相同，更多的是因为它们的公司文化存在差异而不是规模。当前广受欢迎的SAFe方法所面临的一大挑战即为单一规模——多匹配视图。该视图表明，组织还需拥有架构组，但至今为止许多卓有成效的敏捷组织并没有这样的架构组，而且若成立了这样的组，将会对敏捷组织自身造成伤害。

每一个组织都需要去探索属于自己的道路，不要期望于能简单地从其他组织那复制黏贴。

InfoQ：有些人认为，工程实践的就位是判断实施Scrum是否准备就绪的标准。关于这点您的看法是什么？

Mark：开始实行Scrum的唯一的先决条件就是，拥有一个稳定的团队，并有能力对至少未来两周的工作做计划安排。就这么多。不然的话，就是不存在开始的完美时间点，开始去做就是了，Scrum将帮助你发现你需要改进的地方。工程实践确实很重要，但如果你在开始的时候没有集齐所需的东西，Scrum会迅速地显露出问题所在。

InfoQ：您正在写关于“光用Scrum是不够的”的系列文章。请您向读者们分享下该系列里即将完成的后续文章吧。

Mark：在接下来的几个月里，我要写的文章是关于：

组织改进——大视图的系统问题的解决难度超出了任一单个团队的解决能力范围，我们该如何解决这个问题？这篇文章写的是我眼下正在客户们那做的东西。

团队组织——功能团队？组件团队？其它的类型？

开发团队内的协调——如何同开发团队协调工作？Scrum of Scrums是其中最为广为人知的模式，不过通常情况下，它不是个好的选择。

工程实践——没有踏实的工程实践，代码根基的健康度将随着时间的流逝而不断恶化，目前还有很多组织把焦点放在提升开发团队的数量上，而不是先让已有的开发团队变得更有效率。

InfoQ：您有什么话想对敏捷实践者们说？

Mark：不要停止寻找改进的方法。永远要相信你当前的团队能做得更好。如果你的团队认为自己已无可改进之处，请联系InfoQ要一份这方面的案例学习一下。

采访嘉宾简介

Mark Levison，Scrum认证培训师，作为一名软件开发者和企业开发管理者，他拥有20年的行业经验和资历。2001年，在经历了软件开发过程中的各种出错状况后，他转向敏捷和Scrum寻求改进的方法和工具。在2009年，他创立了Agile Pain Relief Consulting，帮助独立开发者和公司建立高性能团队，帮助组织进行敏捷培训，并提供敏捷教练以及咨询服务。除了Scrum之外，Mark还学习了行为心理学和神经科学，以便能更深入地理解团队的工作并提高团队活力。

查看英文原文：Scrum Alone is Not Enough – An Interview with Mark Levison