为了更好的拥抱变化，很多团队选择使用敏捷去管理组织或者团队的研发过程，Scrum作为最常用的敏捷框架之一，备受青睐。使用Scrum的团队叫做Scrum Team，Scrum Team（以下简称团队）按迭代进行交付，在一个迭代中，团队要完成需求的规划设计认领、编码、测试以及部署上线工作。有的团队刚接触Scrum，一个问题令他们很困扰：迭代初期开发人员的工作较多，测试人员闲着；迭代末期开发人员闲着，测试人员的工作比较多，怎么解决资源等待的问题呢？

一、问题分析

造成以上问题的原因大致有以下几种：

1、团队搞的Scrum其实是小瀑布

团队搞的不是真正的Scrum，而是披着Scrum“皮”的小瀑布——团队有SM、PO，需求使用用户故事记录，迭代中的活动比如每日站会、评审会议等一个不落的开展，但是，团队在迭代中依然按照瀑布模型进行运作——认领完需求进行开发，开发全部完成，交付测试，测试完成，项目上线，整个流程走下来，就造成资源等待。

2、需求拆分不够细

需求粒度偏大且没有做进一步拆分，这种情况导致开发人员完成需求的编码工作，就已经到了迭代末期，迭代前期测试人员设计完测试用例，就只能等待了。

3、开发和测试之间缺乏沟通

开发人员完成了某个新需求编码，没有告诉测试人员；测试人员也没有主动且频繁的向开发人员询问是否有已完成的新需求需要测试，直到迭代末期，开发人员才将所有开发完成的需求一并交给测试人员，造成了资源等待。

二、解决方法

1、让团队了解真正的Scrum工作方式

小瀑布相比于传统瀑布，应对变化的能力可能有所提升，但小瀑布的运作方式和Scrum所倡导的做法还有差距。Scrum使用“Increment”（增量）来表示每一个即将交付的需求，作为Scrum的三大工件之一，Increment有两个重要特性：满足DoD、随时都可以发布，Increment这两大特性为敏捷应对频繁变化提供了保障。反观小瀑布——迭代前期开发、迭代后期测试，如果迭代过程中，突然要发布新需求，那显然是有风险的——因为代码没有经过测试。Scrum中，迭代运作过程更像下图，每个需求完成编码，都直接交给测试人员，测试通过即可准备上线（就绪即可，不是必须上线），在这种情况下，资源等待的问题就会被解决。

究其原因，还是团队对Scrum的理解不够深入，很多团队接到组织安排要进行敏捷转型，就将Scrum角色和流程搬进来，但团队不了解Scrum是什么，为什么，这样转型往往换汤不换药，也许有效果，但一定没有真正的Scrum运作效果好。想改变这种情况，Scrum Master和Product Owner应该对敏捷有深刻的理解，这样才能影响团队甚至向上影响到组织高层，让高层也从根本上了解Scrum过程以及Scrum带来的好处，而不是关注有几个团队用了Scrum。

另外，聘请外部教练来帮忙做Scrum导入也是不错的选择，首先外部教练通常具备专业性，更了解Scrum的运作流程，Ta会帮助团队运作Scrum，并对各个角色进行Scrum相关知识的辅导，避免团队因为对Scrum理解不到位，而走弯路。而且，中国有句俗话“外来的和尚好念经”，不管对于团队，还是对于高层，外部教练相比于内部教练可能更容易说上话，提出的建议也更容易被听取。

2、对需求进行拆分

当需求太大时，团队可以和Product Owner一起，将需求拆分、细化——一方面可以更好的提炼产品价值，另一方面可以更好的划分工作量。

3、加强团队成员之间的沟通

团队成员之间缺乏沟通，表面上看可能是由于成员之间业务、分工不同，实际也是由于对敏捷理解的不到位，敏捷宣言提到“个体和互动胜过流程和工具”，团队成员之间应该频繁沟通，就像DevOps打破开发、运维的壁垒一样，在Scrum Team中开发、测试之间也不应该有隔阂。Scrum Master应该积极组织每日站会，通过站会让团队成员了解项目进度——哪些需求正在开发、哪些已经开发完成等待测试。如果站会效果不理想，团队可以尝试使用电子或物理看板来记录需求及需求的价值流动，这样哪些需求待测试一目了然。

4、培养多面手

除了以上三种方法，还有一种方法可以解决资源等待问题，那就是培养多面手，比如开发人员既可以做开发，也可以对自己实现的功能进行测试。

实际上，Scrum确实提倡这么做，Scrum Guide中提到：“Scrum Team 是跨职能的（cross-functional），这意味着团队成员具有在每个Sprint中创造价值而所需的全部技能”，团队能力允许的情况下，培养多面手不单能够解决资源等待问题，还可以让团队更好的践行Scrum。