想要把握这个时代，就必须理解计算机。理解计算机的关键，则是要理解计算机背后的人。

背景介绍

互联网时代，头部的基本需求已经被全部满足，未来的方向或许是现有模式的颠覆，或许是长尾个性化需求的充分满足，又或许是小众人群的挖掘。在这样的大背景下，如何通过极致的研发运营效率，快速发现新的机会，降低创新成本就变得尤为重要。

实际上，国外的互联网公司已经做了先行者，进行了很多不同的实践，其中之一就是持续交付。有人问：“为什么持续交付的概念在09年就已经在国外盛行，而中国近几年才开始流行？”

面对这样的问题，有三个这样的答案。

• 百度工程效率部负责人：这是互联网发展的客观规律，现在的企业对精益团队有需要了，运维等底层技术也在不断突破；
• 乔帮主：90年左右国外软件工程就开始发展了，而中国的黄金一代在98年，我们仍然处于一个补课的阶段；
• 腾讯副总裁：现在生意不好做了，人手不够但要做事，就开始讲究效率了。

腾讯的答案给人印象深刻，跟我们现在的实际场景也很像。或者说，这是企业发展到一个阶段的必然现象。

开始之前

文章的内容多摘抄于《持续交付2.0》(侵权即删)，也希望大家能够购买并阅读乔老师的新作，我也算为精益思想的布道做了力所能及的贡献。
在签售会上，乔梁老师用了一个小时来介绍写书的用意，以帮助读者更好的认识持续交付2.0。
这里，笔者不自大于能带领大家领略持续交付方法论的思想，但希望文章能够给大家埋下一个意识，在面对组织上的迷茫时，能够想起有持续交付这个方法，然后翻开书本，揣摩其深意。
如此这般，就是有价值的。

历史缩影

Part I

在1968年，出现了第一次软件危机，落后的软件生产方式无法满足迅速增长的计算机软件需求，导致软件开发和维护过程中出现一系列严重的问题。

在全新的计算机领域中，人们借鉴了工程领域的工程方法，以实现“按预算准时交付所需功能的软件项目”的愿望！

1970年，Dr. Winston 首次提出了瀑布式软件开发方法，它将软件开发过程定义为多个阶段，每个阶段有严格的输入和输出标准，管理者希望通过这种重计划、重流程、重文档的方式来解决危机，具备这三个特征的开发方法统称为“重型软件开发方法”。

瀑布图

软件开发像瀑布一样，从一个阶段流向另一个阶段。实际开发过程中，每个阶段都需要花费过长的时间(数月)，需求也在不断变更，然后按预算准时交付的问题仍然没有得到很好的解决。

Part II

1994年，Chaos Report 显示，软件交付项目的失败或交付困难的比率仍旧很高(成功率16.2%，受到挑战的52.7%，失败的31.7%)。

很多优秀的软件工作者也不满意于瀑布式开发的交付成果，并在工作实践中总结了新的开发方法。在2001年，17位软件大师齐聚加拿大的小镇“雪鸟”，总结了“轻量级软件开发方法”的特点，发表了“敏捷宣言”。

敏捷开发方法，从一开始就不特指某一种开发方法，而是一簇软件开发方法的代名词。

敏捷的核心原则是：强调人的主观能动性，提倡面对面沟通、拥抱变化、通过迭代和增量开发尽早交付有价值的软件。

很多团队认识到，软件开发其实是一件不断迭代学习的过程，软件工程师需要不断和业务领域专家交流讨论来学习，将其转化为数字世界的表达方式，并不断持续这个过程。简单的说，把业务和软件工程师整合在一起。

在敏捷早起，迭代的周期仍然非常的长，业务人员和研发人员之间关于需求的变更仍然是主要矛盾。

这两个时期，无论是瀑布式开发还是敏捷开发，最重要的关注点都是可交付的软件包本身，即如何快速的把软件需求变成可交付的软件包。

敏捷实践

软件需求的反复变更，俨然成为了IT领域最为突出的问题。

从“敏捷宣言”中，我们已经看出了解决的方向：拥抱变化、尽早交付、增量开发、反复迭代。

