讲座实录:2015年12月敏捷专家Evelyn谈《Scrum捷径,敏捷策略、工具与技巧》

引言


2015年12月17日,著名敏捷大师Evelyn 在敏捷微课程上,分享了《Scrum捷径:敏捷策略、工具与技巧》这本书的一些内容。Evelyn大师的讲解,深入浅出,简单易懂,每每给人以启发,屡有茅塞顿开的感觉。

本文是Evelyn大师的讲座实录,全文内容基本忠实保持了Evelyn讲座的全部内容,包括语气等。但本文不包括讲座之后的问答环节。如时间允许,冰块将会随后整理那些问题,并以Q&A的形式在另一篇文章中专门分享。

Evelyn Tian谈《Scrum捷径,敏捷策略、工具与技巧》


开场语

现在听不听得见吗?OK,那大家有人帮我确认了,说可以听的到,那我就开始了。大家好啊,我是Evelyn Tian。今天呢,很高兴有机会和大家在这里一起分享。首先呢,我想借这个机会谢谢组织者任群的邀请。还记得大概是11年还是12年的时候呢,那个时候还住在上海,参加了上海的一些活动,当时呢就觉得是,我可以把自己学习到一些内容啊,还有自己的一些经验呀,当然包括一些成功的,也包括一些走了弯路的一些经验,可以跟大家分享一下。就是但是呢,熟悉我的同学都知道,就是因为我平时出差比较多,同时呢,我自己呢,又是业余爱好比较多,攀岩呀潜水啊,我的事,反正就按排都比较忙,所以呢,时间上总是很纠结。在线的分享呢,就这种特别适合我这个状况。今天呢,正好我也是在韩国的首尔,能够通过公司的这个网,能连回中国去,到中国的,再跟大家一起学习、探讨很是开心。所以呢我就代表我自己,也是代表大家一起呢谢谢任群,帮助我们这些对敏捷和变革管理非常感兴趣的同学提供这样一个平台,让我们有机会互相交互,有机会共同进步呢,谢谢任群哈。

自我介绍

首先呢,我先做一下自我介绍啊。我是Evelyn哈,来自爱立信通信有限公司。爱立信呢,是一个瑞典公司,成立于1876年,一百多年的历史,在中国呢,在全球的话有180几个国家。那目前我们有十几万的员工啊,因为我们的产品呢,与普通消费者距离比较远,所以大家可能对我们没有那么熟悉,因为我们是通信公司在全世界的话呢,有超过40%的通信的流量是在我们公司的设备上的啊。我在爱立信内部呢,有两个职责哈,第一个是负责我们爱立信东北亚研究院的精益敏捷。另外一个是负责我们爱立信,我们有一个这样全球变革指导中心,我负责这边的工作。嗯,我呢,在爱立信呢,大概有20年了啊。在这20年的话,做过多个岗位,从最开始做开发测试啊,也做过项目经理啊,产品经理系统设计啊,还有架构师一直呢做到客户的支持。

在2007年的时候呢,首次接触到敏捷。我做过呢,做过Product Owner,也做过Scrum Master,是在2009年的时候,我们公司内部呢,有一个2200人左右的一个组织,开始做大规模的这种敏捷转型的时候呢,那个时候,我也自己就转型为一个全职的精益和敏捷的教练。那个时候呢,我受了蛮多的这个辅导啊,学习啊,还有教练。所以现在想起来,还是很感谢公司给我这样各种各样的成长的机会。我当时呢,可能是可以说的是,说的算是接受了最全面最高端的学习和受教练的这样一个机会。当时的话呢,我们有请了9个不同的世界上比较有名的这样的教练过来帮助我们一起在5个月的时间呢,培训我们,然后呢,让我们可以回到公司里面去做内部的这样一个教练的工作。我呢就是同时也有各种各样的这样外部的培训和交流的机会,我自己的话呢,唯一现在说实话,有一点时间上的挑战。目前呢,我还是比较努力的找时间去做一些具体开发团队的教练工作。因为呢,我总是坚信做为一名教练的话呢,无论如何,都还是要有最新、最一手的这样经历和实践才好,在软件技术实践上呢,我也是尝试着保持更新,保持领先,我是国际电子电气工程师协会的软件顾问,然后同时的话呢,如果大家要是感兴趣在这个IEEE软件上发表文章呢,可以随时联系我。同时的话呢,在2016年的这个年度的敏捷联盟就是Agile Alliance的年度学术会上,我也是技术实践的联合主席。如果呢,大家有感兴趣交话题的话,今年是在亚特兰大。如果要是大家感兴趣交话题的话也可以联系我。我相信我们中国一定有很多新的好的实践,可以到世界上敏捷爱好者这个圈子里去分享的。我自己的主要的这个兴趣方向呢,说起来呢,比较宽,一个是对领导力这方面比较感兴趣,对组织转型变革管理,然后同时呢,对大规模的这个敏捷转型比较感兴趣,这个当然一个原因就是我们公司内部,我们的通讯产品都比较大。另外一个的话就是说现在外面的话也有好几个好多,其实细数数,有大概有12个可以用的哈,扩展的框架,从SAFe啊、LeSS、Nexus有蛮多的还是,然后就是软件的公益。此外的话呢,就是属于一个业余的爱好呢,当然,对敏捷的那个教练工作也有帮帮助,我是这个国际认证的这个专业的教练啊。这张呢话呢?大家可能看到就是说,因为我是从12年还是13年的时候,在我们爱立信的这个LinkedIn,领英那个职业版上面写的一直到现在还在那边,我从那个时候开始每次出去做分享的时候,总会放这一页,放这一页的原因是什么呢?因为是我自己一个自身的这样一个非常真实的这样一个感受。嗯,还有最后一点的话呢,就是我20多年前呢,就去加拿大,数数的话也快,都快30年了哈,这几年才回来,所以有的时候呢,我的词可能是有的,不会、不一定用的那么准确,所以还请大家原谅哈。我呢,也是处于一个持续改善的这样一个状态,我这次呢,给自己设了一个小小的目标呢,是想说除了个别的词呢,我就一定都努力,都用中文,欢迎大家监督啊。

关于《Scrum捷径:敏捷策略、工具与技巧》这本书

今天呢话呢,我们谈一谈敏捷,谈一谈敏捷这本书,这个叫《Scrum捷径》。说到敏捷的话呢,每个人、每个公司、每个团队都有自己的一个敏捷之旅,都有自己的成功呢,也有自己走了弯路的地方。这本书的话呢,介绍了敏捷的策略、工具和技巧,介绍了一些捷径,里面写了一共有30个捷径,这呢,对在敏捷转型路上的同学和组织呢,或多或少都是有很有帮助的。当然呢,在公司内部和外部,我也遇到过一些组织,说,唉,我们敏捷转型都做好了,已经很成熟了。我总会这样说哈,就是说阿敏捷的话呢和精益和敏捷一个精髓的地方,有精华的地方,都是一个持续改善。所以的话呢,其实没有这样一个说我是某某年某某月开始、某某年某某月就结束这样一个概念。总是有新东西出来,总是有新的内容可以学习的。所以的话呢,就说,就算你做转型,做了一段时间,你还是可以再看一下有什么地方可以学习的地方可以做的更好,或者是至少可以借鉴的地方。

也有同学问过我哈,说书上介绍的这些捷径是不是都是最佳的捷径,或者最捷的路径,是不是最佳的推荐?这个问题呢,问的非常的好。我在呢,开始阅读和翻译这本书的过程中呢,都有这个考虑。在翻译的时候呢,说实话,稍微有一个小小的担心,就会觉得说,唉呀,我翻译的话,是不是读者就会认为这个所有的内容都是我认同和推荐的这样一个最佳的捷径呢?当时呢,在决定是否翻译的时候呢,和清华大学出版社的文老师聊天的时候得到了启发。那我呢,是在翻译书,只要呢,我觉得这本书呢,对大家有帮助。唉,就是好的。这本书的捷径呢,肯定是对读者有帮助的。同时呢,随着时间和实践,大家自己也会慢慢意识到可以有最佳的捷径的,或者是更好的捷径。

选择当然是两种哈,一种是要么就是不读,自己在那纠结。另外一种的话,就是可以先读一读,尝试着往前走一走,到那个时候看看自己适合什么样的状态。那个时候呢,有一个什么样的需求,再看一下下一步怎么走。刚才也说到精益和敏捷的这样一个精髓哈,持续进步、持续改善,所以呢我自己的一个建议,就是说,把这本书呢,当做一个工具书。看看有什么时候有需求,因为前面的目录呢,也是蛮清楚的。所以呢,你要是有一个比较特殊的问题,你就可以到目录去找一找。然后看一看有什么地方你可以觉得说,唉,可以的,可以对你有帮助的地方,或者呢,就是说你想从头到尾读一次也是很好的,看一看有一些什么重点的地方,或许你可以在现在目前的实践中尝试一下,可以尝试把这些捷径变得更好。

