这两天的工作，翻译了一篇文章

原文：http://www.informit.com/articles/article.aspx?p=1829417

持续交付分析：五个核心实践

持续交付是一个软件开发策略。它的作用是通过优化你的交付流程，来尽可能快的发布高质量和有价值的软件。这种方式允许你快速验证你对业务的新想法，然后把这个新想法放到用户端进行重复的测试。尽管《持续交付：发布可靠软件的系统方法》这本书主要关注在工程实践上，但是持续交付的概念本身涵盖了整个产品交付的过程：从“模糊前端”到设计，再到特性分析。

持续交付一个普遍的原则是：尽可能让新想法持续并且独立的在用户端得到试验；而不是提出一大串的特性和计划，然后用好几个月时间来发布一次。只有经过仔细思考后，我们才可以将大的特性或者大范围的修改划分为一系列更小的步骤来实现；在此基础上我们才能得到更快速的反馈；并且中途一旦发现想法有缺陷，也可以随时改变策略或停下来。通过一个跨功能团队以小时或天为周期来交付小的特性，你将比你的竞争对象更具有创新性，并且有机会最大化你的投资回报。

在这篇文章里，我将讨论持续交付的五种实践。这五种实践能帮助你创建一条从想法到持续反馈的捷径：

·       始于一个最小可用产品（MVP）

·       衡量特性的价值

·       启动前先做“刚好足够”的分析

·       尽可能少做

·       囊括特性开关到你的故事里

始于一个最小可用产品（MVP）

“如果你没有被产品的第一个版本弄的很不安，那么证明你已经做的太晚了！”LinkedIn的创始人和总裁Reid Hoffman说道。（参阅“构建大规模公司的十大创业原则”）。

如果你的项目是从项目经理桌子上的一个大的需求文档开始，那么你已经失败了。精实创业中流行的“最小可用产品”（MVP）概念是这里的要点：你所能做的最有必要的工作就是去测试你业务假说。

当然，制造业的人们在过去的几十年里一直在生产最小可用产品- 他们称之为原型。诸如原型那样，你不需要将最小可用产品展示给整个世界，你可以选择一组内测用户使用它。原型可能不是一个可工作的软件，因此你不需要写任何代码就可以创建一个原型，并让它来收集用户数据。

如果最终版本对目标客户群来说很重要的话，你应该在更大范围里展示一个精心打磨过的最终版本。曾经有一个公司发布他们最小可用iphone应用程序到不同品牌下面。这样做的首要目的是为了能够简单的获得关于业务计划是否能够成功的反馈报表，然后其次要目标才是用来证明发布流程的可行性。

这么做的关键一点是如何找出一个在业务和技术上符合最小可用产品要求的跨功能团队。团队的角色应包括用户体验设计师，分析人员，测试人员，开发人员，运维人员和公共设备管理人员。（当然你无需一个庞大的委员会来做决策，因为一个人可能会扮演多种角色）。

既然构建一个最小可用产品只需要花费一个小团队几周的时间而不是几个月。 那么从这点上看，你就不需很多的仪式，因此你也不用赌上整个公司或花掉大笔的现金。

衡量特性的价值

“把度量看成你产品的一部分。”Etsy的技术副总裁John Allspaw说道（参阅“建立弹性的网络开发与运维”）。

另一个关键的精益概念是验证学习，你应采取的度量行为是基于产品的真实使用情况，而不是通过询问他人。正如电视里的Dr. Gregory House所说的那样，人们会说谎-或者更仁慈一些的表达是用户也不知道自己想要什么。所以请把你的用户当成无知者，而不是聪明的代理人。

在这种情况下，你需要能够回答以下几个问题：

·       我们对产品所做的修改已经提高了产品的注册率，客户保留率和收益率吗？或者是现在应该进行关键转折了？

·       当我们做过A版和B版的新特性测试后，哪个版本表现的更好？

·       我们所有的系统度量看起来都没问题，但是有一个用户却说我们的站点不能工作。我们可以不管这种情况吗？

·       我们产品中的哪个特性创造了最多的收益？

你应该能够不用搜索全部的Apache日志就可以回答这些问题。可以尝试使用一些特性跟踪工具或是运行一些定制查询。这些问题的答案应该都能从控制面板上找到，并且这些信息是完全可以被审计的。

Eric Ries在他的《精益创业》这本书中讲述了一个关于Grockit的故事：
按照看板中的精益生产原则，Grockit 改变了他们产品流程的优先次序。在新系统中，用户故事一直都被认为是不够彻底，直到他们引入验证学习这一个概念。用户故事可以被标记为四种状态中的一种。这四种状态包括：等待开发，正在构建，完成（从技术角度来说特性已经完成），或正在被验证。经过验证的意思是“首先要知道这个故事是不是一个好想法”。此验证通常表现为分裂测试中客户行为上的一个变化，但也可能包括客户访谈或是调查。