接下来一系列的实践，都在体现这样的精神。

持续集成

“持续集成”作为敏捷开发方法的一个工程实践，率先被广泛的IT组织接受。

持续集成，就是把完成的代码不断转变成可交付的代码。简单的说，把开发和测试的职责整合在一起。

DevOps

在2008年的多伦多敏捷大会上，一个“敏捷基础设施”的临时话题中，独立IT咨询师 Patrick 分享了一个“将敏捷实践应用于运维领域”的讨论，并成功催化出一种运动，迅速传播，这个运动就是DevOps。

DevOps的原始定义是“DevOps是运维工程师和开发工程师参与整个服务生命周期的一组实践”，并提出，倡导运维人员更多地使用和开发人员使用的相同的技术来进行系统运维工作。简单的说，把开发工程师和运维工程师整合在一起。事实上，截止到今天，业界对于DevOps都没有统一的标准定义，如同敏捷，每一位从业者都有他自己的看法。但是值得明确的是，它们的目标和原则都非常明确，DevOps的目标是缩短开发周期，提高部署频率和更可靠的发布，与业务目标保持一致。

和敏捷开发方法相似，DevOps并非一个标准、一个模式 or 一个固定方法，它在提出之时的实操指导性略显不足。同一时间，IT领域出现了的另一个概念“持续交付”。

DevOps

教研-开发

持续交付 1.0

敏捷之势，愈演愈烈，绝知此事须躬行。

秉承能够实践的原则，10年正式出版了一本书《持续交付》，持续交付被定义为一种能力，以一种可持续的方式，安全快速的把代码部署到生产环境上，让用户使用。简单的说，把业务人员、开发人员、测试人员和运维人员都整合在一起。业务人员提出软件需求，开发人员完成编码，测试人员检测功能，运维人员部署并监控服务，业务人员通过监控数据提出新的软件需求，这就是持续交付1.0的闭环模型。

持续交付1.0

持续交付这本书，提供了一系列工作原则和优秀的实践方法，真正在实践中提升了软件开发活动的效率，是一个经过检验的范式。

精益思想

技术必须创造价值，如果没有或者不够，那一定是我错了。

在实际场景中发现，有一些软件功能并没有产生什么影响，根本没有用户使用。但是这些功能确实花费了团队的很多精力才设计实现，这是一种巨大的浪费。这种“无效”的功能越多，浪费就越大，我们能否找到一些方法，让我们付出的努力对业务改善更加有效，或者只用很少的成本就验证对业务无效呢？

最小可行性产品（Minimum Viable Product, MVP）。这个原型并不是一下子设计得到一个完美的产品，而是为了验证自己心中的商业假设，得到用户的真实反馈后，从每次的结果中学习，再快速迭代，持续修正，在资源耗尽前从迷雾中找到通往成功的道路，最终适应市场的需求。

精益思想。根据用户需求，定义企业生产价值，按照价值流来组织全部生产活动，使价值在生产活动之间流动起来，由需求拉动产品的生产，从而识别整个生产过程中不经意间产生的浪费，并消除之。在业务生产中的所有活动，可以被归结为两种，增加价值的活动和不增加的，不增加价值的活动就被称之为“浪费”，浪费也可以被归结为两种，必要的浪费（工作项的交接、寻找信息、测试、管理），和不必要的浪费（无人使用的功能，库存，软件缺陷）。

尽管“消除所有浪费”几乎是不可能的，但是，我们仍旧要全面贯彻“识别和消除一切浪费”的理念，持续不断的优化流程和工作方式，达到高质量、低成本、无风险地快速交付客户价值的目的。

持续交付 2.0

回到开始，我们正处于一个补课的阶段。

2009年左右，LinkedIn 从过去每年发布12次，到现在实行3x3，每周部署3次（Mon, Wen, Fri），每天发布3次(11am, 1pm, 4pm)，Amazon的成功是每年、每周、每月、每天多次实验的结果，FaceBook在任何时候都不只一个版本在运行，而是一万个。

