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

背景介绍

阿里不多提敏捷转型或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。亲身感觉到敏捷给团队带来的改变，立志成为敏捷践行者。

---

本文做者：云效鼓励师

阅读原文

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