所有敏捷开发过程（如scrum）都基于持续改进。我们希望团队采用一种经验的方法 (empirical approach) 来了解随着项目的进展，哪些是可行的，哪些是不可行的，并在必要时进行调整，而不是采用一个永不改变的严格定义的过程 (defined process)。如果将项目分解为很短的增量 (increments)，并且在每个增量结束时进行学习，...

“欢迎不断变化的需求，即使是在开发后期。敏捷流程利用变化来获得客户的竞争优势。” “Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.”

“我们的首要任务是通过及早持续交付有价值的软件来满足客户的需求。”“Our highest priority is to satisfy the customer through early and> continuous delivery of valuable software.”

这四个价值陈述构成了敏捷宣言的基础。敏捷宣言中的原则扩展了价值, 并提供了更多细节。同样, 与值语句一样, 这些语句也应被视为相对偏好, 而不是绝对偏好。这些原则概述如下, 并在以下各节中进行更详细的讨论:

用户故事的目标不仅是记录需求，还要提供客户在生产中使用的工作软件。用户故事提供了一种机制，用于记录客户和开发人员之间关于软件功能的讨论。 定义 “用户故事代表卡中的客户要求，导致对话和确认。” 〜罗恩杰弗里斯 模板 以下是用于定义用户故事和验收标准的众所周知的模板。 价值陈述：作为（用户角色），我想（活...

每个Sprint的输出的正式名字为“潜在可交付产品增量”。在开始第一个Sprint之前，产品负责人、团队和Scrum Master必须审视对于把一个产品待事项列表中的事项做到潜在可交付所需要的所有事情。所有为了交付产品所需的活动都应被包含在“潜在可交付”的定义中，并且要在这个Sprint中完成。

概述： 在团队成员间更新信息和进行协调。 参与者： 团队必须参加；产品负责人不是必须的；ScrumMaster通常会在场，但要保证团队自己主持会议。 时长： 最长15分钟。 一旦Sprint开始，团队就要投身于另一个Scrum实践，那就是每日Scrum会议。在每个工作日指定时间都会举行这个很短的（15分钟，或者更短）会议。团队中的每...

团队；如果产品负责人是能够帮助梳理细节的专家，那么他会全程参与整个活动，否则他可以只参与其中一部分来设定方向或者重排优先级；其他理解需求并能给予团队帮助的人；ScrumMaster将在会议的开始部分来指导团队如何有效地开这个会，否则的话他不必参加。

概述： 对于功能性的产品增量进行审视并调整。 参与者： 团队、产品负责人、ScrumMaster。产品负责人可以邀请其他恰当的利益相关人参加。 时长： 时间箱为Sprint中的每一周对应一个小时。 在Sprint结束后，就到了Sprint评审会议 (Sprint Review Meeting)，人们会评审这个Sprint。出席会议的人有产品负责人、团队成员以及...

概述： 针对流程和环境进行审视并调整。 参与者： 团队、ScrumMaster、产品负责人（非必须）。团队可能会邀请其他利益相关人，否则这些人不准参加。 时长： 时间箱为对应Sprint中的每一周为45分钟。 Sprint评审会议包含了对于产品的审视并调整。而在评审会议之后的“Sprint回顾会议”则包含了针对流程和环境的审视并调整。...

Scrum不仅仅是一套具体的实践，确切地说更为重要的是这个框架提供了透明度并给出了“审视并调整”的机制。Scrum通过让影响产品负责人 (Product Owner) 和团队 (Development Team) 效率的机能失调和障碍变得显而易见，使它们得到及时处理。比如，产品负责人可能不清楚市场情况、特性或如何估算它们的相对商业价值。亦或者团...

Scrum Projects的主要利益相关者是产品负责人产品负责人的一个不可或缺的责任是向Scrum团队传达Scrum项目的重要性和重要性。这是通过使用Product Backlog成功实现任何敏捷项目的关键。

Scrum团队有时被称为开发团队，因为他们负责开发产品，服务或其他结果。它由Sprint Backlog中的用户故事组成的一组人员为项目创建可交付成果。

Scrum方法需要改变传统方法的思维方式。中心焦点已经从瀑布方法的范围转变为在Scrum中实现最大的商业价值。在瀑布中，改变成本和进度以确保达到预期的范围，在Scrum中，可以改变质量和约束以实现获得最大商业价值的主要目标。

