对于那些在组织中实现了 Scrum 的人来说，您最大的障碍是什么？如果您确实克服了这些障碍，又是如何克服的？
最佳答案
背景:2006 年，我与一家大公司签订了契约(Contract)，就在我到达前几个月，该公司已经采用了 Scrum。该公司希望敏捷/Scrum 能够挽救他们庞大的企业软件产品。在那里的一百多名程序员中，我与一个大约十几人的团队密切合作了一年，观察并参与他们的敏捷实验。
总结:我相信敏捷的帮助大于伤害。到年底，团队可以持续估计和生成功能，而之前他们的生产力相当不稳定。
实现:由于这是一个大型组织和大型产品，因此该项目以“scrum of scrums”的形式运行。大约每 15-20 名开发人员就有一名 Scrum Master，这些团队通常被分成更小的、紧密工作的 Scrum，每个迭代大约有 6-8 人。团队在很大程度上是独立的，可以调整自己的迭代频率(1 个月减少到 1 周)，并被赋予很大的灵 active 来实现他们认为最好的敏捷。公司定期引入敏捷教练(例如 Object Mentor)来帮助培训 Scrum Master、团队和管理层。
障碍:很多。其中一些与敏捷相关，一些则不相关。以下是一些经验教训(排名不分先后):
一开始产品待办事项列表的修改过于频繁。最终，团队和管理层花了几天时间来检查所有功能，对其进行评估并确定优先级。这是一个巨大的打击，但它的帮助也很大。经验教训:尽早整理您的产品积压订单并对其进行维护。产品负责人必须清楚地了解自己想要什么。
我们浪费了时间去尝试和应对时尚和炒作。当你开始时，你无法知道你做的事情是否正确。人们很容易不断地摆弄敏捷流程，从而将注意力从产品上转移开。经验教训:拥有经验丰富的敏捷教练确实有助于缩短学习曲线。任何实验都应该有人反对。限制“尖峰”的数量。
一个好的 Scrum Master 是无价的。当然，一开始，这是一个全职职位。
这需要时间。团队花了几个月的时间才开始适应这个过程。
选择你的战斗。一些程序员会持怀疑态度，这是可以理解的，而另一些程序员则完全不喜欢并逃避这种改变。允许一定的灵 active 。例如，强制使用产品待办事项和迭代计划，但不要求每个人都使用记事卡。对引入工具和编程方法(例如结对编程或测试优先开发)特别敏感。
最后，保持沟通畅通并管理期望。
祝你好运!
关于敏捷(Scrum)采用——进展如何？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/395987/