我们呢,现在咱们就开始一起看一看这本书中讨论的内容哈。这本书呢?我们先看一下整个书的这样一个整体的这样一个结构,这本书一共有10个章节,从不同的方面,从Scrum最开始的一个引入工作,到具体工作中的运用和可能会遇到的问题呀,或者是大家可能会考虑的问题,例如说经理该怎么做呀,他们在做什么呢,然后还有一些什么呢,就是说怎么样能把Scrum更深层的引入,唉,这样可以有更深层的这样一些收益啊,我也,我也尝试着把这10个章节呢,按颜色分了一下。前面呢这个紫色的这一块呢,属于关于Scrum刚起步的一些事情。黄色的是态度和能力、规划和保护是属于整个一个周边的这样一个情形,比如说人员的组成啊之类的。绿色的这几块呢,需求、估算、质量、监控,还有,指标、回顾会、还有审核会,这一块都是属于在具体真的在做Scrum引入工作之后,可能会遇到的一些挑战呀,可能会有一些就比较具体的,大家有问题的话是可以作为参照的。再有就是这一块属于算棕色的,是经理这一块,经理这一块的话呢,因为大家所在的公司不同,文化不是很一样,我记得呢,我是2011年的时候在QCon去做了一个关于这种一个Mindset思维,这样的一个演讲的时候,当时我就记得,应该是百度的那个经理,然后就过来跟我说,就是说啊,好像从来都考虑的是团队要做Scrum,团队要敏捷,从来没有考虑过经理需要做一些什么事情。其实呢,对经理来说是肯定呢,也是需要做一些改变的。原因是什么呢?如果Scrum,你只是在一个团队的范围里去做的话,你会不会有收益呢?会有的。但是呢,最大的收益还是要在整个公司的层面来做,才会有更大的这样一个收益。所以从经理来讲的话呢,肯定是有变化的,从你的这一个行为啊,从一个思维呀,还有,从你一个怎么样去管理,跟团队的这样一个交互都是有变化的。然后最大最后一块的话呢,这个叫更大的经验教训。其实呢,想说的是什么意思呢?就是说,唉,把Scrum能够更深层的引入,这样可以有一个更深层的收益。就像刚才说的一样,Scrum如果总是停留在团队的这样一个层面的话呢,那也就是收益也可能也就是那么多了。我们还是想说,唉,怎么能让Scrum帮助我们公司能够帮助我们的产品开发,能有更大的这样一些收益。

分享一:关于Scrum Master

那然后呢?我们呢就看一下,我挑了一些内容哈,跟大家分享一下。

第一个呢,我想分享的是关于Scrum Master。这一点的话呢,我们可能能要多花一些时间谈一下Scrum Master这个角色。之所以呢,想先聊聊Scrum Master,是什么原因呢?是因为只要你的团队在用Scrum,不管你是团队的成员,还是你本人就是Scrum Master,还是你是Product Owner,或许呢,可能你还是你们公司里可能还会是有项目经理哈,或许还有你是做经理,普通的经理、人事经理,不管怎么样的话呢,只要你们公司在run Scrum,都是应该有Scrum Master所以这个角色的。并且呢,你或多或少都是跟他有一些交互的,所以我们先看一下Scrum Master这个角色。在书里面的话呢,捷径4讲出了Scrum Master应该具备的多项关键能力。我们来一起看一下。

现在呢,屏幕上也显示说,第一条是列出来的多项关键能力的第一条呢,就是说没有权力的领导。这一条呢,是很重要的一条。唉,因为这个呢,也是个事实,Scrum Master确实没有职位权力的。

这话怎么讲呢?按照大部分公司的这样一个现状哈,无论你的经理有,或者没有什么能力,无论你喜欢,或者你是痛恨你现在的经理,他呢,都有他的职位权力,他都负责你的工资呀、级别呀、还有其他一些很多的事情。所以呢,不管你喜欢与否,他都有这个职位的权力。这本书中没有细谈到这个职位权力,在那个John Maxwell,就是我们一个世界上很有名的这样领导力大师叫约翰·麦斯威尔,他的这个《5个领导力的层次》这个书里面所说到呢,第一个层次就是什么呀,就是职位权力。职位权力的概念,就是说,人们跟从你,为什么跟从你呢?你为他们别无选择。因为你是他的领导,因为你,例如说是他的一线经理,他没有其他的选择,他可能心里很痛恨你,但他没选择。

谈到第一层的这个职位权力呢,有人可能就会说,唉哟,那不是很不幸吗?因为Scrum Master的话呢,就没有这个职位的权力。因为咱们一开始就说了,对吧,是一个没有权力的领导。熟悉我的同学都知道,我呢,是一个比较乐观的人,我的看法呢,就可能刚才可能想法就是稍微有些不同,不同是在哪里呢?没有职位权力的人呢,换个角度去看,其实呢,或许是个好事情,为什么是好事情呢?因为呢,在公司内还是公司外,因为经常,我也到外面去学术会上面去讲,有很多公司问我些问题啊。唉,我听到了很多大家不同的心声,有什么样的心声呢?就是说,唉,很多的领导,例如说一线经理呢,她都一直停留在这个领导力5个层次,里面的最底层,第一层,就是这个权力层次,是职位权力。她一直停留在这个职位权力呢,唉,有什么问题呢?她领导力非常的低。在这个阶段呢,他停留的时间越久呢,会怎么样了?组织内部的人员流动率会很高。同时的话呢,就算人员没有流动的,会怎么样呀?士气也会越来越低。

所以呢,我建议是什么呢?就是不知道在的大家,我们现在同学里面,咱们有没有是做经理的哈,如果是做呢,现在在做经理的啊,或者考虑以后做经理的,或者是现在在做或者考虑做Scrum Master的同学呢,我都建议呢,大家去看一下,翻一下这个书哈,就是叫《5个领导力的层次》,去体会一下。因为最基本呢,是职位权力,其他就是什么,还有个认同,认同是什么啦,就人们把你当成什么呀,上司般的跟从你,让你呢,就比刚才的职位权力就好一些了。然后呢,第三层是什么?成果,人们跟着你是因为你对过去所做的事情,大家觉得说,哇,你做的事情蛮有意义的嘛,蛮有贡献的。第四个层次是什么啦?是你能帮助别人成长。人们跟着你,是因为你以前为他自己个人所做的事情。最后一层是什么呢?是敬佩。人们跟从你,是因为你的为人,还有你的什么,所有彰显的一切。唉,所以这才是最高的这样一个境界。所以呢,就是说我建议是,想做Scrum Master的同学啊,或者在做的,可以去读一读,看看有什么看看多多少少都会受益的哈。

所以呢,做一个好的Scrum Master,的确很锻炼人。因为你起步的时候呢,没有这个职位的权力,然后呢?怎么样呢?唉,然后你还有很多的大家对你有很多的期待,有很多事情要做。所以呢,做Scrum Master是一个可以让个人可以快速成长的这样一个过程的一个途径,确实。

那我们再看一下其他的关于Scrum Master能力的要求。另外一点就是还说叫什么,叫引入变革不畏惧。唉,引入Scrum,会让整个团队,整个组织或者整个公司都有变化。引入变革的话呢,是需要有技巧的,不能急于求成的。所以呢,厄在做Scrum Master的同学呢,我建议可以怎么样了,稍微掌握一些关于变革管理的知识技巧。知道了一些技巧有什么好处呢?就说你自己的生活变得快乐很多,然后周围的人的话也怎么样,在你的帮助下也接受了一些新的注意啊、新的方式啊、新的方法,所以呢,是一个怎么样,双赢的这样一个局面。

再一点就是说有策略不玩办公室的政治哈。同时呢,怎么样?要不要有私心。唉,然后呢,要保护我们的团队。保护我们什么概念呢?保护我们团队这样的话,团队可以怎么样,可以集中精力做我们这个Sprint的开发工作。不然的话呢,有很多公司都会有这样一个什么局面,总会有非常非常重要的事情,要把人从团队里拿走。所以呢,保护团队的成员也是很重要的哈。然后下一条呢,我也要多说两句,就是关于什么,关于技术知识,这个呢,Scrum Master是不是要有技术的知识?有很多的内部外部,都有人问过我Scrum Master就这技术的要求有多少呀?我不知道,大家都应该上过这个Certified Scrum Master的课,这个Scrum Master认证课,认证课只有两天,内容也比较多,其中,不知道大家记得不记得,说Scrum Master有几样的职责,其中有一条是什么啊,是关于技术实践的。唉,我的团队的技术实践是怎么样的呢?Scrum Master对自己的产品,还有对自己的这个团队所需求的这样一个技术实践还是都应该有了解的。但是呢,我们并不要求说Scrum Master是专家,唉,所以呢,有了一定的了解,但是你并不一定是专家。当然,如果要是可以成为专家也很好啊。但是呢,并不是一个必须。