“持续交付2.0”是一种产品研发管理思维框架。简单的说，精益思想和持续交付1.0整合起来，强调业务和技术之间的快速闭环，以一种可持续方式，高质量、低成本、无风险地快速交付客户价值。对企业来说，开发软件产品的目标是创造客户价值。因此，我们不应该仅仅关注快速开发软件功能，同时还应该关注我们所交付的软件的业务正确性，以及如何以有效的资源快速验证和解决业务问题。也就是说，不断探索发现真正要解决的业务问题，提出科学的目标，设计最小可行解决方案，通过快速实现解决方案并从真实反馈中收集数据，以验证该问题是否得以解决。这是一个从业务问题出发，到业务问题解决的完整业务闭环，也是一个整合精益思想和持续交付的双环模型。

持续交付2.0的四个核心原则

• 坚持少做

  • Netflix 认为，它们想做的事情中，可能有90%是错误的。
  • MicroSoft 认为，那些旨在改进关键指标而精心设计和开发的功能特性中，只有1/3左右成功改进了关键指标。
  • Instagram 被问及“5个工程师如何支持4000万用户？”时说，“少做，先做最简单的事情”。

• 持续分解问题
  复杂的业务问题中一定会包含很多不确定因素，它们会影响问题解决的速度和质量。通过对问题的层层分解，可以让团队更了解业务，更早识别出风险。

• 坚持快速反馈
  如果忽视每一项工作的结果反馈，那么就失去了由问题分解带来的另一半收益，确认风险降低or解除！

• 持续改进并衡量
  无论做了什么样的改进，如果无法以某种方式衡量它的结果，就无法证明真的得到了改进。

2.0 双环模型

价值探索环

这是一个外在的环，价值只能被外部定义。

很多企业在开发新产品时，会采用“概念验证”或“产品原型法”，然后用较长的开发过程去实现产品。由于市场变化太快，花大量时间完成开发后，可能因为对潜在用户的理解存在偏差or用户需求发生变化，导致当初的设计不被市场接受。在这个过程中有三个假设，用户假设（潜在用户），问题假设（臆想需求），解决方案假设（我们很牛）。这三类假设中，任何一个不成立，都会导致事倍功半，甚至前功尽弃。

价值探索环的目的就是要我们从业务问题出发，和团队一起，共同找出这三类假设，制定MVP，借助环的高速运转，获得反馈，不断验证和迭代。

• 提问
  不仅仅是找到“实现什么”以及“如何实现”，更要了解“为什么要实现”。

举办一个知识分享会，有一个客户希望下午能喝一杯咖啡。于是我们就问“需要什么口味”“热的还是冰的”“大杯还是中杯”“什么时候拿到”，这样就会去准备冰箱、冰块、水杯等等。反而忽略了客户为什么想要咖啡。如果客户是因为害怕而错过精彩分享，我们是不是可以采取录制视频，增加互动环节，允许会场走动等活动。

• 锚定
  当选定问题之后，我们要确定具体的目标和结果。
  目标最重要的特征之一是可客观衡量。学生喜欢的课程（学生有效停留率达到95%），有效的课程（纠错率达到60%），服务的稳定性（成功响应率达到99%）。

• 共创
  有了目标之后，团队为设法验证or达成目标而找出多种可行性解决方案的过程。
  同样的，方案最重要的特征之一就是要有量化指示器！为了提高产品的使用率，team member要提高产品的有效率（学生的绝对纠错率达到70%），team leader要提高团队的效率（做课效率从10人天提升至2人天），tech team要赋能业务（监控数据从每周更新到每天更新）。

• 精炼
  在共创环节会有多个方案，精炼是从中选出团队认为最小可行性解决方案的过程。
  不难想象，哪怕是巨大的工程，其解决方案也是一组迷你方案的集合。精炼的目的不是并不是为了删除在共创阶段得出的解决方案，而是将它们按照优先级排列，并让团队将解决方案进一步分解，顺序选出共同认可的最重要改进项，并确保它能够尽早被验证。那么，如何确定我们完成了精炼呢？可以尝试写出下面的句子。

我们相信，通过实现（xxxx最小功能组合），我们的指标可以达到（xxxx程度）的话，说明我们关于（xxxx）的假设是成立的。

