这些日子参加了一个敏捷项目管理专题的培训会，恰巧尝试下生成式AI在这种场景的作用，便在会中做记录时结合AI使用了起来，总结了些要点进行分享，个人感觉效果还是立竿见影的，不单单提升了记录总结的效率，在会中也可以快速的解决一些疑惑点。
敏捷宣言：
敏捷宣言是2001年由软件开发领域的专家起草的宣言，旨在推动敏捷软件开发方法的发展。 它强调价值观和原则，为指导团队实施敏捷开发提供了基础。
以下是敏捷宣言的四个核心价值：
1、个人和互动高于流程和工具：强调团队成员之间沟通、协作和相互支持的重要性，认为人与人之间的协作关系比使用工具和遵循流程更重要。
2、工作软件优于综合文档强调软件开发的核心目标是交付工作软件，而不仅仅是编写文档。 软件开发应该注重实际结果的输出。
3、客户协作优于合同谈判：强调与客户的积极合作和互动，以了解和满足他们的需求。 通过与客户密切合作，我们可以更好地适应变化并提供有价值的解决方案。
4、响应变化胜于遵循计划：强调软件开发过程中不可避免的变化，应灵活对待。 团队要有应变能力，及时调整计划和策略。
以下是敏捷宣言中概述的 12 条敏捷原则：
1、通过尽早和持续的软件交付使客户满意：专注于尽可能早和频繁地向客户交付有价值的软件，以确保他们的满意度并收集反馈以进一步改进。
2、欢迎不断变化的需求，即使是在开发后期：拥抱变化并在整个开发过程中灵活响应不断变化的客户需求和要求。
3、经常交付工作软件，优先选择较短的时间尺度：旨在在短时间内定期迭代交付功能性软件，从而实现更快的反馈、适应和价值交付。
4、在整个项目中与客户和利益相关者密切协作：促进与客户、最终用户和利益相关者的积极协作和参与，以了解他们的需求，让他们参与决策，并确保最终产品满足他们的期望。
5、围绕积极进取的个人构建项目，为他们提供所需的环境和支持：创建一个授权和支持的环境，使自组织团队能够表现出色、做出决策并掌控自己的工作。
6、将面对面的沟通作为最有效的方法：鼓励团队成员、客户和利益相关者之间直接和频繁的沟通，以促进更好的理解、及时解决问题并建立牢固的关系。
7、可工作的软件是衡量进展的主要指标：专注于交付能够为客户提供价值的功能性软件。 根据生成的工作软件评估进度，而不是仅仅依赖文档或任务的完成情况。
8、保持可持续的步伐，促进长期发展：努力实现可持续和可管理的工作节奏，以确保团队的福祉并在整个项目中保持一致的生产力水平。
9、持续关注技术卓越和良好设计：强调技术工艺、质量代码和合理设计原则的重要性，以增强软件的可维护性、可扩展性和适应性。
10、简单性——将未完成工作量最大化的艺术——是必不可少的：重视简单性并避免不必要的复杂性。 专注于提供必要的特性和功能，同时最大限度地减少浪费并避免不必要的工作。
11、自组织团队做出最佳决策：鼓励团队自组织，授权他们做出决策、协作并不断改进他们的工作流程以实现项目目标。
12、定期反思如何变得更有效并相应地进行调整：促进定期回顾以反思团队的绩效，确定需要改进的领域，并调整用于提高有效性和效率的流程、工具和技术。
这些原则为敏捷开发方法论提供了基础，并指导团队采用迭代和以客户为中心的软件开发方法。
Aglie Scrum：
Agile Scrum 是一种流行的框架，用于管理和组织复杂产品的开发。 它基于敏捷软件开发的原则和价值观。 Scrum 强调迭代和增量开发、协作和灵活性。
以下是敏捷 Scrum 中的一些关键概念和角色：
Scrum 团队：Scrum 团队是一个自组织的跨职能团队，负责交付产品增量。 它通常由产品负责人、Scrum Master 和开发团队成员组成。
产品负责人：产品负责人代表利益相关者，负责最大化产品的价值。 他们定义产品待办事项列表并确定其优先级，确保它反映利益相关者的要求和愿景。
Scrum Master：Scrum Master 是 Scrum 团队的促进者和教练。 它们有助于确保遵循 Scrum 流程，消除任何可能阻碍进展的障碍，并营造高效协作的工作环境。
开发团队：开发团队由专业人员组成，他们负责在每个冲刺结束时交付产品的潜在可发布增量。 他们负责自我组织、评估和选择工作，并协作完成任务。
产品待办列表：产品待办列表是产品中需要解决的所有功能、增强功能和错误的优先列表。 它由产品负责人管理，并根据反馈和不断变化的需求在整个项目中不断发展。 Sprint：Sprint 是一个有时间限制的迭代，通常持续 1-4 周，在此期间 Scrum 团队致力于交付产品的潜在可发布增量。 要完成的工作是从产品待办事项列表中选择的，并在冲刺计划会议期间进行计划。
Sprint 计划：在 Sprint 计划会议中，Scrum 团队确定在 Sprint 期间要处理的产品待办列表项。 开发团队与产品负责人合作以了解需求并定义冲刺目标。
Daily Scrum：Daily Scrum，也称为每日站会，是开发团队同步工作的简短每日会议。 每个团队成员分享他们的进展、当天的计划以及他们可能面临的任何障碍。
Sprint 评审：在每个 sprint 结束时，都会举行 Sprint 评审，以展示在 sprint 期间完成的工作并收集利益相关者的反馈。 这是评估产品增量并对产品积压进行调整的机会。
Sprint Retrospective：Sprint Retrospective 是在 Sprint 回顾之后举行的会议，以反映团队的绩效并确定需要改进的地方。 Scrum 团队讨论哪些进展顺利，哪些可以改进，并制定计划在下一个 sprint 中实施这些改进。
敏捷 Scrum 为团队协作、适应变化和在整个开发过程中递增地交付价值提供了一个框架。 它促进透明度、持续改进和客户满意度。
Spring planning：
Sprint 计划是 Scrum 框架中的一个重要事件，它为即将到来的 sprint 设定了方向和目标。 在这次会议期间，Scrum 团队协作计划要完成的工作并定义冲刺目标。
以下是 Sprint 计划的关键方面：
与会者：Sprint 计划会议涉及 Scrum 团队，包括产品负责人、Scrum 主管和开发团队成员。 建议让所有团队成员都在场，以确保有效协作和共同理解。
时间盒：冲刺计划是有时间限制的，对于为期一个月的冲刺，通常最多持续八个小时。 对于更短的冲刺，时间框更短。 Scrum Master 确保会议在分配的时间内举行，以保持效率。
产品待办列表细化：在 Sprint 计划之前，产品负责人确保产品待办列表得到细化和更新，高优先级的项目排在最前面。 团队审查并澄清积压事项，以确保对要完成的工作达成共识。
Sprint 目标：产品负责人分享即将到来的 sprint 的目标或目标。 目标为团队提供重点和方向，指导他们在整个冲刺中的工作和决策。
选择 Sprint Backlog 项目：开发团队与产品负责人合作确定哪些 Backlog 项目将包含在 Sprint 中。 他们审查高优先级项目，考虑他们的能力，并选择他们认为可以在冲刺内完成的工作。
Sprint Backlog：一旦开发团队选择了 Backlog 项目，他们就会创建 Sprint Backlog。 冲刺积压工作包括团队承诺在冲刺期间完成的特定任务、用户故事或积压工作项目。
任务分解：如有必要，开发团队可以进一步将选定的积压项目分解为更小的、可操作的任务。 这种细分有助于在冲刺期间估算工作量、分配任务和跟踪进度。
估算：开发团队估算每个选定的积压项目或任务所需的工作量。 这种估计可以使用各种技术来完成，例如故事点、理想天数或相对规模。 它帮助团队规划他们的能力和管理期望。
完成的定义：团队再次确认完成的定义 (DoD)，它概述了产品待办列表项必须满足的质量标准才能被视为完成。 国防部确保对预期的质量和完成水平达成共识。
Sprint 计划：在 Sprint 计划会议结束时，团队对即将到来的 sprint 有了明确的计划。 他们有一组选定的积压项目、估计的工作量以及对实现冲刺目标需要实现的目标的共同理解。
Sprint 计划通过协调团队的努力、建立 Sprint 目标和定义要完成的工作，为成功的 Sprint 奠定基础。 它使团队能够协同工作，做出明智的承诺，并在整个冲刺过程中逐步交付价值。
Daily scrum：
Daily Scrum，也称为每日站会，是 Scrum 团队在冲刺期间举行的简短而有重点的会议。 它作为日常同步和计划活动，以确保团队内部的有效沟通和协调。
以下是 Daily Scrum 的关键方面：
参加者：每日 Scrum 涉及 Scrum 团队，包括产品负责人、Scrum 主管和开发团队成员。 其他利益相关者可以作为观察员参加，但只有 Scrum 团队积极参与会议。
时间框：每日 Scrum 的时间限制为最多 15 分钟，无论团队规模如何。 时间盒有助于保持专注，鼓励简明更新，并确保会议不会变成冗长的状态更新会话。
站立形式：会议通常由与会者站立进行，以促进简洁并保持讨论的重点。 它有助于保持精力并防止会议变得过于舒适或冗长。
三个关键问题：团队成员在每日站会期间轮流回答三个关键问题：
自上次 Daily Scrum 以来我完成了什么？
在下一次 Daily Scrum 之前我要做什么？
是否有任何障碍阻碍我或团队的进步？
每个团队成员分享一个简短的更新，强调他们的进展、计划的工作以及他们可能面临的任何障碍。
专注于 Sprint 目标：每日站会强化了 Sprint 目标，并确保团队的工作与其保持一致。 团队成员将他们的更新与冲刺目标联系起来，帮助他们专注于更大的目标并相应地优先考虑他们的工作。
沟通与协作：每日 Scrum 为团队成员提供了共享信息、协调工作以及识别任何依赖关系或潜在问题的机会。 它鼓励协作、知识共享以及早期识别障碍或风险。
Scrum Master 的角色：Scrum Master 促进每日 Scrum，确保它保持在时间范围内并保持其目的。 他们可能会提出后续问题，帮助消除提到的任何障碍，并确定改进团队流程或协作的机会。
透明度和检查：每日站会通过让团队成员了解彼此的进展和挑战来提高透明度。 它提供了一个平台，用于检查项目的当前状态，识别与计划的任何偏差，并在必要时调整团队的方法。
适应和后续步骤：根据每日 Scrum 期间共享的更新和信息，团队可以调整他们的计划，调整他们的任务或优先级，并采取必要的行动来保持冲刺在正轨上。 会议是团队内部协作和决策的跳板。
Daily Scrum 是促进 Scrum 团队成员之间的透明度、沟通和协调的宝贵实践。 它有助于让每个人保持一致、了解情况并专注于实现冲刺目标。
Sprint review：
Sprint 评审是 Scrum 框架中的重要事件，发生在每个 sprint 结束时。 它为 Scrum 团队提供了一个展示冲刺期间完成的工作并收集利益相关者反馈的机会。
以下是 Sprint 评审的关键方面：
与会者：Sprint 评审涉及 Scrum 团队，包括产品负责人、Scrum 主管和开发团队成员。 此外，利益相关者、客户和任何对产品进展感兴趣的人都被邀请参加审查。
时间盒：Sprint 评审是有时间限制的，通常在 sprint 持续时间中每周持续不超过一小时。 对于较短的冲刺，时间盒可能会更短，以确保有效利用时间并保持专注。
增量演示：开发团队展示在冲刺期间已完成的产品增量。 他们展示了实现的功能和特性，并解释了它如何与冲刺目标和产品愿景保持一致。
反馈与协作：利益相关者，包括客户、用户和其他与会者，对展示的增量提供反馈。 他们分享想法、提出问题并提供改进建议或新功能。 此反馈有助于为未来的迭代和改进提供信息。
审查 Sprint 目标和产品待办列表：Scrum 团队，尤其是产品负责人，审查在冲刺开始时设定的冲刺目标。 他们评估是否达到了冲刺目标，以及是否需要根据收到的反馈对产品积压进行任何调整。
适应和计划：Sprint 评审作为 Scrum 团队讨论任何必要的适应或调整的平台。 他们考虑在审查期间获得的反馈和见解，并将其用于为未来的规划和决策提供信息。
审查完成的定义：团队再次确认并讨论完成的定义 (DoD)，以确保对必须满足的质量标准达成共识，增量才能被视为完成。 这有助于保持一致的质量水平并指导未来的开发工作。
透明度和协作：Sprint 评审通过公开分享所取得的进展和取得的进步来提高透明度。 它鼓励合作并让利益相关者参与进来，培养主人翁意识和对产品成功的共同责任。
产品待办列表细化：根据 Sprint 评审期间收到的反馈，产品负责人可以更新和细化产品待办列表。 可以考虑新项目、变更或重新确定优先级，以反映利益相关者不断变化的需求和期望。
持续改进：Sprint 评审为 Scrum 团队提供了一个机会来反思他们的过程，确定需要改进的领域，并进行调整以增强未来的 sprint。 它支持持续改进的原则，并确保团队不断学习和成长。
Sprint 评审是一个鼓励协作、反馈和适应的关键事件。 它有助于确保产品增量满足利益相关者的需求。 期望并为 Scrum 团队提供机会来检查和调整他们的方法以适应即将到来的冲刺。
Retrispective：
回顾会议是 Scrum 框架中的定期且必不可少的会议，发生在每个冲刺结束时。 它允许 Scrum 团队反思他们的协作、过程和结果，目标是确定优势、改进领域和变革行动。
以下是回顾的关键方面：
与会者：回顾会涉及 Scrum 团队，包括产品负责人、Scrum 主管和开发团队成员。 会议应该创造一个安全的环境，让每个人都可以公开和诚实地分享他们的想法和经验。
时间框：回顾是有时间限制的，通常持续大约 1-3 小时，具体取决于冲刺长度和团队规模。 Scrum Master 确保会议在分配的时间内举行，以保持重点和有效性。
反思 Sprint：回顾会关注最近完成的 Sprint。 团队审查冲刺的事件、结果和他们自己的贡献，以获得对进展顺利、进展不顺利以及有待改进的领域的共同理解。
欣赏和积极：团队通过承认和欣赏冲刺的积极方面来开始回顾。 这有助于营造积极和建设性的氛围，并鼓励团队成员认可他们的成就和成功。
确定需要改进的领域：团队讨论他们在冲刺期间遇到的挑战、问题或障碍。 他们确定了他们认为可以改进或面临困难的具体领域，无论是在流程、协作、沟通还是技术方面。
根本原因分析：团队深入挖掘已确定的改进领域，以了解根本原因。 他们探索挑战背后的原因，寻找可能导致问题的模式、瓶颈或反复出现的问题。
生成见解和行动项目：基于讨论，团队生成见解和行动项目。 他们集思广益并提出可能的解决方案或更改，以解决已确定的问题并提高他们在未来冲刺中的绩效和成果。
决策制定和优先级排序：团队讨论生成的行动项目并确定其优先级。 他们决定在即将到来的冲刺中关注并承诺实施哪些。 必须优先考虑并选择一些关键项目，以避免团队因过多的变化而不知所措。
跟进和问责制：团队确定谁将负责实施每个行动项目并设定完成时间表。 这有助于确保问责制和朝着商定的变革取得进展。 Scrum Master 可以支持团队跟踪和跟进这些行动。
持续改进：回顾强调持续改进的原则。 它在 Scrum 团队中促进学习、适应和协作的文化。 团队应努力实施已确定的改进并将吸取的教训带入未来的冲刺中。
回顾会议是 Scrum 团队反思他们的工作、从他们的经验中学习并调整他们的流程和行为以提高他们的有效性和效率的机会。 它培养了一种持续学习和改进的文化，支持团队的成长和成功。
Product backlog refinement：
Product Backlog Refinement，也称为 Backlog Grooming，是 Scrum 中的一个持续过程，涉及定期审查、改进和确定产品 Backlog 中项目的优先级。 它确保积压工作保持最新、组织良好并为未来的冲刺做好准备。
以下是产品待办列表优化的关键方面：
协作活动：产品待办列表细化是一项涉及产品所有者和开发团队的协作活动。 Scrum 团队一起工作来分析和改进积压项目。
时间分配：产品待办列表细化是一个持续的过程，通常在整个冲刺期间进行。 然而，Scrum 团队通常会为待办列表细化活动分配专门的时间框，例如每周例会或特定时间段。
积压项目审查：Scrum 团队审查产品积压中的项目，确保它们定义明确、理解并与产品愿景保持一致。 这涉及澄清需求、识别依赖关系以及评估它们与当前产品目标的相关性。
故事拆分：如果积压项目太大或太复杂，Scrum 团队可能会将它们拆分成更小、更易于管理的部分。 故事拆分有助于提高积压工作的粒度，并使团队能够更好地估计、确定优先级和交付项目。
优先级排序：产品负责人与开发团队合作，根据积压项目的价值、依赖性和市场或客户需求重新评估积压项目的优先级。 该团队还可以考虑来自利益相关者和最终用户的反馈，以便为优先级排序过程提供信息。
估算：Scrum 团队可以估算积压项的工作量或相对大小。 可以使用故事点、理想日子或 T 恤尺码等技术来完成此估算。 估算积压项目有助于团队了解所涉及工作的范围和复杂性。
用户故事细化：代表所需功能或特性的用户故事通常是产品待办事项列表中的主要元素。 在细化期间，团队可能会进一步阐述和细化用户故事，确保他们满足“投资”目标。 标准（独立的、可协商的、有价值的、可估计的、小的、可测试的）。
验收标准：Scrum 团队协作定义积压项目的验收标准。 验收标准概述了产品积压项目必须满足的条件才能被视为完成并满足产品负责人和利益相关者的期望。
更新和排序：作为改进的一部分，Scrum 团队使用最新的信息、反馈和见解更新积压项目。 他们还根据不断变化的优先级、市场动态或新出现的需求审查和调整项目的顺序。
透明度和准备：产品待办列表细化的目标是确保产品待办列表透明、有条理，并为即将到来的冲刺做好准备。 完善的待办事项列表项使 Scrum 团队能够有效地计划和执行冲刺，同时清楚地了解要完成的工作。
产品待办列表细化是一个持续的过程，可帮助 Scrum 团队保持健康且准备充分的产品待办列表。 它支持有效的冲刺计划，促进协作和共享理解，并增强开发过程的整体敏捷性和响应能力。
Kanban：
看板是一种流行的敏捷框架，用于管理工作和可视化工作流程。 看板起源于制造业，已广泛应用于软件开发和其他各种知识工作领域。
以下是看板的关键方面：
视觉板：看板依赖于工作的视觉表示，通常组织在分为几列的板上。 每列代表工作的一个阶段或状态，例如“待办事项”、“待办事项”等。 “进行中”， 和“完成”。 该看板提供了工作流和每个工作项状态的清晰可视化表示。
工作项：工作项通常以卡片或便签表示，在看板的列中流动。 每个工作项代表一个任务、用户故事或需要完成的一个工作单元。
进行中的工作 (WIP) 限制：看板强调限制进行中的工作，以避免团队负担过重并促进顺畅的工作流程。 为每个列设置了 WIP 限制，以防止出现瓶颈并鼓励集中精力并及时完成工作。
拉式系统：看板遵循基于拉式的系统，只有在容量允许的情况下，工作才会被拉入工作流的每个阶段。 这有助于防止超载并鼓励在团队成员之间平衡分配工作。
连续流程：看板强调通过确保已完成的项目立即移至下一阶段并在容量可用时引入新工作项目来实现连续的工作流程。 这种方法减少了延迟并实现了更快的价值交付。
明确的政策：看板鼓励为工作流的每个阶段建立明确的政策。 这些策略定义了将工作项从一列移动到另一列的标准，包括质量标准、验收标准和任何特定规则或指南。
指标和数据驱动的见解：看板依靠数据和指标来推动持续改进。 看板中使用的常用指标包括周期时间（完成一个项目所花费的时间）、提前期（从请求到完成的时间）和吞吐量（在给定时间段内完成的项目数）。 这些指标有助于识别瓶颈、分析性能并为决策提供信息。
持续改进：与其他敏捷方法一样，看板提倡持续改进的文化。 团队定期反思他们的流程、政策和绩效，寻求优化工作流程、提高效率和更有效地交付价值的方法。
灵活性和适应性：看板允许灵活地管理和重新确定工作的优先级。 新的工作项目可以添加到待办事项列表中并根据需要重新确定优先级，以响应不断变化的业务需求或客户需求。
协作和透明度：看板促进团队内部以及与利益相关者的协作和透明度。 可视板和清晰的工作流程提供了对工作进度和状态的可见性，促进了更好的沟通、协调和对齐。
看板为团队提供了一种灵活、可视化的工作管理方法，使他们能够优化工作流程、减少浪费并更有效地交付价值。 它强调持续改进和适应性，使其适用于可预测和不可预测的工作环境。
Scrumban：
Scrumban 是一个敏捷框架，结合了 Scrum 和看板的原则和实践。 这是一种混合方法，旨在利用两种方法的优势来优化工作流程并提高团队绩效。
以下是 Scrumban 的关键方面：
Scrum Foundation：Scrumban 结合了 Scrum 的核心元素，例如时间盒迭代（冲刺）、跨职能团队以及产品负责人、Scrum Master 和开发团队的角色。 这些 Scrum 实践提供了结构，并有助于确保专注于在增量迭代中交付价值。
看板可视化管理：Scrumban 采用了看板的可视化管理和工作流可视化方面。 团队使用看板来可视化他们的工作、跟踪进度并管理不同阶段的任务流。
连续流程：Scrumban 强调通过允许团队成员在他们有能力时从积压中提取任务来实现连续的工作流程。 Scrumban 不是在严格限定时间的冲刺中工作，而是允许更灵活地开始和完成工作项目，从而实现更顺畅的工作流程。
WIP 限制：Scrumban 利用在制品 (WIP) 限制来管理工作流程每个阶段的工作量。 通过设置 WIP 限制，团队可以防止负担过重和瓶颈，确保任务的平衡分配和改进对完成的关注。
迭代改进：与 Scrum 类似，Scrumban 鼓励迭代改进。 团队定期反思他们的流程、绩效和工作流程，确定需要改进的领域。 这些改进可以逐步实施，促进持续学习和适应的心态。
待办列表细化：Scrumban 结合了 Scrum 的待办列表细化活动，确保定期审查、细化产品待办列表并确定优先级。 团队协作评估和准备积压项目，以供未来冲刺或立即实施。
时间盒和节奏：虽然 Scrumban 引入了更多的灵活性，但它仍然可以利用时间盒和节奏来提供一些结构。 例如，团队可以选择定期举行仪式，例如每日站会和回顾会议，以促进协作并保持反思和改进的节奏。
精益原则：Scrumban 遵循精益原则，专注于减少浪费、提高效率和持续交付价值。 它鼓励团队识别和消除非增值活动、简化流程并优化工作流程。
持续交付：Scrumban 提倡持续交付的文化，允许团队在任务完成后立即交付价值，而不是等待冲刺结束。 这样可以加快反馈速度、缩短上市时间并提高客户满意度。
量身定制的方法：Scrumban 具有高度的灵活性和适应性，允许团队根据他们的特定需求和环境定制他们的实践。 它鼓励团队试验、调整和采用最适合他们的做法，培养主人翁意识和自组织意识。
Scrumban 将 Scrum 的迭代和协作性质与看板的可视化管理和流程优化方面相结合。 它为团队提供了优化工作流程、提高效率和持续交付价值的机会，同时允许根据团队的需求和环境进行适应性和定制。