采访和书评：《Essential Scrum》

由Kenny Rubin 所著的《Essential Scrum》更加深入地阐释Scrum。该书除了对Scrum及其价值、原则和实践进行了介绍以外，还是如何实施Scrum的灵感源泉。该Scrum实践指南不仅在如何通过Scrum计划和执行项目方面提供了意见，并且还在如何将组织中实行敏捷的部分和未实行敏捷的部分紧密结合起来这一保证敏捷软件开发成功至关重要的方面也给予了指导。

以下是《Essential Scrum》所阐述的四大主题：

• Scrum的核心概念：框架、原则和实践
• 产品负责人、Scrum Master、团队和管理者的角色演绎
• 在不同层次上对Scrum进行规划，从投资规划到迭代计划
• 迭代：计划、执行、迭代回顾和敏捷回顾

该书包含的一些亮点使它成为了当下泛滥的敏捷书籍中的一个有力补充。例如，该书广泛涵盖了技术债务的概念，通过它你就知道如何管理好你的软件产品质量。就像Kenny所描述的那样：

...技术债务是需要支付利息的，它可能是以未来额外的开发工作量的形式偿还的。

对于技术债务中技术和业务两方面的描述有助于我们更好的做出决策，进而促进管理者和工程师在软件开发和维护这个艰难而又无比重要的话题方面更好的进行合作。

书中有一些概念来自于Eric Ries所著的《精益创业》，像是将最简化可实行产品与转型和Scrum结合起来。例如，通过向你展示如何利用敏捷来建立用户知识库，从而使用它来交付有价值的解决方案。该书也解释了“快速失败”和“转型”的联系，并由此清楚地阐释了Scrum是如何帮助你通过使用来自客户的反馈进行创新管理，以及决定在何时调整方向。

如果对一个产品的进一步投资在经济上是不合理的，那么我们就该决定是交付、转型还是终止这个项目。

关于敏捷回顾，Kenny谈到：

...敏捷回顾是Scrum框架中最重要但又最不被重视的实践之一。

他描述了谁应该参加敏捷回顾（为什么要参加），如何组织敏捷回顾，以及采取什么措施来保证持续学习与改进。这里有许多例子可以借鉴，例如使用根本原因分析法，数据搜集，以及如何创造一个氛围使专业人士可以分享他们的观点并且相互倾听对方的看法。

Kenny Rubin在《Essential Scrum》中所描述的经验和示例可以帮助你更好的了解Scrum，就像一位Scrum Master或敏捷教练一样，并且使公司更具敏捷性。这是一本非常全面和实用的书。这里还有一章本书的示例章节。

最近作者就该书与InfoQ进行了交流。

InfoQ：现在市面上关于敏捷和Scrum已经有一些比较有趣的书了。是什么促使你也决定自己写一本关于Scrum的书的？

我写《Essential Scrum》这本书是为了填补行业中一个非常重要的空白。我在很多Scrum培训班里教过课，几乎每个班里都有人问过我这样一个问题：“如果要给我们的团队成员和管理者推荐一本关于Srcum的书，使他们变得成功的话，你会给我们推荐哪本？”我发现没有一本最新的书可以推荐给他们，而这本书需要涵盖Scrum框架的核心以及实施Scrum所用到最流行的方法。结果是，我可以随口说出一系列的书，并且我觉得它们可以提供所需的那些知识。这个书籍列表会增加好几千页的阅读量，这对于任何人来说都是难以承受的。所以，我决定写一本书作为简单独立的资源，给团队成员、管理者和执行者提供基本的Scrum知识。

InfoQ：你的书如何使专业人士在进行敏捷培训和辅导的时候更加出色呢？

