持续集成实践之持续交付的五个核心实践

　　原文发表于 InformIT

　　持续交付是一种软件开发策略，用于优化软件交付流程，以尽快得到高质量、有价值的软件。这种方法让你能更快地验证业务想法，通过直接在用户那里进行试验，做到快速迭代。 尽管《持续交付》一书主要讲的是工程实践，但持续交付的概念对整个产品交付过程都有重大意义，包括对特性的”fuzzy front end”、设计和分析的意义。

　　持续交付的一般性原则如下：

　　与其设计一大堆特性，再策划一个持续数月的版本发布，不如持续不断地尝试新想法，并独立发布给用户。通过充分思考，即便很大的特性或者大范围的变更，也能够通过一系列小步骤得到更快反馈，而且一旦你认为有必要停下来的话，可以随时停下来。利用跨功能团队在几小时或几天内交付这些小且增量式的功能，就能比竞争者有更多的创新，将投资回报最大化。

　　持续交付五个关键实践，为你建立一个从猜测到持续反馈的最有效途径，它们就是：

　　从最小可行产品(MVP)开始——Start with a minimum viable product.

　　衡量新特性的价值——Measure the value of your features.

　　做恰好充分的预先分析——Perform just enough analysis up front.

　　少做——Do less.

　　用户故事中要包括特性开关——Include feature toggles in your stories.

　　Start with a Minimum Viable Product (MVP)

　　“假如你没有因产品首发版本的寒酸而感到尴尬，就说明该产品的发布实在是太晚了。 ” Reid Hoffman, cofounder and chairman of LinkedIn (参见“建立大公司的十大创业原则”)

　　如果你的项目一启动，就有一大堆需求文档 放在项目经理的桌上，那你已经失败了。精益创业运动的核心思想中，关键的一个就是最小可行性产品(minimum viable product, 缩写为MVP)， 即为验证你的业务猜想而需做出的最小工作量。

　　当然，在制造业，MVP的概念已经有数十年的历史——它们被称作原型(prototypes)。在使用原型时，你不必把你的MVP展示给全世界的所有人，只要选择其中一组测试(beta)用户就行了。甚至用一个尚无法工作的软件都行——你可以创建一个pretotype，来收集信息，一行代码也不必写。

　　假如对受众来说，第一个版本至关重要，你也完全可以向全范围的用户展示经过精心打造的更完美的产品。例如，某个公司用别的商标品牌发布了它的iPhone应用的一个MVP版本。只是为了得到具有统计意义的重要反馈，即它的业务规划是否能成功。而次要目标是验证一下该软件的交付流程。

　　找到MVP如何运作至关重要的一点是，需要一个由业务人员和技术人员组成的跨功能团队(cross-functional team)。这个团队中的角色包括用户体验设计(User Experience Designer，UX)，分析、测试、开发、运营和基础设施建设。当然，一个人可以承担多个角色，所以也不是非要很多人，才能完成一件事。

　　由于一个小团队在数周内(而不是一两个月的时间里)就可以完成MVP，所以此时也不需要很多仪式，因为你不必象赌博一样，押上整个公司，或一大笔钱。

　　Measure the Value of Your Features

　　“度量是产品的一部分” — John Allspaw， VP of Technical Operations, Etsy (参见“Building Resiliencein Web Development and Operations”).

　　精益创业中另一个核心概念是验证性学习(validated learning)，即通过收集产品被真正使用后的衡量指标，而不是通过对用户的提问来验证效果。正是电视剧《Dr. Gregory House》中，他喜欢说的那样，人们会说慌的——尽管更文雅一些，我们可以说他们不知道他们想要什么。把你的用户当做是试验对象，而不是那些聪明的代言人(intelligent agents)。

　　你要能回答下面这样的问题：

　　我们在产品上所做的这些修改是否让更多的人注册了，逗留时间增加了，还是增加了收入? Or is it time to pivot?

　　在做A/B测试时，该特性在哪个版本的效果更好?

　　所有的系统指标看上去都不错，一个用户说我们的网站不能用。难道是我们的网站坏了吗?

　　我们产品中的哪些特性是收入的最大来源?

　　你不必在Apache的日志中搜罗信息，也不必试图从那些辅助功能上回溯，或利用定制化查询，就应该能够回答这些问题。这些问题应该看一眼仪表盘(Dashboard)就能知道，而且，这些信息应该是完全可审计的。

　　在Eric Rie的《精益创业》The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses(Crown Business, 2011)一书中，他提到了 Grockit 的故事:

　　遵循精益制造中的 kanban 原则， […]Grockit改变了产品优先级评估流程。在这个新流程中， 直到验证性学习(validated learning)时，用户故事才算完成。所以，一个用户故事要经历四个阶段：在product backlog中，正在实现中，完成(从技术角度看特性是完成了)，以及验证中。验证被定义为：“第一时间知道某个用户故事是不是一个好主意” 。这种验证通常是以某种隔离测试来展示客户行为的变化，当然也包括客户访谈或问卷调查。

　　只有当度量项被放在用户故事中一起完成时，这种学习方式才有可能。

　　看上去，这一原则可能是针对web应用的，事实上，对于嵌入式系统和用户自行安装的产品也是同样道理。为了远程调试和失败报警的目的，以及理解用户的使用模式，所有类型的系统需要收集这些度量项。

　　Perform Just Enough Analysis Up Front

　　“你要知道，当团队在编码之前试图完成规格说明的收集时，你就不是在做迭代开发。” Bas Vodde, “History of Nokia Test.”

　　一旦你想到了一个点子，是一个最小可行产品(minimum viable product)，你就要开始交付软件了。第一步是分析。但是backlog中所有的用户故事不必被全面分析。因为那么做，这也是一种浪费。为了全面分析用户故事，你要从客户、开发人员、测试人员、用户体验设计和用户那里得到信息。如果团队在花大量时间去收集这些信息，那么他们的这些工作实际上还没有交付有价值的功能，也无法从那些使用该系统的用户中得到真正的反馈。

原文转自：http://www.ltesting.net