敏捷: 分工角色 大项目分小项目 每个节点时间设置里程碑
Scrum实施的核心可以概括为“化繁为简”，从几个维度解释下：
团队角色的定义，将团队人员定义为三个角色，Scrum Master（主要负责消除障碍，带领团队运作）、Product Owner（主要负责描绘产品远景，定义优先级）、Scrum Team（主要负责实现产品）
工作任务的拆分，将产品需求拆分成小的用户故事，并评估优先级
时间的拆分，将项目周期拆分成固定时长的迭代周期，每个迭代交付一部分可验收的功能，通常迭代长度为1到4周
精益:
原则1:消除八大浪费
企业中普遍存在的八大浪费涉及：过量生产、等待时间、运输、库存、过程（工序）、动作、产品缺陷以及忽视员工创造力。
原则2:关注流程，提高总体效益
管理大师戴明说过："员工只须对15%的问题负责，另外85%归咎于制度流程".什么样的流程就产生什么样的绩效。改进流程要注意目标是提高总体效益，而不是提高局部的部门的效益，为了企业的总体效益即使牺牲局部的部门的效益也在所不惜。
原则3:建立无间断流程以快速应变
建立无间断流程，将流程中不增值的无效时间尽可能压缩以缩短整个流程的时间，从而快速应变顾客的需要。
原则4:降低库存
需指出的是，降低库存只是精益生产的其中一个手段，目的是为了解决问题和降低成本，而且低库存需要高效的流程、稳定可靠的品质来保证。很多企业在实施精益生产时，以为精益生产就是零库存，不先去改造流程、提高品质，就一味要求下面降低库存，结果可想而知，成本不但没降低反而急剧上升，于是就得出结论，精益生产不适合我的行业、我的企业。这种误解是需要极力避免的。
原则5:全过程的高质量，一次做对
假如，团队整体的分工模式是错误的，那 DevOps 还是没办法消除团队内不同角色间的甩锅与填坑的；能为团队设计出正确的分工模式，是团队能开始协作的关键的第一步。
在 DevOps 的世界里，所犯下的最大的错误是：整天只知讲些文化、协作, 却完全将最重要、最关键，存储在 SVN, Git⋯内的开发人员的 “行为数据” 视而不见。在 DevOps 的世界里犯下这样的错误，将使得团队白白的耗费大量的人力、时间，只是照着 “ DevOps 的课本” 在演出一场 “DevOps 的行动剧”罢了；团队对于如何的持续改善团队成员的开发效率、产品的质量，还是茫然无知的。
不论团队是要导入 DevOps 、Scrum、SAFe、LeSS、Kanban, 都应该要从 “团队的现况” 与 “开发人员的行为数据” 开始。
所以，身为 DevOps, SAFe, Scrum, LeSS, Kanban 的教练、顾问, 都不应该背离了 “编程”，更不该对 “人类的行为模式” 是茫然无知的。
我们总是听到，DevOps 能提升效率、质量。
我们总是听到，不做 DevOps 就会面临被淘汰的命运。
但是，为何当我们每个人都认为 DevOps 是必要的同时，却很少有人会去怀疑，团队在 DevOps 的 Value Stream 中的集成测试，其实是不可信的？
就宛如我们总是听到，因为健康检查，而有多少人能及早发现、治疗了癌症；我们每个人也都认为每年的健康健查是必要的。
但，却很少有人会去关注，有多少比例的癌症病人当中，其实，是每年都有在做健康检查的？！
我们往往都太急于想在急速变化的IT 产业当中，去抓住一块 “浮木” 来获得安全感、专业感；其实，这块浮木，往往是连我们自己都感到茫然、感到陌生的。
为何在 Google, Amazon, Netflix 的内部永远都只专注在：人、架构、代码、自动化工具，而没跟风的去搞所谓的 DevOps, SAFe, Scrum, Kanban⋯却仍然能使得产品拥有质量、价值与竞争力？！
我并不是说 DevOps, SAFe, Scrum, Kanban⋯是没有用的。
我只是想建议，我们应该要 “颠倒” 下我们理解的思路；不要急着将在 DevOps, SAFe, Scrum, Kanban 中所学到的 “答案”，就直接的套在我们日常的软件开发当中。
相反的，应该是从我们日常的软件开发当中，去引导、去设计出我们所真正需要的 DevOps, SAFe, Scrum, Kanban⋯
