采用Scrum的挑战

引入新的软件开发方法会有一系列的挑战，比如“不愿意去改变”、“采用技术不当”，最终导致失败。在敏捷期刊上一系列的文章中，Cesário Ramos 和 Eelco Gravendeel 谈到了向不同的组织介绍 Scrum 时，他们的所见所闻，以及遇到的挑战。作者还提出，有一些方法和策略可以解决这些困难，并会使组织采用 Scrum 更容易。

他们说最主要的挑战以及可能的解决方案有：

没有组织级别的学习——回顾会议的反馈被丢下不管，没有用来提高流程。理想情况下，所有的反馈应该有对应的行动任务。这些行动任务如果对项目有影响就由团队负责，如果对组织有影响就由 Scrum Master 负责。
缺乏信任的环境——通常，这种环境导致大家隐匿错误，不分享观点，并拖延决策的制定。其解决方案是构建这样的环境：有很多正面反馈和很高的透明度。通过扩展信息辐射墙可以得到这种环境，因为它会促进交流和提高透明度。
采用 Scrum 来补救，但不知道问题在哪里——不要因为炒作而去采用一种新方法，组织应该尽量定义自己的期望和衡量标准。“当前的流程哪里有问题？”，“是什么造成的这种问题”，“当问题没有了我们能做什么”，回答这样的问题有助于定义目标期望和衡量标准。
产品负责人自身的缺陷——这些产品负责人要么没有足够知识，要么没有很大权利，甚至两者都没有，所以无法雷厉风行地工作。产品负责人的能力受到限制，无法快速做出决定，这最终影响了团队的速度。
严格遵守并且“只”按规则执行敏捷——Scrum 流程简单，但是行为复杂。对一个组织有用的东西未必对另一个有用。从各个方面来说“只”按规则并不会有用。一旦彻底了解了 Scrum，每个组织就可以按需定制。
组织没有为 Scrum 项目做好准备—— 使用 Scrum 的团队不能埋头单干，与其它团队协作才能成功。产品负责人需要与销售和市场紧密配合；与测试、设计团队紧密配合，使他们成为自己团队的一部分；与最高管理层紧密配合，可在新的项目跟踪、汇报方式方面得到帮助。给新方法打好基础，使所有部门参与，那么采用 Scrum 会更快更简单。
缺少 Meta-Scrum Master—— 负责项目的 Scrum Master 并不能解决所有问题。Scrum 中特别强调了一些问题，需要由组织层次解决，这就需要高层担任 Meta-Scrum Master，在交付时间和投资回报率都有限的情况下下解决这些问题。
Scrum 成为莽撞行为的借口——这种行为意味着，以采用新方法的名义抛弃已有的最佳实践。Scrum 可以快速暴露效率低下以及其它问题，但关键是不要预先优化，而是等问题暴露之后再解决。
把敏捷想的太简单——敏捷原理简单，但实践较难。最好的方法是有一个敏捷教练协助团队。组织里要有敏捷的大拿，在各个层次培训员工，宣扬敏捷、开培训班、指导 Scrum Master，都是采用 Scrum 的关键因素。

Cesario 和 Eelco 建议说，面对新方法人们会有许许多多的问题，要合理地解决这些问题，才能保证最后的成功。

据他们讲：

人们最终会有许多这样的问题：你们怎样计划和评估？我们怎样才能预测？你们怎样管理敏捷合同？我们不能确定最后期限吗？架构呢，自己就突然冒出来了吗？我们怎样才能同时做需求、开发和测试？别傻了！！价值怎样衡量，你怎样根据它给需求设定优先级？已经有了这种计划 - 执行 - 检查 - 调整的方法，我们怎样才能那么做呢？敏捷的成本不是更高吗？
不解决好这些问题，一旦有了压力，人们就会退回到以前的工作方式。我们首先看到的是质量的下降、测试工作的减少，管理步骤的命令和控制方式也随即倒退。结果就是士气低下，速度甚至降得更多，项目被取消，采用 Scrum 变得更加复杂。

所以，采用新技术很容易有多种挑战。关键是要着眼大局，意识到它能带来的好处。所以组织级别要创建这样的文化：不断学习、逐渐适应。

查看英文原文：Challenges in Adopting Scrum

采用 Scrum 的挑战