张迎辉-淘宝直播敏捷实践分享-大熊

大熊

CHECKLIST

• 文章标题优化 是否足够吸引人
• 文章小标题 是否能体现文章逻辑结构
• 文章分段结构 是否已经达到小段落格式，能清晰的识别到作者说话的意图
• 文章精彩看点 是否找到每段落的精彩看点
• 文章导言 是否将文章中切入的疼点都体现出来了
• 文章错字 是否已经完成错别字的校对

不同的企业文化实施和接纳敏捷的方式也是不同的，阿里的同学非常实在就是要见效，只要他们感觉到有效果，原来痛的地方不痛了，原来不流畅的地方顺畅了，他就会觉得敏捷做的这些转型的努力是值得的...

作者介绍

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

背景介绍

大家知道阿里很少提敏捷转型，要进行DevOps，但在阿里工作是一个以业务指标强行驱动的，不在乎用什么办法，也不管用什么办法，一定要达到业务指标。

我们抬头的名称“敏捷教练”是这样叫，但是我们职责是帮助业务团队，包括研发团队但是不限于研发团队，我现在支持的团队包括业务销售团队还包括产品运营团队，帮助整个业务链上所有职能角色大家协作一起完成拿指标。

阿里团队对敏捷也是非常有意思的，通常他们都是有问题才找我，但是他们会提醒我一句话，“我们不在乎敏捷，只要可以解决痛点和问题就可以了”。所以阿里的同学非常实在，就是要见效，只要他感觉到有效果，原来痛的地方不痛了，原来不流畅的地方顺畅了，他就觉得敏捷做的这些转型的努力是值得的。

在阿里敏捷改进中的问题

我们的工作方式可能跟在其他公司有一点不同，敏捷教练更像一个内部顾问的角色，团队来找敏捷教练之后是带着痛点和问题里的，所以敏捷教练团队也要贴着他的问题想办法，一起做实践的落地，一起去评估效果。

1. 迭代过一半，需求还没订下来
   淘宝直播5月底，我进去的时候，他们主要的问题是“需求问题”，大家都知道去年的时候直播是比较新的话题，当然像斗鱼或者其他领域的直播要更早，但是直播跟电商结合在去年5月还是比较新的业务。

   既然是新业务，没有人知道这个业务应该做成什么样，应该往哪走，有没有好的效果。所以，产品也好，运营也好，其实他们一直在摸索。

   摸索的过程中有很多犹豫，这样产品需求会出来的比较晚，比如我们手机淘宝APP一个月发一个大版本，可能离发布版只有两周，这一版到底做什么还没有想明白，所以开发和测试非常着急。

2. 开发时间紧，加班赶工
   需求做下来之后，开发会非常赶，因为还要给最后的测试同学留下一些时间。

   所以开发同学基本在5到8个工作日把一个月的版本需求都提测开发。时间这么紧，而且一个大版本出去也不能光秃秃什么都没有，不能只做一些小改进。

   所以这个时候工作量很大又很集中，这个时候开发在玩命加班赶工。之前说有多少人996，我觉得我们一定是超越了996的。

3. 质量不达标，版本发不出
   赶工我们这里有不少研发同学都知道，赶工是有代价的，赶工出来的东西可能表面上看是OK了，但是内在欠的技术债比较多，想的还不是很清楚，质量也会出问题。

   通常来说，因为手机淘宝是用户量非常大的应用，所以质量卡点非常严，如果有严重等级S1、S2的BUG没有修好绝对不允许上线。

   有一系列指标比如耗电、功耗，其他性能等指标都有严格“卡点”。“卡点”过不了在发布平台上会是“硬卡点”，过不了根本就不让集成。

   淘宝直播从2016年3月底发布第一个公众版本（淘宝的用户都可以用）。到后面3、4、5连续三个版本，每一个版本都没有赶上正常的发版节奏。那么这一天就会因为没有多的淘宝模块要集成进来通过“卡点”。而他们赶不上的原因通常是质量达不到要求，就赶不上了。

   要发布也有办法可以发，但是要走紧急发版的审批流程，要一个非常高层的人审批，提申请的人是超级尴尬觉得很没有面子。而且每次审批人家会问为什么没有赶上，别人都赶上了。

   就算紧急发版，质量还是不好，因为“卡点”只能卡住一些最要命的问题，但是一些体验性的问题、应用性的问题，甚至是一些比较功能性问题解决得不是那么彻底。

