使用Scrum的敏捷方法的一个优点是瀑布方法

Question

如果你必须选择Scrum为瀑布流程提供的一个优势，它会是什么？

Answer 1

您构建了客户想要的东西，而不是客户在收集需求时的想法。

编辑：这是敏捷方法的一般属性，强调早期和经常交付 - 与瀑布完全相反（交付迟到和一次）。

Answer 2

它为您提供了一个过程，可以及早提供可用的业务功能，从而增加客户对结果满意的可能性。它也以相对较低的成本实现，并降低了失败的风险。

Answer 3

瀑布假设您事先知道所有事情，这是不可能的。

一个好的scrum流程就像瀑布一样开始，列出你想要构建的所有内容。不过，Scrum的优势在于，您可以在每次迭代后重新对该列表进行排名，您始终可以构建客户所需的内容。

当我们构建其中一个产品的测试版时，我们允许测试版客户帮助推动下一个周期的堆栈排名。最终的结果是客户想要的产品，而不是我们对他们的要求。

Answer 4

您可以快速提供可用的软件，以便在项目失效前确定您是否在正确的轨道上。

当然，这适用于任何敏捷流程而不是瀑布，而不仅仅是Scrum。

Answer 5

可能有一些软件开发实现在瀑布框架中使用大部分Scrum，因此您的部分问题可能基于错误信息。

我在Scrum中看到的主要优势是它提供的日常沟通和问责制，以便团队中的每个人都可以知道其他人在做什么，并分享他或她所处的位置。这可以让我们了解正在发生的事情以及告诉你正在做什么的责任，这可以使Scrum成为开发软件的一个非常好的部分，假设你正在与可以相处的人合作，并且很自在地制定他们自己的规则。某种程度上。

Answer 6

快乐的开发者

Answer 7

我喜欢SCRUM的首要原因是烧毁概念。没有人关心你花了多少时间，他们需要知道的是你剩下多少时间。

Answer 8

我发现这是一个很好的激励因素，整个团队都参与了规划过程，而不仅仅是几个人（以前就是这种情况）。根据我的经验，这通常也相当于更精确的估计，这对于使项目保持正确的路线至关重要。

此外，很好地了解当前团队的实际情况，了解每个人在某种程度上的工作情况，而不仅仅是让项目负责人单独发布作业。

Answer 9

首先，如果我们只是同意正确的问题更像是“敏捷”与“瀑布”...

作为一名前开发经理，我对此的主要看法实际上有所不同。我喜欢敏捷方法的“工程实践”优势，例如burndows，JIT设计等。 然而，研究表明，流程选择与成功率之间的相关性低于许多人的预期（one example）。当然，敏捷一直表现得更好一些，但目前尚不清楚这些研究是否适应了这样一个事实，即你倾向于在敏捷项目中拥有更好的开发人员 - 或者是因为更好的开发人员倾向于推动敏捷，或者因为敏捷往往会吸引敏捷更好的开发者 如果你看一下Cockburn的一些东西，很明显软件项目的主要成功驱动力是项目人员的质量 - 而不是过程。

请参阅Cockburn's book以获得对此的一些非常好的基本解释（这不是一本如何预订，而是解释基本概念以及为什么要做敏捷的事情）。

在我看来，敏捷方法有助于创建一个优秀程序员想要工作的环境。因为他们是这个过程的一部分，因为他们被允许使用他们的大脑等。
因此，作为一家企业，您更有可能吸引并留住顶尖人才，这意味着您更有可能拥有成功的项目。

在商业层面，这才是真正的理由 - 其他一切都非常好，但这是最重要的一点，也是你可以卖掉链条的一件事。众所周知，真正优秀的开发人员比普通开发人员的工作效率高出许多倍，但他们的成本并不高很多倍。所以，如果你能吸引并留住真正优秀的开发人员，那么同样的钱可以获得更多的产出。哦，你会在这个过程中获得更多乐趣。

更好的环境=＆gt;更好的开发者=＆gt;更成功的项目

提醒一句;如果你碰巧拥有一支没有明显明亮火花的普通开发人员团队，我会担心实施敏捷。至少，不要指望它能解决你的问题 - 你可能会得到同样的结果（在被褥期之后），虽然有了燃尽的好处。但敏捷依赖于拥有真正优秀的开发人员，他们真正了解自己在做什么以及谁在不断更新自己的技能 - 或者至少是一个包含这样的人的团队。敏捷是由一群传奇程序员和非常聪明的人发明的。

