其他人会觉得Scrum不敏捷吗？

41

我是敏捷开发的忠实拥护者，几年前在一个非常成功的项目中使用了XP。我喜欢它的所有内容，迭代开发方法，围绕测试编写代码，配对编程，让客户在现场运行。那是一个高产的工作环境，我从没有感到自己受到压力。

但是我工作的最后几个地方使用/使用了Scrum。我知道这几天是敏捷开发的榜样，但我不是100％相信它是敏捷的。以下是它对我不敏捷的两个主要原因。

项目经理喜欢它

从本质上讲，他们迷恋时间表的项目经理似乎都喜欢Scrum。以我的经验，他们似乎将Sprint Backlog用作跟踪时间要求并记录在给定任务上花费了多少时间的方法。他们都没有使用白板，而是使用一张excel表格，每个开发人员都必须认真地填写该表格。

在我看来，这对于敏捷过程来说是太多的文档/时间跟踪。当我可以继续进行任务本身时，为什么我会浪费时间估计一项任务要花多长时间。或类似地，为什么我会浪费时间记录任务可以花多长时间才能转到下一个任务。

站立会议

我以前工作过的站立会议是一场噩梦。每天我们都必须解释昨天的工作以及当天的工作。如果我们按照时间“完成”一项任务，那么项目经理会发臭，并参考“ Sprint待办事项列表”，以表明您不称职不称职。

现在，我了解了交流的必要性，但可以肯定的是，日常会议的气氛应该轻松愉快，并专注于知识共享。我认为这不应该成为您家庭作业风格的诱人之处。同样可以肯定的是，敏捷的漏洞在于时间线会发生变化，它们不应该一成不变。

结论

敏捷的想法是通过使开发人员的生活更轻松来使软件更好。因此，在我看来，团队使用的任何敏捷过程都应由开发人员领导。我不认为让项目经理使用他们标记为“敏捷”的流程来跟踪项目与敏捷开发有关。

有人在想吗？

agile scrum

— Winarama
source

6

在混乱中，团队应该自我管理。项目经理的目标是最终消除他们的角色，以便团队自行组织和参加日常会议。理想情况下，应该取消项目经理的角色，以参加回顾性会议和计划会议并处理所有组织工作。

— superM 2014年

7

是。即使是敏捷的“父亲”之一也不同意Scrum确实是敏捷的：youtube.com/watch?

— v=hG4LH6P8Syk

18

因此，您要说的是您没有在做Scrum，您知道这一点，但是您对Notscrum还是Notagile感到惊讶吗？

— pdr 2014年

2

我参加会议讨论流程所花的时间从未比我所参与的每个“敏捷”团队都要多。但是我仍然喜欢它比其他选择好得多。

— 罗布

11

以我的经验，Scrum本质上是通过将瀑布分成较小的单元来使瀑布看起来更敏捷的尝试。实际上，冲刺应该更现实地称为“层叠”。

— Berislav Lopac 2014年

25

Scrum中的某些元素更容易变态，但坦率地说，您所描述的是试图让组织采用Scrum而不对所有利益相关方进行全面教育，如何运作的结果，以及它为什么起作用。您需要整个公司的支持才能获得结果。

任何敏捷的转型都将暴露组织中正在发生的所有不良情况，包括但不限于微管理人员，有自己议程的超级渴望的人，训练有素的开发人员，沟通孤岛等。如果没有集体意愿来解决这些问题而您只是“站起来”而只是“在冲刺中工作”，Scrum的实现将一尘不染。

我不能太强调这一点：如果您想做Scrum，就需要有能力的教练为您提供指导。仅仅阅读Essential Scrum，然后仅仅看它能带给您什么，还不够……

— 斯蒂芬·比利埃（Stefan Billiet）
source

16

日常站立与微观管理有何不同？

— Giorgio 2014年

10

站起来是为了让团队安排他们的时间，以便他们不会互相妨碍。谈论估计，过去任务所花费的时间等绝对是不合适的-实际上，项目经理（与Scrum主管相对）应该完全不参加。

— 朱莉娅·海沃德

10

@Georgio：取决于您所说的微观管理。每天在SCRUM中站起来的目的是让每个人都了解其他人在做什么，而不是为项目经理提供机会以惩罚未达到预期的人。实际上，SCRUM中没有项目经理，跟踪和调整估算是团队的工作，如果未满足他们的要求，问题是“是什么原因造成的，我们将来如何避免或允许它？ ”，而不是“这是谁的错，我们能使他感到多严重？”

— Michael Borgwardt

3

@ErikReppen几乎可以解决所有问题，只有一小群人提出了值得改进的建议，然后又有一大群人希望将其货币化并通常完全将其转化：-p我相信Scrum，但是我完全与Scrum联盟及其认证业务保持距离。

— Stefan Billiet 2014年

8

