《持续交付 2.0》读书笔记
软件工程发展概述
“软件工程”这一学科出现于 1968 年，当时正值第一次软件危机。第一次软件危机是落后的软件生产方式无法满足迅速增长的计算机软件需求，从而导致软件开发与维护过程中出现一系列严重问题的现象。人们试图借鉴建筑工程领域的工程方法来解决这一问题，以实现“按预算准时交付所需功能的软件项目"的愿望。
瀑布软件开发方法
瀑布软件开发方法是将软件开发过程定义为多个阶段，每个阶段均有严格的输入和输出标准，项目管理者希望通过这种重计划、重流程、 重文档的方式来解决软件危机。很多人将具有以上 3 个特征的软件开发方法统称为“重型软件开发方法”。
敏捷软件开发方法
敏捷软件开发方法强调发挥人的主观能动性，提倡面对面沟通、拥抱变化、通过迭代和增量开发尽早交付有价值的软件。此时，很多团队已认识到，软件开发实际上是一个不断迭代学习的过程，即软件工程师需要快速学习并理解领域知识，并将其转化成数字世界的表达形式，通过与业务专家的交流讨论来学习并持续迭代这个过程。一个软件交付计划被划分成多个迭代，强调在每个迭代结束时应该得到可运行的软件。
与瀑布软件开发方法只在项目交付后期才能看到可运行的软件相比，敏捷软件开发方法在这方面有很大的进步。“持续集成”作为敏捷开发方法中的一个工程实践，率先被更广泛的 IT 组织所接受，即便那些没有采纳敏捷开发方法的团队也会使用它，因为其强调的频繁自动化构建和自动化测试减少了质量保障团队的重复工作量，也排除了开发团队与质量保障团队之间的沟通障碍。
DevOps 运动
2010 年“The Agile Admin”网站上发表的一篇题为 “What is DevOps”（什么是 DevOps）的文章中指出：“DevOps是一组概念集合的代称，虽然并非全部都是新概念，但它们已经催化为一种运动，并迅速在整个技术社区中传播。”
DevOps 是运维工程师和开发工程师参与整个服务生命周期（从设计到开发再到生产支持）的一组实践。
DevOps 在维基百科上的定义也在随着时间的推进而不断变化着。截止到 2017 年，其定义为：DevOps 是一种软件工程文化和实践，旨在统一整合软件开发和软件运维。
DevOps 运动的主要特点是强烈倡导对构建软件的所有环节（从集成、测试、发布到部署和基础架构管理）进行全面的自动化和监控。
DevOps 的目标是缩短开发周期，提高部署频率和更可靠地发布，与业务目标保持一致。
DevOps 并非一个标准、一种模式或者一套固定方法，而是一种 IT 组织管理的发展趋势，也就是说，通过多种方式打破 IT 职能部门之间的隔阂，改变 IT 组织内部的原有合作模式，使之更紧密结合，从而促进业务迭代速度更快。 这种发展趋势将会引起 IT 组织内部原有角色与分工的变化，甚至范围更大，会影响到相关的业务组织。对互联网公司来说，其软件产品对业务发展起到极其关键的作用，业务结果与 IT 效能强关联，因此顺应这一发展趋势的动力更加明显和迫切。
持续交付 1.0
“持续交付 1.0” 是一种能力，也就是说，能够以可持续方式，安全快速地把代码变更（包括特性、配置、缺陷和试验）部署到生产环境上，让用户使用。具体请看 #持续交付 1.0
“持续交付 1.0” 提供的很多原则及方法是 DevOps 运动的具体实操指引，它们可以为企业的 IT 团队将 DevOps 运动落地实施提供非常具体的指导。
持续交付 2.0
“持续交付 1.0” 关注于“从提交代码到产品发布”的过程，但是，一些软件功能在开发完成之后，对用户或者业务来说，并没有产生什么影响，有些功能根本没有用户来使用。可是，这些功能的确花费了团队的很多精力才设计实现。这是一种巨大的浪费。这种“无用”的功能生产得越多，浪费就越大。
我们是否可以找到一些方法，让我们付出的努力对业务改善更加有效，或者只用很少的成本就可以验证对业务无效呢？
精益思想
《精益创业》的核心理念是开发新产品时，先做出一个简单的原型 - 最小化可行产品（Minimum Viable Product, MVP ），原型的目标不是马上产出一个完美的产品，而是为了验证商业假设，得到用户反馈后，持续迭代，快速修正。
精益思想是指导企业根据用户需求，定义企业生产价值，按照价值流来组织全部生产活动，使价值在生产活动之间流动起来，由需求拉动产品的生产，从而识别整个生产过程中不经意间产生的浪费，并消除之。
在精益管理理论中，“浪费”是指从客户角度出发，对优质产品与良好服务不增加价值的生产活动或管理流程。例如，无效果的功能特性、没人看的文档、软件缺陷、机械性的重复工作等。
尽管“消除所有浪费”几乎是不可能的，但是，我们仍旧要全面贯彻“识别和消除一切浪费”的理念，持续不断地优化流程与工作方式，达到高质量、低成本、无风险地快速交付客户价值的目的。
双环模型
“持续交付 2.0” 是一种产品研发管理思维框架。它将精益创业与 “持续交付 1.0” 相结合，强调业务与 IT 间的快速闭环，以“精益思想”为指导，全面贯彻“识别和消除一切浪费” 的理念，通过一系列工作原则与实践，帮助企业以一种可持续方式，高质量、低成本、无风险地快速交付客户价值。
对企业来说，开发软件产品的目标是创造客户价值。因此，我们不应该仅仅关注快速开发软件功能，同时还应该关注我们所交付的软件的业务正确性，以及如何以有限的资源快速验证和解决业务问题。也就是说，不断探索发现真正要解决的业务问题，提出科学的目标，设计最小可行解决方案。通过快速实现解决方案并从真实反馈中收集数据，以验证该问题是否得以解决。这是一个从业务问题出发，到业务问题解决的完整业务闭环，简称为持续交付 “8” 字环。
它由两个相连的环组成：第一个环为“探索环”，其主要目标是识别和定义业务问题，并制订出最小可行解决方案进入第二个环，第二个环为“验证环”，其主要目标是以最快速度交付最小可行方案，可靠地收集真实反馈，并分析和验证业务问题的解决效果，以便决定下一步行动。
探索环包含 4 个可持续循环步骤，分别是提问、锚定、共创和精炼。
提问，即定义问题。通过有针对性的提问，找出客户的具体需求，并找出具体需求后的原因，即具体需求后要解决的根本问题。在提问中形成团队期望达成的业务目标或者想要解决的业务问题。如果问题无法清晰定义，那么找到的答案自然就会有偏差。因此，在寻找答案之前，应该先清晰地定义问题。
锚定，即定义结果目标指示器。针对问题进行信息收集，经过分析，去除干扰信息，识别问题假设，得到适当的衡量指标项，并用其描述现在的状况，同时讨论并定义我们接下来的行动所期望的结果。
共创，即共同探索和创造解决或验证该问题的多种具有可行性的解决方案。
精炼，即对所有的可行试验方案进行选择，找到最小可行性解决方案，它既可能是单个方案，也可能是多个方案的组合。
验证环也包含 4 个可持续循环的步骤，分别是构建、运行、监测和决策。
构建：是指根据非数字化描述，将最小可行性解决方案准确地转换成符合质量要求的软件包。
运行：是指将达到质量要求的软件包部署到生产环境或交到用户手中，并使之为用户提供服务。
监测：是指收集生产系统中产生的数据，对系统进行监控，确保其正常运行。同时将业务数据以适当的形式及时呈现出来。
决策：是指将收集到的数据信息与探索环得出的对应目标进行对比分析，做出决策，确定下一步的方向。
探索环就像是一部车子的前轮，把握前进方向。验证环则像车子的后轮，使车子平稳且驱动快速前进。它们之间相互促进，探索环产生的可行性方案规模越小，越能够提高验证环的运转速度，如果价值验证环能够提高运转速度，则有利于探索环尽早得到真实反馈，有利于快速决策，及时对前进方向进行验证或调整。
4 个核心原则
“持续交付 2.0” 是指企业能够以可持续发展的方式，在高质量、低成本及无风险的前提下，不断缩短持续交付 “8” 字环周期，从而与企业外部频繁互动，获得及时且真实的反馈，最终创造更多客户价值的能力。
下面逐一介绍缩短持续交付 “8” 字环周期的 4 个核心工作原则：
坚持少做 - 无论公司实力如何，想做的事情永远超过自己的交付能力，需求永远做不完。然而，做得多就一定有效吗？我们应该抵住“通过大量计划来构建最佳功能”的诱惑，坚持少做，想办法对新创意尽早验证。
持续分解问题 - 复杂的业务问题中一定会包含很多不确定因素，它们会影响问题解决的速度和质量。在实施解决方案之前，通过对问题的层层分解，可以让团队更了解业务，更早识别出风险。企业应该坚信，即便是很大的课题或者大范围的变更，也可以将其分解为一系列小变更，快速解决，并得到反馈，从而尽早消除风险。与其设计一大堆特性，再策划一个持续数月的一次性发布，不如持续不断地尝试新想法，并各自独立发布给用户。
坚持快速反馈 - 当把问题分解以后，如果我们仍旧只是一味地埋头苦干，而忽视对每项已完成工作的结果反馈，那么就失去了由问题分解带来的另一半收益，确认风险降低或解除。只有通过快速反馈，我们才能尽早了解所完成工作的质量和效果。
持续改进并衡量 - 无论做了什么样的改进，如果无法以某种方式衡量它的结果，就无法证明真的得到了改进。在着手解决每个问题之前，我们都要找到适当的衡量方式，并将其与对应的功能需求放在同等重要的位置上，一起完成。
持续交付七巧板
讨论了 “持续交付2.0” 的指导思想、工作理念和核心原则。大家很容易意识到，它对适应快速变化的市场环境和激烈的市场竞争是非常有效的。那么，企业如何让“持续交付 2.0”成为一种组织能力，成为组织的 DNA，持续发挥作用，从而领先竞争对手，成为自己的一种竞争优势呢？
持续交付双环模型的实施与改进将涉及企业内的多个部门与不同的角色，无法由某个部门独立实施，必须在整个组织范围内贯彻执行 “持续交付 2.0” 的思想、理念与原则。
企业需要在组织管理机制、基础设施以及软件系统架构 3 个方面付诸行动，而每一个方面都包含多项内容，如下图。
每个企业的实施路径可能各不相同，所需要的周期也各有长短，对各方面的能力需求也不完全一致。正如中国传统玩具七巧板一样，每个企业都应根据自己的意愿和诉求，拼出属于自己的持续交付实践地图。
小结
“持续交付 2.0” 建立在 “持续交付 1.0” 的“可持续地快速发布软件服务”及精益创业的"最小化可行产品”两种理念基础之上，强调要以业务为导向，从一开始就将业务问题进行分解，并通过不断的科学探索与快速验证，减少浪费的同时，快速找到正确的业务前进方向，简称为“双环模型”。因此，其涉及组织中的多个团队，需要各个团队之间紧密合作，才能缩短 “8” 字环的周期。
“持续交付 2.0” 的 4 个核心工作原则是坚持少做、持续分解问题、坚持快速反馈和持续改进并衡量。只有这样，才能不断缩短持续交付 “8” 字环的运行周期，提升用户反馈速度，从而提高业务的敏捷性。这要求管理者跳出原有软件交付管理思维模式，摆脱“害怕失败”的恐惧感，拥抱“科学探索-快速验证”思维方法，快速试错，提升持续交付能力，进而发展现有业务，并快速开创新业务。
推荐阅读
加入读者圈子
174
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
