阿里敏捷教练全面解析淘宝直播敏捷实践之路

1

背景介绍

阿里很少提敏捷转型或DevOps,阿里是强业务驱动的,不管用什么办法,一定要达到业务目标。

我来自敏捷教练团队,我们的职责是帮助团队拿结果。这里的团队不限于研发团队,我现在支持的团队包括销售团队和产品运营团队。我们要帮助整个业务链上所有职能角色协作起来达成业务目标。

阿里同学对敏捷的态度非常有意思。大家有问题才找我,同时会提醒我一句话,“我们不在乎敏捷,只要解决痛点和问题就行”。所以阿里的同学非常实在,就是要见效,只要他感觉到有效果,原来痛的地方不痛了,原来不通畅的地方顺畅了,他就觉得敏捷转型的努力是值得的。

面临的问题

我们更像一个内部顾问,团队带着痛点和问题来找敏捷教练,我们要贴着他的问题想办法,一起做实践的落地,一起评估效果。

  • 迭代过了一半,需求还没定

2016年5月底,我进淘宝直播团队的时候,主要的痛点是“需求定不下来”。当时直播跟电商结合还是新业务,没有人知道应该做成什么样。运营和产品一直在摸索。摸索的过程中有很多犹豫,这样需求出来的比较晚。手机淘宝一个月发一个大版本,可能离封版只有两周,这一版到底做什么还没想明白,开发和测试非常着急。

  • 开发时间紧,加班赶工

需求出来后,开发非常赶,基本在5-8个工作日把1个月的版本需求都开发完。一个大版本总要有些亮点,不能只做一些小改进。所以开发工作量很集中,这个时候开发都在玩命加班赶工。

  • 质量不达标,版本发不出

赶工是有代价的,赶出来的东西可能表面上看是OK了,但是内在欠的技术债比较多,质量容易出问题。手机淘宝用户量非常大,质量卡点非常严,有严重缺陷没修好绝对不允许上线。淘宝直播2016年3月底发布第一个公众版本(淘宝的用户都可以用),3月、4月、5月连续三个版本,每一个版本都没有赶上正常的发版节奏。要申请紧急发版,提申请的人超级尴尬觉得很没面子。

  • 线上问题多,运营变客服

版本发出去了,可是质量太差了,主播天天在说直播间怎么黑屏了,怎么闪退了。运营同学本来应该做一些拉新、留存,想一些玩法,结果很苦的在主播群里做客服,运营同学一片抱怨。

着手解决问题

  • 数据度量

我需要一个仪表盘快速了解团队。我们经常讲到底怎么去衡量一个团队是不是敏捷?或者现在有没有比过去更敏捷?有几个维度还是值得大家去看的。

速率怎么样?一个月能不能交付更多功能,或者交付功能的价值有没有提高。

周期时长有多长?从打算做一个功能到用户可以用上这个功能,享受到它的价值要多久。这个时长越短,团队的适应性越好,在短时间内能响应一个新需求并把它交付。

质量怎么样?很多团队敏捷转型的时候,一上来就追求快。短时间内是快了,却欠了很多技术债。过一段时间速率会下来,最后既没有快也没有好。我的思路是先保证交付的东西质量都特别好,一次把有价值的事情做对,去掉中间的返工、浪费。如果有很好的质量,架构演进会更容易,开发新功能会更快。从质量出发先好再快,长期来讲能够拿到又快又好的效果。

最后准时性很重要。在阿里尤其电商系,可能90%以上需求是倒排的。需求提出来老板不会让团队评估多久可以做出来,老板通常说这个东西很重要,什么时间之前一定要,而且不是光要功能,还要业务结果。阿里不看苦劳看功劳,我们直接拉业务指标看。

还有一个最重要的维度是业务目标。敏捷也好、DevOps也好,最重要的还是业务,如果业务没做好其他都是零。即便做了一百个功能,如果业务指标没上来也是白搭。对于团队来讲,老板跟你说10月底要达到什么样的业务目标,即便没有100%把握做到,也要找到一条可行的路,10月底前把这件事搞定,在阿里这样才是靠谱的。

接下来会讲我们怎么始终扣紧业务目标,做的每一件事情都可以帮助我们拿到业务目标。这点在阿里特别重要。我们会找一些具体的指标来度量这几个维度。

速率度量

完成需求数是一个简单的度量,说它简单是因为我们只度量了单位时间内完成需求的个数,我们没有算故事点数,也没有考虑功能大小。

如果需求非常大,意味着它的开发测试时间都会变长,第一次得到反馈的时间也会很晚。一个大需求如果拆成两个小需求,并且每个需求都可以独立发布,先上一个再上一个,其实是比完成一个大需求再发布更好。这个指标有一个积极的副作用是鼓励团队把需求拆小一点,逐步的迭代和优化。我会跟产品经理商量,有没有办法把需求拆到研发团队在5个工作日内可以提测这样的粒度。如果一个团队有四五个开发,一周之内搞不定一个需求,意味着这个东西本身很大或者很复杂。

