Scrum：发现问题的工具

Scum的意义是什么？与真正的Scrum流程相比，我们现在的Scrum实践到底哪里出了问题？

其实在Scrum的实践过程中，我们经常能听到一些对Scrum的不满：实施了Scrum之后，发现有的问题一直没有解决，比如因为服务器是跨境的，经常会遇到网络问题导致长期的等待，这个问题就算是应用了Scrum之后也没能解决……对于这一类的问题，我想一定有很多人陷入了这样一个误区：Scrum能够帮助大家解决流程中的问题。

实际上，Scrum能够做到的就是帮助大家发现在流程中或者在项目过程中存在的问题，然后我们需要正视这些流程中的问题，通过各种方式来解决问题。举个例子：我们为每一个Sprint都制定了目标，在这一Sprint过程中，Scrum团队将协作交付出达到客户满意的、高质量的产品增量。那在这个Sprint过程中，如果出现了阻碍团队实现Sprint目标的障碍或者困难，比如一个技术难题需要攻克、测试人员少导致测试效率变慢、团队协作出现问题等问题，团队优先解决的就是这些阻碍和困难。
但如果发现迟迟有问题没有解决，一般会有以下原因：

1.“完成”的定义不清晰，团队协作出现问题

如果我们对用户故事完成没有一个统一的标准，那么就会出现研发人员觉得写完代码就算完成了，而测试人员认为编码后自测、然后通过功能测试之后才算完成的情况，这种情况会大大增加沟通成本，降低工作效率。

所以团队需要给用户故事一个完成的定义，比如通过自测、功能测试、集成测试才能算用户故事的“完成”，也就是我们所说的“完成的定义（Definition of Done，DoD）”。

2.资源不足，不是跨职能团队

如果发现团队中出现缺少某一职能角色后就无法正常运转的问题，这也在一定程度上暴露出了团队无法跨职能。Scrum团队要求团队跨职能，这会在团队某一角色空缺时，其他角色能够暂时替代，而使团队的资源能够得到合理分配。

3.Sprint连续失败

如果出现多次Sprint没有成功交付的情况，那产品负责人和开发团队就需要反思是哪里出现了问题：成员的工作效率没有提高到最大？Sprint中要完成的用户故事过多，超出了开发团队的能力范围？还是在Sprint过程中遇到了难以解决的其他问题……

查明是什么原因后，我们才能对症下药：比如团队成员的工作效率问题，我们可以将繁琐、重复、机械的工作自动化起来，解放双手；对于用户故事过多问题，需要产品负责人和开发团队一起讨论，协商出合适的用户故事数，以便更好地交付产品增量……

4.团队协作困难

像一些远程团队、分布式团队，都会出现一些信息同步不及时、沟通成本高等问题，Scrum通过五大会议帮助团队有效对齐目标、减少协作过程中出现的问题。同时也能够反馈团队中出现的沟通问题，比如在会议中大家没有积极参与、无精打采，但是会后发现在会上并没有做到真正的目标对齐。那在这种情况下，我们就需要看看要如何调动起团队的参与积极性，比如通过一些有趣味的帆船回顾会来打破以往的回顾模式，引导团队成员的主动性与积极性，具体帆船回顾会的内容可以查看如何有效进行回顾会议。

除此之外，我们还会在Scrum实践过程中发现各种问题。我们将Scrum看作是一种发现问题的工具，因为Scrum不是万能的，不能帮我们解决过程中的各类问题，而是会督促我们去解决这些暴露出来的问题。如果我们团队在应用Scrum的时候也会经常出现一些效率低下、没有较大提升空间等问题，那不如看看是不是有一些问题已经暴露出来了，但没有得到重视和解决。