瀑布 敏捷 精益 devops

Posted 2021-02-10 gaoyuechen

敏捷:  分工角色  大项目分小项目   每个节点时间设置里程碑

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?