Scrum实施过程中曾遇到的那些“坑”

作为一名Scrum Master，你在敏捷项目中采用Scrum时，遇到过哪些“坑”？不妨来讨论一下。

 

1. Product Owner 不给力

有时候，存在Product Owner与其它团队成员之间缺乏交流，彼此不够信任，Product Owner事先制定好了开发计划，要求开发团队在规定的时间内完成已经确定的功能交付，而具体的功能还不确定（需要一个渐进明细的过程）。这样从一开始，就已经存在了障碍。我遇到过各种各样的Product Owner，其中有一种跨地域的情况是，由于存在语言和文化的差异，当开发团队对于待开发的特性不是特别清楚是，Product Owner不能很好地给予支持和反馈，甚至Product Owner都不知道这些功能要做成什么样子；待开发的功能需要从已经存在的一些系统（Legacy System）中通过接口获取哪些正确的数据时，开发团队就迷失了工作的方向。

Scrum是一个“经验——过程——控制”的开发框架，在这个框架下，跨职能的自管理团队以增量迭代的方式开发产品。在每一个时间盒（Sprint迭代中）内交付一个潜在的可交付的产品增量，理想情况下产品增量是要发布的。

Product Owner负责最大化产品的价值，确定待办事项列表（Product Backlog）中的条目（PBI，Product Backlog Items）优先级，并根据持续的反馈和学习成效以自适应的方式来确定每个Sprint的目标。团队负责实现目标。

Product Owner不应独自处理Product Backlog梳理工作，而应鼓励团队、客户/用户以及其它利益相关者直接合作，并从中获得支持。

所有Product Backlog的优先级顺序都由Product Owner确定，但优先级的澄清工作应尽可能直接在团队、客户/用户和其它利益相关者之间进行。

 

2. Scrum团队工作经常被干扰或者打断

在Sprint迭代过程中，团队的工作经常性的被来自管理层的主管或者经理，甚至是组织中的高层的一些指示、要求事项干扰。

例如：突然要求要求 Scrum Master 进行工作报告，提供项目进度报告，团队绩效，产品功能演示等。甚至，在参加了某次Showcase后，提出了一大堆“不切实际的”要求，指示团队“应该怎么怎么做……”

这样的“微管理”方式，不仅对 Scrum Master造成了工作干扰，而且让整个团队不知所措。

还有，在Scrum项目中，由团队中每个人来贡献自己的价值，实现每个Sprint的增量交付。那是在一个理想的世界里。当客户或者Product Owner试图引入新的需求，甚至Scrum Master也可能开始过多地干预开发团队的工作时，就开发陷入了误区。

组织需要对Scrum Master充分的信任和适当的沟通，通过让Scrum Master严格的保护Scrum流程，来避免Sprint执行中的工作干扰，甚至是工作被打断。

而Scrum Master也必须对额外的请求和Sprint待办事项的添加进行分析、判断，甚至是避免（阻止）；也不要对团队进行“微管理”。

 

3. Sprint持续时间不足

关于完美的Sprint持续时间还没有定论，也许是两周，也许是三周，或者四周。

一些研究表明，一周的Sprint有更多的困难，而其他人认为，许多较短的Sprint迭代使得团队和过程充满活力。

实践中，Scrum Master需要使用他们的专家知识和实践经验来设置Sprint持续时间，但是一次Sprint迭代最好不要超过四周。

时间管理技能是保持Sprint正常运行所必需的。引入时间盒和时间槽的概念，确保没有工作被拖得太久；要尽量减少WIP，一个时间槽最好不超过三天。

将任务分解成可管理的块也有助于管理Sprint的持续时间。

 

4. 缺乏知识和培训

与组织中的其他工作一样，敏捷开发和Scrum的参与者应该也需要接受必要的技术和技能培训。很多时候，组织都假设团队已经掌握了敏捷开发的知识和技能，都已经了解了Scrum的实施方法，会沿着这个过程向正确的方向前进。

但事实上，敏捷也好，Scrum也好，大多数从业者（习惯了传统项目管理方法的PM，开发者、测试者、业务领域的客户等）不要期待他们有先知先觉，对于敏捷开发过程，Scrum框架等都已经充分掌握了。

在Scrum中工作的每个人都必须知道这个过程是如何工作的。你需要一个有经验的Product Owner和Scrum Master，但是知识应该贯穿整个团队。

Scrum最好与一群非常敬业而且专注的“职业从业者”一起工作。

 

5. Backlog管理

Scrum框架的元素是固定不变的，比如日常Scrum和Scrum Master的角色。还有很多事情需要团队自己解决，比如如何实际完成待办事项中的工作。Scrum在Backlog中提供了一个优先待办事项列表，但是没有关于如何实际完成这些工作的指导。

Scrum是关于团队如何协作完成工作的，所以在如何交付产品上允许一些*度。作为Scrum Master，你可以指示团队在从待办事项中提取新项目之前，询问每个人是否需要任务方面的帮助。

 

6. 过分追求最佳实践

我曾经读过一大堆关于什么什么“最佳实践”的图书，也经常在一些技术交流会中看到类似的分享：“……的最佳实践”。

其实，在产品开发中没有最佳实践，而只有在特定环境中的最佳实践。那是别人的东西，未必适合自己的团队和待开发的产品。切记不能照搬照抄，“照猫画虎”。

我们承认好的团队的价值，承认他们总结和分享的价值；我们也需要抱着谦虚和学习的心态去聆听，体会；但是“鞋合不合脚只有自己知道”。学习和转化为应用和实践，需要有一个科学的过程。

过分推广最佳实践会扼杀学习、提问、参与和持续改进的氛围。有一些团队回想我们为什么总是要挑战最好的东西呢，现在不是挺好的吗？

Scrum是一个敏捷实践的框架，它不是一种具体的技术或者工具。敏捷宣言开篇就强调“个人和交互胜过技术和工具”。所以，拥有一个善于协作的团队，彼此能够默契的沟通和交流，是迈向成功的一半。

在你的项目范围内为Scrum设计你自己的最佳实践。你可以选择由团队或整个项目部门来完成。

 

7. 团队协作存在障碍

团队成员之间存在一些显而易见的障碍：

• 缺乏信任
• 欠缺投入
• 逃避责任
• 无视结果
• 惧怕冲突

Scrum团队中的每一名成员，无论你是什么角色：Product Owner、Scrum Master、还是开发团队的一员，都需要扫清上面的障碍，贡献自己的价值。

首先需要创造价值，才能够交付价值。

 

8. 缺乏有效的时间管理

要有效的进行时间管理，除了各种管理培训中都提到的“时间管理四象限”之外，我们需要知道40/30/30原则。

即，作为一名Scrum Master，对于突发性工作分配40%的时间，维持性工作分配30%的时间；发展性工作分配30%的时间。

• 将60%的时间列入工作计划，用于维持性工作和发展性工作；
• 授权，并学会利用（使用）他人
• 将80%的工作安排在20%的高效时段
• 处理打扰（干扰），为任务设定期限
• 按轻重缓急为工作排序

 

结论

有了良好的管理和对问题产生原因的认识，你就可以面对Scrum框架的这些挑战。

如果满足以下条件，你负责的Scrum项目将获得成功：

• 把对Sprint执行过程中的干扰降到最低，包括外包的干扰和来自团队内部的干扰
• 有一个经验丰富的Scrum Master
• 定期训练你的团队，让团队成员提升对敏捷和Scrum框架的认识，还有个人业务能力、技术能力
• 允许你的团队制定他们的时间管理和工作流程
• 需要弄清楚你希望Scrum中缺失的部分如何在你的项目中工作