下一个呢,就是要不固步自封

再下一个,就是说,更加的比较严格一点了,还有什么,有下一代的领导力。这个关于领导力,敏捷领导力是一个比较大也比较广的这样一个话题,所以大家看起来听起来也看到了哈。这对Scrum Master有这么多能力的一个要求,所以呢,如果我们用任何1句话来总结一下是什么呢?不是任何人都可以成为一个很好的Scrum Master的。但是呢,怎么样呢?Scrum Master其实是可以任何人,他所做的,原来做的职位呢,都是无所谓的。可以,原来可能是写代码的,原来做测试的,原来做系统的呀,其实呢,都可以。但是呢,还是要需要有一些锻炼出来一些能力,才能做好Scrum Master的工作。

不知道大家看了这么多要求哈,说能力上的要求吧,大家有没有什么问题?因为呢,我也是第一次用这个腾讯的课堂,我就先不尝试其他的功能了。哈,我也不尝试说让大家提问了。那我给大家提问个问题,不知道你们看了,说这么长串,一共八条的这样一个能力的要求哈,有没有考虑到一个问题,什么人会有这么多这么强的能力呢?或者说哈,如果一个人有刚才讲到的这么多的能力,那他怎么才会去做一个Scrum Master呢?这个不是说,例如说没有权利的领导还能领导好团队,领导好这个一个小的组织的话,他不是应该有能力可以做更大更多的事情嘛?这个问题呢,其实是一个非常有洞察力的这样一个问题哈。而如果一个人真的可以锻炼成长出来这么多的能力,其实它是可以胜任出更多的那个职责的。所以呢,在Scrum Master的人选上,从公司经理的层面也好啊,还是从自己员工个人的自己个人的层面也好,都是应该,其实有考虑的。因为从员工个人的成长和职业一个规划上面每个人还是要为自己怎么样,自己去计划的。

这个是大家发现,我可能出去讲学术会的时候经常谈到的一个问题。因为怎么样呢?因为我觉得是敏捷的话呢,每个人在敏捷中都有更好的这样一个发展的机会。这个的话,在2014年上海的敏捷之旅,我做了一个主题演讲,名字叫《people也Agile》,就是敏捷中的人们,谈到了人,这个在敏捷中非常重要的这样一个因素。因为每个人呢,其实都是可以受益于敏捷的,可以更好的这样一个发展机会。那怎么一个发展法呢?首先的话呢,就要先考虑清楚,作为一个个人的话来讲,你想做什么你对什么感兴趣哈,为什么想做这个。自己想好的话呢,然后可以看一下自己有什么样一个差距,可以通过做Scrum Master帮助你把那些差距锻炼一下,找平。当然呢,也会有人跟我说,以前在国外的时候,在欧洲的时候也会跟我们说,说Evelyn,我就想做Scrum Master,特感兴趣,我一个同事,德国一个同事,就特别的喜欢做Scrum Master。他呢,原来是个经理,自己主动开始做Scrum Master,因为他跟我怎么说呢,他说在做Scrum Master的时候啊,他感受到的自我成就特别巨大。因为呢,同时呢,他可以帮助到团队、帮助到个人,然后呢,可以看到这个团队在成长,也可以怎么样,帮助他的组织在改变。同时呢,自己还有机会学到很多的新东西。他就特别喜欢做。他觉得原来做人事经理的,做经理,做一线经理呢,总是去管一些人呢、成长啊,觉得好像说旁边做的项目呢,好像觉得想帮帮不上,然后好多新的东西自己都不了解了,做Scrum Master呢,把他所有想做的事情,这个他的愿望都满足了,他特别喜欢做,现在还在做Scrum Master。

所以呢,很重要的一点,就是说呢,不论你现在在做什么样的职位呢,都要自己先考虑一下自己的一个职业规划是什么,看看怎么样可以自己帮助到自己,就算你是说,我也是不想做经理哈,我也不想做项目经理,我想做什么呢,我想做一个技术专家。就算你做技术专家,你还怎么样了,还是需要提高一个你的技术领导力。不然的话就说去开一些会议啊,那你有一个非常好的一个,例如说一个proposal,那怎么样啦,那你没有办法让大家别人接受,你讲出去的话,一讲出去给大家听,大家呢,不认同,你的影响力不够。所以呢?无论如何的话不管呢,你想做有什么样一个职业规划呢,你还是都是做Scrum Master还都可以帮助到你的哈。所以的话呢,尝试做Scrum Master,是一个可以帮助个人成长的这样一个一个过程。

下一个的话呢,也是一个关于Scrum Master大家经常问的问题。这个问题呢,Scrum Master会问,经理会问,团队成员也会问。Scrum Master时间呢,是应该怎么分配的呀?然后,Scrum Master应该是不是全职的呢?这个问题,我知道,我跟很多的团队聊过,他们问的时候呢,和很多时候团队在问的时候都怎么样呢,因为他们不理解,他们看不到Scrum Master在帮团队做什么,所以他们总是在考虑Scrum Master这个时间应该是怎么分配呢?应该是全职的吗?因为怎么样,这样的话,如果你的团队在问这个问题,如果你是Scrum Master你可能考虑一下,唉,我给团队带来的价值都有哪些,我还可以带来什么样,一个更多的一个价值。这个的话呢?在2011年的全球Scrum讨会Scrum Gathering上面有这样一个统计的数字,75%的Scrum Master不到一半的时间,在当前的团队里。45%的Scrum Master呢,同时支持两个或者以上的团队。85%的Scrum Master除了Scrum Master角色呢,还担任其他的角色。这个呢只是一个统计数字而已哈,这个并不代表说这样做就是对的。只是说,唉,11年的时候,这样一个统计数字是这样的,如果你好奇知道的话哈。然后呢,从建议来讲的话,书中给了一些建议,我也加了也一些我自己的建议。在Scrum圈子里,大多数人还是坚持认为Scrum Master的角色非常的重要,应该是一个1:1的关系。说直白了,也就是说,应该是一个团队,怎么样,就应该有一个Scrum Master。最好呢,一个Scrum Master,也就怎么样了,也就带一个团队。这里主要的一个建议是什么样呢?在我们团队建立、磨合或者成长期的时候,我们建议是一个什么呢?我建议有一个全职的一个Scrum Master。当团队慢慢成熟的时候呢,团队,Scrum Master可以照顾多于一个团队。这个呢,前提条件是什么呢?是我们没有什么系统性的大的障碍。这些都已经例如说在被前期的时候都已经被扫除了,那可以是可以这样考虑的。这个时候的团队应该怎么样啊?应该已经到了一个自己可以持续改进、持续进步的这样一个正轨了。这个时候呢,Scrum Master或许可以照顾多于一个团队。

另外一种呢就是说当团队怎么样呢,已经达到自组织、自管理的状态时呢,或许你还可以再照顾多一个团队。不过呢,大家也看到我写了哈,黑色写的,说怎么样?不过呢,真的是真心的,是很少见的哈,因为这个时候的团队应该怎么样啦,是一个精英中的精英,很少见的,如果有真的有这样团队呢,的确Scrum Master可以再多带一些团队。不过还是要说这样的团队呢,不是很多见的。原因是什么啦?因为我们想让一个团队达到可以达到一个自组织自管理的这样一个状态的时候呢,一般一个团队还怎么样,我能维持团队在一起时间比较久,给一个团队成长的过程呀,这个团队发展的话,这些状态肯定都要经过的,最后进到什么,进到一个高效的这样一个状态的时候,还是要花很多功夫的。所以呢,的确是不多见的。

同时,下面呢?我们再看一个关于Scrum Master的最后的一个问题哈。经常有人会问我,包括今天我在韩国哈,今天韩国的时候同事也问我说,唉,你对轮流做Scrum Master是怎么看的?我们已经开始轮流做了。这个呢话呢,要看我们团队是在一个什么样的状态,很可惜的是什么呢?大多数有人问我这样问题的时候,等我去真的问一下,去一个状态,看了团队的一个状态,很可惜的是什么呢?大多数的时候,团队都是因为没有人愿意去做Scrum Master才会怎么样,决定轮流去做的。那再想想看,为什么大家都没有人愿意去做呢?因为团队里的这个Scrum Master怎么样啦?说白了就是什么,说白了就是一个打杂的一个阿姨。唉,说到这里的话呢,大家也肯定知道我的这一我的这个意见了哈。所以,所以呢,要先看看到底Scrum Master需要做一些什么,然后呢,可以有些什么样的收获,可以对团队有一个什么样的帮助。如果你们在你的团队里,也在纠结,说唉,我,我们谁都不愿意做,那说明什么了?因为你,你们把这个Scrum Master这个职位做成什么啦,做成一个,让大家觉得没有成长机会,做了就变成一个半职或者全职这样一个打杂的阿姨的话呢,那可能大家都要轮流做,恨不得像一个接力一样,赶紧啊,我赶紧跑时间赶紧过,最好是轮到我这个时候能有个假期最好了哈。然后赶紧把接力棒传下去。那怎么样,这个基本上就告诉我们说Scrum Master可能做得怎么样,是要提高一些哈。

