[关闭]
@gaoxiaoyunwei2017 2018-04-28T03:35:26.000000Z 字数 4147 阅读 379

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

白凡


分享:李智桦-91App 敏捷教练
编辑:白凡

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

image.png-861.9kB

DevOps最开始要做什么?做计划。项目开始第一件事情是看见全貌,这是今天所有的PPT,我们在这里,我们要走到哪里?所以我们先以终为始来做这件事。刚刚裴丹老师秀了很多的数据,AI最重要的数据,指标要对,什么样的指标是好的指标?第一是可以比较的,第二是要简单易懂的,讲出来你就知道AI到底是怎么回事,第三是它一定要是一个比率,我才可以按照它来做动作。如果人工智能做了半天对你的行为没有任何影响,这是没有意义的,第四个是最重要的,会改变你的行为。一定要专业人士才可以做这件事吗?一定要专业人员才可以做AIOps吗?不需要。
虽然专业人员是最好的,但是我们现在不是专业人员,我们可以学习,不断地尝试、学习,你就会了,所以学习是一件很重要的事。
当你看见全貌以后,你要怎么办?你已经看到了项目的全貌了,你看到全貌以后会怎么办?全貌只有一开始的时候能看得清楚,等你开始做进去之后,你的眼光投入在哪一点,你就着重在哪一部分,然后你就看不见全貌了。所以当你看清楚自己在哪里以后,接下来怎么办?当你看见全貌以后,第一件事,你应该知道自己在哪里,你先要知道自己在哪里,你才知道从哪里做,你该学些什么东西,先知道自己在哪里非常重要,然后提出尖锐的问题,只有在项目一开始的时候,你可以提出很尖锐的问题,不会有人怪你,可是一旦整个团队投入之后,就不能再提出尖锐的问题,要全力去完成它。所以项目开始之初先知道自己在哪里,然后提出尖锐的问题。这是一件不可能的事吗?可不可能达到?不提出尖锐的问题,就不知道我们要解决什么问题。
这是我习惯的开场,先让大家看到全貌。

0. 衡量

有一句有态度的句子讲,如果你不能衡量它,你就不可能管理它。这是彼德德鲁克说的一句名言,我是从《如何衡量万事万物》这本书里面看到这句话的,里面有很多衡量的东西来自这本书。

image.png-134.8kB

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

我们经常先入为主的认为很多事物是不能衡量的,但实际上不是这么回事。在公园里面休息的时候看到一些妙龄女郎带着她的男朋友,她会问,如果你昨天爱我这么多,今天怎么样?你会怎么回答?工程师会怎么回答?工程师当然是每天问一次,所以一次加一点点,这是正确的。实际上她的目的是什么,她是想要你比昨天更多一点点。

image.png-79.2kB

谁最会衡量?谁最需要衡量?
老板。
image.png-45.7kB

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

image.png-93kB

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

image.png-258.1kB

1. 谈衡量

image.png-53.1kB

衡量的定义,世界上没有任何事物是不能被衡量的,大部分时间是看似无法衡量,我们先入为主的观念认为它是不能衡量的,所以我们就没有去做,但实际上只要你知道得比以前更多一点,这就是一项成功的衡量,你要做的就是敢去衡量它。举个例子,站立会议的时候团队成员认为工作已经做完了,但是我们没有对做之前是什么样的情况,做之后是什么样的状态进行了解,这个过程叫做衡量,但是中间可能会有时间效应,时间效应可能会导致没有那么快出来,但是基础的衡量是会做的。

image.png-88.7kB

在看板上遇到不能控制的事情通常你会用什么方式来追踪?我第一年做老师的时候就是全校最受欢迎的老师,原因是什么?所有我问的问题学生都不需要回答,都由我回答。所以你们只要举手就可以拿到奖品,不需要回答。

image.png-64.8kB

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

image.png-119.7kB

黄灯的时候,这个可能会有问题,所以警示灯改为黄灯。如果是红灯显示,它一定会出问题。各位可以回想一下,你们看到黄灯的时候第一件事情是干什么?很多人是踩油门快速过去,但是大部分的时候黄灯不是一个正确的设计,你会迟疑下来考虑该做什么决定,我是冲过去还是停车。冲过去的人肯定是不能奖励的,要停车的肯定是有奖励的。我奖励正确会造成大家正确的动作。

image.png-137.4kB

红黄绿灯的好处在哪里?一定要让整个团队明确地知道红黄绿灯的定义,这个意思是什么?你只要拿来做指标,一定要明确化,让人家很清楚黄灯什么时候启动,红灯是什么时候启动,最好可以加上一点数据,站立会议的时候,你明确说厂商出黄灯了,我查询了一下,我发现已经做到3/4,快做完了,可能会有一点问题,所以可能要停下来,所以最好有数据进来,最好的指标是可比较的,一听就懂的,百分比是最好,然后会改变行为。

2. 看板与衡量

image.png-38.5kB

接下来介绍一下传统的看板的衡量方式,然后迅速移到敏捷开发的看板方法,这是我经历的最大的改变。传统的看板里面,如果是黄灯的我们把进度延迟,如果是绿灯,我们把进度加快。

image.png-90.9kB

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

image.png-146.5kB

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

image.png-200.3kB

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

image.png-152.4kB

3. DevOps散步工作法

image.png-227.4kB

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

image.png-92.8kB

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

image.png-231.3kB

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

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

image.png-72kB

举个例子,最近我想调整公司上下班的时间,可是我不知道会影响到多少人,因此我就想做一个调查,上班的时间你们需要多长时间过来,下班之后你们需要多长时间才能回到家里,我做这样一个简单的调查,全公司有1万人,我应该怎么做?最简单的方式是算一下平均值,但是你如果是一个懂得衡量的人资,你只要把眼睛闭起来,挑5个人,右下角有5个人的样本,你直接把这5人的平均值算出来,最后得到一个概率的数值,最少30分钟,最多80分钟,你所采取的样本的平均值在这里面,你的准确度是93.75%,如果你害怕这个准确度让领导混乱,你就可以说准确度在90%以上。所以你需不需要花很多精神去做衡量?你不一定要花很多精神去做衡量,你只要正确地采取计算方式就可以了。

image.png-258.2kB

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

4. 谈系统思维与衡量

敏捷开发最有趣的是什么?当初定的时候是2011年,它只有Dev,没有Ops。你们在公司有执行敏捷开发的,是不是进入了Ops了呢?你在公司执行敏捷的时候,业务部门有没有加入你的开发团队?没有。你的开发团队独立运作,然后发布给运维团队,请问需求团队算不算是敏捷开发人员?算。
所以敏捷开发每次是从Dev开始,但是后面的Ops没有进来,开发团队做得很高兴,慢慢的运维团队进来,DevOps出现了,然后精实开发就把它列入进来。精实开发七大原则,第一原则就是减少浪费,所以你站在看板前面,你要做的一件事情就是找到浪费的地方,然后改善它。第二条是学习,学习可以让你无所不能。

image.png-113.3kB

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

image.png-69kB

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

image.png-80.9kB

我们看完了需求看板以后,我们来看一下实际的开发情况。

image.png-111kB

需求看板、开发看板、部署看板要不要连在一起?要。

image.png-56.1kB

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

image.png-148.5kB

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

image.png-81kB

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

image.png-130.1kB

添加新批注
在作者公开此批注前,只有你和作者可见。
回复批注