10

我听说很多公司表现得好像他们很敏捷，但他们所做的唯一敏捷的事情就是 Scrum 流程。这足以被认为是敏捷的吗？单独使用 Scrum 似乎是一个糟糕的经理更频繁地召开更多会议的完美借口。我应该厌倦这样的公司吗？

4

14 回答 14

17

敏捷是一个大而模糊的概念。很多东西都是敏捷的。

Scrum 是一组用于冲刺和发布的特定技术。它是敏捷的，因为它符合敏捷宣言。

还有许多其他特定的敏捷技术（例如，所有 xDD。）

如有疑问，请将公司的实际实践与敏捷宣言进行比较。

于 2008-10-03T23:31:42.347 回答
9

“我听说很多公司表现得好像他们很敏捷，但他们所做的唯一敏捷的事情是 Scrum 流程。这足以被认为是敏捷吗？”

简短的回答 - 是的。无论如何，在我看来:-)

当然——他们必须真正在做Scrum——而不是把名字贴在墙上。Scrum 不仅仅是每天的站立会议……如果这就是他们所做的一切，那么他们就做得不对。

正确完成 Scrum 迫使公司识别组织运行方式的瓶颈。通过设置定期的时间盒冲刺，获得体面的反馈循环，并在产品所有者和团队之间适当地分配责任，您实际上可以获得有关如何改进流程的有用基线信息。

组织必须听取反馈并采取行动。

这当然不是实现敏捷的唯一方法。它甚至可能不是将敏捷引入组织的最佳方式。我自己更喜欢 XP ——并且发现额外的实践为启动这些流程改进提供了一个有用的框架。

也就是说 - 对于许多组织来说 - 最大的问题是职责分工不当以及完全缺乏理智和快速的反馈循环。Scrum 解决了这个问题。

会议只是其中很小的一部分:-)

于 2008-10-05T15:43:13.977 回答
8

Scrum 所提倡的透明性会让糟糕的管理者脱颖而出。真正拥抱 Scrum 的公司绝对值得一看。

于 2008-10-03T23:17:34.480 回答
3

单独使用 SCRUM 不一定是召开更多会议的借口。能够跟踪每天完成的工作并决定如何修改（通过削减或重新平衡工作）冲刺的其余部分本身就非常有用，而且对我来说听起来很敏捷。:-)

当然，如果你没有敏捷过程的其他组成部分，你将很难衡量你的工作是否成功，所以你可能认为你在冲刺的轨道上，但实际上还差得很远您应该按时交付优质产品。

更新：你不应该仅仅在这个前提下解雇这样的公司。但是，在面试期间，您应该利用这个机会了解他们为什么只使用 SCRUM。如果没有人来支持 TDD 或 CI 之类的事情，那么如果您愿意成为技术负责人，那么它可能很适合您。如果是因为他们将这些流程视为“开销”、“愚蠢”或“不必要”，那么你应该对公司保持警惕。

于 2008-10-03T22:54:21.953 回答
2

我注意到，仅使用 Scrum 会议是一个非常明显的迹象，表明该公司没有正确实施敏捷概念。

想想 Scrum 会议有多简单，只需启动 Outlook 并让每个人每天开 15 分钟的会议。但是，将所有内容分割成快速迭代并确保最终用户快速测试新功能需要更多的工作。

我猜，大多数经理在 Scrum 部分之后就停止阅读，他们就失去了兴趣。但是，他们的日常会议请求永远存在。

于 2008-10-03T23:14:25.580 回答
2

Scrum 是一种项目管理方法，首先也是最重要的。是的，如果你在做 Scrum，你可能会开始更多地考虑敏捷，并为你的客户提供价值。但这并不一定会让你变得敏捷。对于初学者来说，Scrum 不会谈论你如何进行软件开发。这就是诸如 XP 之类的东西的用武之地——其他方法和想法迫使您审查和改变您的工作实践，以便变得更有效率和效力。

因此，与其问“你做 Scrum / XP / 什么”，不如问这些公司他们的整体流程并采取整体观点。公司是否专注于提供最大的商业价值并以持续改进的精神为动力？如果是这样，那么他们可能比那些说它做 Scrum 的人敏捷得多。

于 2008-10-05T19:44:01.493 回答
2

敏捷！= scrum。

敏捷是为改变做好准备。

敏捷多次被呈现为一个保护伞，一组不同的技术、方法，用于在支持变革的环境中工作。Scrum 用于项目管理，开发技术有 xp，为了更好的需求流程，您可以使用 BDD，用于测试 TDD。

从 scrum 开始是敏捷之路的第一步。也考虑其他技术。这需要时间，但有真正的好处。没有什么比共识和良好的团队精神更好的了。作为第一个实现它。

于 2010-12-09T10:54:22.217 回答
2

不能仅仅因为有人说他们在做 Scrum 就判断一个团队是否敏捷。

Scrum 实现有好有坏，但敏捷的关键在于：

  • 项目和团队灵活思考的能力
  • 团队的自组织程度如何（他们是否有控制狂“架构师”或经理？或者是否有相当多的共识决策？）

在没有真正敏捷的情况下，很容易满足团队在进行 Scrum 时需要做的最低要求。这些最低要求只是为了带来某种态度和工作方式。

项目中的决策可能非常不灵活且自上而下受控，但仍符合 Scrum 的最低要求。可悲的是，当我寻找合同约定时，我发现仅名义上的 scrum 实现的数量远远超过了真实的实现。