分享二:Scrum到底是什么

好的,那我们下面呢,换一个话题,换个什么话题呢?说Scrum 到底是什么呢?大家也看到,写了哈,就是Scrum是一个框架,这个framework,不是一个方法。所以呢,要怎么样啦?要理解Scrum的规则,每个规则后面的价值和它意义所在。框架呢,提供更灵活,根据自己的环境的不同呢,怎么样?可以有不同的途径做事情。与此同时还要怎么样了,还要做一个事情,Scrum作为一个框架呢,有着一系列的规则,很简单的规则。很重要的事情是什么呢?大家一定要记住,一定要理解这些规则。“理解”在这里的意思是什么呢?明白这些规则为什么是这样的呢?会给我们带来什么样的价值。这样的话,在实践里面的话呢,我们才会怎么样,在Scrum的这个框架里面,我们去实践,我们才会能有更大的收获。并且同时还要记得什么啦,在Scrum的框架下呢,要有充实的内在来支持的。如果大家做下来的话,只记住Scrum的仪式,对吧,仪式的名称、角色的名称,只是做一个什么简单的严格转换,这种呢,也是见得很多了。大家可能哈说,唉,昨天我还是一个Team Leader哈,我还是一个小组长呢,今天我来了之后变成Scrum Master了。唉,有很多公司都会有这样一个转换,那这样的话会怎么样呢?如果做了这样一个很简单的转换,那么我比较坦率的说什么呢?Scrum在这样的一个状态里呢,不会生长的很好,或者可能说得再直白一点呢,没那么正向的话,跟他们一样,可能根本生长就不好。

下面呢,我们一块看一下哈,以下的几个团队在引入Scrum之后的情形。我们看一下案例分析,然后逐一分析一下团队对Scrum规则的理解是怎么样的。

第一个是什么呢?第一个是有一个功能呢,是怎么样,需要3个Scrum团队一起开发。他们产品呢,一般的状况是什么样呢?说两个星期一个Sprint,这3个团队在开始开发这个功能呢时候呢,就开始开始了个什么Sprint 0。在4个星期之后呢?他们开始开始了,他们的第一个是Sprint。这里面呢,还要说是什么呢,说唉,Sprint 0是个什么样概念呢?Sprint 0呢,是在为真正的功能开发之前呢,做的一些准备工作,一般来说是Sprint 0要短。短的是怎么样呢?但是还要有个目的是什么呢?要能够服务于整个功能的这样一个开发,例如啊,搭建一些物理环境啊,等等,我的建议是什么呢?就说如果再加再用Sprint 0这个概念的时候呢?一定要怎么样,了解Sprint 0想达到的目的,什么样的内容可以放到Sprint 0里面。如果做的不对或者不确认的话呢,那可能不用这个概念,可能还会好一些。因为呢,会看到什么啊?很多这样误用的,例如他这个3个团队的话,为每个Sprint才两个星期,他们Sprint 0就做了4个星期。这个怎么样了?肯定是有事情做的是不大对的,可能把很多的内容都塞进去了哈。

下面我再看另外一个另外一个案例的分析哈。同样还是这3个团队哈。然后怎么样了?其中的一个团队很新,刚从其他的产品转过来。所以呢,他们想要一个什么,那么3个星期,一个Sprint才能把工作做好。唉,这个情况会怎么样啦?就是说Sprint的长度是不是可以换呢?就是说,唉,原来两个星期,要不说你们两个星期,我3个星期,我们刚来的,对吧?这个一般来说哈Sprint的长度怎么样,最好有个规律。对于团队来说怎么样呢?有规律的节奏感可以帮助他们了解自己的速度哈,也可以帮助他们估算。今天我们也会稍微提一下估算呢。并且呢,在大规模的开发团队里面保持规律还是很重要的,例如说我在09年开始做教练工作的时候,那个2200人的组织里面的话,如果每个团队的Sprint长度不规则的话,那会出现有很多什么,很多需要协调的事情,这个里面就接触到了,有什么啊?精益里面的一个核心问题是什么,浪费。大家都很忙、产出不高的这样一个状态。对啊,每个人都很忙,但是怎么样了,把工作分分类,工作仔细分析一下,很多工作都是什么,都是属于一些没有增加价值的一些可以划分到浪费里面的这样一些工作。所以呢,同一个团队保持Sprint的长度规律性很重要。在一个组织里面,最开始也是要保持一定的规律性的。当然,可能我们在座的同学有的可能做Scrum做得比较久,说唉,我们现在已经开始做持续交付了。唉,如果开始做持续交付之后呢,这些可以再去探讨,那是最开始的时候规律性呢,的确是很重要的哈。

下面呢,我们再看下一个案例分析,还是对3个团队哈。然后呢,这次怎么样呢?由于这个功能啊,需要很多特殊的这个测试的设置,所以他们集体决定什么,把最后的3个Sprint作为什么啊?测试的这样一个Sprint。这个大家可能也不陌生的,经常会听到、看到开发的时候会怎么样,有各种各样的理由,测试都没有完全做好,然后最后怎么样增加一个测试的这样一个Sprint。有的,还有曾经也有过说怎么样说,唉,我,我那个文件,文档没写好呢,我再有一个文档的Sprint。这个呢怎么样,尤其是测试,测试呢,是开发的一部分。所以呢,如果不能想办法把测试在同一个Sprint里面做好,那怎么样啦,我们要了解到底是有什么样的障碍在那个影响我们哈。我们首先要做的事情呢,不是说去介绍3个测试的Sprint,是应该怎么样把障碍去扫除掉。嗯,不是去找一些什么变通方案呢,例如说,咱们说什么啊,测试的Sprint。这个Ken Schwaber这个Scrum的这个inventor哈,他也说过一个什么话了。用中文大概的翻译,就是说敏捷本身呢,不会帮助我们解决问题的,但是会怎么样啊?它会帮助我们把问题暴露出来,让我们怎么样,可以更痛苦的感受到问题,从而呢没办法再去逃避,怎么样,逃避我们要解决问题?如果呢,大家都是通过怎么样各种各样的变通方案来降低我们的痛苦,那怎么样?很不幸呢,是可能在多年之后呢,怎么样,我们会生活在一大堆的变通方案里面。所以呢?在怎么样有问题的时候呢,还是看一下障碍是什么,而不是说先去,我们先有个变通方案。

那然后呢,我们再看下面一个案例分析哈。所以这Scrum团队在一起做了半年左右的时间呢,觉得每个Sprint都做回顾会议啊,太耽误时间了。于是他们怎么样呢?是把回顾会议改成一起吃中饭,回来吃中饭聊聊就好了。这个现象呢?在很多的团队里面呢,都比较普遍的。很多时候,大家都会怎么样为自己前面的努力和进步啊,感到高兴感到自豪。可能呢,就多多少少,还有一些可能自满,感觉比较好说,唉呀,我们都已经做得不错了,不需要再做回顾会议了。那我们还是说到前面提到的两个事情。第一个是什么啦,Scrum框架里的规则,每个规则都有它的原因,都有它的价值。第二点是什么啊?说精益和敏捷,很多人也是说,谈到敏捷敏捷的精华精髓是什么,也是要持续改善的。所以呢,其实什么呀,没有最好只有更好。这肯定可以的,我不知道大家听没听过这个丰田呢,有这样一个小的故事、小的笑话是什么了?说啊,她去一个那个这丰田的,很多的高管,在快退休的或者退休之后,都怎么样被西方请过去做这个咨询。咨询的时候怎么样啦,咨询的时候他就去看了,一天都是蛮高价格请过来了,请过来之后,他就去看了看了之后呢,那个日本人,他也是盘着手,他也不说话,然后呢,就走来走去的看,听着大家的介绍。后来的话怎么样啦?后来的话呢,到下午的时候都快走了,他还不说话,大家急了,心想坏了,毕竟钱都付了,你总得说点什么吗?说到底我们怎么样啊,然后他就说了,我不知道,我不知道原因是什么呢?因为怎么样,因为我昨天没有在这,我不知道,昨天今天和你昨天比起来,你是更好了,还是跟昨天一样。把整个丰田的这样一个精神啊就是说怎么要持续改进的,这样一个精神像丰田的话,做了很多年,他们还是怎么样,在公司里面一直有这样的一个文化。所以呢?从精益和敏捷来讲,怎么样都是一个持续的改进,所以的话呢,做了半年或者一年了,就算两年几年的话,其实还是有地方可以改进的。如果有兴趣的同学呢,可以看一看怎么样怎么去组织回顾会议的这样一些工具啊,建议这个书还是蛮多的。这样的话呢?只让大家看到回顾会议的价值怎么样啦,大家就会愿意开会,也就不会这样有名无实了

