弹性研发团队的探索
1.背景
1.1困境
团队内一位测试者对接多位开发者，开发者的需求提测速度远大于测试者的测试速度，导致开发者提测的需求堆积待测试，无法及时上线，团队测试资源匮乏的问题愈加凸显，直接影响团队的需求交付速度。
图1-开发工作流
测试资源匮乏的问题在支付组中尤为严重，且支付项目业务复杂、上手周期长，要求开发者与测试者尽可能的稳定，短期内引进新人也很难解决问题。因此团队的目标是在现有资源供给下，不进行人员变动，而通过优化团队内部的质量保证工作量的分配，既保证团队稳定与研发质量，又提升需求交付速率。
1.2剖析
►1.2.1 概念
在解构团队困境之前，首先定义若干概念，建立一个简单的数学模型进行分析。
(1) 开发侧
Ø 开发资源：团队内部的开发者人数，例如10人；
Ø 单位提测速率：每个开发者平均每天提测的需求数，例如2个/人天；
Ø 提测速率：团队平均每天提测的需求数，显然有：提测速率=单位提测速率×开发资源=2×10=20个/天。
图2-提测速率公式
(2) 测试侧
Ø 测试资源：团队内部的测试者人数，例如2人；
Ø 单位测试速率：每个测试者平均每天测试完成的需求数，例如4个/人天；
Ø 测试速率：团队平均每天测试完成的需求数，显然有：测试速率=单位测试速率×测试资源=4×2=8个/天。
图3-测试速率公式
(3) 上线
Ø 需求交付速率：指团队平均每天上线交付的需求数，由于需求通过测试后基本就能上线了,显然有：需求交付速率≈测试速率=8个/天。
图4-需求交付速率
图5-提测速率>测试速率，需求堆积，需求交付速率受限
►1.2.2 提测速率与测试速率的大小关系
下面分析一下提测速率与测试速率的三种大小关系：
(1) 提测速率>测试速率
存在的问题：我们团队中目前存在这种大小关系，虽然资源都被充分利用，但资源分配不合理，导致开发者提测的需求堆积待测试，需求无法及时交付，需求交付速率与团队分配到的资源不匹配。
解决方案一：重新分配资源，减少开发资源，增加测试资源；
解决方案二：重新分配质量保证工作量，将一部分工作量由测试者转移至开发者。