这个度量指标提出来后有人问我,需求大小不均,为什么只算个数。我说是为了鼓励大家拆需求。他说为什么要拆需求,我说不要憋大招小步快跑。这样他自己会把逻辑理顺。

质量度量

看质量更多是看过程的质量,在提测以后发现缺陷的数量,还有严重缺陷和低级缺陷占比。如果同一批人,同样的周期,缺陷数量突增,就有点不靠谱了。从5月到8月缺陷数量有明显的下降。

严重缺陷很好理解,我们来看看低级缺陷。低级缺陷是傻子都能发现的缺陷。这个指标衡量的是提测质量。如果开发比较上心,对自己交付的东西有责任心,通常不会有很多低级缺陷。回顾会上我会问低级缺陷数量我们有没有办法降下去?团队商量后觉得一个月不应该超过十个,就变成一个目标了,团队会朝着这个方向努力。

周期时长度量

周期时长我们拆了三段:分析时长、开发时长和测试时长,合起来是总的周期时长。

6月的周期时长大概是30天,分析时长大约占了一半。需求准备的时间特别长,大家觉得应该花更多时间分析需求,以免没想明白。实际上我们会发现即便多一倍时间分析需求,也未必能把所有问题都想明白。我们做的是创新的事情,这里有非常多的未知,想在一开始就把所有坑找出来不现实。我们要在研发过程中去探索,而不是在前面增加复杂的流程和评审。

大家会发现从6月到8月分析时长缩短了,开发时长和测试时长增加了。尤其是测试时长从3天增加到了7天。以前我们是小瀑布模式:一个月的功能最后三天一起提测,测试同学加班到凌晨。后来我们改进为小批次逐步提测,迭代的早期开始就不断有需求提测,测试压力分布在整个迭代周期。

还有一点大家可能很困惑,为什么7月的时长这么可怕,如果翻到前面会发现7月份交付需求数量也变少了,这里面有一个很有意思的故事。7月有两个很大的需求插队进来,团队的并发增加了。那个时候看板上有些卡片好几天拖不动,因为开工了太多需求,研发同学根本顾不过来。7月是一个比较失败的版本,我把7月的度量数据拿给开发负责人,我问改进了一个多月,为什么周期时长反而变长了,完成的需求反而变少了。开发负责人非常聪明,说我们并发太高了,这时候我觉得不需要再多说了。其实数据的力量很强大,大家知道高并发的伤害,但是伤害多严重不清晰。数据显示出来,因为并发提高,增加了那么多等待,大家觉得这件事代价太大了划不来。 8月淘宝直播火了,不断有合作方找我们想要加塞需求。经历了7月版本,团队通过反思学会说不。到了8月,我们比较能控制自己的节奏了。

准时性度量

准时性我们看计划交付的功能有多少按时交付了。7月并发度提高了,速率并没有提高,准时交付率也下降了。我们6月和8月是100%准时交付 , 7月没做到。没关系,只要找到原因,吃一堑长一智就可以了。

变化的背后

聚焦业务目标

阿里是强业务驱动的公司,做任何事情在一个季度或半年,业务效果一定要被验证。淘宝直播是一个新业务,大家不知道往哪里去,这时候特别需要快速试错和验证。

我到手淘我也不了解他们的业务,就做了一个业务指标板,列出9月底要达到的目标,每个月发版后更新数据。

这些数据在BI系统里可以看到,为什么还要费力做个物理板呢?我观察虽然在BI系统里随时可以看到,并且大家都有权限,但是真正去看的就那么几个人,主要是运营和产品同学。研发 TL会看,一线同学一般不会看。大家也不太清楚正在做的功能对提升业务指标有什么帮助。

可视化以后,大家经常路过这个板,有时候就会聊两句,7月底了某某指标还没到一半怎么办,还有同学自告奋勇跟运营说有好点子,要知道以前都是运营说服产品和开发同学赶紧做。

业务主线

业务目标只是一个方向或者要去的地方,怎么到那里要有一个路线图,要有一个规划,这个规划是按季度做。产品、研发和业务三方负责人清楚季度规划,一线同学不清楚。后来我们决定季度规划定下来以后要分享给全员,所有人都要知道接下来三个月要去哪里,要攻什么目标,打法和策略怎样,分解到每个月要交付什么核心功能。这个规划就是我们的业务主线。

迭代目标

