标签：Product 中曾 遇到 Scrum Master Owner Sprint 团队

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中缺失的部分如何在你的项目中工作

 

标签：Product,中曾,遇到,Scrum,Master,Owner,Sprint,团队
来源： https://blog.csdn.net/seagal890/article/details/116206688

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。