@jessehouwing：是的，但是将会议强加给一个成熟的团队就像去找一个可以完全走路的人，然后告诉他们：看，你有问题，你不能走路，我会教你正确走路。这些人会看着你问自己：嘿，这个家伙想要我做什么？我当然可以走路。因此，将每天的会议强加给一个成熟，自组织的团队只会打乱他们的工作流程：这只是浪费。做出这样的决定的原因可以是无能的管理人员，也可以是观察/控制团队运作方式的意愿。

— Giorgio

20

是。即便是敏捷的“父亲”之一也不同意Scrum确实是敏捷的：youtube.com/watch?v=hG4LH6P8Syk –欣快

我认为以上评论之一的链接确实说明了一切。值得一看，Bob叔叔简要介绍了Scrum的历史，并且基本上说Scrum并不是敏捷的开发过程，因为Scrum已经随着时间的推移发展成为管理过程。这背后的原因似乎是因为上Scrum课程的是项目经理而不是开发人员。

— Winarama
source

2

这（你写的，不是鲍伯叔叔说的）是不合逻辑的。仅仅因为某件事是管理过程并不能使其固有地非敏捷。

— Dave Hillier 2014年

9

您可以有棕猫和棕狗，但棕猫永远不可能是棕狗。不是因为它不是棕色，而是因为它不是狗。同样，敏捷管理流程不能成为敏捷软件开发流程，这不是因为它不敏捷，而是因为它不是软件开发流程，这就是我们正在谈论的内容。

— winarama 2014年

1

然后，您可能想更新标题为“其他人是否觉得Scrum不敏捷？”的问题。

— Dave Hillier 2014年

感谢您分享视频。我发现它确实很有启发性。

— MickJ'9

好吧，喜欢敏捷的管理者甚至滥用它。因此他们可以责怪开发人员。因此，无论是否使用敏捷都使用敏捷是政治正确性的问题。

— 爱

13

您所描述的是我们专业Scrum培训师在“实施Scrum”的组织中看到的很多东西。通常，他们也“在开发团队中执行XP”，这意味着在某个地方的构建服务器上运行着一些单元测试。这不是混乱。

是的，项目经理可以使用产品积压，尤其是已经数字化的产品积压，以滥用此类系统收集的指标中的地狱。但是开发团队和Scrum Master不应让他使用。无论如何，项目经理在做什么？那不应该是产品负责人吗？

正如XP可能做得不好，某些更严格的过程可能会感觉非常不稳定（通过持续集成，部署，但仍然非常受计划驱动），Scrum只是一个框架。需要懂得价值观和良好执行过程的优秀人才。需要不断学习才能达到目标。

— 杰西霍温
source

12

您可能期望有一个，但是仅仅因为某些人（许多？）以不敏捷的方式滥用Scrum并不意味着Scrum并不敏捷。

项目经理：Scrum团队中没有这样的角色。Scrum Master不负责预算或按时完成任务。他负责帮助团队并消除阻碍他们实现目标的任何障碍。从您的描述来看，您的PM似乎劫持了Scrum，以取代通常属于团队和产品负责人的特权，从而延续了以前的命令和控制习惯。

时间跟踪：Scrum建议跟踪剩余时间并对其进行汇总以确定冲刺状态，而不要指出单个团队成员所花费的时间。这可能看起来很详细，但使以责备为导向的文化与以目标为导向的方法有所不同。

从Scrum指南：

监控冲刺进度

在Sprint中的任何时间点，可以将Sprint待办事项中剩余的总工作量相加。开发团队至少跟踪每个每日Scrum 剩余的总工作量，以预测实现Sprint目标的可能性。通过跟踪整个Sprint的剩余工作，开发团队可以管理其进度。

— guillaume31
source

即使Scrum在理论上是100％政治正确的，也不可避免地要成为一种以责备为导向的文化。

— 爱

2

Scrum是一种项目管理方法

敏捷是一种软件开发方法论

Scrum + Agile效果很好

没有敏捷的Scrum ...没那么多

— 史蒂文·A·劳
source

3

有趣的是，Scrum曾经是一种软件开发方法，但是随着时间的推移，它已经演变成项目管理方法。

— winarama 2014年

2

我认为这是不可避免的。开发人员只是在过程中没有太多的主人翁感（不想要）。在最近的一次Sprint审查中，我质疑团队的目的：编写软件或使燃尽图看起来不错。我提出了我的观点，但是随后房间中的所有PM都必须竭尽全力以强调等等等等的重要性。大声笑！

— 罗布

2

@ T-Pane：更有趣的是Scrum最初是作为新产品开发方法提出的 -hbr.org/1986/01/the-new-new-product-development-game/ar/1

— Steven A. Lowe

2

@ StevenA.Lowe Ah Scrum，这是一次自我发现的旅程。

— winarama

1

我知道它很旧，但是这个答案是完全错误的。Scrum是适合模式的框架。敏捷是一套价值观和原则。

— Venture2099年