敏捷软件开发
敏捷是世界上使用最广泛，最受认可的软件开发框架之一。大多数组织已经以某种形式采用了它，但是在采用计划的成熟度方面还有很长的路要走。本系列教程的唯一目的是将技术和非技术专业人员融入敏捷世界。
我们将逐步引导您完成敏捷之旅，直到您了解使用敏捷背后的理念，优势以及如何实践它。本系列旨在使读者能够将敏捷和 Scrum 学习应用到他们的工作中。这个特别的教程专门向您解释为什么需要敏捷以及如何创建它。这里的基础是让您了解软件开发行业中敏捷采用的概念。
敏捷的历史
敏捷出生在一个晴朗的日子，当时有 17 个人具有不同的开发方法背景，在一起探索可能的替代软件开发解决方案，可以共同进行头脑风暴，寻求可能会缩短开发时间并减少文档的需求量。
当时，软件开发过去发生的时间太长，以至于当项目准备交付时，业务已经向前发展，需求已经发生变化。因此，即使项目能够实现其既定目标，也无法满足业务需求。
因此，这些不同软件工程技术的精英聚集在一起，他们会议的最终结果就是他们所谓的“敏捷宣言”，我们将在本系列的下一个教程中详细讨论。
但是那天出生的敏捷并不是我们今天在组织中看到的。专家们同意的方法被称为“轻量级”且速度快。但是，本次会议的主要成果是认为更快的产品交付和持续的反馈是实现软件开发成功的关键。
现有的瀑布技术过于繁琐，在最终产品准备交付之前没有提供反馈。这意味着没有进行要求修正的余地，并且在整个产品准备好之前，客户对进度没有任何看法。这就是这些专家想要避免的。他们想要一个能够持续反馈的解决方案，以避免后期返工的成本。
敏捷挑战
当时现有的瀑布技术过于繁琐，在最终产品准备交付之前没有提供反馈。它被称为开发的瀑布模型，因为团队首先完成了一步，然后才进入下一步。
这意味着没有进行要求修正的余地，并且在整个产品准备好之前，客户对进度没有任何看法。这就是这些专家想要避免的。他们想要一个可以持续反馈的解决方案，以避免在以后阶段返工的成本。这就是为什么敏捷也是关于自适应和持续改进的原因，同时也是关于持续反馈和交付速度的原因。
什么是敏捷承诺？
敏捷承诺
敏捷不仅仅是在开发软件时应用设定的实践。它还带来了团队思维方式的变化，这促使他们构建更好的软件，协同工作并最终让他们成为一个满意的客户。
敏捷的价值观和原则使团队能够转移他们的注意力并改变他们构建更好软件的思维过程。
敏捷到底是什么？
敏捷不是一套规则。敏捷不是一套指导方针。敏捷甚至不是一种方法论。相反，敏捷是一套原则，鼓励灵活性，适应性，沟通和工作软件超越计划和流程。它在所谓的敏捷宣言中非常简洁地被捕获。
敏捷软件开发使团队能够在开发复杂项目时更有效地协同工作。它由练习迭代和增量技术的实践组成，这些技术很容易被采用并显示出很好的结果。
在将敏捷应用于行动中，我们有各种基于敏捷的方法去满足软件开发行业的所有需求，从软件设计和架构，开发和测试到项目管理和交付。
不仅如此，敏捷方法和方法还为流程改进打开了一个范围，作为每个交付的一个组成部分。
敏捷是一种软件开发的实践理念，建构一个自给自足且跨职能的团队致力于通过迭代进行持续交付，并通过收集最终用户的反馈在整个过程中发展。
如何练习敏捷？
各种多样化行业都有各种敏捷方法论。
然而，所有这些方法中最流行的方法是：
Scrum
看板 (Kanban)
极限编程 (XP)
所有这些方法都侧重于精益 (Lean) 软件开发，并有助于有效和高效地构建更好的软件。
这就是敏捷引言的全部内容。该部分的结构旨在帮助您了解团队在敏捷模式和思维模式下工作时应采用的核心价值观和原则。
敏捷方法论和模型
敏捷方法论简介：
众所周知，敏捷是一种软件开发方法。我们还了解了敏捷创始人在敏捷宣言中提到的价值观和原则。在我们最初的讨论中，我们还避开了敏捷和传统瀑布模型之间的差异。在本教程中，我们将了解敏捷方法的优缺点。
我们会看到什么是 scrum？它与敏捷有何不同？然后我们将了解不同组织正在使用的各种敏捷方法，以及如何使用它们实现敏捷。您还将能够理解这些方法的不同之处以及优缺点。
敏捷方法论的优点
下面给出了敏捷方法的各种优点：
客户在每次迭代 (iterative) / 冲刺 (Sprint) 结束时不断获得项目进度的外观和感觉。
每个 sprint 都为客户提供了一个工作软件，该软件根据他们提供的完成定义满足他们的期望。
开发团队对不断变化的需求做出了很好的响应，即使在开发的高级阶段也能适应变化。
持续的双向沟通 (feedback) 使客户参与其中，因此所有利益相关者 (Stakeholders) – 业务和技术 – 都能清楚地了解项目的进展情况。
产品设计高效，满足业务需求。
敏捷方法论的缺点
虽然敏捷方法有几个优点，但它也有一些缺点。
他们是：
#1）不希望使用全面的文档，这会导致敏捷团队错误地解释这一点，因为敏捷不需要文档。因此严谨性会因文档而丢失。应该通过不断询问自己这是否是足够的信息来避免这种情况。
#2）有时，在项目开始时，要求并不十分清晰。团队可能会继续发现客户的愿景已经重新调整，在这种情况下，团队需要整合许多变更，而且很难衡量最终结果。
敏捷方法的类型
世界各地都有几种敏捷方法。我们将详细了解最受欢迎的四个。
#1）Scrum
Scrum 很容易被认为是最流行的敏捷框架。“scrum”一词被大多数从业者认为是“敏捷”的同义词。但这是一种误解。Scrum 只是您可以实现敏捷的框架之一。
Scrum 这个词来自体育橄榄球 (Rugby)。球员们在一个互锁的位置挤在一起推着对手。每个球员在他们的位置上都有明确的角色，并且可以根据情况的需求发挥进攻和防守的作用。
同样，IT 中的 Scrum 相信赋予自我管理的开发团队有三个具体且明确定义的角色。这些角色包括 – 产品负责人（PO），Scrum Master（SM）以及由程序员和测试人员组成的开发团队。它们在迭代时间盒装持续时间中一起工作，称为冲刺。
第一步是 PO 创建产品待办事项。这是 scrum 团队要做的事情的待办事项列表。然后 scrum 团队选择优先级最高的项目并尝试在称为 sprint 的时间框内完成它们。
记住所有这一切的更简单方法是记住 3 -3- 5 框架。这意味着 scrum 项目有 3 个角色，3 个工件，5 价值 和 5 个事件。
这些是 –
3 角色：PO，Scrum master 和开发团队。
3 工件：产品 Backlog，Sprint Backlog 和产品增量。
5 价值: 集中，勇气，开放性，承诺，尊重。
5 事件：Sprint，Sprint 计划，Daily Scrum，Sprint 评论和 Sprint 回顾。
我们将在后续教程中更详细地了解每个内容。
#2）看板 (Kanban)
看板是日语术语，意思是卡片。这些卡包含要在软件上完成的工作的详细信息。目的是可视化。每个团队成员都了解通过这些视觉辅助工作要完成的工作。
团队使用这些看板卡进行持续交付。就像 Scrum 一样，看板也可以帮助团队有效地工作，并促进自我管理和协作的团队。
但是这两者之间也存在差异 – 比如在 scrum sprint 期间，团队正在处理的项目是固定的，我们无法向 sprint 添加项目，而在看板中，如果有可用容量，我们可以添加项目。当需求经常变化时，这尤其有用。
同样，另一个区别是，虽然 scrum 已经定义了 PO，Scrum master 和开发团队的角色，但是在 Kanban 中没有这样的预定义角色。
另一个不同之处在于，尽管 scrum 建议对产品待办事项进行优先排序，但看板没有这样的要求，而且完全是可选的。因此，看板需要较少的组织并避免非增值活动，并且适用于需要对变化做出响应的过程。
#3）精益 (Lean)
精益是一种专注于减少浪费的理念。它是如何做到的？
在精简中，您将流程划分为增值活动，非增值活动和基本的非增值活动。任何可归类为非增值活动的活动都是浪费，我们应该尝试在过程中消除这种浪费，使其更加精简。
更精简的流程意味着更快的交付和更少的工作浪费在任务上，这无助于实现团队目标。这有助于优化软件开发周期中的每个步骤。这就是精益原则从精益制造转变为软件开发的原因。
通过应用以下所示的七项精益原则，可以在任何 IT 项目中使用精益软件开发：
正如他们的名字所暗示的，这些都是不言自明的。消除浪费是第一个也是最重要的精益原则，我们看到了如何做到这一点，我们只是将活动分类为价值和非增值。
非值添加活动可以是代码的任何部分，可能使其不那么健壮，增加所涉及的工作量并占用大量时间而不添加合理的业务价值。它也可能是模糊的用户故事或不良测试或添加大图中不需要的功能。
第二个原则放大学习再次易于理解，因为团队需要各种技能，以在快速变化的环境中提供产品，新技术可以在短时间内出现。
做出迟到的决定可以在减少返工的情况下获得回报，就像预期会有任何变更，然后更好地延迟，以便团队不必在业务需求变化时重做工作。
但是这里总是存在一种权衡，因为团队需要平衡这一点与提供更快速的第四个原则。推迟决策不应影响整体交付，也不得减少工作节奏。一只眼睛应该始终在完整的画面上。
赋予权力的团队现在也非常普遍，这甚至是敏捷的建议。赋权团队更负责任，可以更快地做出决策。拥有权力的团队的所有权意识可以带来更好的结果。为了赋予团队权力，应该允许他们自己组织并自己做出决定。
因此，我们看到精益和敏捷有很多共同之处，只有一个明显的区别 – 精益团队可以帮助改进产品，敏捷团队就是实际构建产品的团队。
#4）极限编程（XP）
极限编程是另一种最流行的敏捷技术。根据 extremeprogramming.org，第一个 XP 项目于 1996 年 3 月 6 日开始。他们还提到 XP 以五种不同的方式影响软件项目开发 – 沟通，简单，反馈，尊重和勇气。这些被称为 XP 的值。
其中，一切都始于沟通。XP 团队定期与业务团队和其他程序员协作，并从第一天开始构建代码。这里的重点是在其他视觉辅助工具的帮助下尽可能地进行面对面的交流。
极端程序员还会构建一个简单的代码，并从第一天开始获得反馈。重点是不要过分或预测尚未共享的要求。这使设计简单，只生产出满足要求的最小产品。
反馈有助于团队改进并提高工作质量。这有助于他们在彼此学习的过程中建立对彼此的尊重，并学习如何分享他们的观点。
这也给了他们勇气，因为他们知道他们已经收集了每个人的最佳想法，并根据其他人的反馈产生了一个好的产品。因此，他们也不害怕包含变更或收到有关其工作的进一步反馈。
这在需求经常变化的项目中特别有用。持续的反馈将帮助团队以勇气包含这些变化。
因此，我们已经看到了不同的敏捷方法，如 Scrum，XP，看板和精益，以及它们各自的优缺点。
现在，我们可以轻松区分它们，也欣赏它们之间的微妙差异。我们还了解了每种方法的基本原理，并了解了如何在需要时将它们应用于我们的项目中。
在下一部分中，让我们了解 Scrum 的一切。
Scrum 框架 (Scrum Framework)
SCRUM 是敏捷方法中的一个过程，它是迭代模型和增量模型的组合。
传统瀑布模型的主要障碍之一 是 – 在第一阶段完成之前，应用程序不会移动到另一阶段。而且，如果在周期的后期阶段发生一些变化，那么实施这些变化就变得非常具有挑战性，因为这将涉及重新审视早期阶段并重做变更。
SCRUM 的一些关键特性包括：
自我组织和专注的团队。
没有巨大的要求文件，而是有一个非常精确和重点的故事。
跨职能团队作为一个单元一起工作。
与用户代表密切沟通以了解功能。
有一个最长一个月的明确时间表。
Scrum 不是一次完成整个“事物”，而是以给定的间隔做一些事情。
在提交任何内容之前，会考虑资源功能和可用性。
要很好地理解这种方法，理解 SCRUM 中的关键术语非常重要。
重要的 SCRUM 术语
1）Scrum 团队
Scrum 团队由 7 人组成，其中包括 + 或 – 两名成员。这些成员是能力的混合体，由开发人员，测试人员，数据库人员，支持人员等组成，还包括产品所有者和 Scrum 主管。
所有这些成员通过紧密协作一起工作，以递归和确定的间隔，开发和实现所述特征。SCRUM 团队的坐姿安排在他们的互动中起着非常重要的作用，他们从不坐在小隔间或小木屋里，而是一张巨大的桌子。
2）冲刺 (Sprint)
Sprint 是预定义的时间间隔或时间范围，其中必须完成工作并使其准备好进行审查或准备进行生产部署。这个时间框通常在 2 周到 1 个月之间。
在我们的日常生活中，当我们说我们遵循 1 个月的 Sprint 周期时，它只是意味着我们在任务上工作了一个月，并准备好在该月底之前进行审核。
3）产品负责人 (Product Owner)
产品所有者是要开发的应用程序的主要利益相关者或主要用户。产品所有者是代表客户方的人。他 / 她拥有最终权力，应始终为团队提供。
当任何人有任何需要澄清的疑问时，他 / 她应该可以到达。对于产品所有者而言，了解并且不在 sprint 中间或 sprint 已经开始时分配任何新要求非常重要。
4）Scrum Master
Scrum Master 是 Scrum 团队的推动者。他 / 她确保 Scrum 团队富有成效和进步。如有任何障碍，scrum master 会跟进并为团队解决问题。SCRUM Master 是 PO 和团队之间的中介。
他 / 她让 PO 了解 Sprint 的进展情况。如果团队存在任何障碍或问题，请与 PO 讨论并解决问题。就像团队的每日站立时一样，每天都会有一个关于 PO 的 SCRUM Master 的站立。
5）业务分析师（BA）
业务分析师在 SCRUM 中扮演着非常重要的角色。此人负责完成要求并在需求文档（基于其创建用户素材）中起草。
如果用户故事 / 接受标准中存在任何含糊之处，他 / 她是技术（SCRUM）团队接洽的人，然后他将其接收到 PO 或者如果可能的话自行解决。在大型项目中，可能有超过 1 个 BA，但在小规模项目中，SCRUM Master 也可能作为 BA。
项目启动时获得学士学位总是一个好习惯。
6）用户故事 (User Story)
用户故事只不过是必须实现的要求或功能。
在 scrum 中，我们没有那些巨大的需求文档，而是需求在一个段落中定义，通常具有以下格式：
作为 < 用户 / 用户类型 > 我想 < 一些可实现的目标 / 目标 > 实现 < 做某事的某些结果或理由 >
例如：
作为 [管理员]，我想 [要密码锁]，实现 [以防用户连续 3 次输入错误的密码以限制未经授权的访问]。
应该遵守用户故事的一些特征。用户故事应该简短，逼真，可以估计，完整，可协商和可测试。用户故事永远不会在 Sprint 中间被更改或更改。
SCRUM Master 和 BA（如果适用）负责确保 PO 使用适当的“验收标准”正确起草用户故事“。如果要进行任何会影响 sprint 发布的更改，那么这些故事将从 sprint 中撤出，或者按照可用时间完成。
每个用户故事都有一个验收标准 (Acceptance Criteria)，应由团队明确定义和理解。
验收标准详细说明了提供支持文档的用户故事。它有助于进一步完善用户故事。团队中的任何人都可以写下验收标准。测试团队根据这些验收标准确定测试用例 / 条件。
7）史诗 (Epic)
史诗是模棱两可的用户故事，或者我们可以说这些是未定义的用户故事，并保留用于未来的冲刺。
试着把它与生活联系起来，假设你要去度假。当你下周去的时候，你已经准备好了所有的东西，比如你的酒店预订，观光，旅行支票等等。但是你明年的假期计划呢？你只有一个模糊的想法，你可能会去 XYZ 的地方，但你没有详细的计划。
史诗就像你明年的假期计划一样，在那里你只知道你可能想去，但是在这个时间点你不知道所有这些细节的地点，时间，对象。
以类似的方式，存在将来需要实现的特征，其细节尚不清楚。大部分功能都以 Epic 开头，然后分解为可以实现的故事。
8）产品积压 (Product Backlog)
产品待办事项是一种存储所有用户故事的存储桶或源。这由产品负责人维护。产品待办事项可以设想为产品所有者的愿望清单，产品所有者根据业务需求对其进行优先级排序。
在计划会议期间（参见下一节），从产品待办事项中获取一个用户故事，然后团队进行头脑风暴，理解并完善它，并在产品所有者的干预下共同决定要采取哪些用户故事。
9）Sprint Backlog
根据优先级，用户故事一次一个地从 Product Backlog 中获取。Scrum 团队的头脑风暴决定了它的可行性，并决定了在特定冲刺上工作的故事。Scrum 团队在特定 sprint 上工作的所有用户故事的集合列表称为 Sprint backlog。
10）故事点 (Story Point)
故事点是用户故事复杂性的定量指示。基于故事点，确定故事的估计和努力。
故事点是相对的而不是绝对的。为了确保我们的估计和努力是正确的，检查用户故事并不重要是很重要的。用户故事越精确，越小，估计就越准确。
每个用户故事都根据 Fibonacci 系列（1,2,3,5,8,13 和 21）分配到故事点。数字越高，复杂就是故事。
确切地说
如果你给出 1 /2/ 3 的故事点，那就意味着故事很小而且复杂度很低。
如果你给分数为 5 /8，它是一个中等复杂的
13 和 21 非常复杂。
这里的复杂性包括开发和测试工作。
为了确定一个故事点，头脑风暴发生在 Scrum 团队中，团队共同决定一个故事点。
开发团队可能会为特定故事提供 3 个故事点，因为对于他们来说可能有 3 行代码更改，但测试团队给出了 8 个故事点，因为他们觉得这个代码更改会影响更大的模块所以测试工作量会更大。无论你给出什么样的故事，你都必须证明这一点。
因此，在这种情况下，头脑风暴发生，团队集体同意一个故事点。
无论何时决定故事点，请记住以下因素：
故事与其他应用程序 / 模块的依赖关系。
资源的技能组合。
故事的复杂性。
历史学习。
用户故事的接受标准。
如果您不了解特定故事，请不要调整大小。
每当故事大于或等于 8 分时，它就被分解为 2 个或更多故事。
11）烧掉图表
刻录图表是一个图表，显示了 scrum 任务的估计 v / s 实际工作量。
它是一种跟踪机制，通过该机制，对于特定的冲刺，跟踪日常任务以检查故事是否正在朝着完成提交的故事点的方向前进。
示例：要了解这一点，请查看下图：
我假设：
2 周冲刺（10 天）
2 个实际在冲刺上工作的资源。
“故事”– > 此列显示为 sprint 拍摄的用户故事。
“任务”– > 此列显示与用户素材关联的任务列表。
“努力”– > 此栏显示了努力。现在，这项措施是完成任务的总工作量。它没有描述任何特定个人的努力。
“第 1 天 – 第 10 天”– > 此列显示完成故事的剩余时间。请注意，小时不是已经完成的小时，但仍然是剩下的小时数。
“估计的努力”– > 是努力的总和。对于“开始”，它只是整个单独任务的总和：SUM（C5：C15）
必须在 1 天内完成的总工作量是 70/10 = 7. 因此在第 1 天结束时，努力应该减少到 70 – 7 = 63. 以类似的方式，计算所有的直至第 10 天，估计的努力量应为 0（第 16 行）
“实际努力”– > 顾名思义，实际上是完成故事的努力。也可能发生实际努力增加或减少的估计值。
您可以使用内置函数和 Excel 中的图表来创建此燃尽图表。
刻录图表步骤将是：
输入所有故事（A5 列 – A15 列）。
输入所有任务（B5 – B15 列）。
输入天数（第 1 天 – 第 10 天）。
输入起动工作（总结任务 C5 – C15）。
应用公式计算每天（第 1 天至第 10 天）的“估计工作量”。在 D15（C16- $ C $ 16/10）输入公式并将其拖动一整天。
对于每一天，输入实际的努力。在 D17（SUM（D5：D15））输入公式，用于总结剩余的实际工作量，并将其拖动到所有其他日期。
选择它并按如下方式创建图表：
12）速度
Scrum 团队在 sprint 中归档的故事点总数称为 Velocity。Scrum 团队通过其速度来判断或引用。话虽如此，但应该记住，这里的目标不是达到最大的故事点，而是要获得高质量的交付，尊重 Scrum 团队的舒适程度。
例如：对于特定冲刺：用户故事总数为 8，故事点如下所示。
所以这里的速度将是故事点的总和 = 30
完成的定义：
当所有故事都完成后，Sprint 被标记为完成，所有开发，研究，QA 任务都标记为“已完成”，所有错误都是固定关闭的，否则可以在以后完成（如不完全相关或不太重要）在备份日志中提取并添加代码审查和单元测试，估计的小时数已经达到了任务中的实际小时数，最重要的是，已经向 PO 和利益相关者提供了成功的演示。
在 SCRUM 方法论中完成的活动
#1）规划会议
计划会议是 Sprint 的起点。这是整个 Scrum 团队聚集的会议，SCRUM Master 根据产品积压和团队头脑风暴的优先级选择用户故事。
根据讨论，Scrum 团队根据 Fibonacci 系列决定故事的复杂程度并根据其进行调整。团队确定任务以及完成用户故事实施所需的工作（以小时为单位）。
很多时候，计划会议之前都是“预先计划会议”。这就像 scrum 团队在参加正式计划会议之前所做的一项功课。团队试图在计划会议中写下他们想要讨论的依赖关系或其他因素。
#2）执行 Sprint 任务
顾名思义，这些是 scrum 团队完成任务并将用户故事带入“完成”状态所做的实际工作。
#3）每日站立
在冲刺周期中，scrum 团队每天都会遇到，不超过 15 分钟（可能是一个直接的电话，建议在一天开始时）和状态 3 点：
昨天团队成员做了什么？
团队成员今天计划做什么？
任何障碍（障碍）？
促进这次会议的是 Scrum 大师。如果任何团队成员遇到任何困难，scrum master 会跟进以解决问题。在 Stand ups 中，董事会也会进行审核，并自行显示团队的进展情况。
#4）审核会议
在每个 sprint 周期结束时，SCRUM 团队再次会面并向产品所有者演示实现的用户故事。产品所有者可以根据其验收标准交叉验证故事。Scrum 大师再次负责主持这次会议。
同样在 SCRUM 工具中，Sprint 关闭，任务标记完成。
#5）回顾会议
回顾会议在审议会议之后召开。
SCRUM 团队会见，讨论并记录以下几点：
Sprint（最佳实践）期间进展顺利？
什么在 Sprint 中表现不佳？
得到教训
行动项目。
Scrum 团队应该继续遵循最佳实践，忽略“不是最佳实践”，并在随后的冲刺中实施经验教训。回顾会议有助于实施 SCRUM 流程的持续改进。
流程如何完成？一个例子！
阅读了 SCRUM 的技术术语。让我试着用一个例子来演示整个过程。
例：
步骤 1：让我们拥有一个由 9 人组成的 SCRUM 团队，其中包括 1 个产品所有者，1 个 Scrum master，2 个测试人员，4 个开发人员和 1 个 DBA。
步骤 2：Sprint 决定遵循 4 周的周期。所以我们从 6 月 5 日到 7 月 4 日开始为期一个月的 Sprint。
步骤 3：产品所有者在产品待办事项中具有优先级的用户故事列表。
步骤#4：团队决定于 6 月 4 日举行“预先规划”会议。
产品所有者从产品积压中获取 1 个故事，描述它并留给团队进行头脑风暴。
整个团队直接与产品所有者讨论并进行沟通，以便清楚地了解用户故事。
以类似的方式，采用各种其他用户故事。如果可能的话，团队也可以继续调整故事的大小。
在所有讨论之后，个人团队成员回到他们的工作站和
确定每个故事的各自任务。
计算他们将要工作的确切小时数。让我们来看看会员如何结束这些时间。
总工作小时数 = 9 减 1 小时休息，减 1 小时会议，减去 1 小时电子邮件，讨论，故障排除等 所以实际工作时间 = 6.Sprint 期间的总工作天数 = 21 天。总可用小时数 = 21 * 6 = 126. 该成员休假 2 天 = 12 小时（每个成员有所不同，有些可能请假，有些可能不休。）实际小时数 = 126 – 12 = 114 小时。
这意味着该成员实际上可以在此 sprint 中使用 114 小时。所以他将打破他的个人冲刺任务，总共达到 114 小时。
第五步：6 月 5 日，整个 Scrum 团队召开“规划会议”。
产品待办事项中的用户故事的最终判决已完成，故事将移至 Sprint Backlog。
对于每个故事，每个团队成员都会声明他们确定的任务，如果需要，他们可以讨论这些任务，可以调整大小或调整大小（请记住 Fibonacci 系列!!）。
Scrum 主人或团队在工具中输入他们各自的任务以及每个故事的小时数。
完成所有故事后，Scrum 主人注意到了最初的 Velocity 并正式启动了 Sprint。
步骤#6：Sprint 启动后，根据分配的任务，每个团队成员开始处理这些任务。
第 7 步：团队每天开会 15 分钟并讨论 3 件事：
他们昨天做了什么？
他们今天打算做什么？
任何障碍（障碍）？
步骤#8：Scrum master 在“Burn down chart”的帮助下每天跟踪进度。
步骤#9：如果遇到任何障碍，Scrum 主管会跟进解决这些问题。
步骤#10：7 月 4 日，团队再次召开审查会议。成员向产品所有者演示实现的用户故事。
步骤#11：7 月 5 日，团队再次召开会议，讨论回顾
什么进展顺利？
什么不顺利？
行动项目。
步骤#12：7 月 6 日，团队再次召开下一次冲刺的预先计划会议，并继续进行循环。
推荐阅读
Scrum Artifacts
What are Scrum Artifacts?
Definition of Done vs Acceptance Criteria
What is Definition of Ready in Scrum?
How to Write a Sprint Goal?
What is Product Backlog in Scrum? Who Responsible for It?
How to Refine Product Backlog?
Agile & Scrum Basis
Comprehensive Scrum Guide
What are Scrum’s Three Pillars?
What is Agile Software Development?
Scrum in 3 Minutes
What are the 5 Scrum Values?
What is the Evolution of Scrum?
Agile & Scrum Principles
The Agile Manifesto and Twelve Principles
10 Most Frequently Mentioned Basic Rules in Scrum
Scrum Roles
What is Scrum Team?
What is a Self-Organizing Team in Scrum?
How Scrum Team Works? – A Brief Guide
How to be a Good Product Owner in Scrum Project?
What is Product Owner’s Role in Scrum?