导言：
在许多工作场景中运维经常遇到的很多问题实际上和研发、质量、测试是有关联的，运维作为产品交付的最后环节遇到的很多问题其实和研发遇到的也非常类似。于是我向廖君仪老师询问能不能把敏捷看板带到运维团队内部，使用敏捷的方法来解决这些问题。
接下来我们会从上到下跟大家分享以下五部分：运维面临的挑战，敏捷开发方法，还有我们的运维看板，以及敏捷软件生命周期，最后是我们的结论：运维也可以敏捷。我们希望通过这次分享向大家交付两个内容，第一点，理解敏捷是什么，第二点大家回去后能尝试进行看板实践。
运维的挑战
运维到底能在DevOps里面做什么？这其实是在解决DevOps在运维部门如何落地的问题，也是在解决怎么横向在部门之间扩散的问题，作为一个质量部的负责人和作为运维部门的负责人，相互之间怎么合作，怎么做这个事情？
先来看看运维的发展方向
大家都知道运维的发展要经过这么几个阶段，标准化、流程化、自动化。但是这样分类太过于局限性。因为我们很多公司的运维部门在很多时候都会面临一个问题，就是我没有达到最终自动化之前，那我该如何更优雅的过渡呢？
在我们看来这其实是一个复利的问题。
我在运维工作中会遇到紧急的问题和重要的问题，这就考验我们如何高效处理紧急问题。因为只有更高效的解决掉紧急问题，才能腾出更多的时间精力来解决重要问题。比如运维部门持续不断的减少紧急任务的处理时间，持续不断的优化工具，比如跟质量部门一起在公司把整个产品交付做得更好，这就是我们运维在DevOps里面的定位。
那我们看一下运维走向终极目标前会遇到哪些问题
第一个，常见的任务反馈不及时，导致呈现出来“效率不高”。
第二个，紧急任务繁多，严重挤压到重要任务完成进度。基本上运维整年都是一样，一年到头发现我们部门没有什么变化。
第三个，虽然很忙，但是无法改变平行部门的评价“效率不高”。到年底的时候，各个部门的领导都非常揪心，因为平行部门经常会评论“运维部门效率高不高，我只能给你打很低，因为好多时候你反馈非常慢。”
第四个，任务被严重挤压，而且没有办法量化，化解。
第五个，任务的风险经常被“侥幸心理”带进项目里。
第六个，运维人员的个体能力、经验差异、经常会偷偷的给团队带来风险。风险难控制。我们团队里面都存在一些英雄，我们非常崇拜一些英雄，经常在关键时刻帮我们团队化解危机，但是往往当我们对英雄依赖变得很强的时候，英雄一旦离职，可能这个部门某一段时间就会遭受很大的打击。
Ok，带着这些问题我们看看是否只有运维团队遇到这些问题，是否其他部门也遇到过，他们是怎么解决的呢？
实际上在这个图里面，对比运维交付跟产品交付，虽然呈现出来阶段是不同的，但是我们仔细想里面隐藏的关联和矛盾性，产品交付和运维交付里面都是存在的。而产品交付过程中敏捷起到至关重要的作用，那敏捷是否可以同样解决运维的问题呢？我们先了解一下什么是敏捷。
大家看到敏捷这个词的时候，首先会想到什么？大部分的人可能想到提高效率，通过很快的发布，还有降低成本，提高质量这些，但是我要说的是，这些东西其实都是我们目前看到的，这个只是敏捷可能带来带来的一些结果。
但是敏捷到底是什么意思？敏捷最开始的解释是”flexibility灵活性”的意思，发展到现在业界对于敏捷的公认解释是:是灵活而优雅。
敏捷的流派
开始认识敏捷的时候，我们会面临很多的敏捷的流派，比如说精益、敏捷与Scrum、看板还有XP。
我们看到上面外围的图片左边是一些精益思想屋，右边是敏捷宣言，外围的来看其实是一个思想和文化层面，就是在我们组织里做精益做敏捷都是有一些文化和价值观的东西在里面，里面我们可能看的比较多的就是Scrum，看板和XP的方法论。
Scrum是业界最流行的一种敏捷项目管理的框架，包括了一些敏捷的实践。敏捷的流行，Scrum功不可没，在最开始的时候，Scrum的一些实践和做法可以让团队很迅速的照搬一套初具样子的方法和实践。
Kanban 方法是近几年上升最快的敏捷方法之一，Kanban最早起源于丰田生产方式，所以它和精益的关系很紧密。 2004年Daid Anderson的小蓝书出现，是Kanban方法从制造业到软件业应用的一个转折点。
XP是90年代末最早出现的，最初是由13个工程实践组成的，也最受程序员的欢迎。后面我们会展开来讲一下敏捷最普遍的使用的三个方法论。
敏捷宣言
敏捷宣言可能大家都听说过，我可以讲一些历史，比如说2001年敏捷这个词怎么来的，是上世纪九十年代到这个世纪初的时候，在欧美有很多的软件方法学的流派出现，是对抗传统的大型软件开发的流程，出现的各种方法，比如特征驱动开发，水晶方法族，自适应软件开发，但是他们这些流派也是互相都有各自的特色，没有办法说服别人，怎么办？
在2001年的时候，这些大牛大概一共有17位大师凑到美国的盐湖城的一个叫SnowBird的滑雪场，做了两天的封闭式讨论，最后达成了一个敏捷宣言，其实方法论上也没有说服对方什么，你会发现现在还有很多敏捷的流派在这里存在，但是他们达成了一个共同的宣言，这个就是大家看到的这个敏捷宣言，个体的交互重于过程和工具，可工作的软件重于面面俱到的文档，客户合作重于合同谈判，响应变化重于遵循计划。
敏捷宣言发展到现在，其实有一点点的误解，就是一定要说的，我们强调的是左向的价值，虽然右向也具有价值，但是左向具有很大的价值，我发现现在很多的团队刚接触敏捷有一个误解，认为右边完全没有价值，其实不是的，做敏捷过程和方法的，从来没有说我们不需要过程和工具，不需要文档和计划。敏捷从来没有说这个。
精益思想
精益思想其实是比较复杂的，也有好几本书，最开始是从丰田生产方式起源的，我们用一个故事大家可能更容易明白，上世纪五六十年代丰田汽车想打入美国市场的时候，他遇到很强劲的对手是通用汽车，通用在美国是一个大规模生产的代表，大概是一个流水线生产几十万台车，推向市场，丰田用什么方式最后打败通用汽车的？
一开始丰田也是用了一些广撒网的方式做一些市场调研和设计，但是区别是当一个设计出现的时候，他并不是把自己的设计和产品大规模的推向市场，而是他用了一些小规模换模的技术，在同一个生产线上可以一次只生产几十台的汽车，在这种小规模的小批量生产上，他会很快的试错，以及当车销量不好可以及时的停止生产方面的浪费，那么如果销量好，就会持续扩大生产以达到一定规模生产。
最后用这种小批量的用市场反馈来指导生产方式远远超过了大规模生产的通用汽车，背后的原理是什么？具体的制造业的做法，我们不是需要太关注的，从制造业到软件业，我们更关注的是精益思想。精益思想的五个原则，我这边简单介绍下，有兴趣《精益思想》这本书大家可以看一下。
原则一：价值
首先要重新定义一个组织的价值，这个价值是去识别给客户带来的价值，从而去指导这个价值所需要的工序。原则二：价值流
其次，根据工序的画一个价值流图导向，只要跟这个新定义的价值没有关系的生产，都把它称为浪费。原则三：流动
第三点，我们根据建立起来的价值流图的指导让工序的流动速度越来越快。原则四：拉动
整个的生产方式是拉动的，并不是推动的。推动的意思就是我要生产什么东西，我设计生产开发测试到发布，这个是从前往后的推动的过程，拉动的过程就是客户需要一个什么零件，他直接到一个汽车零件的代理商那里去要一个零件，这个代理商会到丰田的工厂里去提交一个需求订单，倒过来去推我需要交付这样一个零件，那么我应该怎样做设计，怎样做生产，开发测试和发布。这样从后往前去走拉动的过程。原则五：尽善尽美
追求善美，从定义价值到拉动的生产，这四个原则我们不停的循环，通过不停循环的过程达到组织流程不断的完善以及追求尽善尽美的目的，组成了这个第五个原则，这个是有一点抽象的。精益思想的价值远大过于丰田的生产方式和丰田管理的具体做法，特别在软件业里面能用的地方要多的多，比如现在的精益产品设计，精益创业，和精益企业的一些方法。
Scrum
Scrum应该算是相对比较简单的一个部分，Scrum是一个项目管理框架，纯Scrum的方法目前创业团队还有之前所在的外企用的比较多，核心重点有一个时间盒的概念，在一个时间盒范围内，比如两周会发起一次冲刺。
在两周这个过程中会交付一些潜在的可交付的产品增量。在这两周的冲刺中，会有一些项目管理的实践。开始就是建立一些计划会议，就是迭代的计划，在这个过程会有每日站会，两周快结束会有一个演示会议。
最后团队坐在一起做回顾，大家看一下Scrum框架本身还是对于启动来说是比较简单的，也是为什么在最开始的时候敏捷能够迅速风靡全球，Scrum起到一个很重要的作用，因为他开始起来很简单。
Kanban
Kanban看板是今年来上升最快的一些敏捷实践方法，04年David Anderson出版的《看板方法》这本小蓝书把整个精益看板方法，从制造业第一次带到软件业做最全面的阐述开始的，近两三年看板方法非常热。
看板方法相对来说出来会晚一点，因为开始看板的方法是从制造业过来的，大家可以看到我们平时在白板写一些队列和泳道，上面的数字叫WIP下面有一个紧急的通道，红色的卡片这块，还有一个很重要的方法，就是流动。
刚才体现的怎么加快流动，当然看板方法并不是等于大家看到的看板墙，看板墙只是一个白板，而看板方法反映的一系列的方法，看板方法是通过这面墙改进流动。
XP
XP时间也很久了，是从上世纪九十年代开始的，是带有一些敏捷工程实践比较多的一些实践在里面
XP研发出身的人了解多一些，它是上世纪九十年代出现的比较早的开发实践，包括一些持续集成，结对编程，重构，代码集体所有等等。这些工程实践是现代软件工程的很重要的贡献。包括我们现在很热的持续交付，DEVOPS，离不开XP的铺垫。
敏捷开发方法选型
方法对比
我们给大家讲一下各种敏捷开发的对比，Scrum看有9种实践，XP有13种实践，而看板只有3种实践，我自己其实对于哪一个流派的优劣没有特别大的偏见，因为这是组织适应的问题。但通过对比我们还是能看出，看板在实践数量上要求要更少，所以适应性更强。
情景分析
我们公司（中交兴路）是做货运车联网的，我们有全国最大的货运定位平台，搭载460万的车，还有跟中石化合作发行柴油联名卡的项目，我进入这个公司，自己也是从外企完全做Scrum出身的，过来以后我就发现，我到这个公司做敏捷转型，如果只走Scrum可能走不通，因为有很多各方面的问题。那个时候刚开始看小蓝书，就想到了从看板方法开始。
选择看板方法
看板有什么好处？是可以带来一个渐进式变革的开始，但是现在我们大概有七八个团队都在用敏捷的看板，甚至有业务比较新的团队在用Scrum都用的不错，我们是听起来有点像国企的上市公司子公司。用看板转变是很好的办法，改变一点点，慢慢的开始，而不是一开始就上来一堆名词，PO,Scrum master，这些。
看板是一个非常好的启动变革的方式。当然其实你在接触多一些的敏捷的方法的时候，你会发现你看板走得好，你走到后面会越来越像Scrum。
看板方法-三大核心实践
第一步，是可视化工作流，有一个好处，你不用预设任何的流程，你就把你现在所在的组织开发的流程直接搬到板上，第一步就是可视化就可以了。
第二步，在制品（WIP）限制我们通过一些手段，比如说在制品的个数的控制，从上一个阶段到下一个阶段流转的规则，去调整整个看板的设计或者是给开发团队制定原则。
第三步，是整个团队的流动的速度的提高，以渐进的方法进行度量和管理这个流动，这是三大实践，后续我们会把这三大实践在我们的运维看板例子里详细的讲。
看板实践案例
先讲一下我们其他团队的看板，再进入到运维看板实践过程中，当然我也是属于何勉老师的忠实粉丝，所以我们公司的大部分看板的实践都结合了何老师的微信公众号的一些内容。
案例一、物理看板
这个看板是我们一个APP叫“车旺大卡”平台的看板，目前有一百多万卡车司机在用这个平台，看板上开发测试到完成的工作，这边都可以看到，有意思的是刚才说我们有一个待开发，这是缓冲区等待区的概念，我们在待开发的这些需求的过程，到开发的过程中，我们会把需求拆分成任务，拆分了以后我们测试环节又会合并，这样体现开发和合并的过程，左下角可能还会有一些废弃区，右下角是何老师的每日站会“非常6+1”实践的提示。案例二、电子看板
第二个是我们一个纯创业的团队，现在可能多了一个人，之前是六个人，这是我们定制的一个纯Scrum的看板，因为他们是创业团队，所以没有什么其他的旧的流程，完全是重新做，大家基本上接近Scrum。一开始在公司里当然有很多的物理看板在这里运行，目前电子看板的采用也越来越多。
我们的运维看板实践
问题一：常见的任务反馈不及时，导致呈现出来“效率不高”
首先我有一个故事场景给大家分享一下：
有一次领导跟下属在聊天，当时听到聊的挺好，后来领导话锋一转“上次跟你说关于服务器优化的事情有没有进展？”接下来的画面是：同事跟领导五秒钟的对视，说“那个事儿不就说一说，还要做吗？”…… 这种场景我觉得应该不罕见吧。
领导的想法太多，变化太快，下面的人跟不上，所以你不确定。任务的不确定因素太多，不是说领导变化太快，别尝试跟上，因为如果能跟得上，那你肯定就是领导了。
改进方法：
我们如何解决这个问题呢？这个时候我们需要一个看板，具备可视化。我们可以把领导跟我分配的内容记录下来，筛选一下，哪些是真的要做，然后贴在看板上。
看板上的任务卡写上达到什么目标，再跟领导确认实施时间。然后放到BackLog里面，领导就会知道你这个东西有没有做，有许多把我想的事儿放到看板上。如果领导改变主意了，那自然也可以再最短的时间内被取消掉。同时在每日站会进行确定和跟踪，这是看板第一点。
问题二、紧急任务繁多，严重挤压到重要任务完成进度。
这里也有一个场景跟大家分享：我们有集群，大家都知道集群里有一台服务器如果宕机，影响服务稳定性之后。作为运维第一个解决问题的原则是什么？原则就是先将故障的设备剔除出集群，并恢复服务，然后再找去问题。
但是集群中有问题的这个机器被剔除之后，由于原因比较隐晦，而且当时事情又比较多，接近一个月这个问题也没有找到。直到有一天一个同事说：“我今天在集群找到一个机器没有人用，太开心了，我们现在有一个项目没有资源部署，我现在捡到空闲的设备，刚好可以放进去化解一下资源紧张的问题”。
其实他不知道已经把一个地雷放到了另外一个集群内部。这就是问题没有解决，没有结论，没有跟进，没有持续反馈的结果，问题没有得到重视。还有就是一个任务的跟进太依赖于人。领导事情一多，这个事情基本上会拖，下属积极性弱一点，或者事情一多，这个事情同样会被拖，所以很糟糕。
改进方法：
这是我们目前在用的，我们会把我们所有的运维要做的一些事情放到看板上，看板又分几个类型：有虚拟化和持续交付、监控、自动化、安全、还有项目运维工具化，纵向也分几个区域。
以刚才场景为例子，我们就需要一开始将服务器的问题贴上去在BackLog中，并且会在每一天反馈，推进这个问题的同时进行跟进。同时在任务过期后我们需要怎么做呢？
这个时候会调整优先级，如果我发现问题一直没有人解决，会分给A同学，比如A同学手里已经有其他事情，这个时候就体现看板的价值了。我会把任务分给别的同学，这个时候内部资源能够得到调整，同时在看板上就可以体现出来。
问题三、虽然很忙，但是无法改变平行部门的评价“效率不高”。
作为支撑服务部门，由于没有管控工具，其他的团队提给运维部门的需求事件是容易产生积压的。而我们需要通过看板将其他团队的需要在板上体现出来，让他们很容易知道自己的需求到什么阶段，做到更快的反馈机制和方法。
而且有了看板以后很容易发现一些问题：有一些任务项长时间停留在doing里面，这就是所谓的堵塞。
比如我们一个安全部门说这次要做一个安全的实施。听起来很简单，但是任务卡滞留将近两周。原因是这个任务依赖于另外一个任务。而另一个任务的执行者是其他人。
改进方法：
当我们在追溯原因的时候才知道，执行者按照看板的理论中，他会自己选择更紧急的任务执行。这其实就是另外一个看板的原则：我们看板每天开会的时候不仅仅要描述我昨天做什么今天做什么，还要找出重点风险和阻碍的任务。
如果我这个任务卡被另外一个任务卡住了，那个就是阻碍，我要及时的提出来，这个时候我们应该及时的调整优先级，这样能够让任务的前置时间很短，能尽快进入到自己的过程。同时我们会增加WIP（Work In Process）的记录，也就是我们部门每一个运维人员手里不要超过三个事儿，因为要保持运维人员的聚焦。
因为系统工程师都知道上下的切换对机器来说是消耗比较小，但是对人来说是非常可怕的。如果你手里有超过三个事儿，基本上工作效率下降非常高。所以我们每个人手里三个事儿，如果超过三个事儿，我会尽量不让其他事情流到同事的手里。
看板帮我们目光聚焦在控制在制品上，其实控制在制品的概念就是我们理解部门在并行需求处理极限值，需要我们关注并行处理的合理值，在成员处理的效率和并行处理数量中找到平衡点，并不断的优化。保持任务项流动的更快。
这也是通过看板进行一个变革，一个改善流程工序，加快流动的最核心的基点所在。所谓短板效应，木桶的容量不取决于最长的那个木板，而且取决于最短的那个木板。看板最大的优势就是帮助你从系统层面用可视化的方法发现瓶颈并尽快的解决，以达到系统整个加速流动的目的。
问题四、任务严重挤压，但是没有办法量化、化解
