术语
ITI
GTD
TOC
Theory of constraints：约束理论/瓶颈理论
所有在非约束点的改进都是假象：在瓶颈之后做出任何改进都是徒劳的，因为只能干等<br>着瓶颈把工作传送过来；而在瓶颈之前做的任何改进则只会导致瓶颈处堆积更多的库存。(P78)
TOC（Theory of constraints），我更喜欢称之为瓶颈理论：任何系统至少存在一个制约因素/瓶颈，<br>系统最终的产出受限于系统内部最薄弱的环节。要想显著提高系统的产出，就必须找到系统最大的瓶颈<br>解决掉。所以，持续优化过程就是：<br> (1) 先找最大的瓶颈；(2) 最高优先级地解决掉这个瓶颈；(3) 然后再找新的瓶颈，重复上述步骤。<br> 这个过程渗透着3个问题：应该在什么环节改善？改善应该带来什么成果？怎样推行改善？<br><br> 我在百度工作的时候，大家都把自己的工作内容用便利贴粘到画板上，每项任务都需要提交<br>申请，通过在画板上的需求栏、执行栏、完成栏之间移动便签纸呈现项目各个环节的状态，不<br>仅让团队成员参与其中，还能清晰地展现出哪个环节最容易成为瓶颈。
三步工作法
约束点理论，等待时间，业务项目/IT运维项目/IT变更/计划外工作
(1) 确保工作流水线不要中断。比如，需求、开发、测试、小流量实验以及推全这些环节中有一个中断了，那就降低了整体的效率。
<br>(2) 出现问题，就要找到问题的源头，从根源上解决掉。比如，线上出BUG，根源很可能是系统code混乱到需要重构，不只是测试的问题。
<br>(3) 持续地尝试改进系统，不要把全部人力用在功能开发上，留有20%人力改进非功能性需求。
(1) 确保互相依赖协作的部门之间的工作流能够无缝衔接。如开发代码不断的在提交，但运维始终不能把代码部署上去，这就属于衔接出现了断节<br>(2) 部门之间出现问题，一定从找出问题源头，并从源头上解决问题。<br>(3) 养成习惯或氛围：不断的试错、实践，从实践中学习经验并成长。
# 第一工作法
<br>是关于从开发到IT运维再到客户的整个自左向右的工作流。为了使流量最大化，我们需要小的批量规模和工作间隔，绝不让缺陷流向下游工作中心，并且不断为了整体目标（相对于开发功能完成率、测试发现/修复比率或运维有效性指标等局部目标）进行优化。必要的做法包括持续构建、集成以及部署，按需创建环境，严控半成品，以及构建起能够顺利变更的安全系统和组织。
<br># 第二工作法
<br>是关于价值流各阶段自右向左的快速持续反馈流，放大其效益以确保防止问题再次发生，或者更快地发现和修复问题。这样，我们就能在所需之处获取或嵌入知识，从源头上保证质量。必要的做法包括：在部署管道中的构建和测试失败时“停止生产线”；日复一日地持续改进日常工作；创建快速的自动化测试套装软件，以确保代码总是处于可部署的状态；在开发和IT运维之间建立共同的目标和共同解决问题的机制；建立普遍的产品遥测技术，让每个人都能知道，代码和环境是否在按照设定的运行，以及是否达到了客户的目标。
<br># 第三工作法
<br>是关于创造公司文化，该文化可带动两种风气的形成：不断尝试，这需要承担风险并从成功和失败中吸取经验教训；理解重复和练习是熟练掌握的前提。尝试和承担风险让我们能够不懈地改进工作系统，这经常要求我们去做一些与几十年来的做法大不相同的事。一旦出了问题，不断重复的日常操练赋予我们的技能和经验，令我们可以撤回至安全区域并恢复正常运作。
<br>必要的做法包括营造一种勇于创新、敢于冒险（相对于畏惧或盲目服从命令）以及高信任度（相对于低信任度和命令控制）的文化，把至少20%的开发和IT运维周期划拨给非功能性需求，并且不断鼓励进行改进
第一工作法的关键部分，在开发部和IT运维部之间建立快速工作流，看板上的索引卡片是做成这件事最好的机制之一，因为每个人都能看到半成品。现在根据<br>第二工作法，你必须根除计划外工作的最大源头。
第一步，如何建立快速工作流
<br>第二步，如何缩短及放大反馈回路，避免返工
<br>第三步，文化，探索
类比
把it开发运维比做加工厂，一切还在开发中的未上线的版本，都是<br>积压在车间的半成品，不创造业务价值。这个比喻有种全新的视角。
