背景介绍
阿里很少提敏捷转型或 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。亲身感受到敏捷给团队带来的改变，立志成为敏捷践行者。
本文作者：云效鼓励师
阅读原文
本文为云栖社区原创内容，未经允许不得转载。