《持续交付2.0》是一本由乔梁著作，人民邮电出版社出版的平装图书，本书定价：89.00元，页数：327，特精心从网络上整理的一些读者的读后感，希望对大家能有帮助。
《持续交付2.0》精选点评：
●双环模型总结的挺好。此外，全书像是对于敏捷开发全流程的一个很好的综述，对于方方面面都有很好的阐述，值得工作中不断借鉴。
●融合了精益、敏捷研发，业务探索比较好的集大成的DEVOPS丛书，说是DEVOPS丛书是因为书中关于双环中的讲解还是右边delivery部分的比较详细且有实战经验，左边的discovery多数还是停留在精益创业的概念阶段，能讲通顺，力度稍显薄弱。
●方法论不错，开发流程中的各个点都 cover 到了。
●BAT各种出来讲述敏捷和Devops解决方案的人只有乔老板的能力是最强的，只有在不断否定自己，不断追求卓越的人才是最符合敏捷追求的人。永无止境追求极致~
●整理得很好。光是几种 分支 workflow 、软件工程发展史 就值回票价了。 适合随时翻
●双环模型：价值探索环和快速交付环 书的组织很流畅易读
●我们遇到了什么样的问题？该怎样去解决这些问题？如何从小处入手、从工程落地去解决问题？真正帮助组织团队去实施持续交付并实现效益。别提敏捷，只解决问题！不是直接告诉你该怎么做该怎么去改，一切从解决问题出发才是能真正达成共识。持续交付的双环模型、整体持续交付每个节点都一一讲到，真的是一本该细读多读的书籍。在最后的案例中，有一瞬间我都差点被惊到，真的感觉好像我们公司我们部门的例子……有时候，别走太快，该等一等灵魂了，系统的方法论和对之前的总结反思才是能走好未来使之更进一步的基础……五星推荐！
●内容很全，不过我都知道了…
●如果真的做的这么好，软件开发就不会这么苦逼了。
●不错，东西很全，当然大部分都懂。后面几个改造案例不错。
《持续交付2.0》读后感(一)：《持续交付2.0》读后感——软件工程实战进阶
在还没有阅读本书之前，我以为本书是介绍devops工具的，看完之后，觉得本书应该属于软件工程，并且是接地气的，进阶版的软件工程。
开篇便是从较宏观的角度介绍软件研发过程的双环模型，探索-->验证-->探索-->验证...，很熟悉的模式，想起实践论、小步快走、用户调研，总的来说，双环模型是很好的抽象总结。
接着介绍了组织文化，怎么让双环模型落地。章节内容不多，但谈到了很多要点，总结下我有感触的文化上的点：（1）owner意识，组织里的每一个人都对整体产品负责，任何好的制度，最终都要落到人来执行，安灯系统在制度上更容易激发执行者的责任意识；（2）目标感，在流程的每个方面强化目标感，基于目标衍生出来的动作，包括：关键结果、培训、衡量手段；（3）学习型组织，允许犯错，定期复盘，让组织越来越好；
除了介绍文化之外，还重点介绍了，如何建立企业文化，这点和团队管理比较像，作者总结的很完善:（1）定义想要做的事情；（2）定义期望的做事方法；（3）提供相应的培训。（4）做些必需的事情来强化那些行为。
读到这里是，心有戚戚焉，也是总结了我在团队管理上的探索：我希望我们团队是一个（1）执行力强又有创造思维；（2）协作高效；（3）有分享精神、有影响力；（4）持续进步的团队。于是我总结出来一套做事方法，并采取一些制度流程：制定需求开发的标准流程、定期每周一次团队分享会议、每周复盘团队OKR、每周复盘个人需求规划&执行情况、鼓励每个负责人自己提炼需求——技术驱动、强制CR制度、强制文档总结、强化导师带人时间投入等等。还提供了一些职业素养的指导文档、新人手册、导师文档以及推荐阅读书籍，并在团队会议、奖项申报、绩效考核中强化团队导向，让符合团队导向的同学拿到更多激励。
接下来有多个章节，主要介绍了软件研发流程中的要点。首先是软件系统架构，可持续交付对系统的架构有要求，常见的是微核架构和微服务架构。 作者总结的持续交付架构写得很好：（1）为测试而设计；（2）为部署而设计；（3）为监控而设计；（4）为扩展而设计；（5）为失效而设计。5个小点很精炼，高扩展、容易测试、容易部署、可监控、有容错，仔细思索，影响交付效率的通用的要点就是这些。
然后是需求协作管理，包括从需求产出到需求交付的全流程，其中很重要的点是如何拆分需求，INVEST原则：独立的、可协商的、有价值的、可估算的、规模小且适中的。需求编码完成之后，就是部署，接着介绍了部署流水线原则和工具的设计，这里详细介绍了流水线涉及的每个环节.
再接着，回过头来看开发过程的分支策略，当前推崇的是主干开发，主干发布，注意：只要分支时间存在时间极短（文中有两个数据：不超过1天、不超过3天），及时合回到主干，那么就可以算作这种模式。代码编写过程中怎么能够持续的合入代码、快速编译反馈，依赖基础设施建设、研发流程，以及工程师的素质。要实现持续高效的代码合入，减少人力，在代码质量上需要自动化——自动化测试。为了实现流水线的“一切自动化”——软件配置管理就显得非常重要，软件配置管理是指在整个软件生命周期中，对生产和运行环节中相关产物的管理。接着是低风险发布，指在发布环节如何保证低风险高效率。最后是监测与决策，服务上线之后，监控少不了。
最后三个章节介绍了三个案例。（1）将大团队拆小：feature term模式的实践；（2）小团队从“假”敏捷到“真”敏捷转换的实践；（3）小团队从混乱模式进入到敏捷开发，再进入到持续交付，并形成devops文化的实践；
我正好在职业生涯中参与过类似案例1和3的团队。 2011年毕业工作，遇到的第一个团队便是采取敏捷开发模式，没有猜错的话，也正好是和案例3是同一家公司，我参与的是PC客户端研发团队，当时还将我们团队的敏捷实践作为学习案例贴在宣传栏上——男厕所坑位宣传栏:)。 2016年到T厂，正好是某APP团队按feature term模式拆分之后，没机会见识一个超级大团队的混乱。
身在其中，有时并不懂得其中的幸福，刚毕业以为所有的软件研发团队都该是敏捷的，有story、有需求拉通PMRDQA评审、有jenkins...等等，后来到了公司的深圳研发中心，才见识到石器时代的开发模式，一时震惊。 越往后见识过不同的研发模式、不同的人，越觉得那些年在B厂呆过的第一个团队，无论人员战斗力、研发模式、氛围，都是难得再见的。好的研发模式，必须要有优秀的执行者，粗放的研发模式下呆了三年多之后，见到T厂某BG终于重视研发效能，重视工程师素养培养，真实可喜，如今新入职的小同学们，是否能够意识到，你们正处在前所未有的幸福之中？
附录：一些比较新的名词：测试左移、质量内建。
《持续交付2.0》读后感(二)：价值做指引，不断探索发现自己走向成功的路径
今天，分享的内容取自这本偏技术的图书，不过其中有些部分还是可以给我们一些关于工作和生活的启发。
- 1 -
持续交付的双环模型
书中最重要的一个概念，就是持续交付的双环模型。
这个模型，描述的是互联网产品从用户需求提出，到确定解决方案、验证解决方案的完整过程。其中所谓的双环，即指价值探索环（简称「探索环」）和快速验证环（简称「验证环」）。
探索环的目标，在于识别和定义业务问题，并制订出最小可行解决方案，进入第二个环。
而验证环的目标，是以最快速度交付最小可行方案，可靠的收集真实反馈，并分析和验证业务问题的解决效果，以便决定下一步行动。
通过这个概念，我们看到一个产品概念的形成，首先，需要对问题进行定义（提问），对结果目标进行描述（锚定），在此基础上探索和提出具有可行性的多种解决方案（共创），最后，针对提出的方案进行选择，找到接下来进行实践的解决方案（精炼）。
在这个过程中，我们不能看到用户的问题后，就匆匆忙忙给出一个想当然的解决方案，而是要从问题背后，找到其真正的诉求，深挖用户需求背后的痛点，在此基础上提出可能的解决方案，形成最小可验证模型（MVP）进行验证。
而验证的过程，需要的是「快」，毕竟「天下武功，唯快不破」。通过快速的将方案转换成符合质量要求的软件包（构建），交付给用户，为用户提供服务（运行）。在用户使用的过程中，收集相关使用和反馈数据，确保服务的正常运行（监测），对其数据进行分析对比，确定接下来近一步解决方案的完善（决策）。
在这个双环过程中，要坚持四个原则，即：
我们在生活中，想要去尝试一件新的事情时，也可以应用这个双环模型进行梳理，扪心自问自己想要尝试的理由，想清楚自己想要尝试的方向，在这个方向上拿出自己的方案，快速实践，快速验证，快速决策，不断迭代优化。
想起前几天看的一个视频，讨论的是主业和副业的问题。视频中的主讲人，分享自己做主业的同时，利用业余时间尝试用视频解读哲学知识的故事。他通过不断的精进，根据用户的反馈不断的优化自己解读的方式、细节，最终将副业转化成了主业。
在这个过程中，找准方向，快速实践，持续交付视频，就是对双环模型最好的实践。
- 2 -
度量工作
在做实践的过程中，我们需要对自己的实践过程进行「监控」，指引自己有目标、有计划的优化。
书中提到了度量指标的四类属性，分属于两组：引领性指标 VS 滞后性指标，以及可观测性指标 VS可行动性指标。
其中，引领性指标是对目标有引领性作用的，一般具有预见性，实践目标的人是可以影响这些指标的。而滞后性指标，是指为了达到我们树立的目标进行跟踪性的指标，当我们得到结果时，数据已经确定，无法改变。
可观测性指标，是指可以被客观监测到，但无法通过直接行动来改变的指标。而可行动性指标，是指在能力可触达范围内，通过团队努力，可以设法改变的指标。
在我们了解了这些度量指标的分类后，我们就可以有选择的制订我们度量的方向和指标。
在这个过程中，我们需要牢记的是，度量的目标是为了改善现状，改善我们工作的过程，而不是为了制订目标而制订目标。我们需要通过制订的指标，判断改进过程是否有效，是否有意义。
我们需要清楚的了解到，度量是一把双刃剑，我们很容易会落入「你度量什么，就会得到什么」的误区。
在我之前的工作经历中，就有出现这样的情况。上级制订了一系列度量指标后，总有同事会为了迎合度量目标而故意「造数据」，最终数据符合预期了，但最终极的满足客户价值的目标却没有实现。
对于我们个人，在制订个人计划和目标时，老生常谈的是「SMART原则」。在明确其中的Measurable（可度量）时，也要注意避免这样的情况。
- 3 -
提升工作
在书中「文化塑造四步法」的部分，提到了丰田汽车公司创建的方法论。
这个方法论不仅适用于传统的制造行业，也适用于高新科技公司，更适用于我们个人。
当我们想要改变自己，期待自己做出一些改变的时候，或者想要带领自己的团队做出新的挑战和改变时，也可以按照这样的步骤去实践。
在这个过程中，我们同样需要不断的改进和优化其中的细节，根据实际的运行情况做出调整，来让整个转变更好的持续下去。
当我们在过程中不断的实现里程碑时，或者最终实现既定的宏伟目标时，多给自己奖励，让自己收获「及时反馈」带来的兴奋与愉悦，为后续更好的投入做好准备。
《持续交付2.0》读后感(三)：提高产品研发生产力
几年前看过《持续交付(发布可靠软件的系统方法)》，感触不是很深，最近看了这本书的译者乔梁编写的《持续交付2.0》，结合工作中的种种，又有一种相见恨晚的感觉。可见好书是需要经常翻阅的，每次都会带来新的收获和思考。
全书围绕着双环模型展开，介绍了持续交付，快速实现客户业务价值的一系列的方法论和实践工具。本文将结合实际工作中遇到的问题来谈谈这些方法论和工具。
即便是再熟悉，再有默契的人，沟通同一个事物的时候也会产生理解上的偏差。我觉得在探索环中需要做到信息的一致性，即便不能完全一致，后面的验证环也能快速出成果给客户确认，因为足够小，可以及时地调整方向，把风险降到最低。
信息偏差不止是客户和我们之间，在团队内部也经常会出现，我们在安排任务时不管是口头描述还是有详细的文档，总会出现结果和期望有偏差的情况。樊登讲过的日本企业交代任务的方式我觉得可以尝试一下：
看似很麻烦，但可以确保双方的想法能达到一致，减少后续返工的风险，其实就是磨刀不误砍柴工。
开发软件的目的是创造客户价值，所以，我们不应该仅仅关注快速开发软件功能，还应该关注我们所交付的软件的功能正确性。
双环中有很多的步骤，每个步骤环环相扣，从探索环业务需求的输入到验证环产出可以运行到成果，这是一个闭环，这个闭环的周期越短风险就会越小。从输入到输出，整个流程像流水线一样运转时，效率是最高的。就像敏捷中的看板文化一样，随着时间的推移，一个个的用户故事从最左边逐步移动到最右边。如果中间某个环境出现堆积或者断层，都说明可能出现问题了，需要停下来解决。
最近一个项目中需要做数据迁移，由于数据量和迁移的范围非常大，项目经理召集了公司很多其他项目组成员进行协助，项目经理按照自己熟悉的技术规划了迁移方式，学习成本比较高，对于初级开发或测试人员来说，短时间内很难上手，导致进度缓慢。
后来我们领导提出了更合理的方式，就是将迁移任务根据技术的难易程度分解成了几个大的步骤，各种水平的人都有事可做，并可以很快上手，最终高效完成了任务，这就是流水线效率的体现。
书中讲到了四大原则：
四个原则概括下就是要「聚焦」，特别是在时间紧任务重的情况下，更是要聚焦，只有聚焦了，双环模型的周期才会缩短。
最近团队有几个同事在开发一个独立的类邮件模块，功能涉及到收发邮件、删除邮件、收藏等功能。客户第一阶段关注的是，先要有这样一个功能模块，功能可以后面完善。聚焦的做法就是，快速完成邮件的收发功能，在交付期前有多的时间再完善删除邮件、收藏等功能。到了交付期，删除和收藏功能没有完成，不影响我收发功能的发布。
如果一开始将收发、收藏、删除等同时并行在做，可能到了最后时间，每个功能点都完成了一部分，但却不能交付客户。
我们开发的产品是一个功能强大的快速搭建平台，最近一客户使用我们平台来搭建业务功能，上线时间非常紧迫，这时就应该聚焦有哪些必须（阻碍业务）的功能目前还不能实现，利用探索环提交到产品团队，讨论出最小可行解决方案，然后在验证环快速出成果交付客户验证。
这时如果客户关注点在平台的非核心功能（主业务无关），提出各种优化需求和新增需求，这样就本末倒置了，最终上线会有极大的风险。
「Andon」是一个信号灯，丰田公司要求员工，在生产流水线上遇到麻烦，都可以拉这个信号灯，生产线会立即停下来，直到问题解决，流水线才恢复运行，不让问题流到下一个环节。
安灯系统最重要的是让每一个员工都有质量意识，软件开发团队的中的成员往往就缺少这种意识，为了能早点完成任务，常常忘记完成这些任务的最终目的。
在这里分享一个小故事：
从本职工作来说两人都完成的挺好，但没有价值。仔细想想一想，我们有时候是不是就像上面挖坑的人或是填坑的人一样？所以团队的每个人都应该为结果负责，都要能在适当的时候勇敢地拉下这个信号灯。
持续交付在实践过程中离不开自动化工具，大体可以分为自动化构建和自动化测试。
不同大小的公司，或者处于不同阶段的团队，会采取不同的工具，适合自己的才是最好的，之前写过的几篇文章可以给大家参考：
1、GitLab 配合 Jenkins 打造自动化部署 2、在团队中使用 Gitlab 中的 Merge Request 工作模式 3、在 CentOS7 中安装 GitLab 4、敏捷下的需求和代码分支管理 5、不断进化的分支和需求管理
在上面的文章中有介绍我们是采用 GitLab 的 Merge Request 模式，对应到书中的分支策略，就是是主干开发，主干发布，因为每一个 Merge Request 分支的周期非常短，最终还是合并到主分支进行构建发布。但这种方式有一个问题，当同时并行任务过多时，合并时容易混乱。后面会尝试主干开发，分支发布的方式。
自动化测试大体可以分为单元测试和端到端测试，单元测试对开发人员的要求比较高，要保证持续交付高质量的产品，单元测试非常重要，我们现在也在规划和完善。
端到端测试目前已经在使用中，在之前的文章《端到端测试实践：Jenkins 集成TestCafe 》有所介绍。
持续集成2.0这本书中有很多的干货，本文我只是找了几个我认为比较重要的点进行了描述，总之就一个目的，我们要快速地、正确地、高质量地把任务完成，并交付客户。
