持续创作，加速成长！这是我参与「掘金日新计划 · 6 月更文挑战」的第3天
介绍
在上一个章中，您了解到与传统的项目管理方法相比，敏捷有很多好处。让我们深入探讨这个话题！在本章中，您将了解：
- 敏捷的价值观和原则。
- 敏捷思维的重要性。
- 团队、角色及其职责。
- 工件，您将每天使用它。
- Scrum 事件（其中一些也称为敏捷仪式）。
但是所有这些概念是如何相互关联的呢？让我们绘制一个高级流程概述并将其与我们的用例相关联。
作为 Tangram 公司的企业主，Sophie 对 Tangram 应用程序应该是什么样子有一个想法。然而，她不能把所有的时间都花在这个项目上，她正忙于制定战略目标。她需要重新考虑整个公司的战略并定义投资组合的样子。Sophie 意识到她需要一位产品负责人 (PO) ，她将代表并推动她的想法、目标和愿景，以实施 Tangram 应用程序。
在之前的项目中，Sophie 使用的是瀑布方法。她的瀑布团队包括：
- 负责收集需求的分析师。
- 一个建筑师，一个设计者，一个开发者，一个应用程序的编程者。
- 一名测试人员，专门用于测试应用程序。
在组织敏捷团队时，她意识到这意味着她需要与产品负责人、业务负责人以及Scrum 团队合作。事实上，做她的第一个敏捷项目对她来说有点新鲜，所以让我们弄清楚她需要知道什么！
敏捷思维
在一个早期使用瀑布方法和/或对敏捷完全陌生的人真正采用敏捷思维之前，必须发生几件事。首先，您需要了解敏捷价值观并了解敏捷原则。
2001 年，一群软件开发人员聚集在一起分享他们的经验。他们分析了最佳实践，定义了4 个价值观并制定了12 条表征敏捷方法的原则。这些价值观和原则在敏捷社区中被称为敏捷宣言。
然而，敏捷是不够的，只有敏捷和敏捷才能取得成果！通过根据敏捷价值观和原则进行检查、调整和交付来实践敏捷是很重要的。事实上，实施敏捷思维的唯一方法就是去做！在稳定的小型跨职能团队中进行协作是成功的先决条件。
如果您想知道从哪里开始采用敏捷思维方式，请尝试以下选项：
- 把你的工作分解成更小的部分。尽管工作范围变得更小，但它可以让您集中注意力并能够快速交付结果。
- 尽快获取并提供反馈，并定期进行。犯错误是一种改进的方法，但您希望尽早获得反馈，以便交付满足要求的产品。
- 公开透明地进行沟通。更好的沟通有助于管理 Scrum 团队和参与项目的其他利益相关者的期望。
- 取得所有权。在自我管理团队的背景下，您没有项目经理，因此请为您所从事的任务采取主动、责任和所有权。Scrum 团队对最终产品负责，但这种所有权和责任是 Scrum 团队中每个人的累积结果。
4大价值观
敏捷宣言确定了几个值（在此处查看它们的原始描述），表明某些事物的优先级应该不同，使某些方面优先于其他方面。
- 个人和交互超过流程和工具。这并不意味着流程和工具不重要，而是表明人与人之间的协作至关重要，您需要投资并致力于透明和信任的沟通。
- 工作软件胜过文档。传统的瀑布方法产生了大量的文档，但本质上，交付工作软件比描述更有价值。敏捷并没有消除文档，而是将重点放在功能齐全的产品上，而不是文档上。
- 客户超过合同谈判。与其与客户达成严格的协议并提前定义确切的细节，更好的方法是与客户建立协议以进行协作以找到最佳解决方案。为客户安排演示和产品评论的可用性是验证团队开发的产品正确性的重要一步。
- 响应变化而不是遵循计划。任何事情都不会按照您的计划进行。与其提前制定包含所有详细步骤的详尽计划，不如在此过程中调整优先级，并保持项目边界灵活且对变化开放。
12条原则
除了敏捷宣言制定的 4 个价值观之外，还有 12 条敏捷原则（在此处查看它们的原始描述）。他们列出了应该如何进行敏捷软件开发。原则清单：
- 有价值软件的早期和持续交付。 我们的首要任务是通过早期和持续交付有价值的软件来满足客户。
- 拥抱变化。欢迎不断变化的需求，即使是在开发的后期。敏捷流程利用变化来获得客户的竞争优势。
- 频繁交货。频繁地交付工作软件，从几周到几个月不等，优先考虑更短的时间范围。
- 商务人士和开发人员在一起。业务人员和开发人员必须在整个项目中每天一起工作。
- 有动力的个人。围绕有动力的个人建立项目。为他们提供所需的环境和支持，并相信他们能够完成工作。
- 面对面交谈。向开发团队和在开发团队内部传达信息的最有效和最有效的方法是面对面交谈。
- 工作软件。工作软件是进度的主要衡量标准。
- 可持续发展。敏捷流程促进可持续发展。赞助商、开发人员和用户应该能够无限期地保持恒定的步伐。
- 技术卓越。对卓越技术和良好设计的持续关注提高了敏捷性。
- 简单。简单——最大化未完成工作量的艺术——是必不可少的。
- 自组织团队。最好的架构、需求和设计来自自组织团队。
- 定期反思和调整。团队定期反思如何变得更有效，然后相应地调整和调整其行为。
价值观与原则之间的联系
如果您分析这些原则，您会注意到其中一些涉及我们之前描述的 4 个敏捷价值观的各个方面。工作软件优于文档的价值与工作软件、有价值软件的早期和持续交付以及频繁交付等原则有关。由于您的目标是通过尽早、频繁和持续地交付有价值的软件来满足客户，因此衡量进度、了解已完成的功能以及了解团队速度（例如交付软件需要多长时间）非常重要）。
对于 Sophie 来说，拥有一个可以工作的功能性应用程序现在是最高优先级。她不能通过出售应用程序的文档来真正赚钱，所以她希望应用程序尽快登陆应用商店。Sophie 对确保早期和持续交付的原则非常满意，因为她希望几乎每周都能看到进度，并能够及时提供反馈。
激励个人、面对面对话和自组织团队的原则与个人的价值以及流程和工具的 交互 密切相关。如果团队成员承担的责任超出了他们的软件开发任务，则无需让经理分配任务。一致、频繁和开放的沟通对于团队内部的一致性至关重要。它支持创造力、责任感，并建立在信任、尊重和勇气的基础上，以生产高质量的软件，而无需从上面进行过多控制。****
在我们的用例中，Sophie 以前从未与自组织团队合作过。她有点难以想象开发人员在没有经理分配特定任务的情况下如何定义自己的工作。然而，她意识到，在创建第一支团队时，她应该选择能够独立工作、能够承担责任的人，同时也愿意建立一种团队文化，让每个人都能乐于表现出主动性和尊重。
拥抱变化的原则与遵循计划价值的变化最接近。但结合定期反思和调整、简单性和技术卓越性原则，它们涉及过程部分及其持续改进。考虑到需求变化的快节奏，在开发过程中允许灵活地改变需求是很重要的。敏捷方法欢迎这种变化，即使是在开发的后期。无论业务需求多久变化一次，团队都应该持续关注技术卓越，因为好的设计可以提高敏捷性。作为变更管理的一部分，每次业务需求变更时评估技术设计的有效性非常重要。忽视一个好的技术设计可能会减慢团队的速度并延迟软件交付。持续改进的另一个方面是通过消除不应该完成的工作并尽可能自动化工作来关注简单性。
如您所见，不仅是公司，索菲本人也需要进行转型并成为变革经理。以前 Sophie 相信她的商店会产生稳定的月收入，现在 Sophie 需要不断研究市场、竞争和培养批判性思维。对新想法持开放态度并支持它们的实现成为她的新（待开发）技能。
业务人员和开发人员在一起的原则与客户高于合同谈判价值有关。消除协作障碍并允许开发人员和业务部门每天进行交互可以提高透明度并有助于管理期望。定期让业务人员参与审查会议可以让开发人员获得有价值的反馈，并更好地了解它应该利用的产品和业务价值。
Sophie 对整个项目的积极性和参与度对与开发人员的合作产生了积极影响。在这个时代，当 Sophie 需要专注于其他业务事务时，Product Owner 就成了她的耳朵和眼睛，必须积极参与协作会议，及时通知 Sophie，并在需要时支持开发人员。作为新任命的产品负责人 - 准备好集中注意力！有了正确的心态，Sophie 已准备好加入敏捷团队。让我们见见她的团队，了解他们的角色和职责！
工件
Artifacts
Artifacts 是一个总称，用于表示团队以这样一种方式执行的工作，即每个人都了解这项工作的价值和重要性。工件用于 Scrum 流程的各个阶段。通常，Scrum 团队的所有成员都可以访问它们，但是对于这些工件的创建/维护有明确的责任。
在我们开始解释在流程的哪个阶段使用哪些工件之前，让我们先了解一下 Sprint。Sprint 是 Scrum 框架的核心。这是一段有限的时间，通常在 1 到 4 周之间。Mendix 使用持续时间为 1-2 周的 Sprint。让 Sprint 持续更长时间可以延长向利益相关者展示产品的时间。这推迟了开发人员可以进行的反馈和干预，以根据要求调整产品。因此，将您的 Sprint 保持在 1-2 周的范围内，以确保频繁的反馈和快速的开发！Sophie 决定从 1 周的 Sprint 开始，以确保非常频繁地进行对齐。
每个 Sprint 都需要有一个目标。这个目标由所有团队成员共同制定，通常旨在提供与 Sprint 开始时商定的一样多的特性和功能。通过 Sprint Backlog 和“完成的定义”获取关于需要开发和交付的内容的协议。
Sprint Backlog 包含以用户故事的形式制定的需求。这些用户故事最初来自产品负责人创建的产品待办列表。Scrum 团队计划在给定的 Sprint 内进行开发，承诺解决所有选定的用户故事并在给定的 Sprint 内完成它们。
用户故事是否完成是根据完成的定义来定义的。Sophie 发现拥有一个经过良好测试的产品很重要，因此她通过指定需要首先测试开发团队提供的每个功能，为完成的定义做出了贡献。
在 Sprint 结束时交付的所有结果形成一个产品增量，然后将其呈现给用户和利益相关者进行审查。获得此反馈后，产品负责人有责任整合所有反馈，以便更新产品待办列表并重新确定优先级。
现在您已经了解了通用流程的样子，让我们更详细地讨论每个工件。
产品积压
产品待办列表是产品负责人根据业务的需要和要求确定优先级的要求列表。平衡的产品待办列表是关键！产品负责人的工作是对项目进行排序，以使最重要的项目具有最高优先级并提供最大的业务价值。如果您不知道要设置哪些优先级，请与业主联系！
产品待办列表可能会出现两件事。如果产品负责人留下的积压项目太大，这可能会导致在 Sprint 期间浪费时间来提炼并将它们分成更小的部分。因此，重要的是不仅要对积压工作进行优先排序，还要让最重要的项目为 Sprint 做好准备。无法在一个 Sprint 中交付的项目太大，应该分解成更小的项目。另一个陷阱是产品负责人花太多时间详细描述整个积压工作。在这里，您可以通过专注于最重要的项目来节省您的时间！
Scrum 团队中的每个人都可以将项目添加到产品待办列表中，但产品负责人有责任确定这些项目的优先级——与各种利益相关者协商。产品待办列表是一个需要不断完善的活文档，因为可以添加、更改或删除项目。
Sophie 计划与产品负责人（您！）定期会面，在那里您可以讨论进度、影响因素，并一起讨论优先事项。Sophie 从价值的角度思考，总是试图将能够产生最大商业价值的项目放在待办事项的顶部。
与 Scrum 团队一起，产品负责人可以确定如何在逻辑上分解待办事项。如此大块的工作，旨在实现特定类型的功能，通常被称为史诗。让我们看看史诗与用户故事和任务的关系。
史诗、用户故事、任务
在她的公司中，Sophie 处理正在开发的多种产品，她的开发人员以及业务合作伙伴都有很多期望和需求。她需要解决这个问题，以便每个人都可以按照合乎逻辑的逐步流程进行操作，并且不会忘记任何要求！她对整理需要做的事情有一个绝妙的想法，她认为对于团队和企业的合作来说，三个要素很重要：
- 每个人都需要知道应用程序的最终用户是谁。让我们称之为.
- 每个人都需要知道最终用户需要做什么。让我们称之为.
- 每个人都需要知道如何帮助最终用户实现上述目标？让我们称之为
现在，拥有这些信息非常有帮助，因为现在 Sophie 可以以合乎逻辑、清晰和解释性的方式制定需求，看：
As an END USER <**user type**>, I want SOMETHING <**what**>, so that MY NEEDS are met.
使用每个人都能理解的敏捷术语，这转化为通用模板：
As a <**user type**>, I want <**what**>, so that <**business value**> is met.
每个企业都有多个用户故事，因为他们有很多需求和要求。必须以这种方式编写（完成）的一个单独的功能或业务需求称为用户故事。换句话说，用户故事从用户的角度提出了需求或愿望。
在她目前的情况下，Sophie 对应用程序的下载次数以及用户是只使用免费内容还是付费内容缺乏洞察力，因此她要求您编写用户故事。你认为你会如何处理这个问题？好吧，您可以编写这样的用户故事：
As a Director, I want to see which content the users consume within the app, so that I can define the most valuable and popular features.
As a Director, I want to see the number of times the app has been downloaded from the app store, so that I can monitor its popularity.
请注意，在编写用户故事时，它不应包含太多功能，并且适合在 2-3 天内完成。否则，这样的用户故事可能不适合 Sprint 或包含太多无法测试的功能。
由于用户故事不止一个，Scrum 团队需要一种方法来确定它们的优先级——这是特定积分系统最有效的地方！开发团队需要为每个用户故事分配一些点，表明用户故事的复杂性。分配故事点对于开发团队来说是必不可少的，以便定义多少个用户故事可以包含在一个 Sprint 中。随着时间的推移，团队学会反思团队的速度，并知道为 Sprint 计划多少故事点是现实的。通过获得更多经验，团队学会更快地执行某些任务，这可能会导致团队速度加快。
还记得我们提到过一些用户故事可能会变得太长/太复杂吗？虽然其中一些可以分解为几个较小的部分，但有些可以组合成一个代表更大想法的池。大型用户故事称为史诗。
史诗是一个大型的用户故事。它捕获了一个太大而无法在单个 Sprint 中交付的需求，并且需要分解成更小的可交付成果（故事）。在 Tangram 应用程序的开发中，我们可以确定如下史诗：支持愿意探索应用程序而无需首先注册的匿名用户；或开发网上商店功能；或搭建七巧板社区平台、代币化、分布式竞赛。
您之前编写的用户故事将完全适合以下史诗：
(An example of epic) “As a Director, I want to have a management dashboard so that I can easily manage the work of my company".
所以，总而言之：史诗是大型用户故事，用户故事是业务需求或功能。但是我们如何将用户故事分解为可操作的项目呢？我们可以通过特定的任务来做到这一点！
任务是构建用户故事的元素。通过确定需要为给定用户故事执行哪些任务，您可以确保一旦用户故事设置为正在运行，就不会错过任何步骤。任务通常使用 SMART 方法定义：具体的、可衡量的、可实现的、相关的、有时间限制的。
在 Mendix 中，创建页面、按钮、添加数据、实现逻辑只是任务的一些示例。
*An example of a task: “Create a button to open a page.”* *Another example: “Create a variable showing the number of users online.”*
冲刺积压
在 Sprint 期间，Scrum 团队从 PO 创建的 Product Backlog 中识别项目，他们计划在下一次迭代中交付这些项目。Scrum 团队选择处理的项目成为 Sprint Backlog 的一部分。
出于监控目的，需要定期检查和更新积压项目的状态，并且最好有一个集中的地方，每个人都可以访问，以便对其进行监控。这样的地方通常被称为 Scrum 板。由团队决定他们将使用物理的 Scrum 板还是虚拟的 Scrum 板。每个用户故事都有一个状态：新建、进行中或完成。Scrum Master 确保 Scrum 板定期更新。拥有实体 Scrum 板的好处是它增加了团队进度的透明度（对于位于同一房间的人）。缺点是还需要虚拟注册用户故事，以使所有其他利益相关者能够以远程方式咨询 Sprint 的状态。可以想象在数字时代，每个人都将进行虚拟协作。在这种情况下，团队需要选择一个虚拟协作工具，以便对 Scrum 板进行共享和实时调整。
Sophie 还决定了她的团队将用于管理用户故事的工具。你知道她做了什么选择吗？是的，她的团队将使用 Mendix 开发人员门户，该门户提供维护用户故事的功能，还允许以可视仪表板的形式计划和监控其执行。
产品增量
产品增量是 Sprint 期间完成的所有用户故事的总和。由于 Scrum 是一个迭代过程，因此产品增量迭代地演进并为之前的产品增量添加新功能。在最后一个 Sprint 结束时，产品增量代表将呈现给客户的需求产品。只有当产品满足验收标准时，客户才会正式接受它并给它一个 Go 来发布它。
产品增量的一个示例可能是 Tangram 应用程序中的仪表板。
完成的定义
为确保开发团队知道产品增量应满足哪些验收标准，产品负责人需要在称为完成定义 (DoD) 的可访问文档中预先定义它们。根据项目的具体情况，此类 DoD 有助于确保开发的产品提供所需的功能，并确保预期的质量水平。DoD 应该用于检查每个 Product Backlog 项目。
让我们看一下 Sophie 的团队认为在 DoD 中为 Tangram 应用程序包含的几个重要标准。它们通常被编写为成功执行时应检查的步骤，例如：
- 代码审查
- 单元测试通过
- 功能测试通过
- 产品负责人接受了用户故事
Scrum 事件
Scrum 规定了许多有助于围绕每个 Sprint 组织流程的事件。Sophie 不能只雇佣一个开发团队并告诉他们开发应用程序。她需要围绕这个开发安排流程，让团队知道需要完成哪些范围的工作，什么时候需要交付，展示哪些工作已经完成，最后反思开发过程是如何进行的。幸运的是，Sophie 不必自己计划所有这些活动，因为这些组织任务是 Scrum Master 的责任！Scrum 使用的四个事件是：
- 冲刺计划
- 冲刺回顾
- 冲刺回顾
- 每日站立
在这些事件旁边，Scrum 团队执行Product Backlog Refinement。这不是正式的 Scrum 事件，但就像其他列出的事件一样，这种改进会定期发生，在所有其他计划的 Scrum 事件之前。这是因为，在您开始处理任何用户故事之前，您需要知道要处理什么 - 因此产品待办列表细化！
每个提到的事件都有一个专门的目标，消耗一些输入，并提供几个输出。下面显示了 2 周 Sprint 的典型时间表的概要。提前计划这个会议节奏是很方便的，以确保所有需要的利益相关者在他们的议程中保留一个时间段。
让我们先尝试了解时间限制，然后再详细讨论每个事件！
好的，所以 Sprint 从 Sprint 计划开始，开始接下来的 2 周。然后，Scrum 团队每天都会聚集在一起进行每日站立会议。本次会议仅持续 15 分钟，最好在早上组织，以便团队成员在白天就特定主题进行协作。在第二周结束时，组织了 Sprint 评审和 Sprint 回顾会议。它们旨在反映产品以及过程本身。Backlog Refinement 是唯一在一周中举行的会议。如果需求变化很大，可能需要每周重新访问产品待办列表。这使开发团队能够更好地预测即将发生的变化。
还记得早些时候 Sophie 决定运行 1 周的 Sprint，对吗？一般来说，这意味着会发生相同的事件，只有除每日站立之外的所有事件的持续时间将比两周 Sprint 的情况花费更少的时间。这与需要计划或审查的用户故事数量较少有关。根据要讨论的项目，回顾可能会持续更短，因为一周内发生的事情较少。
Scrum Master 已经计划了这些活动，并确保 Sophie 在她的议程中占用了一些时间。你可以想象苏菲渴望看到第一个结果！
产品待办列表细化
会议节奏从产品待办列表细化会议开始。本次会议的目标是就从产品待办列表中选择的用户故事达成相互理解。这种对齐是必需的，因为 Product Backlog 可以由不同的人修改。您要防止的是，这些故事被各方错误地解释了。在这次会议期间，可以细化积压工作。如果需要，PO 将重新确定积压的优先级。在为积压项目分配优先级时，PO 会考虑利益相关者的需求和愿望。但最重要的是，PO 关注用户故事将利用的业务价值。重要的是要从上到下对项目进行优先级排序，确保首先处理最重要的项目。
为了阐明特定用户故事的内容，可能有必要让 SME 也参与此次会议。但总的来说，这次会议由核心 Scrum 团队的所有成员参加。
在完善用户故事时，团队需要将故事点分配给他们。早些时候，我们已经提到，这些故事点表明了用户故事的复杂性以及团队为解决用户故事而需要投入的估计工作量。在 Mendix 中，用于表示故事点的权重基于类似斐波那契的序列（1、2、3、5、8、13、20、40 和 100）。
在定义完成用户故事所需的工作量时，您需要考虑三个因素：
- 用户故事的细节
- 完成的定义
- 验收标准
如果对用户故事的复杂性存在分歧，意见最极端的团队成员会讨论他们的论点。通常，详尽的对话可以阐明问题，并且团队成员就故事的重要性达成共识。 您可以实现的方法之一是规划扑克 - 一种当每个人都将权重点分配给用户故事（他们认为自己的“价值”）并且得分最低和最高的项目是唯一讨论的项目时.
作为该 Sprint 的结果而获得的精炼用户故事可作为 Sprint 计划活动的输入。
Sprint 计划
Sprint 计划是一个协作过程，涉及 Scrum Master、产品负责人和整个敏捷开发团队。Scrum Master 在那里为会议提供便利。Scrum Master 也会关注是否需要让 SME 参与进来。产品负责人负责阐明产品待办列表项的详细信息及其各自的验收标准。PO 确保解决在产品待办列表细化会议期间仍未得到解答的问题，并尽可能解决所有其他不明确的问题。开发团队定义了实现 Sprint 承诺所需的工作和努力。
产品负责人确保开发团队在 Sprint 期间有明确的目标和重点。在 Sprint 计划期间，开发团队决定为给定的 Sprint 选择哪些用户故事。通过定义范围，开发团队承诺在 Sprint 结束时以高质量完成选定的用户故事。团队速度是决定团队在一个 Sprint 中能够完成多少工作的因素。了解团队速度后，团队几乎可以精确地定义他们可以在 Sprint 中涵盖多少用户故事。只需聚合所有选定用户故事的故事点，团队就可以检查选定工作负载的可行性。
团队速度可能会在项目期间发生变化。在稳定的团队中工作并更好地了解项目的情况下，团队速度可能会提高。但是，如果团队进行某种重组，它也可能会减少。通常，改变团队的构成会对团队的速度产生负面影响。
Sprint Review
在 Sprint 结束时，Scrum Master 会组织一次 Sprint Review。该活动旨在向产品负责人、管理层和最终用户展示 Sprint 的结果。审查产品时，起点是 Sprint 目标，其中范围已设置为解决一组用户故事。
在演示期间，验收标准用于检查呈现的增量是否满足完成的定义。从 PO 和其他利益相关者那里收到的反馈可能会导致在下一个 Sprint 中添加新的用户故事，或者产品待办事项可能需要进行一些调整。
对于团队来说，根据本次会议期间进行的讨论确定接下来的步骤是非常重要的。Sprint Review 的结果是一组经过 PO 批准的潜在新积压项目。
Sprint 回顾
回顾会议通常在每个 Sprint 结束或主要开发周期结束时举行，对于打开沟通渠道至关重要。在产品负责人审查产品增量之后，是时候让 Scrum 团队举行回顾会议了。在 Scrum Owner 的推动下，这次会议中，每个人都对进展顺利、需要改进的地方或需要采取哪些新的干预措施提供反馈。这样的会议可能需要长达 1.5 小时。这是一个反思已完成 Sprint 的流程、人员和组织方面的好机会。
Scrum Master 需要创造一个环境，让每个团队成员都能轻松地分享他们的反馈。每个成员都应该能够与团队的其他成员分享他们的诚实意见。
在本次会议期间可以评估几件事：
- 什么进展顺利，你应该继续做什么？
- 哪些方面做得不好以及如何改进？
- 团队成员可能会开始做哪些新事情，为什么？
最常见的设置是每个团队成员列出每个类别的五个项目。然后通过投票，团队可以决定哪三个改进点将包含在新 Sprint 的过程中。这里的常见陷阱之一是试图一次改变太多，这不会导致所需的过程。每个改进点都是整个团队的责任，但是为每个改进点分配一个负责人来监控它是很方便的。
每日站立
会议 在每日站立会议中，Scrum 团队成员与团队分享自己的进度。此会议通常由开发人员参加，但也欢迎 PO。每个开发人员都共享以下内容：
- 我昨天做了什么？
- 我今天要做什么？
- 是什么阻碍了我，我的障碍？
事实证明，召开一个每个人都必须站起来的会议，表明它是快速有效的。为确保站立会议不超过专用的 15 分钟，重要的是要解决举行此类会议的一些规则。这次会议的目的不是更新 Scrum Master，而是通知团队成员。本次会议的目的不是详细说明解决方案或解决问题，而是在您需要他们的意见或帮助时通知其他人。此外，团队通常会查看已计划项目与已完成项目的列表（通常称为燃尽图），它衡量已完成的工作量与 Sprint 结束时所需的总工作量。
对于大型敏捷团队，每日站立会议往往会超过 15 分钟的限制。为了解决这个问题，Scrum Master 需要在不涉及团队成员的情况下，主动浏览 Scrum 板上的用户故事，并简要介绍用户故事的状态。通过从右到左讨论项目（例如解决已完成、正在进行和新的项目），最重要的项目将首先被讨论。
要求每个开发人员报告每个用户故事的状态可能效率不高。在涉及多个开发人员的复杂用户故事的情况下，尽量避免重复。让 Scrum Master 接管报告部分，并通知其他人这些复杂项目的状态
总结
在本章中，您学习了构成敏捷方法基础的所有概念。您现在具备敏捷思维，准备好参与 Scrum 活动，并且您知道您将与谁合作。您现在是自组织团队的一员。所以让我们激活你的知识。在下一章中，您将获得改变，开始构建您的敏捷技能！