业务主线不落地也是空的,接下来迭代里的核心功能要扣住季度规划的业务目标和业务打法。我们做了比较狠的事情,产品经理不只要讲做什么功能,还要说明白做这个功能的业务价值在哪里,这个价值还要可度量。发布了这个功能以后看数据,比如直播间的观众有不同来源,有人从直播列表进来,有人从微博过来,有人是关注了主播从主播的直播预告列表进来,通过埋点可以知道每个来源对直播间UV的贡献。直播间UV这个月相比上个月有提升,到底哪个来源贡献比较大,上了哪个功能带来了这样的变化。有个新入职的产品经理以前做游戏直播也没有电商经验,但是她提的需求经过数据验证确实非常有效,大家非常信任她。反过来讲如果一个产品经理一次没命中,我们会觉得他运气不好,如果总是摸不中,再提需求可能大家要打一个问号。

迭代计划

我们的迭代计划可以一层层展开,从业务主线链接到核心需求。我刚去的时候他们刚好要发版,我问这个版本三个最重要的需求是什么。我分别问了三个开发同学,他们的回答不一样,有个开发同学直接跟我说做了很多,但是零零碎碎都想不起。6月、7月、8月我们主线很清晰。

迭代过程

迭代过程我们有物理看板,这是一个完整的端到端的板,这里只显示了一段。白色的是需求卡片,黄色的是任务卡片,红色的是风险、问题或缺陷,绿色的是谁做这个需求。我跟开发同学讲,每个人只有两张绿纸条,每个同学同一个时刻最多领两个任务,先领高优先级需求的任务,完成一个任务再领新任务。6月份开始用看板,集成封板前一天,我在钉钉上收到电子照片,所有需求在待集成那一列,然后开发TL跟我说感谢。之前连续三个版本都没赶上节奏,这次顺利集成了,大家都很开心。6月我们没有做更多的改进,只是把研发过程可视化出来,每天按照优先级的顺序更新今天进展如何,明天计划到哪里,有没有问题和风险。大家会有一种强烈的动力想把卡片拖到终点。

我刚进团队的时候大家觉得敏捷教练不干活,就是做了几个板弄了点数据,到底有什么用。大家也不太认敏捷这一套,比如开回顾会,我跟开发TL说开个回顾会吧,开发TL说代码写不过来没空开,我就说我很会控场,保证一小时之内开完。他有点活动心思,就开一个小时。回顾会开了以后,他觉得说的问题都在点儿上,改进行动也靠谱,就比较认同了。

去年双十一之后我离开淘宝直播去支持别的团队,今年1月底我去回访,发现他们的敏捷实践坚持得非常好,那个板比原来的更漂亮。阿里的同学都是价值驱动的,他觉得这个东西有用,才会坚持做下去。

快速验证假设

快速验证假设的工具在很多公司都有,就是A/B Test。在手淘A/B Test有非常好的技术支持,在APP里面集成SDK,服务端是现成的,很快可以接入。怎么样把工具用好是另外一个挑战了。

首页改版

当时想尝试在直播列表里透出直播信息,最容易想到把评论信息透出来,这样气氛能够感染到用户,吸引用户进来看直播。开发同学尝试了一个礼拜很苦恼地找我说,把评论透出来很麻烦,消息系统我们用了别人的,这个功能他们没有,要现开发一个。他们有一时排不上,就想看代码自己改,结果花了一个礼拜才调通接口,有没有办法可以快一点?我说最核心验证点在哪里,是不是透出来评论吸引用户进直播间?如果透出来的评论信息不是从消息流里自动获取的,而是在某几个直播间手动抓一些评论透出来,多久能实现?他说快的话今晚就可以搞定。先弄清楚验证的核心点是什么,再去看验证这个核心点最快最轻成本最低的方法是什么。

直播首页改版是很大的需求,我们不会所有东西一块做,而是拆成小点。每个点可以独立验证,而且非常轻,用户几乎感觉不到变化。这个例子里有两个点,一是底下赞的地方从静态变成动态,还有一个是从主播的静态图片改成直播间当前的十秒视频回放。这样可能气氛好一点,会吸引更多用户看直播。不需要PRD和交互视觉设计,运营直接和开发同学聊一下,大概知道要验证什么做成什么样,开发实现核心功能,推1%的用户做一个A/B TEST。数据如果有明显统计意义上的区别,可能摸对了,再按照做产品的方式精细地做出来。没摸对,成本肯定不会超过一个礼拜,这个事情不用再投入了。

一起打磨需求

需求为什么定不下来?

我去参加需求评审会,发现会开得很长,三个小时还没有结束的意思。还有需求评审会变成了需求讨论会。开发和测试提很多问题,好像产品经理都没考虑到。会后我问开发你是第一次看到这个需求文档吗?他说是的。人的大脑很神奇,复杂的东西只要足够长的时间都可以理解,但要在短时间内理解或者判断一个复杂的事情就非常挑战。开发和测试短时间内看一个很复杂的需求,很容易漏掉一些东西。另外有一些事情只有开发和测试知道,产品经理不知道,如果预先没沟通,只能现场聊。