只有在度量被构建到故事中时，我们才是需要这样的学习。

尽管这个原则可能是面向网站类的项目，但是它也同样适用于嵌入式系统和客户机安装程序。所有这类的系统都需要以远程调试和错误报告为目的来采集度量数据，就像我们为了解产品的使用模式所做的那样。

启动前先做“刚好足够”的分析

“当你不在进行迭代开发的时候，请让团队在编码前先完成规格说明”，Bas Vodde在“诺基亚测试历史”里这样说。

一旦你对最小可用产品有了一个想法，那你就需要开始去发布软件了。首先第一步就是分析，但是弄一大堆完全分析完的用户故事在待开发列表里是一种浪费。为了完整分析用户故事，你需要从客户，开发人员，测试人员，用户体验设计师和最终用户那里获得输入信息。如果你的团队都花时间在收集这些信息上，那么他们就无法为发布有价值功能而工作，并且你也无法从一个可工作的软件上获得用户最真实的反馈。

那么在启动前我们要完成多少分析工作呢？在开发一个用户故事前， 我们需要关心下面三件事：

·       这个用户故事交付的边际价值是什么？

·       这个用户故事交付的边际成本是什么？

·       我们是否有足够的信息来开始交付这个用户故事？

前两个问题非常重要，它使得我们的交付能力变的有价值，同时我们也可以依据这两个问题来决定团队下一个要开发的用户故事。为了做到这点，我们需要找出哪个用户故事会带来最大的经济效益。而后两个问题比较接近，因为通常评估边际成本的信息量要比评估开始交付的信息量多。但是正如我的同事Peter Gillard-Moss曾经给我指出那样，他说无论如何你至少需要一份项目的接收规范。

要想将“做刚好足够的分析”这一概念贯穿项目的始终，我们就要在项目中不停的强调创建非常小的，增量式的用户故事。这也引出了下一项实践-尽可能少做。

尽可能少做

“如果你发现自己跟着卡片跑出了房间，那么请改用更小的卡片”Phllp说道（参阅：“Re: [XP] Re: Token definition in User Stories”）。

也许在敏捷分析里面最流行的缩写就是Bill Wake’s的投资原则。Wake提到好的用户故事应该是独立的，可协商的，有价值的，可估计的，小的并可测试的。那么我想把下面的讨论焦点集中在“小的”概念上。

人们通常认为特性和用户故事是可以互换的。有时认为一个特性就是要花几周时间去完成的东西。我曾经在一个项目里看到过由有好几页word文档来描述“用户故事”。

这也是极限编程要求人们将一个用户故事的总结写到3至5 个索引卡片上的原因。一个用户故事不应该花费超过2天的时间来完成。任何用户故事如果需要超过一周时间来完成那就太长了，这时我们应该把它拆分成跟小的部分，为什么要这样做？

·   因为我们经常能从用户那得到反馈，所以我们知道正在做的事情是否有价值。

·   检验我们的工作是否真正做完，要以能否以被发布为准而不仅仅是开发完成 。这样就可以证明我们还走在正确的路上。

·   不要去创建一大堆很难被集成，测试和部署的工作。

·   要确信我们在经常测试并不断的提高我们的交付流程。

 

反对的观点是：你不可能做任何有价值的事在短短的两天里面。但我认为这个陈述即缺乏想像力，又对价值构成存在着误解。正如我前面说的那样，故事的价值只有通过交付给用户才能被衡量。当然你不可能在两天的时间里完成一个完整的特性。但是你可以完成特性的核心功能并得到反馈。例如，你在开发一个在线预订客房的网站，你想加入一个功能来允许用户能够选择是否需要早餐这项服务。这时你不要为所有的酒店或合作伙伴的站点来开发这项功能，取而代之的是开始一个故事来允许你添加这个功能到单个酒店，没有任何的配置选项，并且如果必要的话在进行下一步工作前去获取反馈。

无论你做什么，谨记不要将功能根据解决方案方式去拆分成多个“故事”，比如一个“故事”放在持久化层实现，另一个放在业务逻辑层，第三个放在界面层。故事应该总是小范围的垂直分割。 如果你不得不做一联串集成工作，还请将重点放在小范围的垂直分割上。例如，你有一个功能是不得不发送一系列消息给另一个系统，那么你的第一个故事应该是发送最简单的消息，这样做的目的是去驱动出一个端到端的集成。

