衡量：DevOps 架构下的人工智能思维
作者：互联网
分享：李智桦-91App 敏捷教练
编辑：白凡
我住在阳明山脚下，我每天起床都到这个地方，大概海拔800公尺左右，大概要55分钟到60分钟到。
DevOps 最开始要做什么？做计划。
项目开始第一件事情是看见全貌，这是今天所有的 PPT，我们在这里，我们要走到哪里？所以我们先以终为始来做这件事。
刚刚裴丹老师秀了很多的数据，AI 最重要的数据，指标要对，什么样的指标是好的指标？第一是可以比较的，第二是要简单易懂的，讲出来你就知道 AI 到底是怎么回事。
第三是它一定要是一个比率，我才可以按照它来做动作。
如果人工智能做了半天对你的行为没有任何影响，这是没有意义的。
第四个是最重要的，会改变你的行为。
一定要专业人士才可以做这件事吗？一定要专业人员才可以做 AIOps 吗？不需要。
虽然专业人员是最好的，但是我们现在不是专业人员，我们可以学习，不断地尝试、学习，你就会了，所以学习是一件很重要的事。
当你看见全貌以后，你要怎么办？ 你已经看到了项目的全貌了，你看到全貌以后会怎么办？ 全貌只有一开始的时候能看得清楚，等你开始做进去之后，你的眼光投入在哪一点，你就着重在哪一部分，然后你就看不见全貌了。 所以，当你看清楚自己在哪里以后，接下来怎么办？ 第一件事，你应该知道自己在哪里，你先要知道自己在哪里，你才知道从哪里做，你该学些什么东西，先知道自己在哪里非常重要，然后提出尖锐的问题； 只有在项目一开始的时候，你可以提出很尖锐的问题，不会有人怪你，可是一旦整个团队投入之后，就不能再提出尖锐的问题，要全力去完成它。 所以项目开始之初先知道自己在哪里，然后提出尖锐的问题。 这是一件不可能的事吗？可不可能达到？不提出尖锐的问题，就不知道我们要解决什么问题。 这是我习惯的开场，先让大家看到全貌。
0. 衡量
有一句有态度的句子讲，如果你不能衡量它，你就不可能管理它。
这是彼德·德鲁克说的一句名言，我是从《如何衡量万事万物》这本书里面看到这句话的，里面有很多衡量的东西来自这本书。
衡量的定义是：减少不确定性，优化问题的有效手段。你更了解这件事，我们就称之为衡量。
我们经常先入为主的认为很多事物是不能衡量的，但实际上不是这么回事。
在公园里面休息的时候看到一些妙龄女郎带着她的男朋友，她会问，如果你昨天爱我这么多，今天怎么样？
你会怎么回答？
工程师会怎么回答？工程师当然是每天问一次，所以一次加一点点，这是正确的。
实际上她的目的是什么，她是想要你比昨天更多一点点。
谁最会衡量？谁最需要衡量？老板。
相传15世纪时西洋棋发明人向国王要求奖励，在棋盘的每一格放一粒米，第二格放二粒，第三格放四粒米，按此规则放满整个棋盘就可以了。如果你是国王你会怎么办？
如果我是国王的话，我就直接把他杀掉了。如果你会衡量的话，你简单地算一下2的64次方，如果35粒米是1克的话，总共有527万亿公斤，以15世纪的生产，恐怕整个欧洲加起来都不够他用，你说这种人要不要杀掉？直接把他杀掉就好了，你还真的给他吗？
1. 谈衡量
衡量的定义，世界上没有任何事物是不能被衡量的，大部分时间是看似无法衡量，我们先入为主的观念认为它是不能衡量的，所以我们就没有去做。
但实际上只要你知道得比以前更多一点，这就是一项成功的衡量，你要做的就是敢去衡量它。
举个例子，站立会议的时候团队成员认为工作已经做完了，但是我们没有对做之前是什么样的情况，做之后是什么样的状态进行了解，这个过程叫做衡量，但是中间可能会有时间效应，时间效应可能会导致没有那么快出来，但是基础的衡量是会做的。
在看板上遇到不能控制的事情通常你会用什么方式来追踪？我第一年做老师的时候就是全校最受欢迎的老师，原因是什么？
所有我问的问题学生都不需要回答，都由我回答。所以你们只要举手就可以拿到奖品，不需要回答。
看板上你看到这种情形的时候就是不能控制，不能控制的就丢到看板上，这是不对的，但是它又需要显示出来，通常你们会怎么办呢？我们通常会用红黄绿灯来显示它，绿灯的时候一切OK，站立会议的时候汇报，这个很正常，没有什么问题。
黄灯的时候，这个可能会有问题，所以警示灯改为黄灯。
如果是红灯显示，它一定会出问题。
各位可以回想一下，你们看到黄灯的时候第一件事情是干什么？很多人是踩油门快速过去，但是大部分的时候黄灯不是一个正确的设计，你会迟疑下来考虑该做什么决定，我是冲过去还是停车。
冲过去的人肯定是不能奖励的，要停车的肯定是有奖励的。我奖励正确会造成大家正确的动作。
红黄绿灯的好处在哪里？一定要让整个团队明确地知道红黄绿灯的定义，这个意思是什么？你只要拿来做指标，一定要明确化。
让人家很清楚黄灯什么时候启动，红灯是什么时候启动，最好可以加上一点数据。
站立会议的时候，你明确说厂商出黄灯了，我查询了一下，我发现已经做到 3 / 4，快做完了，可能会有一点问题，所以可能要停下来，所以最好有数据进来，最好的指标是可比较的，一听就懂的，百分比是最好，然后会改变行为。
2. 看板与衡量
接下来介绍一下传统的看板的衡量方式，然后迅速移到敏捷开发的看板方法，这是我经历的最大的改变。
传统的看板里面，如果是黄灯的我们把进度延迟，如果是绿灯，我们把进度加快。
信息雷达是什么？信息雷达是你站在看板前面，你走过去，你会看的第一个地方，它透露出一种辐射的味道，你走过去自然的就会看它。
这句话里面最清楚的信息雷达是你的需求，你会发现你的需求在一直往上调整，然后掉下来，后来又拉上来，最后又急起直追，一直往上，这代表需求做不完。
第一个是范围增加，第二个是WIP增加，你会看到时间轴，这是分析，这是开发，这是测试，开发完了交给测试，最后这个空间越来越大，代表开发和测试脱节了。
所以突然间拉下来就是有需求不见了，为什么需求会不见了呢？因为工作都放回去了，不需要做，或者说它的重要性不够。
敏捷开发是一种快速的开发方法吗？不是。
为什么叫敏捷呢？因为它是应变需求变化非常快速。
你们的开发有需求变化这么快速的吗，通常不会有这么大的变化。如果你使用看板的话，你就会很清楚，最有趣的是这种现象，有两条线会合在一起。
例如测试在忙别的事，开发人员追上了，通常都是开发人员追上测试人员，或者是快速接近，因为太简单了。
3. DevOps 散步工作法
2015年是第一版，2016年是第二版。
里面提到非常重要的东西，除了贝叶斯函数之外，它把蒙特卡罗运算放了进来，蒙特卡罗运算也称统计模拟方法，是1940年代中期由于科学技术的发展和电子计算机的发明，而提出的一种以机率统计理论为指导的数值计算方法。
我们的度量是针对系统，而非个人，针对个人是KPI，我个人是非常讨厌KPI的，敏捷组织也非常不喜欢KPI，因此很多组织就不用KPI，而用ORK，用目标来做判断，这只是一种改善的方法。
我们来看这句话，“知道概率比准确的数据还要重要”，这句话合理不合理？
举个例子，最近我想调整公司上下班的时间，可是我不知道会影响到多少人，因此我就想做一个调查，上班的时间你们需要多长时间过来，下班之后你们需要多长时间才能回到家里？我做这样一个简单的调查，全公司有1万人，我应该怎么做？
最简单的方式是算一下平均值。
但是你如果是一个懂得衡量的人资，你只要把眼睛闭起来，挑5个人，右下角有5个人的样本，你直接把这5人的平均值算出来，最后得到一个概率的数值，最少30分钟，最多80分钟，你所采取的样本的平均值在这里面，你的准确度是93.75%。
如果你害怕这个准确度让领导混乱，你就可以说准确度在90%以上。所以你需不需要花很多精神去做衡量？你不一定要花很多精神去做衡量，你只要正确地采取计算方式就可以了。
我们练习一下衡量。信息雷达大家已经知道它的意思了，信息雷达是属于第一眼看到的时候你的感觉是什么，回去以后在你的看板前面走过去，第一眼看，这就是信息雷达，你的看板显示出来最基本的经过就在这里。你要改变它，右边是看板，右侧是需求层次的提高，你如果看到结束点在这里的话，意味着永远没有结束的时候。
4. 谈系统思维与衡量
敏捷开发最有趣的是什么？当初定的时候是2011年，它只有Dev，没有Ops。
你们在公司有执行敏捷开发的，是不是进入了Ops了呢？你在公司执行敏捷的时候，业务部门有没有加入你的开发团队？没有。
你的开发团队独立运作，然后发布给运维团队，请问需求团队算不算是敏捷开发人员？算。
所以敏捷开发每次是从Dev开始，但是后面的Ops没有进来，开发团队做得很高兴，慢慢的运维团队进来，DevOps出现了，然后精实开发就把它列入进来。
精实开发七大原则，第一原则就是减少浪费，所以你站在看板前面，你要做的一件事情就是找到浪费的地方，然后改善它。第二条是学习，学习可以让你无所不能。
真正要敏捷化，走到精实，再走到系统思维，需要很长的路线，不仅是AIOps要出来，后面还要把需求再拉进来，把需求拉进来以后，后面还要到业务的团队也加入，这样会得到快速回馈。快速回馈以后，然后我们学习、做调整，这是持续调整的方式。
你需要知道的实际上就是利特尔法则，你的生产效率等于存活数量除以周期时间。
开发的人再多，能力再强，如果没有一个好的需求，意义也不大，需求决定产品的价值在哪里，所以需求要不要有需求看板？一定要。很多团队在成长，需求太多，但是还是被骂产能太差，只有一种还行不被骂，就是需求都写得很棒，你只要做一两个很棒的需求，开发团队就表现得很好，所以要严格要求你的需求，怎么要求你的需求？度量它。
我们看完了需求看板以后，我们来看一下实际的开发情况。
需求看板、开发看板、部署看板要不要连在一起？要。
分开来的看板只是局部的优化，一定要把这三个连在一起，必须要会衡量，在开始开发之前做一次度量，开发完成之后再做一次度量，市场的销售量是激增还是完全没有影响，如果影响不大，这个需求就不是很好的需求，如果影响很大，这是一个非常好的需求，对贵公司的贡献就非常大。
连在一起非常难，一个企业的战斗能量在这里，如果我们真的实现这三个连在一起的时候，企业的战力就变成可衡量的。
度量的指标，好的指标是可比较的，如果我讲了半天这个指标你一点感觉都没有，那就不是一个好的指标。另外它要是简单易懂的，然后它是一个比率，然后它也可以改变你的行为。
标签：需求,架构,人工智能,DevOps,衡量,开发,敏捷,团队,看板 来源： https://blog.51cto.com/15127503/2657858