agile - 敏捷（Scrum）采用——进展如何？

Question

对于在您的组织中实施 Scrum 的人来说，您最大的障碍是什么？如果您确实克服了这些障碍，又是如何克服的？

Answer 1

背景：2006 年，我与一家大公司签订了合同，该公司在我到达前几个月就采用了 Scrum 冷火鸡。该公司希望 Agile/Scrum 能够挽救他们庞大的企业软件产品。在那一百或更多的程序员中，我与一个十几个人的团队密切合作了一年，观察并参与了他们的敏捷实验。

摘要：我相信敏捷带来的好处多于伤害。到年底，团队可以持续地估计和生成特征，而之前他们的生产力相当不稳定。

实施：由于这是一个大型组织和大型产品，该项目以“scrum of scrums”的形式运行。大约每 15 到 20 名开发人员就有一个 Scrum Master，这些团队通常被分成更小的、紧密工作的、大约 6 到 8 人的 Scrum 进行迭代。团队在很大程度上是独立的，可以调整自己的迭代频率（从 1 个月缩短到 1 周），并且在他们认为最好的情况下可以灵活地实施敏捷。该公司定期聘请敏捷教练（如 Object Mentor）来帮助培训 Scrum 大师、团队和管理人员。

障碍：很多。其中一些与敏捷有关，一些与敏捷无关。以下是一些经验教训，排名不分先后：

产品积压工作一开始就被修改得太频繁了。最终，团队和管理层花了几天的时间来检查所有功能，评估它们并确定它们的优先级。这是一个巨大的打击，但它提供了巨大的帮助。经验教训：尽早整理好您的产品待办事项并保持维护。产品所有者必须清楚他们想要什么。

我们浪费了时间来尝试和处理时尚和炒作。当您开始时，您无法知道自己是否正确地做事。人们很容易不断地摆弄敏捷过程，从而将注意力从产品上移开。经验教训：拥有经验丰富的敏捷教练确实有助于减少这种学习曲线。任何实验都应该有人反对。限制“尖峰”的数量。

一个好的 scrum master 是无价的。当然，一开始，它是一个全职职位。

这需要时间。团队花了几个月的时间才开始适应这个过程。

选择你的战斗。一些程序员会持怀疑态度，而另一些程序员会完全不喜欢并逃避改变。允许一些灵活性。例如，强制使用产品积压和迭代计划，但不要求每个人都使用记事卡。对引入工具和编程方法特别敏感，例如结对编程或测试优先开发。

最后，保持沟通畅通并管理期望。

祝你好运！

Answer 2

几年前作为 Delphi 开发人员工作时，我设法让 Scrum 被我的开发团队采用了一段时间。

整个过程对我们来说效果很好——让团队估计积压任务的优先任务给了我们有意义的目标时间框架，整个“管理工作是消除障碍”很棒。

最大的问题是这个过程总是被认为——并被称为——“贝文的好主意”。

虽然团队赞赏我们获得的价值，并且很高兴继续使用 Scrum，但团队并没有将 Scrum 方法论视为自己的。一段时间后，我厌倦了“推动”，我们“放弃”了遵循 Scrum 方法。

教训：确保团队接受 Scrum 并拥有这种方法。

Answer 3

我们主要在客户现场进行 Scrum 项目。在我的经验中，最困难的部分是在客户组织中找到一个好的产品负责人：

• 太多人认为他们应该是产品负责人，
• 产品负责人很难跟上团队的步伐
• 产品负责人很难获得团队需要的所有详细信息
• 将项目移到产品积压中以添加具有更高优先级的内容是很困难的
• 等等

培训内部团队使用 scrums 是可行的，引入自己的 scrum master 是可行的，但一个好的产品负责人应该是客户组织的一部分。训练这个外在的人更难。拥有与客户产品负责人一起工作的代理产品负责人确实有很大帮助。

Answer 4

我一直在几个项目中运行 Scrum。在我看来，最大的问题是并非组织中的每个人都参与了这个过程。每个人都需要承诺。不仅是开发人员团队。管理者通常是初始化流程的人，并期望事情会在他们不做任何事情的情况下变得更好。

我的建议是你与整个组织一起举办一个研讨会，这样每个人都知道这个过程是如何运作的。不仅仅是开发商。有一个真正投入到这个过程中的人是很重要的。可以回答团队和组织的问题的人。一个导师。

敏捷就是迎接变化。你不应该让这个过程妨碍你的理解。做对你的组织有用的事情，但你应该在扔掉一些东西之前尝试整个过程。

Answer 5

我从一家采用敏捷的公司转到另一家遵循传统方法的公司。

也许我看到的最大不同是第二家公司难以确定优先级。每个人的工作量很大，以至于他们无法按时交付。IMO，敏捷为情况带来了一些透明度，并让整个团队优先考虑。

