DevOps看板度量

信息雷达是什么？信息雷达是你站在看板前面，你走过去，你会看的第一个地方，它透露出一种辐射的味道，你走过去自然的就会看它。
这句话里面最清楚的信息雷达是你的需求，你会发现你的需求在一直往上调整，然后掉下来，后来又拉上来，最后又急起直追，一直往上，这代表需求做不完。

第一个是范围增加，第二个是WIP增加，你会看到时间轴，这是分析，这是开发，这是测试，开发完了交给测试，最后这个空间越来越大，代表开发和测试脱节了。
所以突然间拉下来就是有需求不见了，为什么需求会不见了呢？因为工作都放回去了，不需要做，或者说它的重要性不够。

敏捷开发是一种快速的开发方法吗？不是。
为什么叫敏捷呢？因为它是应变需求变化非常快速。
你们的开发有需求变化这么快速的吗，通常不会有这么大的变化。如果你使用看板的话，你就会很清楚，最有趣的是这种现象，有两条线会合在一起。
例如测试在忙别的事，开发人员追上了，通常都是开发人员追上测试人员，或者是快速接近，因为太简单了

敏捷开发最有趣的是什么？当初定的时候是2011年，它只有Dev，没有Ops。
你们在公司有执行敏捷开发的，是不是进入了Ops了呢？你在公司执行敏捷的时候，业务部门有没有加入你的开发团队？没有。
你的开发团队独立运作，然后发布给运维团队，请问需求团队算不算是敏捷开发人员？算。
所以敏捷开发每次是从Dev开始，但是后面的Ops没有进来，开发团队做得很高兴，慢慢的运维团队进来，DevOps出现了，然后精实开发就把它列入进来。

真正要敏捷化，走到精益，再走到系统思维，需要很长的路线，不仅是AIOps要出来，后面还要把需求再拉进来，把需求拉进来以后，后面还要到业务的团队也加入，这样会得到快速回馈。快速回馈以后，然后我们学习、做调整，这是持续调整的方式。
你需要知道的实际上就是利特尔法则，你的生产效率等于存活数量除以周期时间。

开发的人再多，能力再强，如果没有一个好的需求，意义也不大，需求决定产品的价值在哪里，所以需求要不要有需求看板？一定要。很多团队在成长，需求太多，但是还是被骂产能太差，只有一种还行不被骂，就是需求都写得很棒，你只要做一两个很棒的需求，开发团队就表现得很好，所以要严格要求你的需求，怎么要求你的需求？度量它。

连在一起非常难，一个企业的战斗能量在这里，如果我们真的实现这三个连在一起的时候，企业的战力就变成可衡量的。