强迫自己经常剥离功能，直到你认为它对用户来说是有价值的，并且是最小的，必须的。这样做通常很困难，但是又有巨大的价值。你可以通过反馈来确定是否够小，然后在用两天时间进行一次增量开发。一旦你觉得当前的特性没那么有价值那就停下来。

在你的头脑里要有这样的意识，软件发布中最大的浪费是没用的功能。所有开发完的功能很可能有一半没被使用或很少被使用，这个结论来自一个实验研究。

不要问“我们能加入什么样的功能来使用户喜爱它”或“我们要把哪个额外功能放到这次发布中会使得这个产品更好”这样的问题。而是要问“我们现在能交付已有的功能吗？如果不能，为什么？”尽可能少做，你将可以把注意力集中到你的工作上而不是从用户那里学习。

在把一堆的故事做完前，你可能不愿意展示你的功能给所有人。你总是需要权衡到底是拿走一项功能，还是说保证所发布的功能都具有高质量（这由用户决定）。为了做到这点，你需要下一节描述的特性开关。

囊括特性开关到你的故事里

“从现在开始，我们下六个月甚至更长时间要做的主要内容的代码，在Facebook.com都已经有了。” Chuck Rossi说道(参阅Rossi在 2011年5月26号在TechCrunch上关于 "Facebook Tech Talk"的讨论).。

如果你想频繁的发布版本，那么最必不可少的步骤就是降低基于完整特性的发布行为。特性开关（众所周知的位开关或选择器）是一个模式，使用这种模式你可以控制哪些特性对哪些人可见。这样你就可以在软件的新版本里包含一部分已完成的特性-可能就是一两个故事的工作，而不是所有的功能。

Facebook's Gatekeeper 软件允许Facebook动态的控制谁能够看到什么特性。例如，导出一个功能给10%的Facebook用户或者Facebook的员工，或大于25岁的女性用户，或持有英国护照的人等等。（Gatekeeper有一个开关可以让一个特性对所有人可见除了TechCrunch的员工）。此功能允许Facebook的程序员尝试一个只与统计相关的特征，并随着时间的推移逐步推出这个特性。

特性开关展示了一个关键的约束，即你可以在故事里关闭一些特性。通常反对使用特性开关的观点是“我的某些故事模糊的控制着所有的用户接口。为让某个故事对用户不可见将要做大量的工作来添加一个开关”。那么答案是？分解你的特性到多个故事，让添加特性开关更容易。

特性开关应该是你故事里的“一等公民”。Orbitz的一个团队在他们的故事里添加特性位（特性开关的一种实现）。在他们开发一个故事的时侯，第一件事就是添加特性位到这个故事中。特性位表现为故事价值的一部分，并且添加特性位的工作也要跟故事一起进行估点。如果添加特性位这项任务估点很高，那么也就预示着你需要进行特性分解。

除了可以启用功能的增量式交付外，特性开关有另一些重要的用法。它们可让你的服务进行平滑的降级（例如，关闭一些资源敏感的特性如推荐引擎）而没有额外的负担。如果有一次发布出现了错误，它也可以让你关闭有问题的特性。这种方案可视为回滚你的发布的一个选择。

结论

软件项目常见的失败模式是当产品的所有者在尝试一次发布成功后，会添加越来越多的功能到项目中。这是一个恶性循环，最终导致成本和计划出现指数级的增长。Don Reinertsen 在他的书里称之为大批量死亡螺旋线。

持续交付允许团队在发布高质量软件的同时显著的降低交付成本。你可以做更多更频繁的交付，并得到更快速的反馈周期（从用户到产品团队）。但是同时你要改变管理方式，你需要通过软件交付过程来管理工作流。尤其是，如果你所做的持续发布过程是正确的，那么技术人员将不在是发布产品到用户端验证新想法的约束。在传统的发布流程中，我们需要等待数周或者数月才能看到我们的想法出现在可工作的软件中。通过交付小的，增量的功能并获取反馈，我们就有时间思考“下一步我们要尝试什么”。目前我没看到任何团队在实现持续交付后，还会再愿意回到老的工作方式。

使用传统的交付方式，我们必须很小心的选择那些我们真正想要交付的想法，因为软件的交付过程很昂贵。当然，那种筛选的过程也常常不是基于真实数据的。通过持续交付，我们将有一个防护网，我的同事DariusKumana称之为“创新失败的安全气囊”；我们可以疯狂的尝试新的想法，在任意的时刻廉价并且安全的去演化整个系统；如果它们不想被展示给某一小组用户的话，也没有什么风险。持续交付通过显著降低成本和发布软件的风险来解放我们，将分析师放回到他们自己的位置上-那就是强力创新。

感谢Chad Wathington, Elena Yatzeck, Dan McClure和Darius Kumana为本文的早期版本提供了反馈。