持续交付是指持续的将各类变更（包括新功能、缺陷修复、配置变化、实验等）安全、快速、高质量地落实到生产环境或用户手中的能力。
持续交付是软件工程领域的重要概念，
与之相关的还有 持续集成（CI）、持续部署（CD） ，甚至 DevOps 等等。
有很多文章，已经在技术视角，关于如何实现 CI/CD 做出了解释。
本文想继续深究，为什么会有这个概念，如何做好，以及未来的发展方向。
动机
交付能力
持续交付是一种能力，代表着人们在软件工程领域的强烈意愿，
人们希望，软件团队可以更快速的响应市场需求，
并且还要在保证质量、安全性的前提下。
所以说，持续交付从一开始，并不是单指支撑团队进行持续交付的软件系统。
而是，团队本身所具备的一种能力。
为了能让团队具备这种能力，可以采取很多种不同的办法，
其中，将基础设施工具化、将操作流程自动化，用以辅助团队，是最容易出结果的。
而这些工具、系统 确实也能在很大程度上提升团队的持续交付水平。
但仅仅看到这些还不够。
交付主体
事实上，整个团队才是交付的主体。
空有一套系统，而未抓住精髓，并不能有效的帮助团队达到高水平交付。
我们从团队的边界来看，整个团队就像一个大型的持续交付系统。
它能吞吐多少需求，能以多高效的响应市场变化，
才是最终需要解决的问题、衡量的标准。
这个时候需要考虑的点就非常多了。
如何获取市场所需，打造什么样的产品可以赢
需求如何进行转换，可以快速的被开发人员所理解和把控
系统如何设计，能够更加灵活，用更少的变更将功能实现
质量和安全如何保障
服务如何提供给用户，用户反馈如何获取
这是一个大的反馈循环，从市场来到市场去，软件功能从实现到更新。
整个团队通过产品形态不断的跟外界进行交互。
关于团队内部如何支撑这个循环，属于内部行为。
策略
做好持续交付，比完成持续交付软件系统的建设难得多。
因为需要关注方方面面，
甚至包括 产研销全流程、团队的组织形态与文化、以及人的因素。
可以假想一下 50 年后的软件研发团队，看看持续交付的极限在哪里。
等待时间
当前持续交付的第一个瓶颈点在于，等待时间过长，大部分人并没有有效的进行工作。
- 等待上游
上游完不成，下游就不能开展工作，只能等着，这些损耗是巨大的。
精益生产提供了解决这个问题的办法，
就是把大任务拆散，一小块一小块，在流水线中完成（增强流动性）。
- 沟通时间
还有很大一部分时间，耗费在团队内部的共识达成上。
团队内部有很多讨论，在众多可选的方案中，用何种办法解决会更好。
确定负责人、区分利益相关者，是一个不错的实践。
- 多任务切换
人脑的上下文切换能力是有限的，最高效的办法是不要一次处理多件事。
同时涌入很多任务，而这些任务又是相互关联的时候，
应当以何种顺序解决它们，得需要管理者、或系统加以辅助。
- 疲劳度
工作会产生疲劳，高效的工作则更甚。所以效率与产出并不总是正相关的。
这取决于完整工作时间内的自动化水平，以及干扰水平。
这甚至跟团队文化相关，是加班还是追求效率（实际上工作更累）。
基础设施
团队能够交付更快，取决于自动化工具的丰富度、可用性和稳定性。
首先要有工具，其次这些工具必须能被用上，最后，还要好用、够稳。
因此，如何形成一套有效的工具、流程实践，才是重中之重。
- 技术、非技术
这套实践不只包括 开发环节，还要包括 市场、需求、测试、运维、运营 等等。
开发也只是很小的一个关注阶段。
大部分团队可能没有意识到，其他阶段对持续交付的影响。
也就是说，仅开发人员能够持续交付软件功能，这远远不够。
所以我们提供的基础设施，应当是面向 产研销全链路 的，而不只是开发。
尤其是这些不同职能角色之间的边界上，中间产物、价值 如何流转。
这可能并不是以一人之力，或者一个团队之力能够解决的。
往往会动摇多个团队的利害关系，甚至部门内外的大协同。
因此，组织架构的设计和团队的职责划分很重要，什么样的划分就有什么样的系统和产品。
很多团队做好了基础设施，但是整个业务线还是无法达到高水平交付，
可能的原因之一，就在于各职能之间的关系没有理顺。
或者没有共同达到较高的交付水平。
- 业务开发、基础架构
如果只考虑开发阶段的话，主要包括两种角色，一种是业务开发，另一种是基础架构。
基础架构为业务开发提供可编程的、可复用的软件工具。
这一层封装，是为了减少整体的技术多样性和复杂度，便于量产。
难点在于，稳定好用的封装层，不容易打造。
在提高效率的同时，也增加了新手的门槛，一开始甚至还会降低效率。
并且增加依赖深度的同时，也容易让整个系统变得更加脆弱。
链路上的每个环节，一旦出现问题，就容易影响全局。
所以基础架构团队的交付产物，必然还要比业务研发团队具备更高的质量要求。
而且还要从一开始就考虑兼容性问题。
沉重的技术债务最容易出现在基础架构团队，而且影响面非常广。
目标设定
比起单个人提升效率而言，如何让多人沿着相同的目标前进，无疑更重要。
此外，如何激发每个人的动力，发挥主动性，也很重要。
所以在部门团队层面，如何设定目标，能很大程度上影响持续交付。
目标不能是拍脑袋想出来的，需要非常多的沟通。
但实际执行下来，不论是自底向上，还是自顶向下的设计目标，都有问题。
- 自底向上
往往最底层员工，是最了解问题的，或者说是离问题最近的。
但并不一定是最善于解决问题，或者最适合、最能够解决问题的。
因为第一眼看到的可能只是问题的表象。
所以自底向上的考虑目标，容易使得目标无法解决真正的问题。
也容易缺少规划，因为规划能力底层员工所欠缺的。
自底向上的传导，也很容易造成信息折损，重心也容易跑偏。
甚至还取决于不同员工，向上反馈问题时的个人水平。
- 自顶向下
自顶向下的拆分，会使得目标更有格局，眼光更加深远。
但难免会与实际脱节，或者没有完整考虑各种细节因素。
人的精力有限，全局和细节，真的很难兼得。
当企业采取这样的拆分方式时，很容易形成揣摩上意的风气。
上层的一次些微调整，底层就得转的飞起，就像齿轮套齿轮一样。
为了能够完成上级的目标，拆分容易促进层层加码，
到了底层可能会变成无法完成的任务。
- 改进
有了以上思考之后，
既能了解上层目标，又能了解底层问题，就显得非常重要。
这取决于，目标在制定之后，能否、以及用什么样的方式可做出修订。
以及企业文化，能否支撑不同层级的员工，就目标进行修订。
只有可以被修订、不断被修订的目标，才能使得上下同心。
当然修订的周期、涉众 也是需要考量的。
结语
未来仍然是人的社会，不论新兴技术如何发展，最后还是要解决人的问题。
只不过机器与人边界会进一步压缩、调整。
当一个产业变成全自动化时，再讨论持续交付就是失去了意义。
因为进一步提高生产力的关键，只剩下了科技。
全自动化产业的人力投入，也将极大程度的缩减。
此外，这也意味着，这个产业的需求也趋近稳定。
比如农副产品，人们会种植、量产、销售 特定品类的农副产品。
发达国家中，几乎所有的生产活动都被机器所取代。
软件行业还远没有达到这种丰富程度，因为人们的想法无穷无尽。
所以除了一些特定领域，随着需求不断稳定之外，
持续交付在软件行业，还有很长的路要走。