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

引言


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

本文是Evelyn大师的讲座整理,总结了Evelyn讲座的全部内容,去掉了某些跑题部分和关系不大的语气词语等。如想阅读讲座实录,可以阅读上一篇文章《讲座实录:2015年12月敏捷专家Evelyn谈<Scrum捷径,敏捷策略、工具与技巧>》。

本文仍不包括讲座之后的问答环节。如时间允许,冰块将会随后整理那些问题,并以Q&A的形式在另一篇文章中专门分享。

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


开场语

大家好,我是Evelyn Tian。很高兴有机会和大家在这里一起分享。首先,我想借这个机会谢谢组织者任群的邀请。还记得大概是11年还是12年的时候呢,那个时候还住在上海,参加了上海的一些活动,当时就觉得,我可以把自己学习到一些内容、经验,当然包括一些成功的,也包括一些走了弯路的一些经验,可以跟大家分享一下。但是我平时出差比较多,业余爱好比较多,比较忙,时间上总是很纠结。在线的分享这种特别适合我这个状况。今天能够通过网络跟大家一起学习、探讨很是开心。代表我自己,也代表大家谢谢任群,帮助我们这些对敏捷和变革管理非常感兴趣的同学提供这样一个平台,让我们有机会互相交互,有机会共同进步呢,谢谢任群。

自我介绍

首先,做一下自我介绍。我是Evelyn,来自爱立信通信有限公司。我在爱立信内部,有两个职责,第一个是负责我们爱立信东北亚研究院的精益敏捷。另外一个是负责我们爱立信,我们有一个这样全球变革指导中心,我负责这边的工作。我在爱立信大概有20年了。在这20年的话,做过多个岗位,从最开始做开发测试,也做过项目经理、产品经理系统设计架构师,一直做到客户支持。

2007年首次接触到敏捷。做过Product Owner,也做过Scrum Master。在2009年,公司内部有一个2200人左右的组织,开始做大规模敏捷转型。那个时候,我也转型为一个全职的精益和敏捷的教练。很感谢公司给我这样各种各样的成长的机会。当时我们请了9个不同的世界上比较有名的教练过来帮助我们一起在5个月的时间呢,培训我们,然后让我们可以回到公司里面去做内部的教练的工作。目前我还是比较努力的找时间去做一些具体开发团队的教练工作。因为我总是坚信,做为一名教练的话呢,无论如何,都还是要有最新、最一手的经历和实践才好。在软件技术实践上,我也是尝试着保持更新,保持领先。我是国际电子电气工程师协会的软件顾问,如果大家要是感兴趣在这个IEEE软件上发表文章呢,可以随时联系我。2016年的年度敏捷联盟年度学术会上,我也是技术实践的联合主席。我相信中国一定有很多新的好的实践,可以到世界上敏捷爱好者这个圈子里去分享的。我自己的主要兴趣方向比较宽,领导力、组织转型变革管理,然后对大规模的这个敏捷转型比较感兴趣。我是这个国际认证的专业教练。

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

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

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

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

我们现在就开始一起看一看这本书中讨论的内容。我们先看一下整个书的整体结构。这本书一共有10个章节,从不同的方面,从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,还是你们公司里项目经理,或许你是经理,普通经理、人事经理,不管怎么样,只要你们公司在用Scrum,都应该有Scrum Master这个角色。并且,你或多或少都跟他有一些交互,所以我们先看一下Scrum Master这个角色。在书里面,捷径4讲了Scrum Master应该具备的多项关键能力。我们来一起看一下。

第一条是多项关键能力的第一条,没有权力的领导。这一条是很重要的。因为这个也是个事实,Scrum Master确实没有职位权力。

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

谈到第一层的这个职位权力,有人可能会说,那不是很不幸吗?因为Scrum Master没有职位权力。我的看法,没有职位权力的人,换个角度去看,其实或许是个好事情。在公司内还是公司外,我听到了很多大家不同的心声,就是说,很多领导,例如一线经理,她都一直停留在这个领导力5个层次里的最底层,第一层,就是这个权力层次,是职位权力。一直停留在这个职位权力有什么问题呢?她领导力非常低。在这个阶段停留的时间越久,组织内部的人员流动率会很高。同时,就算人员没有流动,士气也会越来越低。

所以,我建议大家去看一下,翻一下这个书,就是《5个领导力的层次》,去体会一下。最基本是职位权力,其他还有个认同,认同就是人们把你当成上司般的跟从你,比刚才的职位权力好一些了。然后第三层是成果,人们跟着你是因为你对过去所做的事情,大家觉得你做的事情蛮有意义的,蛮有贡献的。第四个层次是你能帮助别人成长。人们跟着你,是因为你以前为他自己个人所做的事情。最后一层敬佩。人们跟从你,是因为你的为人,还有你所有彰显的一切。这才是最高的境界。所以我建议,想做Scrum Master的同学,或者在做的,可以去读一读,多多少少都会受益的。

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

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

