2016年5月底我进入团队时，淘宝直播还是一个新业务，产品还在摸索中。迭代过了一半了，需求还没定下来；开发时间紧，需要加班加点赶工；

淘宝直播并不是独立的应用，它是跟着手淘大版本，在这一超级应用中发版，而手淘的发版是火车制，有严格的质量卡点，质量不达标是不能发版的，而且火车制要求发版时间固定，错过之后就只能申请紧急发版。紧急版本线上问题非常多，运营人员忙于解决主播的问题，变成了客服。

如上图团队仪表盘显示，判断一个团队有多敏捷，大致可以从图示的四个维度确定：

（1）Capacity：团队的容量，是指在单位时间内能够交付多少有价值的功能点；

（2）Lead time：周期时间，是指从用户提出需求到用户用上其想要功能的时间跨度。它是 敏捷的核心指标，反映了团队的响应力。时间越短，团队的迭代速度越快，对市场的 响应速度 越快，越有可能胜出；

（3）Quality：质量，它决定了产品的存亡；

（4）Predictability：可预测性，它反映了团队能否信守承诺。

在接下来的三个月里，我和团队跟踪了上述指标的变化。

上图是淘宝直播团队在6、7、8月变化的雷达图，在上图中，除了有上文所提到的四个维度，又加入最为重要的业务指标维度。业务指标达不到，再好的研发过程指标也是竹篮打水一场空。

从雷达图中可以看到，团队在稳步朝着业务指标前进。由于数据安全原因，这里不能展示具体的业务指标。下面从研发过程指标（完成需求数、周期时长、新建缺陷数、需求准时交付率）来看一下团队的变化。

完成需求数

上图是6、7、8三个月完成需求数的对比图，其中7月份之所以下滑是因为突然插队了两个需求，打乱了原本的节奏，进而影响了完成的需求数。而8月份，在没有插队需求的情况下，敏捷实践的效果就得到了凸显，完成的需求数较6月有所增加。

周期时长

上图是三个月的周期时长对比图，可以看到7月的开发时长和测试时长相比于其他两月有特别明显的升幅，这是由于插队的需求导致研发团队的并发度上升所致。这里也给各位团队负责人敲响了警钟，如果不想打乱团队的节奏，不希望团队一心多用，那么就要让团队按照自己的节奏来工作。

另外一点值得注意的是需求分析的时长在6、7、8月逐渐下降，这是淘宝直播团队产品和UED小伙伴努力的结果；而测试时长呈现增加的趋势，是因为测试的工作压力比较均衡的分散开。

新建缺陷数

从上图可以看到，从5月份到8月份，缺陷总数和严重缺陷数量是不断减少的，产品质量得到了提升。同时低级缺陷（非常容易发现的缺陷）数量也明显减少，说明提测质量提高了。

需求准时交付率

在6月和8月，需求准时交付率做到了100%, 7月份由于插队需求的影响，交付率表现得差强人意。

敏捷落地的过程并非一帆风顺。这种时候，我和团队都没有失去信心。

变化的背后——聚焦业务目标            

那么从6月分到8月份，发生这些变化的背后，我们究竟做了什么呢？我认为其中最为重要的一点就是聚焦业务目标。

上图是为淘宝团队制作的业务目标看板。每个月产品发版以后，都会更新上面的指标。大家可能会问业务指标不是在BI系统里，为什么还要贴到物理板上？这块板前面常常围着三三两两的小伙伴，大家一边分析指标一边想办法提升业务指标。这就是看见的力量。

业务主线

明确业务目标之后的工作是寻找一条实现业务目标的思路。

业务主线的重要性在于它能帮助我们聚焦，保证“要事第一”落到实处。

从上图可以看到，7、8、9月份的业务主线：主播质量和转化、频道和互动升级、互动营销。这三条主线落实到具体的迭代中就变成了迭代目标：

产品同学在提出功能时，就要分析这个功能能否提升业务目标，而且要用具体的数据说话，例如主播质量的提升和转化的业务目标是将主播的日均直播场次提高多少场，主播的活跃度提高多少。

在发版之后要进行数据对比验证这项功能是否真的有效。

迭代过程

上面这块板是从需求设计到开发、测试、发版的端到端看板。左边白色的需求卡片是按照优先级排列的，跟业务主线相关的需求都在上面。黄色的卡片是任务，开发同学领任务时也是先领高优先级的任务。

为了限制大家的并发度，每个开发人员最多同时只能领两个任务。红色的标签表示风险。有了这块板，研发过程的风险、研发人员的分工、进度一目了然。

变化的背后——快速验证假设            

快速验证假设是所有创新业务面临的挑战。如何实现业务目标并无固定的途径，必须要靠摸索，去试错。在这个过程中，快速地试错、快速地验证假设变得尤为重要，它也是敏捷性的核心体现。

