如何才能做到持续交付？(2)

　　此时，这个项目就进行了所谓的“两难境地”，或叫“死亡行军”，人们在很大的压力上加班工作，试图修复整个系统。这令每个人都极不满意，而事实上， 在某些领域，这种失控模式已经成为一种家常便饭。

　　在那些实践持续交付的项目中，开始时进展可能比较慢。因为项目一开始要建立基础设施，对构建、测试和部署做自动化，并在得到成功构建的产品后，在类生产环境中执行验收测试。这让团队成员，尤其是刚接触它的管理者，感到不舒服。然而，这正说明它起作用了。持续交付的影响表现在它把痛苦提前了，从而让交付过程更加平稳、真实且可度量。

　　你原来体会到的是“开发完成“，与“真正完成”不一样。现实中，真正的“完成”是指发布给用户，或者至少在集成环境上严格地进行验收和回归测试后，在类生产环境中向客户演示。在新功能开发完后，其实还有很多工作要做：交付过程中的这部分被叫做最后一哩。持续交付坚持认为：“只有过了这一哩”，工作才算完成，根本就没有“完成了百分之五十”这个说法，所以，这让整个交付进度看上去比较慢。​

　　然 而，通过持续交付，你能得到可持续性。首先，因为持续交付意味着软件一直处于可发布状态，所以可以把原来的测试与集成阶段移掉，这就会大大降低项目风险。在这两个阶段，经常会发现严重问题，甚至是整个架构的缺陷。而修复这些问题的时间则很难预期。通过持续交付，这些问题在交付过程的早期就会被发现，些修复成本往往比较低。

　　​其次，对于新开发的特性来说，能更快地从客户和用户那里得到反馈。通过增量开发和持续发布给用户，你能在特性创作过程中就得到早期反馈，并不断调整。这样，软件的演进可以更快速地满足用户的需求。

　　设法进行增量开发

　　在主干上增量开发时，为了能够将大的特性拆分成小的、有价值的、可测试且相对独立的用户故事，需要分析人员、测试人员及开发团队的紧密合作。这么做，有几个好处。

　　可能最重要的好处就是，它促使团队将一个功能里，关键的部分和非关键部分区分开来，这让客户能在更小的粒度上做决策。将一个“必须做”的特性分解成多个小的、可增量开发的小需求，能更有效地区分出哪些是该功能的核心，哪些是外围需求。

　　然后，你可以将功能的核心部分(最初的最直接的实现)给用户进行测试，并找出用户接下来想做什么。这样可以给客户一些具体的数据，让他们更好地对该功能的剩余工作进行优先级的排序。当然，也很可能在他们看过以后，客户希望将后续的时间花在其它功能上了。而且，假如客户看过以后。认为这个特性没有什么价值，你可以马上停下来，不再浪费精力在这上面了。

　　增量开发依赖于每个人每天都能够提交一次，这样，应用程序才可以持续集成。对于那些习惯于在长生命周期分支上开发新特性或每个分支对应一类客户的团队来说，这看上去是不可能的。好消息是，在主干上开发是可行的，对于很大的团队也是可行的。坏消息是，它要求应用程序由松耦合的组件构成，并有良好的架构。它还要求，可以通过配置项在UI上能控制特性的开与关，这样，你才能可以灵活地控制，当功能准备好后，再打开开关。即使一些新功能只开发到一半，你也能持续地发布你的软件。

　　然而，这样做的收益也很大：你能持续不断地把已经做好的功能交付给客户，而不用绞尽脑汁地猜测哪个功能有价值。频繁地发布有价值的新功能是提高收入的 最好方式。

　　我怎么知道我是不是真的在持续交付?

　　持续交付是否需要一个像“Nokia 测试”那样的checklist呢?实际上，没有那个必要，因为有一个非常简单的方法来验证，你是不是真的在持续交付：你的软件是不是一直处于产品可发布状态。你只要按个回车键就可以把 它发布给用户。如果你的发布过程很痛苦，而且不太频繁，并且在发布之前还有一个充满风险的集成阶段，那么你就没有在做持续交付。

　　持续交付中最重要的度量是周期时间(cycle time)：从决定实现某个想法开始，到将其发布给用户为止这段时间长度。有几个原因让它成为一个很重要的度量：

　　第一，这是一个全局度量指标，用于度量整个过程的有效性。

　　第二，这是一个团队度量指标，而不是一个个人度量指标——只整个团队关注于改进交付过程，才有可能改变周期时间。

　　部署流水线提供了部分答案：部署流水线的实现会给你提供一些你需要的数据，主要是从提交到发布这段时间的。那么，只要你有一种方式将提交与特性关联起来，你就可以看到某个特性的周期时间。如果现在的工具不能让你收集这些数据，那就找一个去吧。

　　这样，你就可以制定一个持续改进流程，应用约束理念 ，或者使用看板，在交付过程中找到瓶颈，并想办法移除它们。持续交付可以也应该同样使用持续改进的方式减少成本，提高收入的增量地方式实现。

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