其他分享
首页 > 其他分享> > 衡量:DevOps 架构下的人工智能思维

衡量:DevOps 架构下的人工智能思维

作者:互联网

衡量:DevOps 架构下的人工智能思维
衡量:DevOps 架构下的人工智能思维
分享:李智桦-91App 敏捷教练
编辑:白凡

我住在阳明山脚下,我每天起床都到这个地方,大概海拔800公尺左右,大概要55分钟到60分钟到。

衡量:DevOps 架构下的人工智能思维

DevOps 最开始要做什么?做计划。

项目开始第一件事情是看见全貌,这是今天所有的 PPT,我们在这里,我们要走到哪里?所以我们先以终为始来做这件事。

刚刚裴丹老师秀了很多的数据,AI 最重要的数据,指标要对,什么样的指标是好的指标?第一是可以比较的,第二是要简单易懂的,讲出来你就知道 AI 到底是怎么回事。

第三是它一定要是一个比率,我才可以按照它来做动作。

如果人工智能做了半天对你的行为没有任何影响,这是没有意义的。

第四个是最重要的,会改变你的行为。

一定要专业人士才可以做这件事吗?一定要专业人员才可以做 AIOps 吗?不需要。

虽然专业人员是最好的,但是我们现在不是专业人员,我们可以学习,不断地尝试、学习,你就会了,所以学习是一件很重要的事。

当你看见全貌以后,你要怎么办?

你已经看到了项目的全貌了,你看到全貌以后会怎么办?

全貌只有一开始的时候能看得清楚,等你开始做进去之后,你的眼光投入在哪一点,你就着重在哪一部分,然后你就看不见全貌了。

所以,当你看清楚自己在哪里以后,接下来怎么办?

第一件事,你应该知道自己在哪里,你先要知道自己在哪里,你才知道从哪里做,你该学些什么东西,先知道自己在哪里非常重要,然后提出尖锐的问题;

只有在项目一开始的时候,你可以提出很尖锐的问题,不会有人怪你,可是一旦整个团队投入之后,就不能再提出尖锐的问题,要全力去完成它。

所以项目开始之初先知道自己在哪里,然后提出尖锐的问题。

这是一件不可能的事吗?可不可能达到?不提出尖锐的问题,就不知道我们要解决什么问题。

这是我习惯的开场,先让大家看到全貌。

0. 衡量


有一句有态度的句子讲,如果你不能衡量它,你就不可能管理它。

这是彼德·德鲁克说的一句名言,我是从《如何衡量万事万物》这本书里面看到这句话的,里面有很多衡量的东西来自这本书。

衡量:DevOps 架构下的人工智能思维

衡量的定义是:减少不确定性,优化问题的有效手段。你更了解这件事,我们就称之为衡量。

我们经常先入为主的认为很多事物是不能衡量的,但实际上不是这么回事。

在公园里面休息的时候看到一些妙龄女郎带着她的男朋友,她会问,如果你昨天爱我这么多,今天怎么样?

你会怎么回答?

工程师会怎么回答?工程师当然是每天问一次,所以一次加一点点,这是正确的。

实际上她的目的是什么,她是想要你比昨天更多一点点。

衡量:DevOps 架构下的人工智能思维

谁最会衡量?谁最需要衡量?老板。

衡量:DevOps 架构下的人工智能思维

相传15世纪时西洋棋发明人向国王要求奖励,在棋盘的每一格放一粒米,第二格放二粒,第三格放四粒米,按此规则放满整个棋盘就可以了。如果你是国王你会怎么办?

衡量:DevOps 架构下的人工智能思维

如果我是国王的话,我就直接把他杀掉了。如果你会衡量的话,你简单地算一下2的64次方,如果35粒米是1克的话,总共有527万亿公斤,以15世纪的生产,恐怕整个欧洲加起来都不够他用,你说这种人要不要杀掉?直接把他杀掉就好了,你还真的给他吗?
衡量:DevOps 架构下的人工智能思维

1. 谈衡量

衡量:DevOps 架构下的人工智能思维

