Scrum和敏捷开发有什么区别？
Scrum和敏捷开发有什么区别？ Sprint和迭代是一样的吗？
Scrum只是众多迭代和增量式敏捷软件开发方法之一。 你可以在这里find一个非常详细的过程描述。
在SCRUM方法中，冲刺是发展的基本单位。 每个sprint都是从一个计划会议开始的，在这个会议上确定sprint的任务，并为sprint目标做出估计的承诺。 一个Sprint结束了一个审查或回顾会议的进展是审查和下一个冲刺的教训确定。 在每个冲刺阶段，团队都会创build一个产品的完成部分。
在敏捷方法中，每个迭代都涉及到一个团队在完整的软件开发周期中进行工作，包括计划，需求分析，devise，编码，unit testing和验收testing。
因此，如果在SCRUM sprint中执行所有软件开发阶段（从需求分析到验收testing），并且在我看来，您应该可以说SCRUM sprint对应于AGILE迭代。
如上所述，
Scrum是一种用于pipe理软件项目和产品或应用程序开发的迭代和增量式敏捷软件开发方法。 所以Scrum实际上是一种在软件开发中广泛使用的敏捷方法。
所以，Scrum是敏捷的特定风格，特别是它被称为敏捷项目pipe理框架。
另外Scrum里面主要有两个angular色，它们是：1.主要/核心angular色2.辅助angular色
主要/核心作用：主要由三个angular色组成：a）。 Scrum Master，b）。 产品负责人，c）。 开发团队。
辅助angular色：Scrum团队中的辅助angular色是那些没有正式angular色，不经常参与Scrum游行的angular色，但是必须考虑到这些angular色。 即 利益相关者，经理。
Scrum Master：Scrum中有6种types的会议：
- 每日Scrum /站立
- 积压美容：故事情节
- Scrum的Scrums
- Sprint计划会议
- Sprint审查会议
- Sprint回顾展
让我知道是否有人需要更多的投入。
Scrum如何适应敏捷开发？
尽pipe敏捷方法不仅适用于软件行业，也适用于其他行业的产品开发，但是Scrum是软件开发专用的。
Scrum不是一种方法。 它只是提供了敏捷开发的结构，规范和框架。 整个项目由一系列Sprint或Sprint Cycles（1到n）组成，每个Sprint的持续时间相同。 如果“时间”用T表示，则T1 = T2 = T3 = … Tn。 Sprint可以在2到4周之间的任何地方。 短于2周的短文并不理想，使用频率也较低。 在每个Sprint结束时，都会生成一个用户可以实际testing的function/工作软件。
原创文章在这里…
SCRUM：
SCRUM是一种敏捷方法。 这是一个框架而不是一个方法论。
它没有提供详细的说明，需要做什么，而大部分依赖于正在开发软件的团队。 因为开发这个项目知道如何解决这个问题，所以为什么还要留下这个问题
在发生混乱的情况下，跨职能团队和自组织团队是必不可less的。 在这种情况下，没有团队领导将把任务分配给团队成员，而是整个团队解决问题或问题。 它是跨职能的，每个人都从这个想法到实施项目都参与到项目中。
Scrum的优势在于项目的方向是根据完成的工作进行调整，而不是根据猜测或预测。
涉及的angular色：产品负责人，Scrum Master，团队成员
敏捷方法：
构build本质上不可预测的软件应用程序
在这种方法中使用迭代和渐进的工作节奏称为冲刺。
敏捷和SCRUM都遵循这个系统，其中一些function是作为冲刺的一部分，并在每个冲刺的结尾; 这些function是从编码，testing和集成到产品中完成的。 在每次冲刺结束时向所有者提供function演示，以便可以对下一次冲刺进行反馈。
敏捷开发宣言：
- 个人和stream程和工具上的交互
- 通过全面的文档工作软件
- 客户协作合同谈判
- 根据计划做出回应
也就是说，虽然右边的项目是有价值的，但我们更看重左边的项目。
敏捷和Scrum是项目pipe理中使用的术语。 敏捷方法采用增量式和迭代式工作节拍，也称为冲刺。 另一方面，Scrum则是软件开发中使用的敏捷方法。
敏捷是实践，而Scrum是跟随极限编程（XP）的实践过程，看板是遵循敏捷开发实践的替代过程。
瀑布方法是一个连续的devise过程。 这意味着，随着八个阶段（概念，启动，分析，devise，施工，testing，实施和维护）的每一个阶段都完成，开发人员将继续下一步。
由于这个过程是顺序的，所以一旦完成了一步，开发人员就不能回到前一个步骤 – 不是一味地拖延整个项目，而是从头开始。 没有改变或错误的余地，所以项目成果和广泛的计划必须在一开始就设定，然后小心谨慎
ACP Agileauthentication是针对瀑布方法的缺点而提出的“解决scheme”。 敏捷方法不是一个连续的devise过程，而是一种渐进的方法。 开发人员从简单的项目devise开始，然后开始使用小模块。 这些模块的工作是每周或每月冲刺完成的，在每个冲刺结束时，评估项目优先级并运行testing。 这些冲刺允许发现错误，并在下一次冲刺运行之前将客户反馈纳入devise。
由于缺乏最初的devise和步骤，这个过程常常因为其注重原则而不是过程的协作性质而受到批评。
首先我要说的是，敏捷是一个从统一过程（Iterative＆Incremental Development，IID）开始的渐进式方法论。 IID更强调在施工阶段（实际编码）和递增交付的迭代开发。 它不会更多地强调在迭代本身中处理需求分析（初始）和devise（精化）。 所以，这里的迭代不是一个“迷你项目本身”。
在敏捷方面，我们把这个IDD做得更进一步，增加了更多的现实，比如团队合作，进化需求和devise等。而SCRUM则是考虑到人为因素和围绕“智慧集团”原则build立的工具。 所以，这里的Sprint是一个“迷你项目本身”，改善了一个纯粹的IID模型。
所以，以敏捷方式实现的迭代是，理论上是Sprint（突出显示迭代的规模很小，交付很快）。 我没有真正区分敏捷和SCRUM，我发现SCRUM是将敏捷原理投入使用的一种自然方式。