任务计划和评估对于按照优先产品Backlog中指定的要求迭代开发产品至关重要。Scrum团队在任务评估会议中估算完成任务列表中每项任务所需的工作量。此过程的结果是Effort Estimated Task List。Scrum团队使用Task列表，这是一个包含团队为当前Sprint提交的所有任务的综合列表，用于开发Effort Estimated Task List。任务列...

对于大多数转向敏捷方法的公司而言，产品所有者 (Product Owner) 是新的东西。但是，每个月您都会看到产品所有者需求的显着增长。为什么？我们将在本文中讨论它，更多地关注产品所有者在软件开发项目中的角色。

本教程适用于敏捷软件开发新手的Scrum团队成员，以了解他们的角色和职责。本教程还将帮助那些已经在敏捷模型中工作的人提高他们的技能，并帮助那些只想了解这些角色的人。它还将提供对责任及其所隐藏的每个角色的洞察力。

敏捷是世界上使用最广泛，最受认可的软件开发框架之一。大多数组织已经以某种形式采用了它，但是在采用计划的成熟度方面还有很长的路要走。本系列教程的唯一目的是将技术和非技术专业人员融入敏捷世界。

站立会议为团队成员提供了一种简单的方法，可以在不花费大量时间参加会议或不必编写和阅读大量状态报告的情况下使彼此保持最新状态。它侧重于快速讨论进度，计划和问题。会议的主要目的是让小组成员快速了解：

最初，用户故事是在索引卡或便签上写的。它们被安排在墙上以便于规划和讨论。您现在可以在任何主要的敏捷工具中突出显示它们。实体卡片或笔记将焦点从通过讨论的写作转移到关于能力和共享理解。事实上，这些讨论比故事中所写的更重要。

敏捷鼓励包括设计，开发和测试在内的一切都在同一时间完成。相反，传统的项目方法在下一个开始之前关闭并完成一个阶段。敏捷鼓励短暂，频繁的反馈循环并包含对需求的更改。在瀑布中，通常直到项目结束才收集反馈，并且不鼓励进行更改。

自我評估作為Scrum大師, 你在扮演什麼角色（上面? 還是下？） 哈哈！有些人仍然無法改變舊的思維方式 一个伟大的Scrum Master 确保整个团队支持所选的Scrum流程; 管理超出团队自组织能力的障碍，阻止他们实现Sprint目标; 认识到健康的团队冲突并促进建设性的分歧; 准备好具有颠覆性，以便在组织内部实施变革; 理解自组织...

Scrum是一种管理项目的敏捷方式，通常是软件开发。使用Scrum进行敏捷软件开发通常被视为一种方法论; 但不是将Scrum视为方法论，而是将其视为管理流程的框架。

今天（2017年11月7日），Ken Schwaber 和 Jeff Sutherland 发布了 Scrum 指南的更新。Scrum指南是Scrum的最终定义，由Scrum的创建者Ken和Jeff编写。《Scrum指南》描述了Scrum框架。而且，它只有19页长。通过保持简短的定义，它不仅强制实现一个明确的重点，而且提醒每个人它不是一种方法论。过程是根据团队所处的情况使...

最新版Scrum指南已由来自Scrum, Inc的Scrum共同发明人Ken Schwaber和来自Scrum.org的Jeff Sutherland联手发布。上一版发布于2013年，此版最大的变化是包含了Scrum价值观 (Scrum Values)。

Scrum是产品开发和团队组织的迭代和增量过程。借助Scrum框架，可以更快，更高质量地完成任务。这是可能的，因为团队的高自我激励，自己选择如何执行任务。客户需求将被迭代优先级并快速实现

敏捷专注于保持流程的精益，并创建最小的可行产品（MVP），在最终结果出现之前经历多次迭代。不断收集和实施反馈，总而言之，这是一个更加动态的过程，每个人都在朝着一个目标努力。

SCRUM使用经验方法（或有时称为经验主义）以适应客户不断变化的需求。经验主义是根据实际经历的内容做出决策的行为。经验方法意味着以事实为基础，以经验为基础，以证据为基础的方式开展工作，特别是，进展是基于对现实的观察，而不是基于大量前期要求的虚构计划。

Scrum是一个项目管理框架，强调团队合作，问责制和迭代进展，以实现明确的目标。该框架从一个简单的前提开始：从可以看到或已知的东西开始。之后，跟踪进度并根据需要进行调整。

将Lean和Agile看作几乎相同的事情，它们基本上是处理具有很多不确定性的项目的好方法，这就是为什么成功的初创公司采用这种方法。 （有关精益，敏捷和Scrum起源的事实历史，请参阅 此处 。）