第一原则：流动原则

• 描述的是开发到运维快速的、平滑的、能向 客户交付价值的工作流。

• 使工作可见

  • 在技术流中，价值的传递要比传统制造业更难可见。
  • 所以必须找到一些方式将在技术流中的价值传递变得清晰可见，比如在哪里流动，排队或停滞。
  • UAT测试（User Acceptance Test）用户验收测试。
  • image.png
  • 上图用一个工作板类似的思路实现了这个想法。
  • 其中每个任务也可以设定优先级。

• 限制在制品数

  • 制造业中工作任务是由定期的任务组成的，但是在技术工作中就出现了更多的不确定性，即比较动态。
  • 制造业中生产中断是代价很高昂的事情。因为他们操作的是实际的半成品，半成品被中断十分严重，在it中，尽管中断的代价很大，但开发的中断是个很常见的操作。
  • 所以在传统制造业中，你可以根据你最终产品的情况来选择总共同时进行多少操作，在it中，我们最好对任务板的任务数做一个上限，是3个就做3个，即使有人先完成，也可以等待，或者纠错帮助他人来完成另外的。

• 减小批量大小

  • 关于小批量和大批量之间的巨大差异，James P. Womack和Daniel T. Jones在《精益思想》一书里，通过“模拟邮寄宣传册”的经典案例进行了说明。这个例子假设要邮寄出10本宣传册。邮寄之前，每本宣传册都必须经历4个步骤：折叠，插入信封，给信封封口，盖戳。如果采用大批量策略（即“大规模生产”），我们会对每本宣传册按顺序执行上述4个步骤。换句话说，首先要将10张纸全都折叠完，再将每张纸分别插入信封，然后给所有的信封封口，最后全部盖章。另一种方式是小批量策略（即“单件流”），即对每本宣传册顺序地执行所需的所有步骤，然后再开始处理下一本宣传册。换句话说，先折叠一张纸，将其插入信封，再给信封封口，之后盖章；然后，取下一张纸，并重复以上过程。
  • 小批量和大批量的一大区别在于，小批量的第一个产品就绪的时间很早，这在it中是很好的事情。
  • 小批量也要比大批量更早的发现产品错误，这在it中也很重要。
  • 假设我们定了一年的开发任务，然后在年底突然大量上线，大概率会遇见一大群乱七八糟的错误。

• 减少交接次数

  • 这里就是字面意思，具体怎么减少我一点也没有概念。

• 持续识别和改善约束点

  • 在任何价值流中，总有一个流动方向、一个约束点、任何不针对此约束点而做的优化都是假象。
  • 如果我们优化约束点之前的那个工作中心，那么工作必将在这个约束点上更快地积压起来。反之，如果优化约束点之后的工作中心，那么它还会处于饥饿状态，等待约束点处工作的结束。对于这种现象，Goldratt博士给出了解决方案，定义了如下“5个关键步骤”：识别系统的约束点；决定如何利用这个系统约束点；基于上述决定，考虑全局工作；改善系统的约束点；如果约束点已经突破，请回到第一步，但要杜绝惯性导致的系统约束。
  • 环境搭建：如果生产或搭建总是需要数周或数月，则按需部署就无法实现。解决措施是按需建立完全自服务的环境，保证团队在需要环境的时候，能通过自动化方式创建。
  • 代码部署：如果代码的部署需要花费数周或更长时间，那么就无法按需部署。 解决措施是尽可能自动化部署的过程，以便让任何开发人员都可以按需自动化部署。
  • 测试的准备和执行: 如果每次代码部署都需要两周的时间来完成测试 环境的准备和数据集的配置，手动执行所有的回归测试还需要另外四周时间，那么就无法实现按需部署，解决措施是实现自动化测试，这样才能安全、并行地执行部署的同时，使测试的速度能跟上开发的速度。
  • 紧密耦合的架构：如果架构是紧密耦合的，那也无法实现按需部署，因为每次要做代码变更时，工程师都不得不从变更评审委员会里获得执行变更的许可。解决措施是创建松散耦合的架构，这样开发人员才能和安全、自主地进行变更 ，提高生产力。

• 消除价值流中的困境和浪费

  • 半成品：它指的是价值流里任何还没有彻底完成的工作（例如，需求文档或尚未审核的变更单）、处于队列中的工作（如等待QA审核或服务器管理员审核的工单）。部分完成的工作会逐渐地过期，随着时间的推移最终失去了价值。
  • 额外工序：在交付过程中执行的、并未给客户增值的额外工作，可能包括那些在下游工作中心从没使用过的文档，或是对输出结果做出的并不增值的评审或审批。额外工序不仅增加了处理的工作量，还增加了前置时间。
  • 额外功能：在交付过程中构建的那些组织或客户完全不需要的功能（如“镀金”[插图]）。额外功能增加了功能测试和管理的复杂度和工作量。
  • 任务切换：将人员分配到多个项目和价值流里后，他们需要进行上下文切换，并管理工作之间.
  • 等待：由于资源的竞争而在工作之间产生了等待，这将增加周期时间，延迟了向客户交付价值。
  • 移动：信息或数据在工作中心之间移动的工作量。例如，在一个需要频繁沟通的项目里，团队成员实际上不在一起办公，无法坐在一起紧密协作，这时人员移动的浪费就产生了。另外，工作交接也会产生移动的浪费，需要额外的沟通来澄清所有歧义的部分。
  • 缺陷：由于信息、材料或产品的错误、残缺或模糊，而需要一定的工作量来确认。缺陷的产生和被检测出来的时间间隔越长，解决问题就越困难。
  • 非标准或手动操作：需要依赖其他人的非标准的或手动的工作，例如使用不能自动化反复重建的服务器、测试环境和配置。理想情况下，任何依赖运维团队手动完成的操作，都应该配置成自动化的、按需提供的，或者是自助服务。
  • 填坑侠：为了实现组织的目标，不得不把有些人和团队置于不太合理的处境，这甚至会成为他们的家常便饭（如半夜两点生产环境出现事故，连夜给软件版本提交了上百个工单）。