对于那些在你的组织中实施过Scrum的人来说，你最大的障碍是什么，如果你确实克服了它们，那又如何？
答案 0 :(得分：11)
背景：2006年，我与一家大公司签约，该公司在我到达前几个月就采用了Scrum冷火鸡。该公司希望Agile / Scrum能够保存他们庞大的企业软件产品。在那里的一百多名程序员中，我与一个大约一年的团队密切合作一年，观察并参与他们的敏捷实验。
摘要：我认为敏捷帮助的不仅仅是伤害。到今年年底，该团队可以持续估计和生成功能，而以前他们的生产力相当不稳定。
实施：由于这是一个庞大的组织和一个大型产品，该项目是一个“scrums scrum”。每15-20名开发人员中就有一名scrum master，这些团队经常被分成较小的，密切合作的scrums，大约6-8人进行迭代。团队在很大程度上是独立的，可以调整他们自己的迭代频率（1个月到1周），并且给予了很多灵活性来实现他们认为最好的敏捷。该公司定期引入敏捷教练（如Object Mentor）来帮助培训Scrum主管，团队和管理人员。
障碍：很多。其中一些与敏捷有关，有些则没有。没有特别的顺序，这里有一些经验教训：
产品积压在开始时经常被修改。最终，团队和管理层花了几天的时间来检查所有功能，估算它们并确定它们的优先级。这是一个很大的打击，但它帮助很大。获得的经验教训：尽早获取产品待办事项并保持其状态。产品所有者必须清楚自己想要什么。
我们浪费时间尝试和处理时尚和炒作。当你开始时，你无法知道你是否正确地做事。有一种诱惑就是不断摆弄敏捷过程，将焦点从产品上移开。获得的经验：拥有经验丰富的敏捷教练确实有助于减少这种学习曲线。总会有人推迟任何实验。限制“尖峰”的数量。
一个优秀的Scrum大师是非常宝贵的。当然，在一开始，它是一个全职的职位。
需要时间。在团队开始对这个过程感到满意之前，花了几个月的时间。
选择你的战斗。一些程序员可以理解为持怀疑态度，而另一些程序员则完全不喜欢并推动变革。允许一些灵活性。例如，强制使用产品积压和迭代计划，但不要求每个人都使用记事卡。对引入工具和编程方法（如结对编程或测试第一次开发）特别敏感。
最后，保持沟通畅通并管理期望。
祝你好运！答案 1 :(得分：5)
几年前，当我作为Delphi开发人员工作时，我设法让我的开发团队采用了Scrum一段时间。
整个过程对我们来说非常有效 - 让团队估计积压的优先任务给我们提供了有意义的目标时间框架，整个“管理工作就是消除障碍”非常棒。
最大的问题是这个过程总是被认为 - 并且被称为“Bevan的好主意”。
虽然团队对我们获得的价值表示赞赏，并乐于继续使用Scrum，但团队并没有将上的scrum方法作为他们自己的。过了一会儿，我厌倦了“推动”，我们“不再”遵循Scrum方法。
课程：确保团队采用Scrum并拥有该方法。
答案 2 :(得分：2)
我们主要在客户站点进行scrum项目。在我的经验中，最难的部分是在客户组织中找到一个好的产品所有者：
培训内部团队使用scrums是可行的，引入自己的scrum master是可行的，但是一个好的产品所有者应该是客户组织的一部分。训练这个外在的人更难。 拥有与客户产品所有者合作的代理产品所有者确实提供了很多帮助。
答案 3 :(得分：2)
我在几个项目中一直在运行Scrum。正如我所看到的，最大的问题是，并非组织中的每个人都参与到这个过程中。 每个人都需要承诺。不仅是开发团队。通常，管理者是初始化流程的人，并且期望在没有他们做任何事情的情况下事情会变得更好。
我的建议是你和整个组织一起举办研讨会，这样每个人都知道这个过程是如何运作的。不仅是开发人员。你必须拥有一个真正融入这个过程的人。能够回答团队和组织的问题的人。导师。
敏捷就是欢迎改变。你不应该让这个过程妨碍你。做一些适合你的组织的事情，但是你应该在抛出一些东西之前尝试整个过程。
答案 4 :(得分：2)
我从一家采用Agile的公司搬到另一家采用传统方法的公司。
也许我看到的最大的不同是第二家公司努力优先考虑。每个人的盘子上都有很多工作，他们无法按时交付。 IMO，Agile为这种情况带来了一些透明度，让团队作为一个整体优先考虑。
敏捷世界的Scrum大师将负责消防并成为（冲刺）团队的代言人。事实上，在第一家公司（我们有一个独立的Scrum主管和项目经理）中，当后者向管理层做出虚假承诺时，scrum master会与项目经理讨论。这意味着，scrum master知道一个团队在几次冲刺后能够产生/交付多少，这有助于她确定团队的可预测性。
我还注意到R＆amp; D资源在每个周期结束时都有成就感，并期待着下一个周期。但是，一个优秀的项目经理也可以在传统场景中完成这项工作。
答案 5 :(得分：2)
如前所述，我所经历的最大问题是缺乏买入。很难让人们真正成为这个过程的归属。
另一个问题，也是直接导致上述问题的问题，也是敏捷的一个主要原因之一，就是缺乏管理层来坚持敏捷宣言的大纲。
在Scrum，Lean或任何与您合作的敏捷版本中，都无法摆脱宣言。如果正在使用一个流程来摆脱这些优先级，那么很可能管理层正在搞砸，买入将会崩溃。必须遵循宣言：
宣言：
某些情况可能是由于某种原因上述进程之一出现甘特图。甘特图可能很有用，但如果开发人员突然用管理层审查甘特图，最后一点就会被打破。应对变化的速度已经放缓，因为计划的鼓励正在受到改变的青睐。相反，应该使用带有胶粘物的电路板，简化电路板上只有当前工作项目和后燃烧器项目。这使得更改变得容易。一旦任何东西在“工具”中固化，它就会减慢对变化的响应。当然，管理层需要以某种方式记录和跟踪事物，但是将其推向开发只会减慢对变更的响应，并将工具推送给开发人员（除非他们希望开发并且可以适当地利用它们）弄乱了第一点，个人而不是工具和过程。
另一方面，不要为了编写全面的文档而停止开发。除非您只有一个开发人员，否则有人应该从开发角色自主加载文档。将这些东西推到一起会大大减缓开发速度，并且在一段时间内，可以关闭实际获得工作软件的任何努力。
最后一点，始终是，始终以某种方式与客户或潜在客户保持联系。定期与他们谈论他们想要什么。每天与他们交谈，尽可能多地展示他们的UI，甚至数据流工作。他们应该明白他们应该看到的任何东西。与他们交谈，向他们介绍进入应用程序的架构和想法，永远不要忘记您正在为他们构建应用程序。
要点：
最大的问题是买入。其次是管理层坚持宣言指南。
如果你可以减轻这两种风险，你应该好好去。在获得购买并让管理层了解他们需要真正强大的非微观管理经理之后，还有其他任何事情。具体而言，管理者甚至可能需要成为领导者，或者填补不同风格的角色。
...希望我没有太多偏离点。 ：）
答案 6 :(得分：2)
我们在一个环境中实施了Agile（一套SCRUM - 管理和XP - 工程实践），这个环境在大量集成的环境中是大型项目。瀑布警察随处可见。可以想象，许多项目都失败了。在以前的雇主做过敏捷之后，我们获得了为该项目试用敏捷的许可。
团队内部，我们使用了敏捷实践。在外部，我们使用瀑布流程包含敏捷实践，主要是报告。因此，我们从外面看起来像一个瀑布项目。但是，有一个很大的区别，在内部我们使用敏捷，因此我们按时在预算内以高质量交付。
关键的成功因素是嵌入式教练（Iteration Manager Coach，Dev Lead Coach，Test Lead Coach和Solution Analyst Coach）。在高度集成的环境中，必须提前确保从属系统的承诺（要求我们展望未来以确定依赖系统和这些系统所需的工作）。在开始之前，我们将团队的技术和业务成员沉浸在敏捷的训练营中。这确保了关键参与者（产品所有者和技术团队）知道角色并且可以有效执行。最后，使用瀑布式报告包装项目使我们能够与企业中所有现有的报告结构相结合。
最终结果是该公司正在将瀑布项目转移到敏捷。这一切都是因为我们能够以可持续的速度提供高质量的软件。
答案 7 :(得分：2)
我工作的地方一直在使用Scrum一段时间，但似乎已经经历了几个阶段。在障碍方面，一方面是防止一次性进行太多改变而只是缓慢地介绍一些事情，例如。每周站立一周，几周后放入故事板，几周后引入配对编程。这允许各种调整将发生作用，如果改变改善了事情，那么这可以帮助建立一些良好的势头。另一点是要确保如果某些事情发生了变化，那么被纠正的人就不会被贬低或嘲笑。有时这可能意味着你打断某人或者你带来了“我们可以回归基础吗？”或类似的东西试图让事情回到正轨，而不是只是对某人大喊大叫或做一些适得其反的事情。
聘请顾问是IMO最好的事情之一。现在，these guys进来帮助发展如何在这里完成开发。引入结对编程，TDD，破窗户等概念，组织项目文件夹，以及引入模拟测试，都是很好的补充，虽然我们可能已经自己到那里，但可能需要很长时间才能工作这么好。