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

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

 

上一篇:第一次反射实践


下一篇:Xcode5中如何切换Storyboards为xib