ShineScrum捷行曾邀请图灵社区与Ken Schwaber展开一场关于敏捷的访谈，下面请见详细访谈内容和Ken Schwaber精彩回答。
Ken Schwaber
Ken Schwaber是敏捷软件开发运动的领导者之一。Ken和Jeff Sutherland（Scrum Inc. CEO）共同建立了最初版本的Scrum开发方法，在OOPSLA’95的年度会议上，他们第一次把Scrum作为正式方法提交出来。Schwaber和Sutherland是敏捷宣言的最初签署者之一。
图灵社区：
你建立Scrum的最初动机是什么？
Schwaber:
因为Scrum管用。当时我的公司正在忙于交付一个高级产品，这个产品的市场正火，需要有经常性的改动。如果我们采用长开发周期，我的公司就会破产。所以我们设计了Scrum，它让我们涅槃重生。
图灵社区：
你觉得在中国推广Scrum有文化障碍吗？
Schwaber:
不会比其他文化更困难。一种文化是否能接纳并利用Scrum的关键点在于对可预测性的相信程度。
在文化中更理解和接纳可预测性的人会相信他们可以预测未来。他们工作的目的就是通过利用人力和资源让未来变成真正的现实。
使用Scrum的人们都曾有这样的看法，像软件开发这样充满复杂性和创造性的工作是毫无预测性可言的。这样的结果很可怕：糟糕的软件，赶不上的进度，浪费的金钱，泄气的工作者。所以他们知道最重要的就是预测什么才是真正的需求，让员工们都认识到这点，然后竭尽所能帮助人们实现这个目标。Scrum之道的核心在于“有可为”，利用机会，避开障碍，敏捷起来。
图灵社区：
经常有人会抱怨舍弃瀑布模型的困难重重，你认为有必要把敏捷和瀑布模型结合起来吗？为什么？如果可行的话，如何做到？
Schwaber:
这两个模型分别适合于两种极端不同的情况。
对于瀑布模型，我们预测我们要建的是什么，怎么制作，建立计划，然后按照进度完成。所有事情的关键都在于界定想要什么的准确性，以及直到产品最终成型前的有效沟通的准确性。如果沟通环节完美无缺，没有改变的需要，这么做是可行的。
Scrum的假设是沟通是有缺陷的，而改变才是永远不变的。在不超过30天的短周期中，人们建立起他们认为最终想要的东西。这在周期的最后会被检查。根据结果与需求的和谐程度，要做出下一个周期的计划。这是一个一直在改变的持续反馈环，根据检查结果和需求变化做出改变。
有人曾尝试结合两种方法，结果让人失望，毫无意义。还不如分开的好。
图灵社区：
一家公司如何知道Scrum是否适合他们的企业以及他们产品？
Schwaber:
Scrum几乎从来不会和某些软件公司的企业文化契合，这些公司因为不适当的瀑布模型而压力山大，他们在过去30年中一直都使用毫无新意的技术。
Scrum确实适合某些企业文化，为了年度预测而模仿销售周期，然后年度预测变成了月度预测，然后检查结果，并作出合适的变化。
多数公司对给他们开发软件的部门都不甚满意，因为浪费、失败、糟糕的质量屡见不鲜。那些极度绝望或者有真知灼见的人们会努力转移到Scrum上，这是一种更加适宜的方法，它可以反映出这家公司其余部门运作的方式。
图灵社区：
在现实开发中，有些公司执着于死板的方法，而不会调整这些方法以适用于他们自身的环境，你对这些公司怎么看？你对他们有什么建议吗？
Schwaber:
软件发展之迅速，已经成为了公司是否能存活的关键，这不仅关乎公司运转的方式，也关乎已经被嵌入到他们产品中的软件。那些不进化的企业，不在软件和产品开发中应用敏捷方法的企业，就无法有效竞争并存活下来。
我的建议就是，敏捷是一场关于适者生存的进化。
图灵社区：
Product Owner有很大的责任，有时候，他们会成为整个团队的瓶颈，如何解决这个问题？
Schwaber:
这个问题确实存在。所以我们要解决它。要解决这个问题有很多方法，包括为团队增加更多的领域知识。如果团队没有领域知识的话，Product Owner就不存在，那么我猜测整个开发就会慢下来，直到问题解决。否则就要等发布糟糕产品，丢人现眼之后再解决了。
图灵社区：
番茄工作法是提高个体效率的方法，可以在Scrum中使用番茄工作法吗？
Schwaber:
如果你愿意的话，Scrum是一种可以内嵌番茄工作法的框架。但是，不加调整地盲目应用任何技术都是有害的。
图灵社区：
如何控制和管理技术负债？
Schwaber:
在你写每条功能的时候，都要假设你后半辈子要一直维护和提升这个功能。就算你要上手一条烂到骨子里的老程序的时候，也要这么做。否则，那部分用来维护和支持老产品的开发预算就会吞噬所有要花在新工作上的费用。
图灵社区：
你认为敏捷方法过分强调了 YAGNI（你不会需要它）吗？这样会造成忽视远期目标吗？
Schwaber:
敏捷方法并不包含 YAGNI。但是敏捷确实需要清理不需要的东西。比如，为什么要在有记录文档的情况下和别人沟通，而不是直接和他们交谈？无论如何，维护一个产品所需要的文档应该在每个周期都有发展。做有用且需要的事，剔除所有其他。
图灵社区：
有人认为敏捷方法现在在走下坡路，你认为为什么会有这样的声音？你的看法呢？
Schwaber:
我曾听见有人问，敏捷是一种潮流吗？我认为敏捷是一系列的价值观和原则。而Scrum建立在敏捷之上，Scrum也建立在专注，勇气，开放，承诺，和尊重这些价值观之上。
价值观不是潮流。在我的想法中，在这些价值观和原则下工作的人们会成为潮流，他们的方法远远超过其他的方法，或潮流。
图灵社区：
你怎么看敏捷的派别之争？你认为他们之间有冲突和矛盾吗？他们的不同来自哪里？
Schwaber:
敏捷和Scrum是非常非常简单的方法。不同和冲突来自想通过制造工具、方法，以及创造基于敏捷理念的新方法而赚钱的机构。一旦金钱进入了等式的一端，冲突就会发生。这些冲突并不是非发生不可的。用你的眼睛选择对你来说有用的方法。试验，并持续改进。
原文链接：https://www.ituring.com.cn/article/67146
原创文章，作者：ItWorker，如若转载，请注明出处：https://blog.ytso.com/295305.html