衡量的定义,世界上没有任何事物是不能被衡量的,大部分时间是看似无法衡量,我们先入为主的观念认为它是不能衡量的,所以我们就没有去做。

但实际上只要你知道得比以前更多一点,这就是一项成功的衡量,你要做的就是敢去衡量它。

举个例子,站立会议的时候团队成员认为工作已经做完了,但是我们没有对做之前是什么样的情况,做之后是什么样的状态进行了解,这个过程叫做衡量,但是中间可能会有时间效应,时间效应可能会导致没有那么快出来,但是基础的衡量是会做的。

衡量:DevOps 架构下的人工智能思维

在看板上遇到不能控制的事情通常你会用什么方式来追踪?我第一年做老师的时候就是全校最受欢迎的老师,原因是什么?

所有我问的问题学生都不需要回答,都由我回答。所以你们只要举手就可以拿到奖品,不需要回答。

衡量:DevOps 架构下的人工智能思维
看板上你看到这种情形的时候就是不能控制,不能控制的就丢到看板上,这是不对的,但是它又需要显示出来,通常你们会怎么办呢?我们通常会用红黄绿灯来显示它,绿灯的时候一切OK,站立会议的时候汇报,这个很正常,没有什么问题。

衡量:DevOps 架构下的人工智能思维
黄灯的时候,这个可能会有问题,所以警示灯改为黄灯。

如果是红灯显示,它一定会出问题。

各位可以回想一下,你们看到黄灯的时候第一件事情是干什么?很多人是踩油门快速过去,但是大部分的时候黄灯不是一个正确的设计,你会迟疑下来考虑该做什么决定,我是冲过去还是停车。

冲过去的人肯定是不能奖励的,要停车的肯定是有奖励的。我奖励正确会造成大家正确的动作。

衡量:DevOps 架构下的人工智能思维

红黄绿灯的好处在哪里?一定要让整个团队明确地知道红黄绿灯的定义,这个意思是什么?你只要拿来做指标,一定要明确化。

让人家很清楚黄灯什么时候启动,红灯是什么时候启动,最好可以加上一点数据。

站立会议的时候,你明确说厂商出黄灯了,我查询了一下,我发现已经做到 3 / 4,快做完了,可能会有一点问题,所以可能要停下来,所以最好有数据进来,最好的指标是可比较的,一听就懂的,百分比是最好,然后会改变行为。

2. 看板与衡量


衡量:DevOps 架构下的人工智能思维

接下来介绍一下传统的看板的衡量方式,然后迅速移到敏捷开发的看板方法,这是我经历的最大的改变。

传统的看板里面,如果是黄灯的我们把进度延迟,如果是绿灯,我们把进度加快。

衡量:DevOps 架构下的人工智能思维

信息雷达是什么?信息雷达是你站在看板前面,你走过去,你会看的第一个地方,它透露出一种辐射的味道,你走过去自然的就会看它。

这句话里面最清楚的信息雷达是你的需求,你会发现你的需求在一直往上调整,然后掉下来,后来又拉上来,最后又急起直追,一直往上,这代表需求做不完。

衡量:DevOps 架构下的人工智能思维

第一个是范围增加,第二个是WIP增加,你会看到时间轴,这是分析,这是开发,这是测试,开发完了交给测试,最后这个空间越来越大,代表开发和测试脱节了。

所以突然间拉下来就是有需求不见了,为什么需求会不见了呢?因为工作都放回去了,不需要做,或者说它的重要性不够。

衡量:DevOps 架构下的人工智能思维

敏捷开发是一种快速的开发方法吗?不是。

为什么叫敏捷呢?因为它是应变需求变化非常快速。

你们的开发有需求变化这么快速的吗,通常不会有这么大的变化。如果你使用看板的话,你就会很清楚,最有趣的是这种现象,有两条线会合在一起。

例如测试在忙别的事,开发人员追上了,通常都是开发人员追上测试人员,或者是快速接近,因为太简单了。

衡量:DevOps 架构下的人工智能思维

3. DevOps 散步工作法

衡量:DevOps 架构下的人工智能思维

2015年是第一版,2016年是第二版。