4. 线上问题多，运营变客服
   我们有一个运营团队，本来他们应该做一些拉新、留存、运营活动想一些玩法，但是质量太差了，运营同学就很苦的在主播群里变成客服，因为主播天天在说看看直播间怎么黑屏，怎么闪退了，没有时间做自己应该做的，所以运营同学也一片抱怨。

着手解决问题的方法

数据度量

快速了解一个团队，我需要迅速了解这个团队现状的工具，简单做个比喻就是一个仪表盘。我们经常讲到底怎么去衡量一个团队是不是敏捷，或者现在有没有比过去更敏捷，这件事情可以比较的，这个团队有没有比过去更敏捷是可以比较的，有几个纬度还是值得大家去看的。

• 速率怎么样?，在同样一个月里面能交付的东西，或者交付这些东西的价值有没有提高。

• 交货时间怎么样，可能下一个订单到拿到货物要花多长时间。到研发过程类似的交货时间，从打算想去一个功能或者需求，可行性评估也可能是分析设计，从这个时间开始把秒表按下来计时，到这个功能真的上线用户可以用上，能够享受到它的价值这个时间有多长。

  通常来说这个时间越短，这个团队它的适应性更好，在短时间内能响应一个新的需求并且把它交付。

• 质量怎么样，有很多团队做敏捷的时候，一开始会说怎么能够更快，有的快是速率，有的快是Lead time。

  但是如果我去到团队里面，第一件解决快的问题，短时间内是快了，但是因为欠的技术债很多，反而过一段时间以后发现因为欠的技术债使得它不能够很好往前走，所以他的速率会下来，比如工程时间没有，质量不好。

最后他既没有快也没有好。但是倒过来我的思路是怎么样能够让我交付的东西质量交付都是特别好的，我能够一次性把有价值的事情做对，去掉中间的返工、浪费，因为质量不好是最大的浪费，有了BUG再有人把他检出来再修，这个中间很浪费。如果有很好的质量先要保证，然后再追求快。所以它开发新的功能，它的架构演进会更容易，所以质量出发先好再快往往是最后长期来讲能够拿到又快又好的效果。

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

对于团队来讲，因为是强业务驱动，所以它的可预测性很重要。老板跟你说十月底什么东西一定要上线，也会清楚这件事情很重要，那么什么样的团队是靠谱，我知道可能十月上线不是100%有把握，什么现在不知道能不能上线，但是我能够找到一条可行的路，十月底把这件事搞定，在阿里这个是靠谱的，所以在阿里这些事情是很重要的。

这几个纬度很重要，但是如果这个东西是虚的，可能看不见摸不着，我们没有办法看我们有没有进步，所以我们会找一些具体的指标度量。像质量可能是不只一个指标，可能是一组指标。

响应力主要是Lead Time，可预测性是测的比较简单，可能是计划到十月底交付哪些功能，到十月底这些功能有多少是按时交付的。

我觉得不管敏捷也好、DevOps也好，最重要的还是业务，在阿里如果业务没有做好其他都是零。因为在敏捷做了一百个功能点上线，但是你会发现UA还是没有上来没有用，那不管花多少精力在里面，这个效果没有出来的，所以在这里面所有其他的指标都是围绕业务指标。

接下来会讲我们怎么始终扣紧业务指标，做的每一件事情是可以帮助我们拿到业务指标的，这点在阿里特别重要。

任务度量

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