Answer 10

我认为真正的瀑布日已经过去了。螺旋接管了瀑布，许多团队甚至在不知情的情况下以螺旋形式运作。在我以前的一个标签中，我提到过敏捷是从螺旋式演变而来的。

Answer 11

与瀑布方法相比，敏捷方法有明显的优势。对我来说，敏捷和瀑布方法是两种不同的软件开发方法。 在敏捷方法中，整个模块被划分为小的子模块，开发工作以快速和模块化的方式完成，而不是像瀑布模型那样整个大模块。 在敏捷方法中，设计和要求的变化可以很容易地适应瀑布的情况。 与瀑布模型不同，Agile的上市时间也非常快。 敏捷方法缩短了测试周期。

Answer 12

团队拥抱变革而没有与瀑布中的变更控制过程相关的所有创伤。

Answer 13

Scrum超越瀑布的最大例子？几乎每天都能看到项目状态/进度，或缺乏。大多数瀑布项目都被高兴地说是在轨道上，直到非常接近检查站/阶段门......然后他们被发现迟到了一些未知的数量。使用Scrum，您始终可以知道自己的位置，并且可以及早了解问题，以便您可以实际执行某些操作。最重要的是，Scrum项目状态跟踪比瀑布项目状态跟踪容易得多，并且本质上更准确，因为度量单位是剩余功能而不是工作小时数。

Answer 14

我喜欢Agile的一个原因是它允许你更快，更快，更便宜（意思是，如果项目要爆炸，你会更快地发现它）

Answer 15

其他人说Scrum给了我们“快乐开发者”和“动力开发者”。对我来说这是最引人注目的观察。我不同意Scrum只是放大了（精英/坏）程序员的表现：根据我的经验，它不断提高开发人员的表现。

为什么，好吧：

• 感受到团队的一部分是充满活力的。他们得到了你的回报。你有他们的。
• 你可以感觉到你的作品有一种意义。 PO将确保。
• 你致力于达到目标，你感到掌控
• 你不会被困住很长时间，你不会感到孤独
• 你看到了你的劳动成果，你可以立刻感到骄傲

请注意，这些不是“技术性”，而是“非常情绪化”。我觉得这很“开心”。在所有这些之后，增加你的幸福的唯一途径是更多是尝试成为一个更好的程序员...我看到一次又一次地发生。

总结：

Scrum让开发人员达到更高，表现更好，内在享受。

Answer 16

'后期绑定'。 在敏捷方法中，推迟决策。当您实际拥有相关知识时，您可以在项目周期的后期进行调用，而不是之前的相关知识。这可以提高您的决策质量。

Answer 17

您将看到的最大好处之一是您有迭代周期。客户会改变他们的想法，预算等。这有助于灵活，而不是得到反应，“这不是我要求的，所以我不付钱”

Answer 18

能够在不影响计划，成本或性能的情况下改变方向或处理课程更正。

Answer 19

它促进了紧急设计/紧急架构。

Answer 20

SCRUM（以及遵循敏捷宣言的所有敏捷方法）都承认软件开发人员是人。瀑布从业者更可能相信软件是由可互换的人月机器人开发的。

Answer 21

瀑布是使用通用工程方法解决软件开发的第一次尝试。换句话说，它对所有人来说都是可怕的。

SCRUM的主要优势？它实际上计划用于软件开发。

主要是代码“增长”的新信息，只有在有人说你拥有的信息足够（从来没有）之后才能“组装”。

Answer 22

我经常看到这种困惑，所以让我们具体一点：

1. Scrum是项目管理方法，
2. 'waterfall'是软件开发方法

这两者并不相同。

出现混乱是因为Scrum经常被用作敏捷开发过程的项目管理部分，但Scrum和Agile不是一回事

所以在技术上准确，你的问题做出了错误的假设！也许你想改写它？

Answer 23

用户（产品负责人）参与决定接下来需要什么。

因此您可以立即从用户那里购买 当故事与他们的预期不符时立即反馈。

Answer 24

没有死亡游行。

定义每个sprint可以提供的内容 如果你没有通过推动后续冲刺中的功能（对不起的故事）立即反映它。