@feuyeux
2015-03-21T00:42:17.000000Z
字数 3734
阅读 2007
infoq agile
Andy Singleton所著的《Unblock! A Guide to the New Continuous Agile》一书为基于云的分布式开发提供了持续交付的思路和实践。书中讲述了如何构建、测试、频繁发布代码，以及如何让处于持续交付环境中的管理团队、产品和企业做到持续敏捷。
Andy Singleton所著的《Unblock! A Guide to the New Continuous Agile》一书为基于云的分布式开发提供了持续交付的思路和实践。书中讲述了如何构建、测试、频繁发布代码，以及如何让处于持续交付环境中的管理团队、产品和企业做到持续敏捷。
关于什么是持续敏捷、和Scrum有何不同、如何与用户故事负责人一起使用服务矩阵扩展软件开发，以及为什么在持续改进中使用快乐调查等话题，InfoQ采访了Andy。
InfoQ: 为什么你会写一本关于新的持续敏捷的书？
Andy: 因为这是爆炸性的材料，可以挽救读者于陈旧乏味的Scrum循环之中。世界上有成千上万的最好的软件工程师和技术公司意识到使用云计算来构建软件，从中得到完美的速度和规模，我的这本书就是一探此间的。在Assembla，我和分布式的团队共事，有过万的团队使用我们的在线工作空间，我自己管一个来自10个国家的30人的团队。Scrum的执行对于分布式团队来说不好，因为要开太多的会，所以我尝试着试用替代方案。大约两年前，我将
Assembla从两周发布变为持续交付。这极大地减轻了我们的压力，适时地隐藏和打开某些功能还帮我们提高了产品质量。我们所使用的测试和合并代码的模式和Jez Humble所写的那本《Jez Humble》书上所述的不一样，更接近于其他SaaS公司的标准，所以我开始画代码流程图，还为此撰写博客。因为我们的开发者更爽了，我就得以加快和完善产品管理。所以持续的指标为导向的产品管理成为了另一个研究领域。最后，我开始和更大更牛的团队谈他们的持续交付和持续敏捷。和Google的一些人还有Hubspot的VP聊完，我最大的启示是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那我们学到了“快乐调查”的格式，这让我们拿到更好的效果。它的问题略有不同：“现在感觉哪里做得最好？现在感觉哪里做得最差？改进什么能使你快乐起来？”你会想到这变成了无关紧要的个人问题，但在实践中，它会指引提高生产力的实际行动。而且，我们可以在任何时间做这件事情，无需按照发布计划来。
Andy Singleton是Assembla创始人, 这是一家致力于帮助分布式软件团队一起工作的SaaS公司。他此前创办过PowerSteering软件公司，做企业项目管理系统，还有Cambridge Interactive，做电子商务顾问。在1992年，他曾使用一屋子的单板计算机去运行可以发现完美学习参数的“元遗传算法”，视图揭开进化和创新的奥秘。 他持续学习创新方法，自哈佛本科毕业后，发布了20多款软件和信息服务产品。
查看英文原文：http://www.infoq.com/articles/book-unblock-continuous-agile