• Part1：如果需求非常大，Quality非常高，意味着无论它的开发测试这个时间都会变长，迭代周期也会变长，第一次得到反馈的时间也会变得很晚，所以我们希望直接看完成多少需求。

  同样的功能如果拆成两个需求，当然每个需求要独立上线可验证，如果拆成两个独立需求，先上一个再上一个，我会认为其实是比你完成一个大的更好，所以这个指标有一个副作用是鼓励你把需求尽量拆小一点，逐步的迭代和优化。

  小的程度基本我会跟产品经理商量，有没有办法把你的需求拆大研发团队在5个工作日内可以提交测试这样的力度，不能比这个力度再大，因为比这个力度再大可能在一个版本里面，或者在一个迭代里面没有办法交付。

  通常如果一个有四五个开发的研发团队，一周之内搞不定一个需求，意味着这个东西本身很大或者很复杂，需求描述都过于复杂。我遇到这种情况建议产品经理一个办法，把需求拆分到研发同学在三个工作日左右就可以提交测试的力度。

• Part2： 如果需且本身拆解成任务的时候，这些任务之间可以并发做，而不是偶合在一块，这个项目可以更大。比如做一个需求有前端有后端，有业务逻辑有数据存储，但是如果这几个任务并发都可以开工，不需要等后端好了再写前端，大家商量接口可以同时开工到点一起连调，这个情况可以做一个相对，因为可以三方同时开工做五个工作日也是蛮大的需求。

  这个指标提出来以后有很多人问我，为什么需求个数和大小不一样，我说就拆。他说为什么要拆我说为什么不要憋大招为什么小步快跑，因为他自己会把逻辑理顺。

质量管理

看质量更多是看过程的质量，在提测以后发现缺陷的数量，这里还有严重缺陷的数量和低级缺陷数量的占比。

当然我们也可以衡量密度，但是如果从团队角度讲，同样是做一个迭代，周期是一样的，在这个周期里面产生出越多的缺陷，就可能有点不靠谱了。我们从5月到8月缺陷数量有比较明显的下降，因为严重缺陷很好理解，低级缺陷是傻子都能够发现的缺陷。

衡量这个是提测的质量，或者是开发的质量，如果开发比较上心，对自己交付的东西有责任心，通常不会有很多低级BUG，如果这个数值比较高，我们会跟开发的同学讲，感觉这个值我们可以想办法降下去一些，开发经理会说一个月不应该超过十个，我就顺水推舟，其实对他们有一定压力的。但是因为在这个场合他会觉得这些BUG的确傻子可以发现也觉得不好意思，这个就变成一个目标了，他会朝着这个方向努力。

时间管理

这个是周期时长，分不同的工种所以我们拆了三段，这是分析时长、开发时长和测试时长，合起来是整个总的周期时长。

我们总的周期时长大概是30天，分析时长很高的，相当于需求前面准备的时间特别长，觉得需求应该花更多时间分析，以免后面需求没有想明白，但是实际上我们会发现即使给产品经理多一倍的时间，他能够把后面研发过程中的所有问题都想明白吗？会发现即使多给他一倍的时间他也没有办法把所有问题想明白。

第一个是说有些方面是产品经理自身的角色，它的支持经验所限，他想不到架构方面的问题，技术方面的问题。还有一个问题，我们现在是无卡的时代，我们做的是一件不是板上钉钉大家确切知道怎么做的一件事情，如果是那样谈不上创新，既然做的是创新的事情这里有非常多的未知。

所以想在一开始需求分析阶段把所有坑找出来，这件事不靠谱，所以我们觉得产品经理可能花更多的时间，因为迭代周期就那么长。

如果产品经理占那么长时间又没有很好的投入产出比，我们倾向于把这个时间放在后面，给开发更多时间，测试更多时间，让他们在后面把这些坑填上，或者在研发过程中发现什么问题我们解，而不是在前面搞很复杂的流程，很复杂的评审，结果最后发现开发不够了，时间不够了，测试时间不够了。

