按照DevOps流程图去创建工具链和工具流程，然后用DevOps成熟度模型去去检验实施的程度，不就实施了DevOps吗？但是实践当中我们会遇到各种各样的问题，他们来自不同的维度。
比如按照阻力来源，可以划分成这个来自组织层面，还有团队层面以及团队内部的各种各样的问题。另一个维度，组织规模的不同也会有不同的问题出现，那怎么办呢？我们现在也能够获得一些建议，达成共识很重要，需要去打通各个角色，实施交付流程。如果难于共识，可以选择一个合适的范围去推进，分析利益相关方确定变革的阻力，也可以引入约束理论分析阻力的等级。
还有，为了减少研发人员的这种情绪，我们把推进DevOps叫做DevOps改进，而不是DevOps转型，让大家慢慢去适应，变得主动去接受DevOps的拥抱。还有，就是选择小的切入点，选择一个试点团队，再进行经验的复制，然后把这些实践标准化，形成一系列标准化文档，包括推广教练，敏捷教练等等。
但实际上我们仍然很迷惑，比如有些实践完全是矛盾的。比如有的企业认为切入点要选择最容易突破的点。但另外一种情况是，如果已经聘请了外部DevOps顾问，为了效果的显著，我们就想去选择问题最多的团队作为实验田，这样会有最明显的效果，这明显是相互矛盾的一个选择。
再有想要一个高效协作的团队时，需要去消除这些障碍，比如竞争排名，个人奖励，分布式团队等。还有一种说法，觉得比学赶超的团队气氛也不错，这些建议其实都是有些相互矛盾的。
那么有没有一套系统的方法能够指导DevOps的落地呢？有没有一个比较全面的模型让我们参考？
进入到我们今天的主题敏捷流畅模型。它主要描述了三个问题，让敏捷团队了解可以获得哪些益处，为了获得这些益处需要做哪些投入，以及如果没有达到预期，从哪里去着手检查。
区间选择
敏捷团队在学习过程当中，会经过四种不同的区间，每一种区间都会获得特定的收益。团队从预敏捷开始，通过改变团队的文化进入到“聚焦”区间，最终团队会产生业务价值，再通过转变团队技术及职能进入到“交付”区间，最终团队根据市场节奏进行“交付”，再通过转变组织结构进入到“优化”区间。最终，团队引领市场，通过组织文化的转变进入到延伸区间，团队使组织变得更加强大。四个区间每个区间都依赖于一系列敏捷技能的熟练程度，熟练程度反映在可以被观察到的行为上。
通过这些行为，团队能够获取当前区间的特定收益，比如通过学习测试驱动开发，DDD能够提高代码的质量。在敏捷流畅模型中，我们关注流畅的熟练程度，这是最关键的。也就是说，在任何期间，即便是在压力下面，也会习惯地表现出这种熟练程度，但真正的流畅是娴熟的自然的，即便有一些其他的事情让你分心，也会持续地运用这些技能。
敏捷开发是一种团队活动，流畅性是一种团队属性，所以在实践中，某些技能的熟练程度将由所有的团队成员展现，有些会是个别成员的专长，但无论哪种情况，团队的流畅性都来自于团队成员的自组织能力，也就是在适当的时间内，每个成员用敏捷的技能来做正确的事情。
敏捷流畅模型≠成熟度模型
当团队对一个区间中所对应的所有敏捷的技能都能达到流畅的程度时，我们说这个团队在这个区间就达到了流畅。每个流畅区间都有自己的收益，这个模型很容易被看成是一个成熟度模型。对于成熟度模型，成熟度是越高越好，可以比作是汽车拉力赛，他的目标是越远越好。流畅模型描述的是一系列选择，每个流畅区间都代表着一个完全成熟的选择，每个区间都带来价值。
流畅模型可以被比作坐公交车，上车时根据目的地去买相应的车票，每个流畅区间都有其价值，同时也带来挑战。过多的投入会导致组织的抵制，甚至会影响人们对敏捷的接受程度。所以说哪个区间适合于你的团队，取决于你的组织。交付区间和优化区间通常是最佳的选择，但是聚焦和延伸也可能是适合的。
“聚焦”团队产出业务价值
聚焦区间代表了敏捷的基础，在这个区间里面，流畅的团队在透明度和团队合作上非常突出，虽然聚焦区间不包含可持续性的技术实践，但并不妨碍聚焦区间的成功，聚焦区间也适合一些不需要长期维护软件的团队。比如一些数字营销公司，交付区间代表着敏捷可持续性，它的典型特征是交付缺陷非常少，团队具有很高的生产率，能够快速响应业务需求，对于那些需要花费几个月去修改维护软件的团队，交付流畅区间通常是一个好的选择。
在这个区间达成流畅对于大多数团队来说，都会是有价值的飞跃。优化流畅区间代表了敏捷的承诺，就是创新业务，敏捷性，尽管它有巨大的回报，但是它也要求对组织结构进行颠覆性的变革，希望引领市场的或者预见到市场混乱威胁的组织，将受益于选择优化流畅区间。
小型或者是灵活的组织当中，对这些变革通常容易实施。延伸空间，可能是敏捷的未来想要创新管理理论和实践的领导者，以及特别想尝试最前沿的敏捷实践的中小组织会发现延伸区间最适合他们的团队。尽管团队可以以任何顺序去培养其技能的熟练程度，甚至可以同时开展实践多个区间中间的技能，但是我们发现团队更倾向于以一种可预见的顺序来获得区间的流畅性。
想说明的是，即使在同一个组织当中，不同的流畅区间也可以适合不同的团队。那如何达到流畅？我们说流畅性与其说是一种技巧，还不如说是一种习惯。虽然培训可以传授基本的技能，但是对技能的掌握达到流畅的关键，是刻意的，需要反复思考和日复一日的练习的，它是通过在实践中不断的学习获得。与前置区间相比，后面的区间对应的技能需要更长的时间来培养熟练程度，团队越早开始提高区间的熟练程度，就越早达到流畅，不同区间的敏捷技能熟练程度是相互促进的。
因此这里的最佳实践就是选择了要流畅的区间以后就同时开始培养该区间和前置区间中所有技能的熟练程度。当然是可以改变主意的，先从一个区间开始，再尝试别的区间也是可以的，只是需要更长的时间达到流畅而已。
影响团队流畅性的最大因素之一就是组织的支持。让我们继续用公交车的比喻，团队必须要坐公交车达到他们的流畅区，没人能够替代他们，但是组织得为他们买车票。一个期望团队达到流畅但又不提供适当支持的组织是让人失望的，更糟糕的是，支持不足会导致团队成员的离开，造成一种愤世嫉俗的企业文化，从而阻碍进步。
所以，在开始流畅之旅之前，要确保组织已经准备好提供所需的支持，达成共识是非常重要的。组织将做出的最大投资就是时间，达到真正的流畅，需要的时间比任何人期望的都要长。根据经验来看，团队需要做到两到六个月的时间才能在聚焦区间达到流畅。而根据代码中技术债务的多少，团队需要另外的3到24个月在交付流畅区间内达到流畅。优化区间可能需要另外的一到五年，具体取决于团队的组织信念和改变组织结构的意愿。扩展区间需要的时间就很难确定。
稳定的团队很少会自己失去流畅性。根据经验是，外部因素干扰导致了流畅性的丧失。失去流畅性最常见的原因就是，新领导层决定敏捷方法不适合他们的愿景，没有组织支持的话，不能够继续实践所学的知识，团队的流畅性会迅速削弱。
随着专业知识的丧失，可能导致团队成员不满而寻求新的职位，员工的流失是导致流畅性损失的关键因素。一个团队如果增加或者流失过多的成员，很有可能会很难维持所学的技能。
组织流畅，要在规模上具有流畅性，就必须在每个团队当中具有流畅性，这是因为组织的工作是由内部的团队相互协作来完成的，因此，组织流畅性来自于团队。团队不能自己达到流畅，但是个人和组织可以为团队的流畅程度作出贡献。
讨论组织对团队流畅性的促进确实是有意义的，因为团队的流畅性不仅取决于团队成员的技能，还取决于管理结构关系和组织文化等等。不要把团队缺乏流畅性归咎于个人，或者假设一个高技能的人就能够确保团队的流畅，因为组织背景往往更重要。当一个团队在培养流畅性过程当中遇到障碍时，他们通常会纠结于某几种流畅程度，有时候问题就在于缺乏知识或者技能，那么培训和指导是所有团队都需要的。
更常见的是，团队的发展是受限于组织约束的，可以通过多个团队进行流畅性的诊断，来检查组织的约束。同时多个团队在相同熟练程度方面遇到问题，则很有可能存在一个系统性的问题，需要组织级别的投资和变革。
“聚焦”团队产出业务价值
接下来我们进入“聚焦”的流畅区间。每个区间都提供价值需要投资，这里面我们关注的是挑战和投资，挑战是难点，也可能是突破点。对于很多管理者和组织来说，最具挑战性的投资不是金钱，让团队更加高效地工作需要改变管理习惯，要让团队的成员全职投入到团队的工作当中。比如说需要重新设计工作空间，特别的是，经理们需要从管理成员的贡献转变为管理工作系统，指导团队的流程，工作习惯，培养技能等等。这样，团队在没有管理层的明确参与下，也能做出正确的决定。
很多的组织不愿意做出这些投资，却依然期待团队达到流畅。这种情况下，团队的流畅程度发展很慢，很难达到完全流畅。
这里列出了一些可能的投资方式。第一，选择具有相应的技能、背景和合作意愿的成员，将他们百分之百分配到团队当中。第二，创建以生产力为中心的共享的工作空间，一个实体空间是非常推荐的。如果不可行的话，可以提供丰富的虚拟的交互的方式，同时接受相对较低的效率。管理人员职能的转变，需要去考虑指导团队的流程等，而不是仅仅考虑考核的贡献。第三，打造强有力的教练和培训团队。第四，消除影响团队高效合作的障碍，比如竞争排名，个人的奖励和分布式团队等。这里的投资建议需要团队自身根据情况来采用，千万不能够生搬硬套。
“交付”团队按市场节奏交付
我们进入到“交付”流程区间，仍然是关注挑战和投资。挑战可能就是我们的突破点。交付区间的特点就是技术密集型，有很多的技能需要去学习，有些虽然学得快，但需要很长的时间来掌握。比如说测试驱动的开发（TDD），团队成员将受益于这些技术技能，包括把极限编程，DevOps、敏捷软件质量专家所描述的各种技术。区间的挑战是什么呢？
团队成员需要时间和精力学习技能，才能发展到一定的流畅程度，交付流畅性通常出现在聚焦流畅性后的3到24个月。具体取决于团队接受的辅导量以及代码库中的技术债务的数量。如果是有巨额的技术债务的大型系统，可能需要更长的时间。区间投资包括在团队成员学习新技能的同时，接受一段时间内工作效率的降低，以及如何去控制降低的程度。
将非编程技术的知识和能力集成到团队当中去，比如说质量管理和运维的能力，提供敏捷技术实践方面的培训，聘请经验丰富的时间教练来指导团队的现实工作。尽管成本高昂，交付流畅性的好处巨大，要偿还之前的技术债务需要时间，但一旦还清了，你就能够看到更短的开发时间，更高质量的软件，以及显著提高的响应能力，团队就有更多的时间来交付新的产品特性。
我们做一个简单的回顾，这个是敏捷流畅模型的详细的图，它包含四个承上启下的流畅区间，引入了流畅度的概念，它是衡量敏捷实践优劣的重要度量指标。每个区间都会带来不同的价值，需要不同的投资。这个模型同时也提供了未达到预期的时候从哪里入手检查，这里面我们在选定了流畅区间以后，更加关注挑战和投资细节。
第三部分给大家分享一下DevOps工具链的一些案例。
这是一家上市的国际物流企业，整个工具链的打造，有业内成熟的产品，也有些开源工具。Clair是镜像漏洞扫描工具，还有Nexus制品管理，这里面使用了开源的Nexus制品管理库。还有像Maven、Junit、sonarQube这些都是很熟的工具。
这个是灵雀云在一家国有能源企业做的DevOps实践，使用了灵雀云的产品，主要集成了Jira、Confluence、Gitlab等。
联系客服
