敏捷简介：什么是敏捷开发？

敏捷软件开发

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

我们将逐步引导您完成敏捷之旅，直到您了解使用敏捷背后的理念，优势以及如何实践它。本系列旨在使读者能够将敏捷和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 日，团队再次召开下一次冲刺的预先计划会议，并继续进行循环。