大家研究后会发现，尤其测试最后到8月我们给他们的时间是有更多，因为平均测试时长是2到3天，经过三个月差不多6到7天自然日。

这个大家觉得测试时间变长了，大家可以想像我们一个月的功能，手淘发一个版本很大，一个月功能平均只有两到三天的时间，对测试同学非常有挑战，这两到三天是集中式的，是一个小瀑布模式，前面一直在分析编码，最后三天所有功能一起提测，虽然是三天，但是对测试同学可能意味着他要加班到凌晨，这件事是不合理的。

所以后来我们通过改进能够做到有从这个迭代的早期开始就不断的也需求提测，所以测试压力分布在整个迭代周期里面，中期和后期里面，而不是都在后期。

还有一点大家可能觉得很困惑，改进了为什么7月的时长这么可怕，如果翻到前面会发现7月份交付需求数量也变少了，这里面有一个很有意思的故事。

到7月的时候有两个很大的需求从天而降，插队进来，这两个需求我们本来没有排进迭代计划，但是我们承诺了，团队的并发增加了，如果看那个时候的看板，我们会发现有一些卡片好几天拖不过去，因为开工也太多需求，我们要关注完成而不是关注开始，其实我们开始那么多都没有用，因为最后大家顾不过来。

需求的交付

7月份是一个比较失败的版本，我会把这个图拿给研发经理，我会问改进了一个多月，为什么现在时长反而变长了，完成的需求反而变少了。

手淘的开发TL也非常聪明，说我们并发太高了，这个时候我觉得不需要再多说了，因为到了8月经过造物节还有运营活动，那个时候淘宝直播也慢慢火起来，不断的有合作方找我们，不断想要加塞一些需求进来。

经历7月以后，这个团队慢慢反思他必须会说不，之前觉得抗不住压力就都YES，最多是加班，但是经历了7月以后，其实数据力量也很强大，因为原来会加塞产出有伤害，但是伤害什么程度不清晰，但是数据可视化出来，同样的人因为并发提高，中间等待增加那么多，觉得这件事代价太大了划不来会说不。

所以到8月份之后，我们比较能控制自己的节奏了。

这个也是非常明显，7月原来有需求又加上加塞的需求，并发度提高了但是产能没有提高，反而准时交付率下降了。我们6月和8月是100% ，但是7月份没有做到，但是我们只要知道原因，下一次不要进入同一个坑就可以了

变化的背后

首先阿里是个强业务驱动的公司，所以做的任何事情在一个季度或者半年里面会被验证的，它的业务效果一定要被验证的，无论如何一定保证做的所有事情是朝着那个方向努力的，不然是打水漂的。淘宝直播是一个新业务，大家不知道往哪里去是最好的路，所以这个时候怎么找到合理的路特别需要快速迭代和验证。

怎么样把准备需求的时间缩短，对团队来说有更多的时间做增值的工作，还有我们怎么样能够提高质量，当然所有一切都离不开落地，我们要持续改进。

聚焦业务目标

我到手淘我也不了解他们的业务，我问运营目标是什么，我做了一个板可视化，上面是我们的业务指标，这个是九月底亲我们要达到的目标，每个月我们会更新当前的数据。

大家一开始不支持我，这个板很花时间，这些数在BI的系统里可以看到。但是我观察虽然在BI系统里随时可以看到，并且大家有权限，但是真正看见那么几个人，运营、产品，研发通常不看的，可能TL看但是一线同学不会看。也不太清楚现在正在做的功能对指标有什么帮助。

但是我可视化出来以后，发生很神奇的事情，他经常路过这个板，他们开始聊天而且是跨角色的，9月底要到多少万，但是已经7月底了一半还没有大怎么办，但是开始着急起来，如果这个东西没有可视化东西出来，大家可能有人着急，但是不会变成整个团队合力的东西，会有同学自告奋勇跟运营说有一个好点子觉得这个事有帮助，以前是运营说服产品和开发同学赶紧做，大家还不乐意。