下面来看一个实际的案例——首页改版。

首页改版有两个功能点：播放十秒视频和飘赞。前者是将淘宝直播页的静态主播照片替换为直播间最新的十秒视频，便于观众快速了解直播内容；后者是将静态的飘赞改为动态。

这两个功能我们并非是直接加入新的版本，而是提前做了两个简单的原型，并且推送给1%-5%的用户做灰度测试，然后在24小时之后就拉到了第一版数据。整个流程总共花费两天时间，短时间验证了功能的有效性，进而加快了迭代速度。

变化的背后——一起打磨需求            

现在来看一下6月到8月需求时长缩短一半的原因。刚到淘宝直播团队时，产品的需求定不下来，需求评审时间长，甚至需求评审会变成了需求讨论会；开发和测试评审时才第一次看到需求，因此提出很多问题。

出现这种现象的一个原因是，大家是接力棒式的协作：不到我这一棒就不起跑。

我们的改进的方式是产品在做需求分析时将开发和测试人员拉入团队，从等待接棒变成携手前行，大家一起打磨需求。

具体做法是成立由产品经理、设计师、研发组成需求小组，人数控制在5人以下；需求小组一起打磨需求，其中产品经理聚焦价值、设计师聚焦用户体验、开发聚焦技术方案、测试聚焦验收标准；需求小组达成共识后再提交需求评审。

变化的背后——从小瀑布到持续交付            

从6月到9月，测试人员的工作压力得到了很大的缓解，这得益于我们从小瀑布改进到了持续交付，而不是快发版的时候，所有需求一起提测。

下图是8月迭代缺陷增量趋势。可以看出迭代进行到一半的时候，就逐步有需求提测，测试和修复缺陷的压力从迭代的最后3天分散到10天，测试人员的工作压力随之减轻。

变化的背后——持续改进            

如果一个团队出于自发的意愿，集体地、持续地改进，随着时间的发展，这个团队一定可以成长为非常棒的团队。

上图是淘宝直播团队在6月迭代回顾会的改进点和行动点，这些都是淘宝直播团队提出的，如最高票的提高评审效率这一改进点。

我在2017年1月份对淘宝直播团队回访时发现，看板、需求小组等敏捷实践团队仍在坚持使用，在完成需求和确保产品质量方面仍起到了很大的作用，有效提高了团队的效率。

原创：张迎辉

2016年5月底我进入团队时，淘宝直播还是一个新业务，产品还在摸索中。迭代过了一半了，需求还没定下来；开发时间紧，需要加班加点赶工；

淘宝直播并不是独立的应用，它是跟着手淘大版本，在这一超级应用中发版，而手淘的发版是火车制，有严格的质量卡点，质量不达标是不能发版的，而且火车制要求发版时间固定，错过之后就只能申请紧急发版。紧急版本线上问题非常多，运营人员忙于解决主播的问题，变成了客服。

如上图团队仪表盘显示，判断一个团队有多敏捷，大致可以从图示的四个维度确定：

（1）Capacity：团队的容量，是指在单位时间内能够交付多少有价值的功能点；

（2）Lead time：周期时间，是指从用户提出需求到用户用上其想要功能的时间跨度。它是 敏捷的核心指标，反映了团队的响应力。时间越短，团队的迭代速度越快，对市场的 响应速度 越快，越有可能胜出；

（3）Quality：质量，它决定了产品的存亡；

（4）Predictability：可预测性，它反映了团队能否信守承诺。

在接下来的三个月里，我和团队跟踪了上述指标的变化。

上图是淘宝直播团队在6、7、8月变化的雷达图，在上图中，除了有上文所提到的四个维度，又加入最为重要的业务指标维度。业务指标达不到，再好的研发过程指标也是竹篮打水一场空。

从雷达图中可以看到，团队在稳步朝着业务指标前进。由于数据安全原因，这里不能展示具体的业务指标。下面从研发过程指标（完成需求数、周期时长、新建缺陷数、需求准时交付率）来看一下团队的变化。

完成需求数

上图是6、7、8三个月完成需求数的对比图，其中7月份之所以下滑是因为突然插队了两个需求，打乱了原本的节奏，进而影响了完成的需求数。而8月份，在没有插队需求的情况下，敏捷实践的效果就得到了凸显，完成的需求数较6月有所增加。

周期时长

上图是三个月的周期时长对比图，可以看到7月的开发时长和测试时长相比于其他两月有特别明显的升幅，这是由于插队的需求导致研发团队的并发度上升所致。这里也给各位团队负责人敲响了警钟，如果不想打乱团队的节奏，不希望团队一心多用，那么就要让团队按照自己的节奏来工作。

