首先感谢wang jun关于《敏捷DevOps成熟度模型》分享，受益匪浅。在这里我也分享一下我的DevOps实践经验。
我刚开始接触DevOps的时候还是在2016年，在公司范围内我算是比较早期的一批学习实践者。刚开始最印象深刻的就是运用GitLab, Jenkins配置了CI/CD，实现了自动编译自动部署。它简直是在开发与运维之间巨大的一道鸿沟中搭建了一座桥梁，解决了发布过程中可能遇到的各种风险问题，实现了开发运维的敏捷。那个时候我主要负责的是容器化、资源调度平台等方面的工作，也在工作了总结了一套CI/CD的流程。
那个时候并没有接触Agile敏捷开发，采用的还是瀑布开发模式，主要工作重点依然是写代码，也并没有项目管理方面的经验。刚开始画以上流程图的时候，觉得自己很牛，觉得自己现在做的东西比较先进比较自动化。现在看起来，以上的流程图明显有局限性或者说不够敏捷。
1. 首先，以上流程图的立脚点是Developer。那么Developer从哪里获取需求，这里没有说。从瀑布开发模式来讲，Developer的需求来自PM，来自需求规格说明书，他面对的就是各种各样页面，原型设计图，他不会去思考这样对不对，也不会与PO沟通。那么他只合照本宣科，专注自己的部分，工期是2年，那最后做成什么样他不管，按时完成他的部分就可以了。
2. 注意看以上的流程图中的测试部分，这里并没有自动化测试。那么问题来了，我都配上了CI/CD了，那为什么我们不配置自动化测试呢？当运维人员终于摆脱了小心翼翼枯燥部署的日子，测试人员还在像原始社会一样一步步手工测试的时候，难度他们不想让测试也能更敏捷一点吗？
3. 敏捷的重要思想就是要快速得到市场的反馈，从以上图中也并没有提到。《持续交付2.0》这本书中提到的双环模型。
第一个环被称为探索环，主要就是搞清楚客户背后真实的业务目的，不只是要实现什么，怎么实现，而是要了解背后真正的原因，才能给出更合理的解决方案，通过沟通讨论出一个最小的可验证方案，以便能快速验证可行性。
第二个环被称为验证环，验证环的主要工作内容就是以最可靠的质量和最快的速度，将最小可行性解决方案从描述性语言转换成可运行的软件包，并将其部署到生产环境中运行。
双环中有很多的步骤，每个步骤环环相扣，从探索环业务需求的输入到验证环产出可以运行到成果，这是一个闭环，这个闭环的周期越短风险就会越小。从输入到输出，整个流程像流水线一样运转时，效率是最高的。就像敏捷中的看板文化一样，随着时间的推移，一个个的用户故事从最左边逐步移动到最右边。如果中间某个环境出现堆积或者断层，都说明可能出现问题了，需要停下来解决。
我想只有这样才能形成一个敏捷文化的社区。让我们为敏捷社区贡献自己的力量吧。