衡量:DevOps 架构下的人工智能思维
里面提到非常重要的东西,除了贝叶斯函数之外,它把蒙特卡罗运算放了进来,蒙特卡罗运算也称统计模拟方法,是1940年代中期由于科学技术的发展和电子计算机的发明,而提出的一种以机率统计理论为指导的数值计算方法。

衡量:DevOps 架构下的人工智能思维

我们的度量是针对系统,而非个人,针对个人是KPI,我个人是非常讨厌KPI的,敏捷组织也非常不喜欢KPI,因此很多组织就不用KPI,而用ORK,用目标来做判断,这只是一种改善的方法。

衡量:DevOps 架构下的人工智能思维

我们来看这句话,“知道概率比准确的数据还要重要”,这句话合理不合理?

衡量:DevOps 架构下的人工智能思维

举个例子,最近我想调整公司上下班的时间,可是我不知道会影响到多少人,因此我就想做一个调查,上班的时间你们需要多长时间过来,下班之后你们需要多长时间才能回到家里?我做这样一个简单的调查,全公司有1万人,我应该怎么做?

最简单的方式是算一下平均值。

但是你如果是一个懂得衡量的人资,你只要把眼睛闭起来,挑5个人,右下角有5个人的样本,你直接把这5人的平均值算出来,最后得到一个概率的数值,最少30分钟,最多80分钟,你所采取的样本的平均值在这里面,你的准确度是93.75%。

如果你害怕这个准确度让领导混乱,你就可以说准确度在90%以上。所以你需不需要花很多精神去做衡量?你不一定要花很多精神去做衡量,你只要正确地采取计算方式就可以了。

衡量:DevOps 架构下的人工智能思维

我们练习一下衡量。信息雷达大家已经知道它的意思了,信息雷达是属于第一眼看到的时候你的感觉是什么,回去以后在你的看板前面走过去,第一眼看,这就是信息雷达,你的看板显示出来最基本的经过就在这里。你要改变它,右边是看板,右侧是需求层次的提高,你如果看到结束点在这里的话,意味着永远没有结束的时候。

4. 谈系统思维与衡量


敏捷开发最有趣的是什么?当初定的时候是2011年,它只有Dev,没有Ops。

你们在公司有执行敏捷开发的,是不是进入了Ops了呢?你在公司执行敏捷的时候,业务部门有没有加入你的开发团队?没有。

你的开发团队独立运作,然后发布给运维团队,请问需求团队算不算是敏捷开发人员?算。

所以敏捷开发每次是从Dev开始,但是后面的Ops没有进来,开发团队做得很高兴,慢慢的运维团队进来,DevOps出现了,然后精实开发就把它列入进来。

精实开发七大原则,第一原则就是减少浪费,所以你站在看板前面,你要做的一件事情就是找到浪费的地方,然后改善它。第二条是学习,学习可以让你无所不能。

衡量:DevOps 架构下的人工智能思维

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

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

衡量:DevOps 架构下的人工智能思维
我们看完了需求看板以后,我们来看一下实际的开发情况。
衡量:DevOps 架构下的人工智能思维
需求看板、开发看板、部署看板要不要连在一起?要。

衡量:DevOps 架构下的人工智能思维

分开来的看板只是局部的优化,一定要把这三个连在一起,必须要会衡量,在开始开发之前做一次度量,开发完成之后再做一次度量,市场的销售量是激增还是完全没有影响,如果影响不大,这个需求就不是很好的需求,如果影响很大,这是一个非常好的需求,对贵公司的贡献就非常大。

衡量:DevOps 架构下的人工智能思维
连在一起非常难,一个企业的战斗能量在这里,如果我们真的实现这三个连在一起的时候,企业的战力就变成可衡量的。

衡量:DevOps 架构下的人工智能思维

度量的指标,好的指标是可比较的,如果我讲了半天这个指标你一点感觉都没有,那就不是一个好的指标。另外它要是简单易懂的,然后它是一个比率,然后它也可以改变你的行为。

衡量:DevOps 架构下的人工智能思维

标签:需求,架构,人工智能,DevOps,衡量,开发,敏捷,团队,看板
来源: https://blog.51cto.com/15127503/2657858