敏捷世界中的 Scrum Master 将负责救火并成为（冲刺）团队的代言人。事实上，在第一家公司（我们有单独的 Scrum Master 和项目经理），当项目经理向管理层做出虚假承诺时，Scrum Master 会与项目经理争吵。这意味着，Scrum Master 知道一个团队在几个 sprint 之后可以生产/交付多少，这有助于她确定团队的可预测性。

我也注意到研发资源在每个周期结束时都有成就感，期待下一个。但是，一个好的项目经理也可以在传统场景中完成这项工作。

Answer 6

如前所述，我也经历过的最大问题是缺乏支持。要让人们真正投入到这个过程中是非常困难的。

另一个问题，也是直接导致上述问题的一个问题，并且在很大程度上也是敏捷的创始原因之一，是缺乏管理来坚持敏捷宣言的大纲。

在 Scrum、精益或任何你正在使用的敏捷版本中，都不能脱离宣言的要点。如果一个流程被用来摆脱这些优先事项，那么管理层很可能搞砸了，买入将分崩离析。必须遵循宣言：

宣言：

• 个人和交互超过流程和工具
• 工作软件优于综合文档
• 合同谈判中的客户协作
• 响应变化而不是遵循计划

某些情况可能是甘特图出于某种原因从上述过程之一中出现。甘特图可能很有用，但如果开发人员突然与管理层一起审查甘特图，最后一点就被打破了。对变化的反应已经放缓，因为鼓励计划比变化更受青睐。相反，应该使用带有便签的板子，简化板上的内容，仅包含当前工作项目和次要项目。这使更改变得容易。一旦任何东西在“工具”中固化，它就会减慢对变化的响应。当然，管理层需要以某种方式记录和跟踪事情，但是将其推向开发只会减慢对变化的响应，并且将工具推给开发人员（除非他们希望将它们用于开发并且可以适当地利用它们）会弄乱第一点，

换句话说，不要为了编写全面的文档而停止开发。除非您只有一个开发人员，否则应该有人从开发角色中自主承担文档负载。将这些东西放在一起会大大减慢开发速度，并且在一段时间内，可能会停止任何实际获得工作软件的努力。

最后一点，始终、始终以某种方式与客户或潜在客户保持联系。定期与他们讨论他们想要什么。每天与他们交谈，尽可能多地向他们展示 UI，甚至是数据流工作。他们会理解的任何东西都应该看到。与他们交谈，向他们介绍应用程序的架构和想法，并且永远不要忘记您正在为他们构建应用程序。

概括：

最大的问题是接受。其次是管理层坚持宣言准则。

如果你能减轻这两个风险，你应该很高兴。在获得支持并让管理层了解他们需要成为真正强大的非微观管理经理之后，其他任何事情都是小菜一碟。具体来说，经理甚至可能需要成为领导者，或担任不同风格的角色。

...希望我没有偏离太多。:)

Answer 7

我们在一个高度集成的环境中实施了敏捷（一组 SCRUM - 管理和 XP - 工程实践），其中包含大型项目的瀑布。瀑布警察无处不在。可以想象，许多项目都失败了。在以前的雇主处完成敏捷后，我们获得了为该项目试用敏捷的许可。

在团队内部，我们使用了敏捷实践。在外部，我们用瀑布流程包裹敏捷实践，主要是报告。因此，我们从外部看起来就像一个瀑布项目。然而，有一个很大的不同，我们在内部使用敏捷，因此我们在预算范围内按时交付高质量。

关键的成功因素是嵌入式教练（迭代经理教练、开发主管教练、测试主管教练和解决方案分析师教练）。在高度集成的环境中，必须提前确保依赖系统的承诺（要求我们提前确定依赖系统和这些系统所需的工作）。在开始之前，我们让团队的技术和业务成员沉浸在敏捷训练营中。这确保了关键参与者（产品所有者和技术团队）了解其中的角色并能够有效地执行。最后，使用瀑布报告封装项目使我们能够与企业中所有现有的报告结构联系起来。

最终结果是，该公司现在正在将瀑布项目转向敏捷。这一切都是可能的，因为我们能够以可持续的速度交付高质量的软件。

Answer 8

我工作的地方使用 Scrum 已经有一段时间了，但它似乎经历了几个阶段。就障碍而言，一部分是防止一次进行过多的更改，然后慢慢介绍，例如一周进行每日站立，几周后放入故事板，几周后引入结对编程. 这允许进行各种调整，如果这些更改可以改善情况，那么这可以帮助建立一些良好的势头。另一点是要确保如果某件事的完成方式发生变化，被纠正的人不会受到轻视或嘲笑。有时这可能意味着你打断了某人，或者你带来了“我们可以回到基础吗？”

IMO，聘请顾问是这里做得最好的事情之一。现在，这些人进来帮助改进这里的开发方式。引入结对编程、TDD、破窗、组织项目文件夹和引入模拟测试等概念，这些都是极好的补充，虽然我们可能靠自己做到了，但可能需要很长时间，但这是行不通的出来这么好。