然后呢?这里面我再加自己的一些感受哈。实践里面呢,总是有人把Scrum作为一个方法来用。然后用了之后怎么样啦,就会产生一些很不好的一些后果。第一呢,团队呢,没有得到最大的一个收益,同时还会怎么样,然后觉得是我们Scrum非常的教条,可能让觉得觉得很讨厌。这怎么说呢,可能都有点把Scrum这个声誉都带得不好了。所以呢我们在做的时候,既然大家呢,对Scrum感兴趣,做的时候呢,我们还是对每一个规则呢,还是有还有它的价值啊,后面的意义呢,都了解清楚,这样的话呢,对我们才有更大的这样一个帮助。

分享三:用户故事的切片

好的,那我们再看分析的第三个内容,是关于切片。那大家看看呢因为我不是很了解大家对Scrum的一个经验有多少,有可能有的做的已经很久了,所以想想在工作里面呢,都有什么东西需要切片呢?那可能我们有同学就说了,唉,切片怎么样啦,用户故事需要切片。哪一直以来呢,用户故事的切片呢,上大家怎么样觉得多多少少都会有一些纠结的地方,到底怎么切呢?还有,另外是什么呢?另外一个大家纠结的地方,就是说怎么把用户故事在切片成具体的任务呢?所以到底怎么切比较好呢?用户故事,切成小的用户故事,和把这个用户故事,切片成具体任务,多多少少呢,都有很多的相似性。

我们先在这里,结合一些书中的内容,我们看一些什么看一个例子哈。例如现在有这样的一个例子,一个案例分析哈,这个作为一个新的客户,我希望登录到这个某某网站。这样呢,我就可以怎么样享受他特别好的这样服务了超级酷的服务。唉,任务一是什么啦,设计一个端到端的功能测试方案。第二个是什么生成一个什么测试数据,下一个呢?开发数据库层,第四个是开发业务逻辑层,任务五是什么啊,开发用户的交互层,第六呢,是开发什么端到端的这样一个功能哈,自动测试案例。

那你对这样一个切片划分成具体任务的例子,你怎么看呢?换句话说,你觉得这个切片切的怎么样呢?那我问问,大家说唉,这个你觉得切片,你觉得这符合逻辑吧?这个是不是属于简单易懂呢?或者你觉得是不是挺好用的吗?那你再仔细看看的话,刚才这个切片的话,怎么看起来是有点像瀑布式开发呢?对吧?我们可以再看一眼啊唉,是不是像瀑布式开发,就是只是很迷你的一个瀑布而已。对啊。那我们有什么样的办法说,唉,可以在任务层面上,也是用到用户故事层面的一个纵向切片法呢?要是这样的话,我们会怎么样啦?我们很快就可以从端到端,开始验证我们的工作。这样不是更好吗?对吧?那下面呢话呢?

我们再看一下那个案例分析二。同样是一个一个一个故事啊,作为一个新的用户,我希望登录到这个网站。然后呢,这个时候呢,任务一是什么呢,开发用户名和密码的功能,然后括号里还写了说包括测试设计和自动化。第二是什么啊,开发电子邮箱邮件的这个权限功能。第三个是什么,开发登陆网页的这个功能。那,大家对这个怎么看呢?再看看咱们说符合逻辑吗?简单易懂吗?是不是好用呢?这个例子里怎么样啦?我们把故事分成一些封装好的最终的用户功能,每个包括都包括一个什么啊,一小块数据库的动作,还有一个业务逻辑的动作,还有一个什么用户界面的一个实现。

这样的话呢?如果刚才说是前面那个案例一的话,如果我们说是什么,把一个是一个迷你的小的瀑布,对吗?那我现在怎么样啊?现在我们现在相当于把那个迷你的小瀑布变成了一个什么小河流流下来了。这样的话怎么样了?我们反馈的这个周期就短了很多。所以呢,这种切片呢,是怎么样,我们比较推荐的哈。嗯,就说无论是用户故事的切分呢,还是用户故事切分成任务呢,都让大家记得说,唉,我们想吃,怎么样切成片呢,这样竖向切的这个蛋糕,这样会怎么样了啊?这个最好吃一点。这样啊,怎么样,你切了之后,才会有人站排等着你这个蛋糕的。

这个呢话呢,从我个人的一个实践呢,我想为大家推荐一个这个读物哈,这个大家看说怎么样,我想介绍一个,大家看到名字是Richard Lawrence,这个也是当时我09年被送去学习的时候的老师之一。他呢,那个时候刚刚总结出来一个什么啦总结出来的关于用户故事的一个技巧的总结,就专门怎么做什么,这个story splitting的这样一个cheat sheet。他准备了一个,这个只是其中的一个一部分哈,我给大家截图下来。然后我的底下呢,也有这个呃,网页的连接。然后呢?当时呢,我学习的时候呢,就给我们用了,也就让我觉得蛮受益匪浅了。因为当时大家也记得,我说我们那个组织是多少,2200人,你想我们做的产品是很大的,每一个功能都是要很多人做的,所以当时就是切片,怎么能把这个用户故事切小了,对吧?当时真的是属于在那揪着头发,真的很辛苦,就是怎么切也切不小。而当时呢?Richard的这个写的一个东西,对我当时还是很蛮有帮助的。唉,所以呢,我给大家也推荐一下,如果你觉得对用户故事切片,感觉有挑战的话呢,可以去看一下它这个总结的这个技巧。

分享四:用户故事的完成标准

下一个的话呢,我们一块探讨一个一个什么呢?探讨一个完成标准。这个呢,也是最开始刚刚接触事,关我们同学可能多多少少都纠结的地方。因为不知道大家的一个用Scrum了多久哈,一个经验,这个之所以分享这个,还是因为什么呢,并且也发现很多的团队,就是说可能都用了三四年Scrum了,他的完成标准并没有任何的一个变化。哈,没有一个任何一个一个一个进展,所以呢我想谈一下这个关于完成标准的事情。完成标准是什么就是DoD,或者叫什么,Definition of Done,当人多的时候怎么样了,复杂性就多了。对啊,同时的怎么样呢?同时设定和统一期望值呢,就变得更加的重要了。如果整个世界里就你一个人,对吧,多简单哈,你想期待啥就期待啥,都清清楚楚的,俩人呢,也容易点儿,人越多越复杂。所以呢,完成标准怎么样了,帮助我们来实现这一点,说怎么样能把我们这个设定和统一下我们每个人的这样一个期待值。完成标准呢怎么样帮助我们定义在交付的时候呢,我们需要有一个什么样的期待,那包括什么呀,包括在产品的质量上呀,还有产品的一些属性上等等。然后呢一般来讲哈,我们有几个层面的这样一个完成标准。

在书里面,我们谈了,怎么样谈了3种。第一种是什么交付完成的标准,第二个是什么用户故事的完成标准,再一个是什么任务的完成标准。那我们现在怎么样呢?我们也把内容扩展一下,我们还是看一个3个团队的哈。我们看一看3个团队的这样一个案例分析,一个功能呢,还是有3个团队来开发,那我们看一下什么呢?以上3个层面的内容一样吗?第一个就是说这个123团队,他们任务的完成标准需要一样吗,还有他们的用户故事的完成标准需要一样嘛,还有,最后他们交付的完成标准需要一样吗?咱们先从最后一个看哈。

交付的完成标准是什么,是产品的层面上的。所以呢?无论有多少个团队,我们最后产品的这个交付完成标准是一样的,所以这个肯定是一样的哈。

用户故事的什么完成标准,是在一个Sprint的一个交付层面上的。这个怎么样啦,3个团队在做同一个功能,所以怎么样还是要保持一致的。不一致的会怎么样啦,我们的Product Owner,我们可能要抓狂了,他怎么样?他记得每个团队的完成标准是什么样子的。他光记住怎么样啦,还是个小事情,最重要的是什么啊,交付出去的软件是不同的,对吧?唉,有的软件是什么样啊,是多一点的,完成标准,有的少一点的,这样怎么样?从质量上产品属性上怎么样,都是不同的,慢慢的,可能他的Product Owner和我们,包括我们团队都要分裂了哈,所以呢,这个怎么样也是要保持一致的。

然后在任务完成的标准层面上是怎么样呢?这个的话呢?每个团队是可以互相学习的看看。唉,你们团队这个任务完成标准是到什么呢?可以相互学习,但是每个团队都有自己怎么样,可能有自己的一个,什么特殊的一个状况,并不一定要保持一致的。