为了帮助组织成功的实施敏捷，敏捷培训师和教练需要做好应对整个组织价值链的准备。仅仅是对技术人员进行培训和辅导常常并不会给组织带来使用敏捷理应得到的好处。我是为全体团队成员、管理者和执行者写的《Essential Scrum》这本书。所以它不是一本单纯针对产品负责人、Scrum Master或开发团队成员某个人的书。相反，该书面向的读者是所有参与到Scrum的人——从Scrum团队的全体成员到他们与之接触的组织相关成员，它旨在向人们提供一个对Scrum的共同理解，该理解的基础是人们平时讨论Scrum时所用到的清晰词汇表所构建的一系列核心概念。通过这个共享的基础，我希望敏捷培训师和教练可以帮助组织在使用Scrum进行业务价值交付的时候能够更加成功。

这本书有一个非常吸引敏捷培训师和教练的独特之处，就是全新的Visual AGILExicon™（发音是 visual agile lexicon），它是一种以丰富图形化和极具吸引力的可视化方式来描述和传播敏捷和Scrum核心概念的语言。该书中多达200张的图片都是通过Visual AGILExicon绘制的（下面有一张图作为示例）。敏捷培训师和教练可以使用Visual AGILExicon来促进敏捷在价值链中的应用。

（点击以放大图片）

InfoQ：在书中你谈到“搁置的工作比闲置的人员更具浪费性，经济利益损失更大”。你能解释一下原因吗？有没有什么例子可以说明一下呢？

当为了等待其他团队而被阻塞或者同时进行过多工作的时候，有些工作就会被搁置下来。当工作被搁置的时候，我们就没有朝着向客户交付价值的方向前进。延期交付价值是要付出代价的，而这个代价应该被量化从而让人们明白由于工作被搁置所带来的真实经济影响。例如，产品下个版本的发布可能会带来$200K/月的收入。因此如果搁置的工作导致产品投入市场的期限要延后两个月，那么搁置的工作所产生的代价就是$400K。

闲置人员，就是指没有被100%利用的人，看上去像是一种浪费。例如，如果我们付给一个开发人员的薪水是$100K/年(满负荷)，但是他的利用率只有80%，那么就可以断定，我们产生了$20K（20%）的闲置浪费。在这个例子中，一个20%闲置的人员产生了$20K的经济损失。而由于工作搁置从而导致延期两个月交付产品则会产生$400K的经济损失。

有趣的地方是搁置的工作和闲置的人员是一个矛盾的综合体。设想一下。为了让人员保持忙碌（消除人员闲置），公司常常让员工参与到多个并发的项目中以达到100%利用的目的。这么做的结果就是同时处理多个不同的工作常常会导致完成每个工作的时间都会延长，从而导致所有的工作都会延期。结果呢，我们消除了一种形式的浪费（人员闲置）却助长了另一种形式的浪费（所有项目的工作被搁置）。所以由于搁置工作所导致的延期代价要比使组织保持一定的松散性所带来的代价要大得多，我们意识到，大部分组织都把精力放在消除错误形式的浪费上。我们应该建立一个价值交付系统来将搁置的工作控制在尽量小的范围内，即使这意味着我们会造成一些人员闲置的浪费。

InfoQ：你在《Essential Scrum》中描述了各种各样的技术债务：幼稚的技术债务、不可避免的技术债务和战略性的技术债务。哪一个对公司造成的损失最大呢？人们又该如何减少这些损失呢？

“更大的损失”这个问题并没有与债务是如何积累的特别相关，而是跟特定债务的经济性息息相关。为了解释这一点，让我首先来定义几个概念。

• 技术债务的形式之一是幼稚的债务，它是由参与者不负责任的行为或不成熟的实践产生的。
• 技术债务的形式之一是不可避免的债务，它通常是不可预测和抗拒的，并且是在团队构建产品的过程中正常产生的。
• 技术债务的形式之一是战略性的债务，它常被用来帮助组织对那些重要且具时效性的决策的经济性更好地进行量化和利用。

