如果你必须选择 Scrum 相对于瀑布式流程的一项优势，你会选择什么？
Mendokusai
问问题
4962 次
24 回答
19
您构建了客户想要的东西，而不是客户在收集需求时认为他们想要的东西。
编辑：这是敏捷方法的一般属性，强调早期和经常交付 - 与瀑布完全相反（延迟和一次交付）。
于 2009-01-08T01:23:35.810 回答
5
它为您提供了一个流程，可以尽早且经常地交付可用的业务功能，从而增加客户对您的结果感到满意的可能性。它的成本也相对较低，并降低了失败的风险。
于 2009-01-08T01:24:51.313 回答
5
瀑布假设你事先知道一切，这是不可能的。
一个好的 Scrum 流程以瀑布式的方式开始，列出您想要构建的所有内容。不过，scrum 的优势在于，您在每次迭代后重新排列该列表，您总是在构建客户想要的东西。
当我们为我们的一种产品构建测试版时，我们允许测试版客户帮助推动下一个周期的堆栈排名。最终结果是客户想要的产品，而不是我们向他们口授的产品。
于 2009-01-08T02:33:22.470 回答
3
您可以快速交付可用的软件，以便在项目偏离轨道之前确定您是否走在正确的轨道上。
当然，这适用于任何敏捷过程，而不是瀑布式，而不仅仅是 Scrum。
于 2009-01-08T01:25:55.773 回答
1
我认为真正的瀑布时代已经一去不复返了。Spiral 接管了瀑布，许多团队甚至在不知情的情况下都在螺旋式运行。在我之前的一个标签中，我提到敏捷是从螺旋演变而来的。
于 2009-01-08T15:07:23.540 回答
1
可能有一些软件开发实现在瀑布框架中使用了大部分 Scrum，因此您的部分问题可能是基于错误信息。
我在 Scrum 中看到的主要优势是它提供的日常沟通和问责制，因此团队中的每个人都可以知道其他人在做什么，并分享他或她的位置。假设您正在与可以相处并且乐于制定自己的规则的人一起工作，那么这提供了查看正在发生的事情以及告诉您正在做什么的责任感，这可以使 Scrum 成为开发软件的一个非常好的部分在一定程度上。
于 2009-01-08T01:24:25.697 回答
1
快乐的开发者
于 2009-01-08T01:25:51.157 回答
1
我喜欢 SCRUM 的第一个原因是燃尽概念。没人关心你花了多少时间，他们只需要知道你还剩下多少时间。
于 2009-01-08T01:29:24.423 回答
1
我发现这是一个很好的动力，整个团队都参与了规划过程，而不仅仅是几个人（以前就是这样）。通常，根据我的经验，这也相当于更精确的估计，这对于保持项目正确发展至关重要。
此外，很好地了解团队目前实际发生的事情，在某种程度上了解每个人正在做什么，而不是让项目负责人单独分配任务。
于 2009-01-08T01:30:43.517 回答
1
首先，如果我们同意正确的问题更像是“敏捷”与“瀑布”......
作为一名前开发经理，我对此的主要看法实际上有些不同。我喜欢敏捷方法的“工程实践”优势，例如燃尽、JIT 设计等。然而，研究表明，流程选择和成功率之间的相关性低于许多人的预期（一个示例）。当然，敏捷相当一致地被证明要好一些，但尚不清楚这些研究是否会针对敏捷项目中倾向于拥有更好的开发人员这一事实进行调整——要么是因为更好的开发人员倾向于推动敏捷，要么是因为敏捷倾向于吸引更好的开发人员。
如果你看一下 Cockburn 的一些东西，很明显软件项目的主要成功驱动因素是项目人员的质量——而不是过程。
有关这方面的一些非常好的基本解释，请参阅Cockburn 的书（这不是一本指南书，而是解释了基本概念以及为什么应该使用敏捷的东西）。
在我看来，敏捷方法有助于创造一个优秀程序员想要工作的环境。因为他们是流程的一部分，因为他们被允许使用他们的大脑，等等。因此，
作为一家企业，您更有可能吸引和留住顶尖人才，这意味着您更有可能拥有一个成功的项目。
在业务层面上，这确实是合理的——其他一切都非常好，但这是对底线很重要的一件事，也是你可以向上销售的一件事。众所周知，真正优秀的开发人员的生产力是普通开发人员的许多倍，但他们的成本不会高出很多倍。所以，如果你能吸引并留住真正优秀的开发人员，你就能以同样的钱获得更多的产出。哦，在这个过程中你会有更多的乐趣。
更好的环境 => 更好的开发人员 => 更成功的项目
一句话警告；如果你碰巧有一个没有明显亮点的普通开发人员团队，我会担心实施敏捷。至少，不要指望它能解决你的问题——你可能会得到同样的结果（在磨合期之后），尽管有燃尽的好处。但是敏捷依赖于真正优秀的开发人员，他们真正知道自己在做什么，并且不断更新自己的技能——或者至少是一个包含这样一些人的团队。敏捷是由一群传奇的程序员和非常非常聪明的人发明的。
于 2009-03-18T07:24:49.263 回答
0
其他人说 Scrum 给了我们“快乐的开发者”和“有动力的开发者”。对我来说，这是最引人注目的观察。我不同意 Scrum 只会放大（精英/糟糕）程序员的表现的观点：根据我的经验，它不断提高开发人员的表现。
为什么，好吧：
- 感觉自己是团队的一员是令人振奋的。他们支持你。你有他们的。
- 你能感觉到你的工作有一种意义。采购订单会确保。
- 你致力于实现触手可及的目标，你感觉自己在掌控之中
- 你不会被困很长时间，你不会感到孤独
- 看到自己的劳动成果，立马感到自豪
请注意，这些不是“技术性的”，而是非常“情绪化的”。我认为这是“快乐”。毕竟，增加幸福感的唯一途径就是努力成为一个更好的程序员……我看到这种情况一次又一次地发生。
总结一下：
Scrum 使开发人员获得更高的成就，表现更好，并具有内在的乐趣。
于 2009-09-08T15:25:13.647 回答
0
与瀑布方法相比，敏捷方法具有明显的优势。对我来说，敏捷和瀑布方法是软件开发的两种不同方法。在敏捷方法中，将整个模块划分为小子模块，并以快速和模块化的方式进行开发，而不是像瀑布模型那样的整个大模块。在敏捷方法中，设计和需求的更改可以很容易地适应，而在瀑布的情况下很难。与瀑布模型不同，敏捷的上市时间也非常快。敏捷方法减少了测试周期。
于 2011-08-02T06:14:28.207 回答
0
您将看到的最大好处之一是您拥有迭代周期。客户会改变他们的想法、预算等。保持灵活性是有帮助的，而不是得到回应，“这不是我要求的，所以我不付钱”
于 2009-01-08T03:27:49.100 回答
0
我喜欢敏捷的一个原因是它可以让你更快、更快、更便宜地失败（这意味着，如果项目要失败，你会更快地发现它）。
于 2009-09-13T20:30:15.680 回答
0
'后期绑定'。在敏捷方法中，推迟决策。当您真正掌握相关知识时，您会在项目周期的后期进行调用，而不是在您没有相关知识时进行调用。这可以提高您决策的质量。
于 2009-01-13T21:55:34.533 回答
0
我经常看到这种混乱，所以让我们具体一点：
- Scrum是一种项目管理方法，
- “瀑布”是一种软件开发方法
两者不等价。
之所以会产生混淆，是因为 Scrum 经常作为敏捷开发过程的项目管理部分来实践，但 Scrum 和敏捷不是一回事
所以从技术上讲，你的问题是一个错误的假设！也许你想改写它？
于 2009-01-08T02:01:20.693 回答
0
Waterfall 是第一次尝试使用通用工程方法解决软件开发问题。换句话说，这对每个人来说都是可怕的。
SCRUM 的主要优势？它实际上计划用于软件开发。
主要是带有新信息的代码“增长”，只有在有人说您拥有的信息足够（永远不会）之后才“组装”。
于 2009-01-08T02:19:17.147 回答
0
没有死亡行军。
定义每个 sprint 可以交付的内容。
如果你没有做到这一点，就会通过将功能（抱歉的故事）从后续的 sprint 中推出来立即反映出来。
于 2009-01-08T01:30:30.367 回答
0
用户（产品负责人）参与决定下一步需要什么。
因此，您可以立即从用户那里购买。
当故事与他们的预期不符时立即反馈。
于 2009-01-08T01:31:51.517 回答
0
SCRUM（以及所有遵循敏捷宣言的敏捷方法）承认软件开发人员是人。瀑布从业者更有可能相信软件是由可互换的人月机器人开发的。
于 2009-01-08T02:35:46.443 回答
0
它有助于紧急设计/紧急架构。
于 2009-01-08T02:36:15.257 回答
0
在不显着影响进度、成本或性能的情况下改变方向或处理路线修正的能力。
于 2009-01-08T03:11:56.667 回答
0
Scrum over 瀑布的最大例子？几乎每天都能看到项目状态/进度，或缺乏项目状态/进度。大多数瀑布项目都被高兴地声明为按计划进行，直到非常接近检查点/阶段门......然后他们被发现迟到了一些未知的数量。使用 Scrum，您始终知道自己的立场，并且您可以及早了解问题，以便您可以实际采取一些措施。最重要的是，Scrum 项目状态跟踪比瀑布项目状态跟踪更容易，并且本质上更准确，因为度量单位是剩余功能而不是工作时间。
于 2009-11-25T10:06:24.307 回答
0
团队在没有与瀑布中的变更控制流程相关的所有创伤的情况下接受变更。
于 2010-03-08T05:20:43.760 回答