那我们再把这个案例怎么样,我们也扩展一下哈,扩展一下这个到刚才跳出来那一页了哈,随着时间的变化,这3个层面的内容是否会有变化呢?大家想想看,大家想想看哈,还是这个3个团队随着时间的变化会发生什么事情呢?一般情况下哈,一般情况下大家会怎么样?技术水平提高了一些啦,对吧?对产品了解多一些啦。然后怎么样开发的过程提高了,因为怎么样?我们自己要持续改善啊,可能引进了一些工具啊,做了一些改善自动化,可能多了一些啦。然后呢,我们再看看这3个层面的完成标准有没有变化哈。

大家可以先考虑一下哈,那这3个层面会有变化吗?咱先看一看,第一个交付的完成标准,随着时间的这样一个推移,对吗?刚刚才我们讲的那些变化,完成标准是在什么在产品层面上的,按理说怎么样,可能是应该是保持一致的,但是也可能怎么样啦?我们持续改善我们对什么,对我们自己产品的质量要求更高了,我们熟悉也提高了,所以呢,也会有一些变化的,是往更好的方向变。这是交付的那个完成标准。

下一个是说,用户故事的完成标准是怎么样啦,是在Sprint的一个交付层面上的,那团队提高了怎么样啦?完成标准应该增加了,因为我们的目标是什么呀?我们目标最好、最理想的目标其实是什么?最好的话是应该用户故事的完成标准,要能达到我们交付的完成标准了那最理想了,当然怎么样啦?不管你做什么产品,多多少少肯定还有一些纠结的地方哈,但是怎么样啦,我们的目标还是什么呢?想让我们这两个跟交付层面的完成标准最好能怎么样,越来越近。这样呢,才是什么一个比较好的这样一个走向。

下面应该是什么任务的,完成标准是团队层面的,这个怎么样啊,还是要看自己的一个团队,看自己一个什么样的变化,按理说怎么样了,可能也多了,也变化了,也变多了一些哈。

好的,那我们再看一个什么最后一个关于完成标准的这样一个问题哈,嗯,经常也会有人问,说接收标准和完成标准的区别。当然了,有以前上过我课的同学,可能就是说了,说唉唉唉,您经常问一些这些怎么样比较诡异的问题,有什么有没有区别的,区别是什么。然后最后是怎么啦?答案是没区别。那大家看看接收标准和完成标准的区别是什么呢?有区别吗?如果有的话区别是什么呢?接收标准是什么?是Acceptance Criteria 哈,那完成标准是Definition of Done,这是一个经常时不时都会问到的问题。一般来说怎么样呢?一般来说,所涉及的内容适用于所有用户故事的那会怎么样啊,就应该是Definition of Done,完成标准的这样一部分。如果呢,只是涉及到什么一个或者一部分的话,就应该怎么样进入接收标准。这就是一个接收标准和完成标准的区别,他们是有区别的哈。

分享五:用户故事的估算

好的,那下面的话怎么样?我们的谈一个是关于什么啊?关于一个估算的一个事情,这个是敏捷中一个非常非常重要,但是呢,经常没有被好好利用的这样一个概念,怎么样,敏捷里面我们推广的是一个什么啊?一个相对估算,还有一些什么啊?我会介绍一些关于相对估算和关于估算呢一些怎么样有关系的几个事情。在这个书里面的话呢?大家有这个书,或者计划买这个,说哈我怎么样的?就是说想看的话是书的捷径,13、14和15呢,介绍了一些关于估算的一些事情。同时呢,这部分里呢,我也会介绍一些什么书里没包括我自己引伸出去的内容,我觉得可能会对这对大家有帮助的。

首先呢,我们先看一下哈,第一,我们为什么要估算呢?咱不是说了吗?说那个敏捷宣言里已经说了,说我们要干嘛呀?我们要提中精力去找一个什么工作的软件,做工作的软件是最重要的,对吗?那我们干嘛还估算呢?对吧?估算的话怎么样了?在业界啊,有很多很多关于估算的这样一个讨论,敏捷宣言是2001年对吧?到现在这么多年呢,这个关于估算的讨论呢,从来就没停止过。那说了,那如果是都是说工作的软件最重要,对吧?那我们干嘛还估算呢?其实估算呢,还是很重要的对吧?第一怎么样了?在书上举了一些例子哈,但主要两点是什么,一个是帮助我们做出比较周全的这样一个决定,第二,怎么样帮助我们设定一个这样的目标哈。如果要是怎么样了,谈到我们一个产品的话,不管你的产品是什么啊,是个新产品啊,还是你的做的东西是什么啊,是在老产品上面,怎么样增加一些功能,知道大概的这样一个估算,会有什么样的好处呢?对产品的整个一个开发呀,销售呀,推广啊,都是很有帮助的。

在牢记工作软件是最重要的一个同时,怎么样啦,我们也就知道了,就算要估算呢,还是工作的软件相对更重要一些,怎么样呢?我们还是要一定要尽量减少做估算,这样一个时间和精力。于是呢,我们怎么样呢?就一定要知道,另外一个敏捷里面推推广的这样一个概念叫什么呢?叫相对估算,那什么是一个相对估算呢?从估算来讲的话呢,我们可以第一,我们大家都会做的一个是什么,我们可以拆分的吧,我们把我们的用户故事怎么样呢?把用户故事一个一个的都拆分拆分到一个,一个什么把需求拆分了,拆分成用户故事用户是在拆分成什么啦任务,然后我们可以在估算任务的这样一个大小,对呀。唉,这样做的话呢?可不可以呢?可以肯定是可以的哈唉,但是呢,如果我们要想,如果要把一个很大的这样一个功能,通过这样拆分的方法来做估算的话,怎么样呢?第一会花,很多时间,对吧?爱花时间是因为什么第一,把拆分要花时间第二的话怎么样?每个人估算的时候,每个人估算都会有有有有有区别的对吧?有的人怎么样啊?比较乐观,一些有的人可能就没那么乐观,可能或者说什么啊,稍微悲观一点,有的人觉得说,这个任务的话,例如说我8小时可以做得完。例如说有人就说了不行,我要24个小时,做得完,对啊,然后就开始讨论,最后讨论说ok,那我们16个小时好了,对啊,所以就算花了时间估算下来之后怎么样啦,是不是精确还是另外一个问题,所以呢?这种拆分的方法呢,就是一个叫什么绝对股算,怎么样,我们是至少我们的目标是什么,非常努力的做到什么,一个精确做到一个精确。

然后呢,相对估算使用的是什么呢?一直比较的这样一个原则,选好了一个基准就开始比较,这个相法,这个方法怎么样会更加快,更加准确。这样的话呢?有刚才我们讲呢,有的人乐观,有的人悲观,对吧?唉,但是我们怎么样有个基准,这样,你把你的乐观的因子和为悲关的因子呢?几乎怎么样,可以怎么样,可以因为我们在对一个相对估算,不管你是乐观也好,悲观也好,这个因素呢?其实呢,也在里面呢,怎么样因素不是特别大的。哈,所以呢,如果我们相对估算呢,用比较的原则,相对来说怎么样来会花更少的时间,并且呢?怎么样呢?人经常这是有这个心理学有研究的话,怎么样人,我们不是,尽管人都非常的喜欢数字,但是怎么样了?我们对数字怎么样,都会是每次做这种估算呢说估算数字的时候都有纠结花很长的时间,并且呢,时间的投入和精确度,到了,过了一段时间怎么样了,就不再成正比了。最开始的时候,例如说开始拆分的时候,拆分成用户故事,拆分成比较大块的时候,那个时候怎么样还是个线性的,就是说,唉,头有投入,具有怎么样,有有进步了有产出,大概可以开始估算了。但是呢,投入的时间越多,并不代表什么啦,你的你做出来的这个估算越准确,并且慢慢的怎么样了这个,这个整个线就慢慢的越来越平,怎么样收益实际,先头出去的收益特别小啊,所以呢,我们怎么样呢?如果要用相对的估算的话,还有个什么好处呢。