工作原则

• 分解并快速试错
• 一次只验证一点
• 允许失败

快速验证环

这是一个内在的环，有了需求，如何快速上线并获得真实可靠的反馈。

质量和速度是验证环的关键，也就是说，发布质量好而且频率要高！(一些来自于1.0的方法：质量内建、小批量交付、自动化一切重复工作)

• 构建
  构建是将自然语言的描述转换成计算机可执行的软件，即可交付的软件包。
  这个环节参与的角色最多，参与角色如业务人员、产品经理、工程师，每个角色的背景知识和技能优势各不相同，如何快速将人们头脑中的解决方案变成可以运行的高质量软件包，一致是软件工程领域的难题。这也决定了这是验证环内不确定因素最多的一个环节。有三个方法可以了解一下：时间盒管理（timeboxing - deadline）、任务分解（breakdown）、持续验证（demo）。

• 运行
  运行将可交付的软件包部署至生产环境。
  如何让用户在无感知的情况下完成软件版本的升级更新是互联网时代最为重要的课题。这一阶段是开发和运维之间发生冲突最多的环节，也是重复性手工操作最多的环节。

• 监测
  监测是收集数据，统计展现结果、及时发现生产系统问题以及业务指标的异常波动并作出适当的反应。

• 决策
  决策是指受到真实的业务数据反馈结果后，根据探索环中已确定的响应衡量指标进行对比分析，从而验证是否符合最初的预期。

工作原则

• 质量内建(built quality in)
  从生产过程的第一个环节起，就要注重产出物的质量，并且在每个环节中都要开展质量保障活动，消除因质量问题导致的返工及次品率上升，以此降低最终的质量风险，保障进度。

• 消除等待
  价值流动，从关注“人”到关注“事”
  任务自助，让“专业”的人做“专业”的事，让“专业”的任务能自助

• 重复事务自动化
  如果以前一个月发布一次，现在每个月发布八次，那发布成本就是以前的八倍，所以自动化发布流程就显得尤为重要。依此类推。

• 监测一切
  “应用健康监测”和“业务健康检测”

补遗

团队的文化建设

It is our choices, Harry, that show what we truly are, far more than our abilities.

链接中是腾讯的人才发展观，干货很多，值得一读。

写书原因

曾：你写本书吧，把你的精益思想写出来
乔：为什么要写啊，你给我一个事情，我能保证把它解决
曾：你能解决一个问题，一个团队，可是我有这么多团队，这么多问题，怎么办？
（语言记录不尽详实）

在团队中也一样吧，程序员能写一个模块，一个系统，那企业有那么多模块，那么多系统，怎么办？

A Small Tip

持续交付2.0是非常好的思维框架，但也并不是可以完全照搬照抄的，框架中重要的是方法论，读书的过程更应该吸收这种思想。就比如软件领域的大型游戏开发，就不可能做一个MVP然后得到用户真实数据后迭代。

SCRUM中令人愉悦的经验

• 持续breakdown的做法。其一，团队中每个人都会参与业务分解，让每个人都有参与感，很容易build团队归属感，也让团队成员相互理解；其二：任务足够小，一旦完成就可以点掉一个，就像打游戏得分一样，给个人的反馈非常及时，是一种成就感；其三，在持续分解时，能暴露更多的业务细节，既能少做很多事情，也能提高了效率。
• 关注价值的做法。其一，每天站会都能感受到价值流动，从交付的代码到实际产生的价值，是直观的刺激，让人有成就感；其二，sprint的故事拆解环节中，每个故事都必须有价值，要找到能够实现价值的最少行为，这让团队专注，让价值清晰。
• 记录工时的做法。程序员有一些不同的薪酬计算方式，paid by lines, commits, hours等等。考虑到程序员其实是“脑力”工作者，写代码是一件非常具有不确定性的工作，SCRUM在试图不断减小这种不确定性，工时直白地展现了一个程序员或者说一个团队的交付能力，这很好。不过当工时和薪酬挂钩时，hmmm...

** 转载请注明出处 ~