几年前看过《持续交付(发布可靠软件的系统方法)》，感触不是很深，最近看了这本书的译者乔梁编写的《持续交付2.0》，结合工作中的种种，又有一种相见恨晚的感觉。可见好书是需要经常翻阅的，每次都会带来新的收获和思考。
全书围绕着双环模型展开，介绍了持续交付，快速实现客户业务价值的一系列的方法论和实践工具。本文将结合实际工作中遇到的问题来谈谈这些方法论和工具。
双环模型
- 第一个环被称为探索环，主要就是搞清楚客户背后真实的业务目的，不只是要实现什么，怎么实现，而是要了解背后真正的原因，才能给出更合理的解决方案，通过沟通讨论出一个最小的可验证方案，以便能快速验证可行性，探索环也是持续交付2.0中新增的一个环
- 第二个环被称为验证环，验证环的主要工作内容就是以最可靠的质量和最快的速度，将最小可行性解决方案从描述性语言转换成可运行的软件包，并将其部署到生产环境中运行。
信息偏差
即便是再熟悉，再有默契的人，沟通同一个事物的时候也会产生理解上的偏差。我觉得在探索环中需要做到信息的一致性，即便不能完全一致，后面的验证环也能快速出成果给客户确认，因为足够小，可以及时地调整方向，把风险降到最低。
信息偏差不止是客户和我们之间，在团队内部也经常会出现，我们在安排任务时不管是口头描述还是有详细的文档，总会出现结果和期望有偏差的情况。樊登讲过的日本企业交代任务的方式我觉得可以尝试一下：
- 1、交代清楚事项
- 2、让员工复述一遍（有的软件公司成为反向交底）
- 3、和员工讨论做此事的目的
- 4、让员工考虑有没有什么风险
- 5、要求员工提出个人见解
看似很麻烦，但可以确保双方的想法能达到一致，减少后续返工的风险，其实就是磨刀不误砍柴工。
开发软件的目的是创造客户价值，所以，我们不应该仅仅关注快速开发软件功能，还应该关注我们所交付的软件的功能正确性。
流水线工作方式
双环中有很多的步骤，每个步骤环环相扣，从探索环业务需求的输入到验证环产出可以运行到成果，这是一个闭环，这个闭环的周期越短风险就会越小。从输入到输出，整个流程像流水线一样运转时，效率是最高的。就像敏捷中的看板文化一样，随着时间的推移，一个个的用户故事从最左边逐步移动到最右边。如果中间某个环境出现堆积或者断层，都说明可能出现问题了，需要停下来解决。
最近一个项目中需要做数据迁移，由于数据量和迁移的范围非常大，项目经理召集了公司很多其他项目组成员进行协助，项目经理按照自己熟悉的技术规划了迁移方式，学习成本比较高，对于初级开发或测试人员来说，短时间内很难上手，导致进度缓慢。
后来我们领导提出了更合理的方式，就是将迁移任务根据技术的难易程度分解成了几个大的步骤，各种水平的人都有事可做，并可以很快上手，最终高效完成了任务，这就是流水线效率的体现。
聚焦
书中讲到了四大原则：
- 坚持少做
- 持续分解问题
- 坚持快速反馈
- 持续改进并衡量
四个原则概括下就是要「聚焦」，特别是在时间紧任务重的情况下，更是要聚焦，只有聚焦了，双环模型的周期才会缩短。
案例一
最近团队有几个同事在开发一个独立的类邮件模块，功能涉及到收发邮件、删除邮件、收藏等功能。客户第一阶段关注的是，先要有这样一个功能模块，功能可以后面完善。聚焦的做法就是，快速完成邮件的收发功能，在交付期前有多的时间再完善删除邮件、收藏等功能。到了交付期，删除和收藏功能没有完成，不影响我收发功能的发布。
如果一开始将收发、收藏、删除等同时并行在做，可能到了最后时间，每个功能点都完成了一部分，但却不能交付客户。
案例二
我们开发的产品是一个功能强大的快速搭建平台，最近一客户使用我们平台来搭建业务功能，上线时间非常紧迫，这时就应该聚焦有哪些必须（阻碍业务）的功能目前还不能实现，利用探索环提交到产品团队，讨论出最小可行解决方案，然后在验证环快速出成果交付客户验证。
这时如果客户关注点在平台的非核心功能（主业务无关），提出各种优化需求和新增需求，这样就本末倒置了，最终上线会有极大的风险。
安灯（Andon）系统
「Andon」是一个信号灯，丰田公司要求员工，在生产流水线上遇到麻烦，都可以拉这个信号灯，生产线会立即停下来，直到问题解决，流水线才恢复运行，不让问题流到下一个环节。
安灯系统最重要的是让每一个员工都有质量意识，软件开发团队的中的成员往往就缺少这种意识，为了能早点完成任务，常常忘记完成这些任务的最终目的。
在这里分享一个小故事：
说有一人在路边看见地里有两人，一个人在前面挖坑，后面的人又用土把挖的坑埋上，由于好奇和不解，上前询问，两人回答，他们在种树，只不过负责放树苗的人今天请假没来。
从本职工作来说两人都完成的挺好，但没有价值。仔细想想一想，我们有时候是不是就像上面挖坑的人或是填坑的人一样？所以团队的每个人都应该为结果负责，都要能在适当的时候勇敢地拉下这个信号灯。
工具
持续交付在实践过程中离不开自动化工具，大体可以分为自动化构建和自动化测试。
自动化构建
不同大小的公司，或者处于不同阶段的团队，会采取不同的工具，适合自己的才是最好的，之前写过的几篇文章可以给大家参考：
1、GitLab 配合 Jenkins 打造自动化部署
2、在团队中使用 Gitlab 中的 Merge Request 工作模式
3、在 CentOS7 中安装 GitLab
4、敏捷下的需求和代码分支管理
5、不断进化的分支和需求管理
在上面的文章中有介绍我们是采用 GitLab 的 Merge Request 模式，对应到书中的分支策略，就是是主干开发，主干发布，因为每一个 Merge Request 分支的周期非常短，最终还是合并到主分支进行构建发布。但这种方式有一个问题，当同时并行任务过多时，合并时容易混乱。后面会尝试主干开发，分支发布的方式。
自动化测试
自动化测试大体可以分为单元测试和端到端测试，单元测试对开发人员的要求比较高，要保证持续交付高质量的产品，单元测试非常重要，我们现在也在规划和完善。
端到端测试目前已经在使用中，在之前的文章《端到端测试实践：Jenkins 集成TestCafe 》有所介绍。
总结
持续集成2.0这本书中有很多的干货，本文我只是找了几个我认为比较重要的点进行了描述，总之就一个目的，我们要快速地、准确地、高质量地把任务完成，并交付客户。