但是现在不一样了，看板变成是大家共同想要的这个东西，自己也会很着急，而且不管什么角色只要有好的点子都会提出来，这个跟阿里考核机制也有一点关系，阿里是技术团队考核不只看技术完成多少，是大家一条船上，业务做不好技术KPI也一样不好的，这个在别的公司有点不一样，所以它很着急。

• 业务主线

有了那个以后只是一个方向或者是要去的地，但是怎么到那需要有一个路线，所以我们要有一个规划，这个规划是按照季度来做的，但是会拆解到月，这只是方向性的东西没有进到研发环节的程度。

但是这个东西产生的过程比较有意思，因为产品会连接业务和研发，所以产品会在这个季度规划，包括目标是什么，怎么样去到那里，这个会经过产品、研发和业务三方负责人的内容，可能部分高层或者是和新的经理知道，一线的同学不知道。

但是后来我们做了一件事情，沟通以后这个要分享给全员所有的人，包括测试同学，包括一线研发同学，所有人都要知道我们接下来三个月要去哪里，要攻什么东西，打法和策略是什么样的，分解到每个月才可以交付。

• 迭代目标
  

  主线不落地也是空的，所以接下来到迭代，我们迭代里所有的功能或者需求要仅仅扣住季度规划的业务目标和业务打法。

  前面括号里面是这个月的主打内容，我们做了比较狠的事情，对产品经理很高的要求，不只要做什么功能，而且要说明白做这件事情的业务价值在哪里，这个还没有完，这个价值是要可度量的。

  所以做完了这个功能上线以后我们会看数据，比如直播间的UA有多少人看直播，有不同来源的，有人直播列表里面进来，有人从微博过来的，有的是关注了喜欢的主播从主播预告列表进来，我们在埋点每一个来源有自己的来源渠道。

  所以我知道我的UA提升，这个月相比上个月提升到底哪个来源贡献比较大，这个东西不会跟KPI挂钩，就算没有达到也不能怎么样，但是有一个很神奇的事情，我们有新入职产品经历以前做游戏直播也没有电商经验，但是他非常能干，他来了以后提的两个需求经过验证确实非常有效，命中率100%，这个事很了不起。

一开始大家有点不太信任他，一个做游戏的是不是拿做游戏的思路做电商的直播，所以他提的需求研发同学挑战的比较厉害。

但经过这两个需求命中率100%，大家会非常信任他。反过来讲如果一个产品经理一次没有命中我们会觉得运气不好，或者这个地方摸错了，但是总是摸不中，下次再提需求可能大家也要打一个问号，所以其实这个对产品经理很高也是比较狠的。

• 迭代计划
  

  我们迭代规划也是很有意思的，提升我们每个加号，点开可以展开的，我们是从业务指标一层一层连接到可能是一个需求，可能是一个原始需求，再拆解成任务，是一层层拆解。

  最顶层一定讲这个业务打的业务指标是深业务打法是什么，要扣住主题。我刚进去的时候他们刚好要发版，我说不许看代码和工具，直觉上跟我说这个版本上的三个最重要需求是什么，我分别问了三个不一样的开发同学，他们给我的回答是不一样的，而且有一个开发同学直接跟我说做了很多，但是零零碎碎都想不起来了。是因为他非常的散，没有一个主线，但是到6月、7月、8月我们主线很清晰。

• 迭代过程

迭代过程我们有物理看板，这个只是其中的一段，我们是一个完整端到端的板，左边白色是需求卡片，黄色是任务卡片，红色是风险问题或者缺陷，绿色的纸条是谁做这个需求，这个也是控制并发度。

我们会跟开发同学讲，每个人职业两张绿纸条，一个同学同一个时刻最终领两个任务，而且领的时候最好从高优先级需求的任务，当一个任务完成这个纸条空出来才去领新的任务。通常我们建议大家领一个任务，除非被阻塞住了才会领下一个任务。