从等待接棒到携手前行

开发说PRD交互都搞定再送到这里,不到我这一棒我不管的。这样到了需求评审、甚至开发测试阶段才发现问题,越到后面代价越高。与其后面发现很多问题,产品重新设计,不如一开始携手打磨需求。所以我们有一个需求小组。需求小组不超过五个人,通常产品经理、交互设计师和一个开发、一个测试足够了。

一起打磨需求

需求小组分工协作:产品经理要把为什么讲清楚,用户什么场景下为了达到什么目的要用这个功能,设计师看这么做体验好不好,是不是反人类的操作。开发同学会看技术上这么干是不是一个性价比比较好的路径,是不是有更好更轻代价更低的方案可以达到同样的效果。测试同学可以着手写验收标准,验收标准应该是场景化的:用户在什么场景下做什么操作,期待得到什么样的效果。验收标准完全可以跟PRD相互印证,指导后面的开发和测试,大家觉得这样的验收标准非常具体可衡量。需求小组里大家先有共识,再拿到大组评审。这里面有对比,当时拿了两个相对复杂的需求做试点,达成共识再到大组评审,很快就通过评审了。那些根本没参加需求小组讨论的也觉得这样设计很自然,因为大家想到的问题需求小组想在前面了。有一个需求没有经过小组讨论,产品经理想做一个比较炫的东西,被服务端开发TL拍回来,说这么搞技术上不可行,就非常悲惨,因为那个时候PRD已经写完了。

提高提测质量

我觉得度量是一个辅助性的工具,度量本身不是目的。团队聚焦于改进的目标,度量帮团队评估进展。低级BUG多开发肯定有进步空间,但是光有指标大家还是不知道怎么改进。

这个事情特别有意思,站会上测试同学说最近提测质量不好,直接闪退了。我问测试同学有什么建议。测试同学说第一次在系统里提测是可以的,信任你质量过关。如何自测用例跑不过,提测要打回。打回了以后,第二次不能在系统里提测,必须拿着手机装上提测版本APP到测试同学面前跑一遍自测用例。我问开发同学,大家觉得合理吗?开发同学觉得有点不好意思,因为确实提测有问题,说就这么办。开发同学自尊心强,让他拿手机到测试同学那里跑用例感觉很没面子,提测不通过的情况少多了。有很多改进很简单,而且不少点子是团队自己想出来的。

此外,大家还约定了明确的提测标准。以前“提测”比较随意,可能自己手打包。现在要求有一个构件号,这意味着代码合入代码库没有冲突,通过了静态扫描,基本上一些安全问题,还有低级编码问题会扫出来,这样才能打出来有构建号的提测包。还有端到端的自测用例通过,不能用mock。

从小瀑布到持续交付

为什么测试同学很晚才回家,因为以前是小瀑布,分析、开发然后整包提测。我觉得让女孩子加班到半夜非常不人道,一定要改。首先需求拆小,尽量拆3-5个工作日可以提测,从第三天开始就逐步有功能提测。

迭代缺陷增量趋势

以前我们在发版前三天所有BUG冒出来,8月我们发现在迭代初期有BUG出现,肯定有东西可以测才有新的缺陷出来。我觉得缺陷增量趋势是非常好的指标。

微软做敏捷转型的时候特别有意思,高层不知道底下团队有没有做敏捷,就去看缺陷增量趋势。如果是小瀑布,很长时间没有BUG,然后一堆BUG冒出来。如果持续有东西可以测,BUG会比较均匀地分布在整个迭代周期里。

对开发来说也很好,如果最后提测发现严重BUG,修完可能带来更多问题,最后BUG不收敛。尽早集成,尽早测试,其实是暴露技术风险最有效的手段。

总结:持续改进

大家可能会说敏捷教练很神奇,能够想到这么多招帮大家改进。事实上这里大部分改进方法都是团队同学自己想出来的,大部分问题也是团队同学通过看板和度量自己发现的。每个人天生就有获得成功和快乐的所有资源。 团队也一样,我相信每个团队都有变得成功高效的所有资源。我只是去帮助大家看到问题,激发大家想办法,引导大家持续改进。只要我们持续改进,这个月比上个月有进步,这个团队慢慢总可以成长为一个非常棒的团队。

作者简介:张迎辉(花名问菊):阿里巴巴敏捷教练,罗汉堂讲师,开发和讲授多门敏捷课程,先后支持手机淘宝、优酷、移动事业群等多个部门的团队敏捷转型。2011年开始接触敏捷开发,是认证的CSM、CSD、CSPO。亲身感受到敏捷给团队带来的改变,立志成为敏捷践行者。



本文作者:云效鼓励师

阅读原文

本文为云栖社区原创内容,未经允许不得转载。


如果觉得我的文章对你有用,请随意赞赏

你可能感兴趣的

载入中...