我用这个分类法来分辨技术债务的产生形式，而不是区分所谓的高损失率和低损失率的债务。技术债务的经济影响应该是根据实际情况进行评估的。比如，我们可能会选择积累战略性债务，因为如果我们认为加快投入市场所带来的好处要远远超过由于加快进度所导致的债务积累所付出的代价，那么我们就会这么做。换句话说，如果我们选择了战略性债务，那么我们期望的就是净效益，而不是净亏。如果我们已经积累了债务，无论以什么形式，我们必须考虑如何来偿还它。首先我们必须承认，不同的债务在经济方面的影响是不同的，管理它们的方式也是不同的。比如，我们在那些常被改动的代码上所支付的债务利率要比在那些几乎不会涉及的、而且不太会产生任何严重问题的代码上所支付的利率要高得多。打个简单的比方，就像是18%的信用卡债务和6%的房屋抵押贷款债务的区别。除非有特殊情况，否则任何一个理性的人都会在还清低息的抵押贷款债务之前先把高息的信用卡债务还清。当进行技术债务管理的时候，确定并优先还清高息债务是非常重要的。

优先偿还高息债务是我在《Essential Scrum》中所讨论的债务偿还策略之一。另一个策略就是实行童子军规则，让离开时的营地比进入时更干净（偿还技术债务——当你在修改代码时遇到不整洁的代码，让它比你发现它的时候更整洁）。我们应该在执行交付客户价值工作的过程中逐步偿还技术债务。这么做了以后，我们就可以避免让产品负责人将技术债务偿还的工作放到产品待办事项列表中，因为债务偿还的任务会代替产品待办事项列表中的具体工作事项。

InfoQ：在《Essential Scrum》中你将Scrum和精益创业联系了起来。比方说，你提到“如果对一个产品的进一步投资在经济上是不合理的，我们就该决定是维持、交付、转型还是终止该产品”。你能详细的说明一下吗？

你所提到的那句话是在《Essential Scrum》的投资规划章节里谈到的。这只是Scrum和精益创业良好结合的众多方面之一。关键是，Scrum和精益创业都非常专注于精益创业中常常提到的验证性学习。验证性学习描述的是当重要的假设被确认或者通过若干个用户验证试验被否决以后所取得的进展。我们在学习确认或否决我们所做的假设的过程就是我们进行验证性学习的过程。在《Essential Scrum》中我举例说明了为什么验证性学习是描述三大敏捷核心概念的一个好方式的。

• 快速验证重要的假设。让一个很重要的假设在未经验证的情况下实行多时会造成重大的经济损失，因为可能已经在这个错误的假设之上创建了许多的后续产品。
• 利用多并发学习循环。在Scrum里我们有日常型、迭代型和发布型的学习循环。在每个循环中我们都按照以下步骤进行操作：假设、构建、反馈、检查和调整。
• 为了快速得到反馈而重新组织工作流，为了更快的进行验证性学习我们需要特别调整工作的优先级。

在书中，我展示了如何在各级规划中（投资、产品、发布和迭代）应用这些原则。现在让我来解决那个投资规划的问题，如何决定在什么时候保持、交付、转型或者终止产品。通常情况下我们从事于一个产品或项目时并不意味着一定要完成它。我们应该定期并且常常（可能每个迭代都需要）回顾我们在产品上的验证性学习，然后决定是否我们在朝着经济合理的解决方案方向前进（在精益创业中这是通过创新的会计方式测量的）。如果有证据显示我们是在构建有价值的东西，并且执行下个迭代（或者其他方面的工作）的边际效益是有利的，我们就该坚持。
如果我们断定未来支出的边际效益是不利的，那么我们就有三个选择：交付、转型或者终止。如果继续下去的经济效益是不利的但我们已经产生了一个最简化可实行产品（也就是精益创业中的MVP），我们就该考虑交付现在的产品。如果在当前的方案下继续下去经济效益是不利的，而且暂时也没有一个MVP，但是我们相信还存在替代方案可以实现一个可实行的产品，那么我们就该转型到该方案上。最后，如果没有任何一种转型方案是可行的，那么我们就该选择终止该产品的开发投入并减少损失（希望我们可以尽早发现我们所追求的是不可行的）。