我去的时候三个版本没有按时集成，6月份立的这个板以后，马上要集成的封板那一天，钉钉上收到电子照片是这个板的照片，所有版本要发的需求都在待集成那一列，然后开发TL跟我说感谢。大家很开心，可能我们没有做更多的感谢，但是把这个板可视化出来，每天按照优先级的顺序更新今天的进展怎么样，明天会是计划到哪里，现在有没有什么问题和风险。

其实大家会有一种强烈的动力想把它从这边拖到那边，尽快把它拉动过去，所以其实没有做特别多的事情，因为还是这些同学，但是一个月时间能够第一次按时发板，而且后面几次也按时发，所以他觉得非常开心。

其实我刚进去的时候大家觉得敏捷教练没有干活，就是做了几个板弄了点数据，到底有什么用，其实大家不太认敏捷这一套，因为阿里同学非常直接。

比如开回顾会，我跟开发TL说开个回顾会吧，开发TL说代码写不过来不开，我不放弃的说我开会很棒，我保证一个小时之内开完。他有点活动心思，就开一个小时。回顾会开了以后，他觉得效果很好，阿里更多的同学是价值驱动，这件事对他有帮助他会坚持做下去。

更好的是我双十一之后离开手淘，因为我家在北京就回来，回来今年1月底又回访看那个团队，发现他们的实践坚持的非常好，那个板比原来做的更漂亮，把做完需求做了一个小信封插进去他觉得这个东西对他很有帮助，所以他会坚持做下去。

快速验证假设

快速验证这个在很多公司都有，就是AB Test，在技术方面可行了以后怎么样把他用好做好这是另外一个挑战了。其实在手淘AB Test这件事有非常好的技术基础设施支持的，在APP里面集成SDK后面服务端东西是共有的，基本上很快可以介入。

• 首页改版
  

当时想尝试在直播列表里透出直播信息，最容易想到把评论信息透出来，这样气氛能够感染到用户，吸引用户进来看直播，开发同学去尝试，结果尝试了一个礼拜很苦恼的找我说发现要把聊天的评论透出来很麻烦，做底层消息系统不在我们团队，这个功能他们没有，所以要他们现给我开发一个。

他们有自己排期所以不给我排，我也想做，就看他代码自己改。但是自己改花一个礼拜调通接口，再做这个功能我觉得太慢了，有没有办法可以快一点，他觉得一个礼拜验证一个想法。

我说这个最核心验证点在哪里，是不是想知道透出来聊天的评论对用户进直播间有没有帮助，如果我们透出来信息不是自动从消息流里拉动的，比如和运营同学在1%灰度里面，在某几个直播间手动抓一些信息把它透出来，通过手动加自动的方式透出要多久？他说快的话今晚就可以搞定。

所以我们想验证一个想法，可能因为只是想验证一个想法，所以可能我们要问的问题是，我们想验证最核心的点是什么，以及能够验证这个核心点的最快最轻的成本最低的方法是什么，后面他们自己领悟到这一点。

首先会把一个大需求拆小，这个直播首页改版其实就是直播列表，直播首页改版是很大的需求，但是我们并不会所有东西都一块做，然后去做需求评审。而是会拆成不同的点，每个点有不同的验证方法。

对每个点验证的非常小了，好处是可以对这个点独立做验证，这个里面两个点，一个是底下赞的地方是静态的，现在是动态的，还有一个是原来放了主播的静态图片，但是同质化程度太高了，现在想放一个直播间当前的十秒视频的回放，这样可能气氛会好一点。

但是会不会吸引更多用户看直播这件事不知道，也不需要PRD，不需要交互视觉设计，直接运营和开发同学聊一下，大概知道要做成什么样要验证什么，把核心的功能实现，利用手淘机制推下去，推1%的用户，我们做一个AB TEST。

