这一章中提到技术价值流，其定义为：把业务构想转化为向客户交付价值的、由技术驱动的服务所需要的流程。其实我觉得这个概念是脱胎于制造业中的精益管理。
定义里面提到的“向客户交付价值”，这里蕴含了客户对所交付产品/服务的两重要求。第一，快速，马上能用（尽管功能不全），能马上为客户带来业务价值；第二，稳定，不会产生混乱和破坏，如服务中断、性能下降等问题。从这两个方面看来，它天生就跟敏捷是一对couple啦（只是，agile更多是偏重于管理实践，devops更多的偏重于工程实践，个人愚见）。
回顾一下以前的瀑布，requirement analysis->design->build->test->deployment->release，整个流程很长，这会造成对客户和开发都带来很坏的影响，尤其现在互联网产品研发更为突出，因为需求模糊，易变。首先，整个项目其实大部分的时间都是给到BA进行需求分析与文档确认，实际留给开发和测试的时间是严重不足，就更加罔论提升交付质量（毕竟交付质量与开发时间根本就是相爱相杀的一对好基友），最后就造成了开发团队跟业务在互相扯皮究竟是需求不清晰还是代码缺陷，内耗特别严重（本人不堪的工作前10年也理所当然的陷进这种天坑）；第二，业务要等上漫长的时间才能收到产品的交付，这势必影响业务的快速开展和市场占领。这样势必会产生敏捷这种小步快跑的模式。
在精益社区里，前置时间与处理时间都是度量价值流性能（我个人感觉叫效能更贴切）的两个指标。
“前子置时间”就是在工单创建后开始计时，到工作完成时的时间段，其实就是等于需求经双方确认后到需求可以交付的时间段；“处理时间”就是从实际开始处理这个工单时才开始计时到完成时间，它不包括在工作队列中等待的时间，其实就是开发人员在开始编码某个需求开始时到可以交付的时间段。
因此，我们的目标是缩短前置时间，例如分钟级别的前置时间，毕竟客户能够体验到的就是前置时间。这样的话，我们就需要减少需求队列的长度，快速开发，快速部署及交付，这样就跟DevOps的三部工作法的出现是不谋而合的。
实现开发到运维的工作快速从左到右流动，减少每批次大小和等待时间，同时通过QA等一系列措施来提升内建质量，杜绝向下游渗透；在从右往左的所有阶段中，应用持续、快速的反馈机制。在整个闭环不断发现问题，修复问题，类似PDCA工作流一样，能够给组织创造出学习与改进的机会；建立具有创新意识和互信的团队氛围，让团队不断自我进化，逐步达到自我管理的境界。