持续交付2.0读后感精选( 五 ) 交付|团队|双环|持续|敏捷|验证「问人人知识网」

在这个过程中，我们同样需要不断的改进和优化其中的细节，根据实际的运行情况做出调整，来让整个转变更好的持续下去。
当我们在过程中不断的实现里程碑时，或者最终实现既定的宏伟目标时，多给自己奖励，让自己收获「及时反馈」带来的兴奋与愉悦，为后续更好的投入做好准备。
《持续交付2.0》读后感(三)：提高产品研发生产力
几年前看过《持续交付(发布可靠软件的系统方法)》，感触不是很深，最近看了这本书的译者乔梁编写的《持续交付2.0》，结合工作中的种种，又有一种相见恨晚的感觉。可见好书是需要经常翻阅的，每次都会带来新的收获和思考。
全书围绕着双环模型展开，介绍了持续交付，快速实现客户业务价值的一系列的方法论和实践工具。本文将结合实际工作中遇到的问题来谈谈这些方法论和工具。
即便是再熟悉，再有默契的人，沟通同一个事物的时候也会产生理解上的偏差。我觉得在探索环中需要做到信息的一致性，即便不能完全一致，后面的验证环也能快速出成果给客户确认，因为足够小，可以及时地调整方向，把风险降到最低。
信息偏差不止是客户和我们之间，在团队内部也经常会出现，我们在安排任务时不管是口头描述还是有详细的文档，总会出现结果和期望有偏差的情况。樊登讲过的日本企业交代任务的方式我觉得可以尝试一下：
看似很麻烦，但可以确保双方的想法能达到一致，减少后续返工的风险，其实就是磨刀不误砍柴工。
开发软件的目的是创造客户价值，所以，我们不应该仅仅关注快速开发软件功能，还应该关注我们所交付的软件的功能正确性。
双环中有很多的步骤，每个步骤环环相扣，从探索环业务需求的输入到验证环产出可以运行到成果，这是一个闭环，这个闭环的周期越短风险就会越小。从输入到输出，整个流程像流水线一样运转时，效率是最高的。就像敏捷中的看板文化一样，随着时间的推移，一个个的用户故事从最左边逐步移动到最右边。如果中间某个环境出现堆积或者断层，都说明可能出现问题了，需要停下来解决。
最近一个项目中需要做数据迁移，由于数据量和迁移的范围非常大，项目经理召集了公司很多其他项目组成员进行协助，项目经理按照自己熟悉的技术规划了迁移方式，学习成本比较高，对于初级开发或测试人员来说，短时间内很难上手，导致进度缓慢。
后来我们领导提出了更合理的方式，就是将迁移任务根据技术的难易程度分解成了几个大的步骤，各种水平的人都有事可做，并可以很快上手，最终高效完成了任务，这就是流水线效率的体现。