InfoQ：你在书中提到可能需要组建产品负责人团队。在什么情况下这种方案是可行的呢？并且在什么情况下你又不建议使用这种方案呢？

在我们讨论产品负责人团队的概念之前，先让我们确保我们对Scrum中产品负责人角色的理解是清晰的。在每个Scrum团队中必须有一个人担当产品负责人的角色，这个人有权利和义务承担起Scrum团队中产品负责人的责任，并且是唯一的一人。好吧，话虽如此，但我们真的应该允许一个团队的人来扮演产品负责人的角色吗？该不该让一群人进行决策共享和承担责任呢？为了正确的实施Scrum，我们需要一个人作为产品负责人来进行决策并且作为利益相关者团体的唯一代言人与Scrum团队进行交流。现在由于种种原因，一些组织组建了他们所谓的“产品负责人团队”。比如，有一个原因就是，避免一个人在没有诸如领域专家、UI设计师和架构师的建议和指导下无法完成工作的情况。这就是大部分组建产品负责人团队的原因，因为产品负责人不能凭空进行工作。

另外一个场景是，当产品负责人的工作量要比一个全职人员所能承受的工作量要大得多的时候。在这种情况下，产品负责人就会把一些负责产品的责任委托给其他人。一个很明显的例子就是在超大型的开发团队中，可能是由同一个人来担当多个Scrum团队产品负责人的角色，但是如果这个人所涉及的Scrum团队过多的时候呢？一个人当然无法担当数十个Scrum团队产品负责人的角色。在这种情况下，就会组建一个产品负责人团队，但该团队是有等级制度的，最终这些人都需要向一个“首席产品负责人”汇报，他必须要对整个在建的产品负全责。

在这些情况下组建产品负责人团队是可以接受的，只要最终决策权还是掌握在团队中某个人的手上，并且产品负责人团队不会沦落为委员会的形式，从而导致每个决定都需要团队中全体成员投票表决。有必要指出的是我常常看到产品负责人团队是由于错误的理由被创建起来。例如，如果一个产品负责人们无力承担产品核心领导者的角色，那么他们不需要一个委员会——他们需要一个不同的角色。类似的，如果产品负责人由于太忙而他无法履行他的职责，那么他不需要一个团队。也许问题的真正原因在于组织在同一时刻进行了太多的开发工作，或者管理核心产品的产品负责人太少了。

InfoQ：以你的经验来看，组织在实施Scrum的时候最大的挑战是什么？又是为什么呢？

Scrum是一种用来揭露那些折磨组织的障碍的工具。一些组织没有欲望解决这些障碍，当然也就对将他们的问题暴露在聚光灯下感到极度不适了。这些公司宁愿调整聚光灯（Scrum）来掩盖问题而不是着力解决它们。而那些打算利用Scrum获得成功的组织已经准备好面对残酷的现实迎难而上了。

关于作者

Kenny Rubin 是Innolution公司的管理负责人，该公司是一个敏捷培训公司，主要是帮助组织以一种有效和经济合理的方式来开发产品。作为一名认证的敏捷教练，Rubin已经在敏捷和Scrum、Smalltalk开发、管理面向对象的项目和转型管理方面训练了超过18,000人。他曾在200家公司进行过培训，涵盖的范围从创业公司到财富榜前十的公司。

Rubin是全球Scrum联盟的首席常务董事，该联盟是一个非营利性的组织，主要从事于进行成功运用Scrum的研究。除了创作《Essential Scrum：最流行敏捷过程的实用指南》这本书，他还是1995年出版的《Succeeding with Objects：项目管理的决策框架》的合著者。想了解更多他的背景请登录：http://www.innolution.com，你也可以在该网站上关注他的博客。Twitter的粉丝关注他请@krubinagile。

查看英文原文：Interview and Book Review: Essential Scrum