两年后重读“凤凰项目”，我又有什么感悟
2019-12-09
来源： DevOps 姚冬
，而堵点前面都是要截流的，有交警敢敞开了放行么？
约束理论TOC
第一是确认约束点，这是大前提，如果约束点认错了，你懂得，”在瓶颈之外的任何地方做出的改进都是假象“；
第二是利用约束点，高效的利用约束点；利用约束点，并不意味着单纯的提高约束点的资源利用率，资源利用率是局部的优化，局部的思维方式，而精益/TOC，需要的是全局思维，更看重的是系统整体的吞吐率，即流动效率。“在产品开发中，我们的问题几乎从来不是停滞的资源（或不动的工程师），而是停滞的产品需求（用户价值）”，让价值流动起来。
第三是把约束点置于次要位置，Drum-Buffer-Rope，鼓点-缓冲-绳子，从高德拉特的TOC到大卫安德森的看板，同样一脉相传。
构建为运营而设计的系统，把非功能性需求考虑在内，包括要考虑易部署、安全性，并且可测试、可验证、会反馈。
关于”已完成工作“的定义Define of Done，同样的，需要考虑端到端，不只是编码完成、各类测试通过，同样要包括部署、运维完成，正常运行。此外，产生预期的业务价值或是业务反馈，也应该在DOD内。事实上，从一个DOD入手，就能深挖出DevOps的思想精髓。
第二步：
建立价值流各阶段自右向左的快速持续反馈流，放大其效益以确保防治问题再次发生，或者更快的发现和修复问题。缩短以及放大反馈环路，从而在源头解决质量问题。这样我们就能在所需支出获取或潜入知识，从源头上保证质量。
必要的做法：在部署管道中的构建和测试失败时“停止生产线”；日复一日的持续改进日常工作；创建快速的自动化测试套装软件，以确保代码总是处于可部署的状态；在开发和IT运维之间建立共同的目标和共同解决问题的机制；建立普遍的产品遥测技术，让每个人都知道，代码和环境是否在按照设定运行，以及是否达到了客户的目标；A/B Testing，蓝绿部署，滚动升级。
不做什么比做什么更重要，Say No，无论是对人或事。系统中最大的浪费恰恰是开发了没人使用的功能。越快把功能推向市场接受考验，就越能获取反馈，消除不必要的浪费。
精益要求对用户的响应速度要快，用户的需求从进去到出来的时间要短，绝对速度要高，要有明确的衡量指标。同时，更要拼相对速度，相对于市场，相对于竞争对手。
精益的核心在于消除浪费，交付价值。如何消除浪费，很关键的就是需要从反馈中汲取经验，锻炼浪费以后能够快速识别出浪费的能力，同“反脆弱”一样的“反浪费”，不是不浪费，而是能从浪费中获益的能力。
关于“停止生产线”，借鉴精益生产中的Andon Cord 按灯拉绳系统，一旦发现质量问题，每个人都可以拉绳，也应该拉绳。按灯拉绳，不只是一个系统而已，背后是员工的责任感，主人翁精神，客户至尚的理念，以及安全感（知道任何拉绳造成的损失都不会被追究，反而被鼓励拉绳）。按灯拉绳不只是对外部客户，也同样适用于合作伙伴，以及内部团队之间，我们在亚马逊的领导力准则中也可以看到同样的思想。
第三步：
创造公司文化，带动两种风气的形成：不断创世，这需要承担风险并从成功和失败中吸取经验教训；理解重复和练习是熟练掌握的前提。
建立文化，技能鼓励探索，从失败中吸取教训，又能理解反复的时间是精通工作的先决条件。
必要的做法：营造一种勇于创新、敢于保险以及高信任度的文化，把至少20%的开发和IT运维周期规划给非功能性需
免责声明：
1、IT项目管理界发布的所有资讯与文章是出于为业界传递更多信息之目的，并不意味着赞同其观点或证实其描述。其原创性以及文中陈述文字和内容未经本站证实，对本文以及其中全部或者部分内容、文字的真实性、完整性、及时性本站不作任何保证或承诺，请浏览者仅作参考，并请自行核实相关内容。
2、本站部分内容转载于其他网站和媒体，版权归原作者或原发布媒体所有。如文章涉及版权等问题，请联系本站，我们将在两个工作日内进行删除或修改处理。敬请谅解！
-
延伸阅读：
-