另外一点值得注意的是需求分析的时长在6、7、8月逐渐下降，这是淘宝直播团队产品和UED小伙伴努力的结果；而测试时长呈现增加的趋势，是因为测试的工作压力比较均衡的分散开。

新建缺陷数

从上图可以看到，从5月份到8月份，缺陷总数和严重缺陷数量是不断减少的，产品质量得到了提升。同时低级缺陷（非常容易发现的缺陷）数量也明显减少，说明提测质量提高了。

需求准时交付率

在6月和8月，需求准时交付率做到了100%, 7月份由于插队需求的影响，交付率表现得差强人意。

敏捷落地的过程并非一帆风顺。这种时候，我和团队都没有失去信心。

变化的背后——聚焦业务目标            

那么从6月分到8月份，发生这些变化的背后，我们究竟做了什么呢？我认为其中最为重要的一点就是聚焦业务目标。

上图是为淘宝团队制作的业务目标看板。每个月产品发版以后，都会更新上面的指标。大家可能会问业务指标不是在BI系统里，为什么还要贴到物理板上？这块板前面常常围着三三两两的小伙伴，大家一边分析指标一边想办法提升业务指标。这就是看见的力量。

业务主线

明确业务目标之后的工作是寻找一条实现业务目标的思路。

业务主线的重要性在于它能帮助我们聚焦，保证“要事第一”落到实处。

从上图可以看到，7、8、9月份的业务主线：主播质量和转化、频道和互动升级、互动营销。这三条主线落实到具体的迭代中就变成了迭代目标：

产品同学在提出功能时，就要分析这个功能能否提升业务目标，而且要用具体的数据说话，例如主播质量的提升和转化的业务目标是将主播的日均直播场次提高多少场，主播的活跃度提高多少。

在发版之后要进行数据对比验证这项功能是否真的有效。

迭代过程

上面这块板是从需求设计到开发、测试、发版的端到端看板。左边白色的需求卡片是按照优先级排列的，跟业务主线相关的需求都在上面。黄色的卡片是任务，开发同学领任务时也是先领高优先级的任务。

为了限制大家的并发度，每个开发人员最多同时只能领两个任务。红色的标签表示风险。有了这块板，研发过程的风险、研发人员的分工、进度一目了然。

变化的背后——快速验证假设            

快速验证假设是所有创新业务面临的挑战。如何实现业务目标并无固定的途径，必须要靠摸索，去试错。在这个过程中，快速地试错、快速地验证假设变得尤为重要，它也是敏捷性的核心体现。

下面来看一个实际的案例——首页改版。

首页改版有两个功能点：播放十秒视频和飘赞。前者是将淘宝直播页的静态主播照片替换为直播间最新的十秒视频，便于观众快速了解直播内容；后者是将静态的飘赞改为动态。

这两个功能我们并非是直接加入新的版本，而是提前做了两个简单的原型，并且推送给1%-5%的用户做灰度测试，然后在24小时之后就拉到了第一版数据。整个流程总共花费两天时间，短时间验证了功能的有效性，进而加快了迭代速度。

变化的背后——一起打磨需求            

现在来看一下6月到8月需求时长缩短一半的原因。刚到淘宝直播团队时，产品的需求定不下来，需求评审时间长，甚至需求评审会变成了需求讨论会；开发和测试评审时才第一次看到需求，因此提出很多问题。

出现这种现象的一个原因是，大家是接力棒式的协作：不到我这一棒就不起跑。

我们的改进的方式是产品在做需求分析时将开发和测试人员拉入团队，从等待接棒变成携手前行，大家一起打磨需求。

具体做法是成立由产品经理、设计师、研发组成需求小组，人数控制在5人以下；需求小组一起打磨需求，其中产品经理聚焦价值、设计师聚焦用户体验、开发聚焦技术方案、测试聚焦验收标准；需求小组达成共识后再提交需求评审。

变化的背后——从小瀑布到持续交付            

从6月到9月，测试人员的工作压力得到了很大的缓解，这得益于我们从小瀑布改进到了持续交付，而不是快发版的时候，所有需求一起提测。

下图是8月迭代缺陷增量趋势。可以看出迭代进行到一半的时候，就逐步有需求提测，测试和修复缺陷的压力从迭代的最后3天分散到10天，测试人员的工作压力随之减轻。

变化的背后——持续改进            

如果一个团队出于自发的意愿，集体地、持续地改进，随着时间的发展，这个团队一定可以成长为非常棒的团队。

上图是淘宝直播团队在6月迭代回顾会的改进点和行动点，这些都是淘宝直播团队提出的，如最高票的提高评审效率这一改进点。

我在2017年1月份对淘宝直播团队回访时发现，看板、需求小组等敏捷实践团队仍在坚持使用，在完成需求和确保产品质量方面仍起到了很大的作用，有效提高了团队的效率。

原创：张迎辉