看到数据以后，如果有明显统计意义上的区别，我们发现可能这两点摸对了，我们按照做产品的方式再做出来。如果没有摸对的话，我们的成本肯定不会超过一个礼拜，这个事情可以知道管不管用。

这样我们把验证一个假设的周期从月甚至周缩短到天甚至小时，如果很着急可以当天搞定。如果能够更快做这个试验，一些小的试验，其实可以更快知道哪些管用哪些不管用，对不管用的可以迅速筛掉。

一起打磨需求

• 需求为什么定不下来？
  

还有提到需求很长时间定不下来，我去了以后说要不要来听他们的评审会，我去了发现会开的很长，开三个小时但是没有结束的意思，我说你们不吃饭，他说拼完了再吃。

还有需求评审会变成需求讨论会。接着是开发和测试提很多问题，开完之后我问大家是不是第一次开需求的会，他说是的，人的大脑很神奇，这么复杂的东西只要足够长的时间都可以理解的。

但是要在短时间内理解一个，或者判断一个复杂的事情非常挑战的，开发和测试短时间内看一个很复杂的需求，这个时候很容易漏掉一些东西，产品经理一开始跟开发测试聊过，所以一些事情只有开发和测试知道，所以只能现场聊。

• 从等待接棒到携手前行
  

不到我这一棒我不管的，开发说PRD交互谁搞定再送到这里，那些没有搞定是不接的。

但是这样有什么问题是一个线性的顺序的，如果后面的人不信，比如开发，比如测试到后面才发现问题，这个时候再返工的时候代价很高，与其这样为什么不一开始协作。与其后面发现很多需求问题反过来跟产品说重新设计，不如一开始携手讨论这个需求，所以我们有一个需求小组的机制一起打磨需求。

大家觉得这个事很重，但是我们做一个讨论也可以继续，效果也可以。这个需求小组首先想最好不要超过五个人，通常产品经理、交互设计师和一个开发经理。

• 一起打磨需求
  

需求小组的分工是产品经理要把为什么讲清楚，用户什么场景下达到什么目的要用这个功能，设计师看这件事这么做体验好不好，是不是反人类的操作。

开发同学会看技术上这么干是不是一个性价比比较好的路径，是不是有更好更轻代价更低的方案可以达到这样的效果。

如果有测试同学，这个时候可以在产品经理还没有写出PRD可以着手写验收标准，它的验收标准完全可以场景化的，当用户在什么场景下做什么操作，他期待得到什么样的效果。

他的验收标准完全可以跟PRD相互印证的，用场景化的东西指导后面的开发和测试，大家觉得这个东西是非常具像化，具体可衡量的。我很清楚这个需求为什么要做，以及什么时候这个需求算是做完了，能不能打成原来的目的。

我们的要求是有需求评审，因为人很多，这个团队30 多人，有做基础平台有做业务的，差不多每次评审有20 人。

我们需求小组里面大家先有共识，至少那几方面大家没有问题了拿到大组评审。这里面有对比，当时没有全部铺开拿了两个需求做试点，发现达成共识再到大组评审，是很复杂的需求。

大家没有时间问题觉得就应该是这样，甚至那些根本没有参加需求小组讨论的也觉得这样是不是自然，因为大家想到的问题小组想在前面了。

还有一个需求是没有经过小组讨论的，可能产品经理做一个比较炫的东西，但是被服务端开发TL拍回来，说这么搞技术上不可行，就非常悲惨，因为那个时候PRD已经写完了。

提高提测质量

低级BUG多肯定是开发提测可以有进步的，但是光靠卡指标没有什么用，我自己觉得度量是一个辅助性的工具，度量本身不是目的，应该要改进的目标是什么，比如我想要好的整个过程中质量好的。

为了看到底是不是有内建质量，再选择一些合适的指标度量它，可能低级BUG是衡量内建质量的指标，但是光有指标大家还是不知道怎么改进，这个特别有意思，我们开站会，站会测试同学说最近提测质量不好，抓了以后直接闪退了。