再一点就是说有策略不玩办公室的政治。同时不要有私心。要保护我们的团队。保护我们什么概念呢?保护我们团队,团队可以集中精力做我们这个Sprint的开发工作。不然的话,有很多公司都会有非常非常重要的事情,要把人从团队里拿走。所以,保护团队的成员也是很重要的。下一条,我也要多说两句。就是关于技术知识,Scrum Master是不是要有技术的知识?大家都应该上过Certified 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帮助你把那些差距锻炼一下,找平。我一个同事,德国同事,就特别喜欢做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,你可能需要考虑一下,我给团队带来的价值都有哪些,我还可以带来什么样的价值。在2011年的全球Scrum Gathering上面有一个统计数字,75%的Scrum Master不到一半的时间在当前的团队里。45%的Scrum Master同时支持两个或者以上的团队。85%的Scrum Master除了Scrum Master角色,还担任其他角色。这只是一个统计数字,并不代表这样做就是对的。从建议来讲,书中给了一些建议,我也加了也一些我自己的建议。在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里面。如果做的不对或者不确认,那不用这个概念可能还会好一些。很多这样误用的,例如他这个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感兴趣,做的时候,我们还是对每一个规则,有还有它的价值,后面的意义,都了解清楚。这样的话,对我们才有更大的帮助。

分享三:用户故事的切片

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

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

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

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

这样,刚才前面那个案例一是一个迷你的小瀑布,那现在相当于把那个迷你的小瀑布变成了一个小河流流下来了。这样我们反馈的周期就短了很多。所以这种切片是我们比较推荐的。无论是用户故事的切分,还是用户故事切分成任务,这样竖向切的这个蛋糕,最好吃。这样,你切了之后,才会有人站排等着你这个蛋糕的。

从个人的实践,我为大家推荐这个读物,Richard Lawrence,也是我09年被送去学习的时候的老师之一。他那个时候刚刚总结出来关于用户故事的技巧,这个story splitting的cheat sheet。学习的时候,就给我们用了,也让我觉得受益匪浅。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个小时好了。所以就算花了时间估算下来之后,是不是精确还是一个问题。所以这种就是一个绝对估算。至少我们的目标是非常努力的做到精确。

相对估算使用的是一致比较的原则,选好一个基准就开始比较。这个方法会更快、更准确。有的人乐观,有的人悲观,但是我们有个基准,你把你的乐观因子和悲关因子可以考虑进去,不管乐观也好,悲观也好,这个因素其实也在里面。所以,相对估算用比较的原则,相对来说会花更少的时间。有心理学有研究,尽管人都非常喜欢数字,但是我们每次做估算的时候都有纠结花很长的时间,并且时间的投入和精确度到了一段时间就不再成正比了。最开始的时候,例如说开始拆分的时候,拆分成用户故事,拆分成比较大块的时候,那个时候还是个线性的,大概可以开始估算了。但是,投入的时间越多,并不代表你做出来的估算越准确,并且慢慢地整个线就慢慢的越来越平,收益实际,先头出去的收益特别小。所以,要用相对的估算的话,除了少花时间,万一出现了变化,比较容易调整。第一个客户的需求可能会有变化,还可能最初没理解对客户的需求或者这货客户真的变了,或者技术变了,然后还有就是在估算的时候,你总会有一些假设,例如说这工作特别难,或者特别简单,这个假设是不正确的,我们需要一个调整。如果出现这种调整时,用的是相对估算,调整起来就变得非常容易。

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

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

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

我自己的一个实践经验是有很多的团队他们用的喯儿熟,特别的熟,特别熟到他团队以及Product Owner, 15个M,10个L,然后多少个22个XL,他看了之后,很快的就可以大概知道怎么做交付计划了。所以这个还是要看自己团队的状态。

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

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

还有动态估算方法。通过这个站排概念,站排来比较,就像咱们小的时候,读书站排一样,排大小个一样,我不是很确认,往这边看看。唉,这样一点可能又比你比你高点儿,我又跑到后面去,基本上这个概念通过站排相互比较,然后把不能够估算的太大个的,就扔出来了。所以,这是一个可以尝试的地方。要记住的就是规划扑克排队用的是历史数据。动态估算用的是用手里的backlog 里面新的用户故事。

比码比大小个。你就说了哪一个用户故事,你就可以比一比,哎呦,这个是可以放到五。动态估算它是最后放分的,先把大小个排好了。然后呢, 给他在大大小小的归个组,给他们再放个分。所以,两个方式都是可以的,这个案例里面还是比较可行的,比较高效。大概五六年的事情,我们曾经用不到80几分不到90分钟的时间,估算过多150几还180几个用户故事,这个还是效率满高的。

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

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

整体结构总结

我今天想分享的主要内容就是这几样。整本书的整体结构大概是这样的,从这个10个章节,我们一块看一下。我们大脑只能记住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都是离技术越走越远,越走越远。

下一个就是关于需求细化,这是切片。 我们讲了切片,我们看了两个案例分析。第一个案例是横着切。第二个案例是竖着切,就蛋糕是竖着切的,切片技巧,然后看了应该蛋糕的图片,也有推荐的读物,就是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月出版。

后记


如果您觉得冰块整理文字太辛苦,想多给一些鼓励和支持,除了关注“冰块观察”公众号并在下面留下鼓励和支持的话,以及与作者进行讨论和交流外,还可以向作者打赏哦。

0 1