除了少花时间,还有,就是说,呃,万一出现了变化,比较容易调整。这个的话一般呢。是时候,那个我讲课的时候,像上次我在清华和南大我讲那个关于那个敏捷的时候,我基本上都用一个什么了,说因为我们一个去,例如说我们都从来都没刷过,屋子刷墙,从来没刷过了。如果,我们去刷墙,用相对估算的办法去估计说唉,我帮Evelyn去刷他的屋子,能花多长时间,然后呢?可能怎么样了,比如说Evelyn,可能旁边又租了个房子,还想刷唉,这怎么样了,增加了我们还用同样的方法怎么样去做,万一说怎么刷,一刷之后说哟,有两屋,那可能,最近经济比较紧张,我不刷了对吧,怎么样最可以增加也可以减少,因为怎么样了,例如在我们现实生活中,现在变化怎么样,越来越多,唉,我们变化包括多种哈,第一个怎么样客户的需求可能会有变化,还可能什么啊,最初可能没理解对对客户的需求或者怎么样,这货客户真的变了,或者怎么样,技术变啦,然后还怎么样?还有就是什么呢?在估算的时候,你总会有一些假设,对吧?例如说像假如说真的帮我刷房子的话,假如咱们大家都没刷过,因为说刷房子用刷墙肯定这么一刷就好刷了对吧,万一说有个窗户啦,还有墙上有个灯啦,这些东西这样的没刷过,不好刷还是不好刷呀,到底多不好刷,我们会怎么样,有一些假设,唉,可能怎么样啦,我们做做的说发现有假设,好像觉得说,例如说这工作特别难,或者特别简单,这个假设怎么样是不正确的,我们怎么样需要一个调整?如果出现这种调整的时候,用的是相对估算,怎么样?我们调整起来就变得怎么变得非常的容易。

然后下面呢?我们也是做几个案例分析哈,第一个是怎么,说怎么来做相相对估算。第一个我们案例分析是什么呢?我们团队怎么样了?上过Scrum课之后呢?使用这个扑克牌打分了,都来,都来那个用那个扑克牌了。然后用的时候呢,就感觉到什么呢等大家都把分打好还要把牌翻过去。这这个有的人很慢,你知道有人动作比较快,对吧?咵,一看好了,翻过去了,有的人怎么样,又慢悠悠的拿着排挑半天,对吧然后也没挑出来。于是大家怎么样?大家说,集体同意说把扑克牌打法调整了一下,但新规则是什么呢?谁先好了,就把分先报出来,然后这样的话就发现怎么了。这个结果是在这个,这个整个把打分的过程速度都提高了。

大家想想看,大家对这个案例怎么看呢?首先对吧,咱们要肯定一点说,团队成员想办法去提高这个效率,把这个时间缩短就肯定是一个一个怎么样是应该肯定的地方。同时呢?我们一起怎么样分析一下扑克牌为什么要翻过去?扑克牌翻过去是怎么样啦,是不想让大家相互影响。那不想让大家相互影响是因为什么呢?因为我们选择牌的时候,例如说你选3我选5对吧,任群可能选8,那我们怎么样啦?你用这个机会让大家怎么样,可以有机会显示显示出来,我们心里的想法的不同,通过这分数把这个不同选显示出来哈,然后这样把我们怎么样呢?把我们心里各自的想法呀,包括我们的假设呀,我们的理解啊,还有我们怎么样我们的一些知识,例如说怎么样了,或许我对测试了解的多一点,或许你怎么样,你对这个设计了解多一点,那这样怎么样?我们看问题思考问题怎么样,多多少少都有一些不同的。所以呢,把牌都准备好呢,是很重要的。因为我们怎么样可以看到大家不同的思维方式也怎么样,是个大家很好很好的这样一个学习的过程。这个就是我们第一个案例。

我们再看一个,下面一个案例。下面还怎么样呢?有些团队觉得这个扑克牌啊,还是有些麻烦,于是怎么样啊?他把扑克牌就改成了什么呢?T恤衫的尺码说,小小号,小号,中号,大号,大大号和大大大号。他就这个都改成这个T血衫的尺码了。大家不知道对这个案例怎么看,大家考虑一下哈,书中的作者呢?对这个看法呢?不是很赞同的。他的想法是怎么样呢?说因为在交付这个计划的时候呢?因为怎么总是要,估计估估估算好了之后,最后还要怎么样啦?我们还是有一个这样交付的计划,说,大概什么时候把这功能能能给客户交付出去哈,交付计划呢?说他觉得是需要再做一次再次转换的啊。

我自己的一个实践的经验的话是怎么样,我觉得是大家自己来决定。因为怎么样呢?因为我也是跟欧洲的一些团队呢还有跟中国啊,我们觉得因为我负责这个全球的又跟很多的不同的不同的团队,都有一些交互。我就发现呢,有很多的团队呢。例如说有的团队从10年11年就开始用那个T恤衫的尺码,他们用的喯儿熟,特别的熟,特别熟到什么地步呢?就是说,唉,他团队,还有这个Product Owner哈,他们怎么样看这个估算,你比如说看了多少,随便说啊,15个M,10个L,对吧,然后多少个22个XL,他看了之后,他很快的怎么样,就可以把这个就大概知道怎么做这个交付计划了。所以呢?这个呢怎么样,还是要看自己团队的一个状态.

然后的话怎么样呢?然后那个另外一个,就是怎么这个号码的话,是这的书上是有这个6种哈。这个的话,慢慢的我,我所接触的团队,他们用的时候怎么样了?那用的时候,他们怎么就把这个号码减少了,没有必要用这么多哈。他们经常他们给我开玩笑说怎么说呢?说在历史的长河里看一下哈,这个XS和S短超小号和小号,这个区别是多渺小呀,太小了,已经怎么样就不需要记了,所以他把那个怎么XS拿下去了,然后怎么样啊?你想大家也想了,同样的原则啊,这个XXL也就拿下去了。当然,他们还是有一个什么说,不能估太大了,没办法估,那就能直接扔出去了。所以这个怎么样,还需要大家看每个团队怎么用的哈,自己可以决定的,这只是一些建议而已哈。

下一个另外一个案例的分析哈,这个Product Owner和怎么样和团队呢?一起协作,backlog在怎么样?在逐步的这样一个完善哈,然后Product Owner怎么样啦?他的Product Owner想尝试一下,让团队估算一下所有的用户故事。并且呢想通过这个过程看一下那些用户,故事是团队感觉已经够清晰拉够小啦,哪一些用户故事还是有待提高的。不知道大家对这个案例怎么看,这个呢方法呢,是一个比较可行的方法,如果你做了一段很久的Scrum,到目前你没有尝试过,我是建议可以尝试一下的。这个里面呢,里面有两个方法,一个是什么啊?一个是Team Planning,他的第一个叫,什么叫规划扑克派对,这样一个是利用历史数据的,历史数据就是原来前面那些Sprint做的,或前面这些功能呢,怎么样?就是说这些在我在团队的时候怎么样,一般的告诉他们怎么样都放在墙上,放到什么地方可以看得到的,然后怎么样,随时可以飞一眼看一下噢,那个时候我对吧唉,然后他也给把我手里的跟那个比一下。唉,这个比较方便,他就怎么规划扑克派对,是用历史数据的。

或者呢?还有??????,这个也是当时09年的我一个老师之一,哈,它什么呢?它有个动态估算的这样一个方法。他基本上呢,一个概念是什么呢?都是通过这个站排这样一个概念,站排来比较,就像咱们那个小的时候,读书站排一样,说那排大小个一样对吧?唉,我往我不是很确认,往这边看看。唉,这样一点可能又有你比你比你高点儿,我又跑到后面去啊,基本上这个概念哈通过站排相互比较,然后怎么样呢?再然后把不能够估算的太大个的了,怎么样就扔出来了。唉,所以的话呢,这个是一个什么呢?是一个可以尝试的地方,要记住的就是什么呢,规划扑克排队的话是用的历史数据动态估算的话,这个是用的什么呢?是用手里的backlog里面新的用户故事。

然后呢?看图的话就可以这样看吧,就是刚才我说的所说的,比码比大小个。唉,你就说了哪一个用户故事对吧,然后你就可以比一比,哎呦,这个是可以放到五吗?对吧,唉,然后你怎么样?像那个白子里的话,那个算是呢,是什么动态估算它是最后放分的,先把大小个排好了。然后呢,给他在大大小小的归个组,给他们再放个分。所以的话呢,两个方式都是可以的,所以呢,就怎么样,这个案例里面还是比较可行的,这个比较高效,这个在嗯,已经比较久了,大概五六年的事情了,我们曾经怎么样,因为我们的产品比较大嘛,我们的话是应该用了,不到80几分不到90分钟的时间,我们估算过多少呢?估算了150几还180几个用户故事,这个还是效率满高的。

好的。那我们在下面再看一下一个哈,下一个也是案例分析。于是呢,怎么样啦,还是再估算的时候怎么样啦?嗯,对于相对估算呢,还是有些纠结,因为怎么样了,相对估算,跟我们原来脑子运行的模式不是很一样的,原来怎么样啦,原来我们喜欢直接就说拿个东西过来,我说有100小时现在的话变成估算了,变成这个斐波那契数字了,对吧,变成这个数了,那怎么样?还是觉得有一些纠结哈,然后后面还没有没有单位说是的3是个5,这样没有单位,然后怎么样啦?于是有一些团队开始尝试把绝对估算再转成相对估算。