就个人而言，我会选择在 scrum 中实现极限编程。（事实上​​，Jeff Sutherland 说他从来没有见过没有进行 XP 实践的顶级生产力 Scrum 团队。）但是，我非常有信心人们也可以非常糟糕地实施 XP... ;-) 它真的失败了对球队的态度。

于 2009-11-07T00:31:40.247 回答
2

敏捷宣言实际上是一种与更好的工作方式有关的哲学。Scrum 是一种敏捷方法，所以是的，使用 Scrum 的公司通常被认为是敏捷的。

然而，在尝试实施 Scrum 时完全有可能忘记敏捷哲学。很容易陷入对完美 Scrum 流程的追求而忽视个人及其互动。

你应该厌倦那些忽视个人和互动的公司，而盲目地偏爱严格的流程和工具。但是，无论他们声明的方法如何，这都是正确的。

于 2017-05-16T14:04:26.217 回答
1

单单 Scrum 就等于敏捷，这完全是一种误解。敏捷是一种保护伞，其中有几种方法，如 scrum master、看板、精益、XP。现在你说伞的一部分如何才能实现伞的整体概念。因此，Scrum 是敏捷的一部分。

于 2016-06-15T11:02:42.743 回答
0

只实践 Scrum 的组织很可能会在软件管理和项目可见性方面看到收益。然而，他们很可能不会通过不结合 XP 原则（如单元测试、持续集成、结对编程等）来实现更高的工程质量和吞吐量潜力，从而使他们的 Sprint 产品的末端不是“潜在可交付”的。

于 2010-02-09T22:52:24.287 回答
0

Scrum 为您提供了一个框架来修复/改进您的开发过程。它应该被视为“结成团队”和更有生产力的团队的起点。您很可能很快就会超越标准的 Scrum 实践，但作为起点，它具有一些吸引人的特性：

  1. 这很容易理解
  2. 它几乎可以应用于任何项目和团队
  3. 有很多人赚钱并帮助公司采用 Scrum

此外，知道 Scrum = 敏捷是否真的不是那么重要。最好专注于提高生产力，不要为这些问题烦恼。

于 2008-10-23T17:35:33.573 回答
0

是的，我同意这里的一些观点。敏捷是遵循宣言并确保您正确排列优先事项。SCRUM 只是另一种写下特定部分的变体。如果有的话，它是一种管理“工具”。

话虽如此，请记住，工具是次要的，你的人是你的首要任务。不要过度关注管理风格，而不是关注人和产品。

于 2008-10-23T17:52:26.160 回答
0

人们成为他们主观观点的牺牲品。我认为敏捷和 Scrum 是什么，另一个人的想法可能会有所不同。幸运的是，我们在敏捷宣言、原则和Scrum 价值观中有一套指导方针，但通常公司最终会变得专注于遵循流程，而不是理解它及其目标。

敏捷宣言

我们正在通过开发软件并帮助他人开发软件来发现更好的方法。通过这项工作，我们开始重视：

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

也就是说，虽然右边的项目有价值，但我们更重视左边的项目。

Scrum 价值观

通过询问他们的价值观以及他们如何遵守这些价值观，您可以了解很多关于使用 Scrum 的公司的信息。这可以让您了解 Scrum 的过程是否只是在没有真正考虑与之相关的价值的情况下执行。

在 Scrum 中执行的所有工作都需要一组价值观作为团队流程和交互的基础。通过接受这五个价值观，团队使它们对其健康和成功更加重要。- 查看更多信息： https ://www.scrumalliance.org/why-scrum/core-scrum-values-roles#sthash.qsmCTxdU.dpuf

  • 重点
  • 勇气
  • 开放性
  • 承诺
  • 尊重

目标

目标是在每次迭代结束时发布高质量的软件。

通过适当的影响，公司内部的价值观可以改变。不幸的是，人们是不可预测的，因此当引入其他变化时，公司可能会重新陷入不良习惯。这就是使软件更具挑战性和令人兴奋的原因。它正在寻找在技术和产品之间建立平衡的方法。

红旗

  • 如果一家公司更关注过程而不是目标。
  • 如果您必须跳过各种圈套和程序来签署最小的更改。
  • 公司不必让流程 100% 正确，但如果他们没有不断调整和改进以实现目标，而不是仅仅遵循流程，那么他们可能最终会以“半途而废”的方式实施敏捷：

我们通过付费顾问和阅读 Gartner 报告听说了开发软件的新方法。通过这一点，我们被告知要重视：

  • 个人和互动优于流程和工具，我们有强制性流程和工具来控制这些个人（我们更喜欢“资源”一词）如何互动
  • 只要该软件有全面的文档，就可以使用软件而不是全面的文档
  • 当然，在严格的合同范围内进行合同谈判的客户协作，并受到严格的变更控制
  • 响应变化而不是遵循计划，前提是制定了详细的计划来应对变化，并且得到准确的遵循

也就是说，虽然左边的项目在理论上听起来不错，但我们是一家企业公司，我们不可能放弃右边的项目。

遵守

一些公司可能有严格的合规程序，阻碍了敏捷。这可能包括无法逃避的治理和其他法规。这可能会影响敏捷方法，使其感觉更加笨重和沉重，但这并不意味着这些流程不能被简化以更适应。

于 2016-06-18T10:45:47.143 回答