我问他们有什么建议，我们有一个工具叫做摩天轮，说第一次在摩天轮上提测是可以的，觉得你是质量过关的。但是我们会先看自测用率是P0跑过，如果跑不过我们提测试要打回。

打回了以后，第二次不能在系统里提测，必须拿着手机装上提测版本APP到座位前Demo给我看，我问开发同学，大家觉得这个合理吗，开发同学觉得有点不好意思，因为确实提测有问题，会说就这么办。

很神奇，因为开发同学很骄傲的也比较好面子，希望自己做的东西很好的，所以让他拿手机到测试那里说提测没有过，提测质量提升了，有很多改进是很简单的，有一些跳动的点，而且还是团队自己想出来的。

还有以前“提测”比较随意，可能自己手打的包，也可能是跟Jenkins集成一下，但是不是端到端可以跑通的，而且还有刚才的板这是另外一个局部，我们有很严格的标准才可以“提测”。

首先是在摩天轮上有一个构件号，这意味着代码是合进去的，没有冲突的，通过摩天轮的静态扫描，基本上一些安全问题，还有低级编码问题会扫出来，这样才可以打出来有提测包的构建号。

还有是端到端的自测用例通过，不能用mock，有了这两条，测试同学用mock通过了不管用，必须端到端，但是没有明确规则所以没有办法约束。现在我们把规则写下来每天同步，测试同学说现在给我的包自测用率没有通过，或者用mock通过的不算，这个时候大家会很注意这个事情。

从小瀑布到持续交付

为什么测试同学总是很晚才可以回家，因为以前是小瀑布，需求分析、开发、测试然后最后集成，到那个时候马上发版了，所以测试同学有加班。

我觉得这件事非常不人道的所以一定要改。我们改成这样一开始需求拆小，需求拆到三个工作日左右可以提测，从第三天开始就可以逐步有功能提测，就不是所有的需求都到最后的三天才提测，所以会把测试的压力、修BUG压力、集成压力分散在迭代里面，这是数据度量的结果。

以前我们在发版前三天所有BUG冒出来，但是现在到8 月我们发现在迭代的前期六七天的时候有功能逐步提测，因为这个是新增缺陷，肯定有东西可以测才有新的缺陷出来，这个指标我觉得非常好的指标。

迭代缺陷增量趋势

微软做敏捷转型的时候特别有意思，高层到VP的层次，不知道底下团队有没有做敏捷的，敏捷效果也不知道，但是看这个，发版前拉缺陷的趋势。

如果是一个瀑布或者小瀑布，就是很长时间没有BUG，然后有BUG，这样你持续有东西可以验证，那你的BUG是比较均匀分布在整个迭代周期里面或者中后端，所以高层想知道有没有做到敏捷也是能有比较靠谱的手段知道。

对开发来说也很好，因为如果所有东西是最后提测，那个时候发现严重BUG，可能修完以来更多问题，最后BUG不修就发不出去，所以是尽早集成，尽早测试，这个其实是解决所有的集成问题和尽早暴露技术风险最有效的手段。

总结：持续改进

大家可能会说是不是敏捷教练很神奇能够想到这么多招帮大家改进，但是事实上这里大部分改进的方法都是团队同学自己想出来，大部分的问题也是团队同学通过看板也好，度量也好，他们自己看到了这有问题自己想办法解决，所以每个人天生就有获得成功和快乐的所有资源，这个也是第一性原理不需要证明的意思是一个真理一定要相信它。

对团队也是一样，我相信每个团队都有使这个团队成功高效的所有资源，所以其实我只是去帮助大家看到问题，去激发大家想办法，去引导大家不断前进持续改进，可能再过一个月时间又不一样了，没关系，只要我们持续改进，看这个月比上个月有进步，这个团队慢慢总可以成长成一个非常棒的团队。