Andy Singleton所著的《Unblock! A Guide to the New Continuous Agile》一书为基于云的分布式开发提供了持续交付的思路和实践。书中讲述了如何构建、测试、频繁发布代码，以及如何让处于持续交付环境中的管理团队、产品和企业做到持续敏捷。
关于什么是持续敏捷、它和Scrum有何不同、如何与用户故事负责人一起使用服务矩阵扩展软件开发，以及为什么要在持续改进中使用快乐调查等话题，InfoQ采访了Andy。
InfoQ：为什么你会写一本关于新的持续敏捷的书？
Andy：因为这是爆炸性的材料，可以挽救读者于陈旧乏味的Scrum循环之中。世界上有成千上万的最好的软件工程师和技术公司正在思考，如何使用云计算构建具备惊人速度和规模的软件，我的这本书就是一探此间的。在Assembla，我和分布式的团队共事，有过万的团队使用我们的在线工作空间，我自己管一个来自10个国家的30人的团队。对于分布式团队来说Scrum的执行方式并不好，因为要开太多的会，所以我尝试着试用替代方案。大约两年前，我将Assembla从两周发布变为持续交付。这极大地减轻了我们的压力，适时地隐藏和打开某些功能还帮我们提高了产品质量。我们所使用的测试和合并代码的模式和Jez Humble所写的那本《Continuous Delivery》书上所述的不一样，更接近于其他SaaS公司的标准，所以我开始画代码流程图，还为此撰写博客。随着开发人员的不断成长，又反过来迫使我加快和完善产品的管理。所以持续的、指标为导向的产品管理成为了另一个研究领域。最后，我开始和更大更牛的团队讨论他们的持续交付和持续敏捷。和Google的一些人还有Hubspot的副总裁聊完，我最大的启示是Google有1万5千多工程师，但是他们却使用着类似的执行过程，我称其为MAXOS。这是在数百或上千的并行组件上做持续交付，是云计算革命的重要组成部分。
InfoQ：这本书名是"Unblock! A Guide to the New Continuous Agile"。你想开启（unblock）什么？
Andy：如果你不能发布代码，那么你的路就不会通畅。我们试图打开这种障碍。这会让你的开发更有可靠性和可扩展性，因为团队或者功能的问题阻碍不了其他的人。InfoQ：能分享下你是如何看待新的持续敏捷的吗？比如和频繁发布或者持续交付有什么不同？
Andy：持续交付是持续敏捷的最重要的基石。持续交付是构建、测试和发布代码的方法。持续敏捷是基于持续交付环境中，管理团队、产品和企业的策略。所以，我们开始从持续交付代码入手，然后通过加入团队、产品和企业相关的策略构建持续敏捷。
InfoQ：新的持续敏捷和Scrum最大的不同是什么，他们可以用到一起吗？
Andy：所有的敏捷方法有着相似的策略，如用户故事、频繁发布和提高过程的回顾。然而，Scrum把大家锁定在同一个周期性的发布循环里，并迫使他们在“多功能的团队”中“自我组织” ，然后为摆脱这个框框而奋战。持续敏捷是一个较新的、更简单和更可扩展的过程，让每个人，尤其是技术带头人和产品经理，用更少的仪式以最佳的速度前进。幸运的是，它很容易从Scrum转型到scrumban、看板和持续敏捷，只是去掉Scrum多余的仪式、加入一些测试层，变得更精益。我已将这个进程描绘在这本书里。
从根本上说，敏捷过程中的多次发布比瀑布过程中的一次大发布更好，因为越多的发布，带来越多的实践。基于这个论点，发布越频繁，生产率越高、压力越低。在实践中，如果允许开发者为每次变更做发布，他们将越来越频繁地发布，比Scrum团队更频繁。这使得发布更小，更容易调试。
在一些基本理念上，新的持续敏捷与Scrum就不一样。 Scrum是一套团队管理的建议。事事都与团队挂钩。持续交付和持续敏捷更看重使用“技术规范”（构建、测试、部署、呈现和度量软件的运转）。使用云计算，我们会有更多、更大的服务器来采集和挖掘数据，用以提高个人的生产力。来自于提升团队管理的收益是有限的，而来自于自动化的收益是无限的。
InfoQ：书中描述了“服务矩阵”或“MAXOS”。你能解释一下它是什么，以及公司该如何使用它来扩展软件开发吗？
Andy：MAXOS是服务矩阵（MAtriX Of Services）的缩写。在MAXOS架构中，软件拆分成多个Web服务，每个服务可以分配给一个开发团队做持续交付。所以，数百或上千个组件可以并行地做持续交付。 MAXOS解决了一些巨大的、代价高昂的问题。那么你就可以管理大型系统了，因为你没必要搞清楚项目计划中的全部依赖。相反，使用持续测试和集成系统，可以找到相关服务的依赖问题，并通知责任相关的团队。这种方法的天才之处在于测试机实际上可以代替很多管理者。这是革命性的、令人兴奋的变化。
我称之为“MAXOS”是为了突出它与SAFe（Dean Leffingwell提出的可缩放敏捷框架）的不同。SAFe很幼稚、用非自动化的方法在Scrum团队之上堆砌管理，没什么技术含量的公司才这么做呢。他们不能堆砌管理，得自动化起来。
InfoQ：能说说持续敏捷交付的好处吗？
Andy：持续敏捷消除了发布的压力或延期发布的问题。对于经常饱受发版压力折磨的开发团队来说，这或许是最大的好处。对于挣扎于延期发布的管理者来说，也是件好事。我们一直处于发布状态，这就变得容易了。我讲过，在恰当的时候打开新功能开关，把精力放在最有价值的功能上去。
当你开始启动精益或者开发精益产品，亦或频繁度量和调整营销过程，你将需要持续敏捷。持续敏捷以更快的交付和适应性为竞争提供了胜机。如果竞争对手用更快的开发周期超过了你，那么持续敏捷能帮助你赶上他们。
如果你正在构建具有很多组件的大型系统 ，持续敏捷同样非常重要。就像《人月神话》中所说的，在过去，这么做具有极高的成本和风险。硅谷的大公司使用持续敏捷过程（就是我说的矩阵服务——MAXOS）解决了这个问题。
InfoQ：你在书中说，“代码审查是获取测试最有效的方法”。能解释一下这是什么意思吗？
Andy：持续交付需要自动化测试。在发布一个变更之前，你要通过一系列的自动化测试层去运行这个变更。开发者必须为此写测试。一些开发经理试图威逼他们的开发人员去写测试。这种方式是没用的。强制性的代码审查是最可靠的获取测试方法。你可以让评审人员检查自动化测试，这些测试应该和新功能或者缺陷的修改一同提供。如果相关的自动化测试没有覆盖这次变更，评审人员可以拒绝并退回提交。这样的方式总会取得立竿见影的效果。
我还注意到，在成功的持续交付工作中，开发者决定了发布。开发者必须测试变更，然后按下按钮启动发布过程。他们不能只是将变更发给质量保障的人并期待他们去完成测试、做出发布决定。这种责任制度让开发者有了强大的动力去构建良好的测试和测试框架。这是在代码评审之上，为良好的自动化测试的提供了第二层激励。
InfoQ：在Assembla，你用故事负责人代替产品负责人。你为什么采取这种方式，两者有何不同？
Andy：故事负责人不能只是规划功能，然后把它丢给设计和开发就不管了。故事负责人得和开发人员一起完成设计、beta测试、推出新功能和度量反响。工作变多了，但功能变好了。我觉得为了争取实现更好的功能，以及更加重视每个功能的使用数据，故事负责人是必要的角色。
InfoQ：能否阐述一下团队如何利用快乐调查持续提高吗？你提到这比回顾更好，能解释一下为什么吗？
Andy：我们希望可以不断地改进过程。回顾会议旨在帮助过程改进，通过提问：“最近发布的过程中哪些做得很好？哪些做得不行？未来的几个星期我们应该怎么改进？”这是伟大的理论，但在实践中，它往往令人乏味和痛苦。我不知道为什么。从Henrik Kniberg和Jeff Sutherland那我们学到了“快乐调查”的格式，这让我们拿到更好的效果。它的问题略有不同：“现在感觉哪里做得最好？现在感觉哪里做得最差？改进什么能使你快乐起来？”你会想到这变成了无关紧要的个人问题，但在实践中，它会指引提高生产力的实际行动。而且，我们可以在任何时间做这件事情，无需按照发布计划来。