这个的话怎么样了啊,这怎么样就好比你去学骑车也好,去学开车也好,感觉,有点害怕,一不敢骑,或者不敢开。于是呢,现在让你去哪,你怎么办呢?都跑着去,你最后你跑着去也行,最后都怎么办啦,最后的结果是你还是不会骑车,你要是学开车的话,还是不会开车。所以呢,觉得相对估算呢,还是一个相对比较简单,比较少花时间的这样一个方法,所以呢还是说没有好好利用的团队,我还是建议大家好好利用。就这种的话,把绝对的转成相对的,这怎么样了?这个其实对我们来说,这个帮助不是很大的哈。

整体结构总结

好的,那我今天呢,想分享的主要内容呢,刚才就是我说的这几样,这五样我们在一起快看一下,整本书的话,整体结构大概是这样的哈,从这个10个章节,包括这些内容,我们一块看一下,因为怎么样了,我们大脑只能记住,怎么样多少多少片信息啊,这个临时记忆跟我们那什么一样吗?跟我们那个Scrum那个团队的人数是一样的,七加减二哈,就是我们同时的话,只能记住5到9个信息,要经过一些重复才能怎么样进入我们长期记忆里面去。

那么一块看一下哈,第一个从起步来说我们怎么样,比较重要的一点是什么?Scrum到底是什么呢?我们通过4个案例的分析,第一个是什么呀,Sprint0。怎么样用的话呢?就要把它用的短,把一些怎么样搭建环境啊,这种的放到Sprint 0里面去。如果说用的不准确的话呢?我建议可以从Sprint 1开始用,并不一定用Sprint 0,有很多团队都不用Sprint 0,人家也过得很好的啊。就说用的话就用好了,不要就是说,把这个所有东西都放到Sprint 0里面去。再一个是怎么样,顺着这样一个规律性,不要随便的改他这样一些规律。再一个是什么这种测试的Sprint啊,这种怎么样了,从测试的这个Sprint也把它延伸到一个什么概念啦?一个各种各样的说,怎么样,一个暂时的一个解决方案,怎么样?对我们整个长期的进步呢?都是,其实是一个什么绊脚石。最好能找出来什么,一旦有了问题,有问题暴露出来,我们要尝试去解决这个问题,而不是以找到一个暂时的解决方案,不然的话怎么样?那打补丁一样,不停地打,然后就是怎么样,你整个是穿的衣服也好啊,还是什么全身都是补丁。再一个就是一个什么啊,回顾会会议。回顾会议也是一样,就是怎么,建议的话,还是怎么想想多尝试一些工具,尝试一些方法,还是有很多书可以看的,对吧?这个Rachel Davies有那个书啊,《Agile Coaching》这个也是被我们几个敏捷的爱好者翻译成中文的,大家都可以去看的哈。然后Scrum是怎么样,是一个框架,不是一个方法。他是框架怎么样,还是要里面有技术内容来支撑它的,所以呢,今天没有细讲,但是怎么样呢,就是Scrum最好还是怎么,有一些技术实践在里面。极限编程,里面怎么样,有12个技术实践。我还是怎么样,在爱立信内部也是非常积极的去推广的,怎么样,最好我们还是用很多的技术实践在里面才会帮助我们进步,才会把我们的框架怎么样,做的真好哈。然后呢,框架里面呢,Scrum的规则也不多,对吧?没有几个,但是呢,每个规则后面的价值和的意义所在呢还是要清楚的。

那我们再下一个呢,就看一下关于Scrum Master。其实我们最最开始讲的,对吧?唉,Scrum Master的一个能力的期待和时间的安排。还有一个什么了?Scrum Master也引申到了什么,我们一个个人的这样一个职业规划的这样一个连接,唉,看看每一个人,可以在敏捷的一个工作里面去,可以找到一个什么样的机会让自己去成长的。然后呢?还要怎么样,记得说Scrum Master的话呢,一定要有技术上呢,还是有一定了解的哈,因为怎么样,有很多的,我看公司内部也好外部为听说哈,Scrum Master都是怎么样,有一些Scrum Master慢慢怎么样,离技术越走越远,越走越远。会怎么样了?你做起来呢,就是Scrum Master也会觉得怎么样,做得比较吃力。

下一个就是关于什么,一个需求的,这样一个细化哈,这是切片。我们讲的切片,我们看了两个案例的分析,对吧?第一个案例是怎么样啦,横着切的,唉,第二个案例是竖着切的,就蛋糕是竖着切的,我们切片那个技巧,然后看了应该蛋糕的图片,也有一个推荐的这样一个读物,就是这个Richard Lawrence写了这个怎么样去怎么切片用户故事的。

再下一个的话呢,我们谈到了什么了,谈到了一个完成标准。而有两个案例里面,对吧?然后呢?第一个是3个层次的这样完成标准。还有另外一个比较重要,是什么啦?如果呢,团队开始最开始的时候,你有一个这样一个完成标准,如果一成不变的话呢,还是怎么样?还是有一些问题的。所以我建议是怎么样了,随着时间的变化还是怎么样呢?要看一下自己的一个完成标准,可以有什么样一个提高。因为完成标准,可以随时提高,只要是几个团队协调好了,对吧,在做一个功能的话,可以怎么样,可以快就变化的。然后我们也说到了一个完成标准和接收标准的这样一个区别哈,一个是所有的用户故事都有的,这样呢,就是一个什么啦,就是完成标准,如果是某一些的话呢,就是什么一个接收标准。

再下一个就是什么啊刚刚讲过的,我们说估算,为什么要做一个相对的估算?然后呢?我们做了4个案例分析,一个扑克牌里面为什么要翻牌?对吧?那翻牌这个概念呢,也是可以演延伸的哈。因为什么呢?我们在整个刚才讲到了,说敏捷里面人的因素非常的重要。我们每个人呢,都是有潜能,每个人呢,不管是说年轻人还在公司里做的经验,很老的人哈,很多很多的人都是有不同的潜能、不同的知识,所以在敏捷里面,我们怎么样精益敏捷都是说人的因素很重要。敏捷的翻牌就是怎么样,把让大家有一个非常好的环境,把大家一个想法表达出来,看到大家思维上面的一个不同,给大家提供一个学习的机会,提供表达的机会。这个呢,可以把这个翻牌的这个概念可以引发到很多其他的地方去的。大家可以自己在,嗯,那个工作里面也可以运用一下哈。下一个是说T恤衫的这样一个号码啊,大家愿意尝试的可以去尝试。再一个就是规划扑克派对。然后再一个就是动态估算这两种方法是怎么样,看一看说,唉,我backlog里面都写了这么多的那个用户故事了,他们状态怎么样呢?唉,最好能大家都能帮我看看能不能估了并且怎么样啦作为一个product owner,你还是需要做什么啦?你还要看一看一个交付的这样一个计划,跟团队一起,所以呢?这个这一两个每个厄都是可以对你有帮助的这样一个哈,如果就是团队来讲,你也可以怎么样,跟product owner一起说做一些这样的,规划扑克的派对和动态估算呢,这样一个工具呢,都可以帮助你们对backlog更好的了解,对一个交付计划的很好的了解。再一个就是绝对估算转相对估算,这个是绝对不推荐的哈。

结语

这个呢就是我要讲的这些内容。刚才呢,也是做了一个很快的这样一个小结,嗯,希望对大家有帮助,如果大家有什么问题的话呢,这个是我的联系方式,左边的话就是微信的那个码。然后再一个就是我的email。上面是我公司的email。底下是关于就是说IEEE的事情。因为呢,我们在IEEE上发表的杂志之类的,从中国来的还是比较少的。还是说大家有如果有兴趣的话,我可以一起帮助你看看,怎么样可以啊,发表些杂志之类的,如果你在学校里面呢,大学里面的话,这对你的那个,你都知道的,最近这个,呃,那个近期啊之类都是有帮助的。所以呢,可以随时联系我。

相关材料


[1] 《敏捷微讲堂:敏捷专家Evelyn谈Scrum捷径,敏捷策略、工具与技巧》,腾讯课堂,http://ke.qq.com/course/107384?mmticket=#term_id=100113855

[2] 讲座PPT, http://pan.baidu.com/s/1bi46nW

[3] 语音记录 (百度云), http://pan.baidu.com/s/1i4xPu89

[4] 喜马拉雅FM,敏捷微课堂。

[5] 《Scrum捷径:敏捷策略、工具与技巧》,Ilan Goldstein著,Evelyn Tian,徐远来 译,清华大学出版社2014年9月出版。 http://item.jd.com/11548820.html

One Reply to “讲座实录:2015年12月敏捷专家Evelyn谈《Scrum捷径,敏捷策略、工具与技巧》”

  1. Pingback: 讲座整理:2015年12月敏捷专家Evelyn谈《Scrum捷径,敏捷策略、工具与技巧》 – 冰块软件观察