什么是敏捷开发的框架

敏捷开发（Scrum）的框架构成：3个角色（产品负责人、Scrummaster、开发团队）；工件（Product Backlog、Sprint Backlog、增量）；仪式（需求梳理会、Sprint计划会、每日站会、评审会、需求回顾会）。

一、什么是Scrum

Scrum 是一个团队集体工作的框架。来为团队的大型比赛进行），Scrum 以鼓励团队学习，以自组织的方式去处理，他们的成功和失败问题以不断改进的方式进行。

中文English的英文神悲剧常说我们的神人的神神人的Scrum最软件开发团队使用，但它的原则和经验可合作的各种团队，这也是Scrum的个人神人的个人原因的一个。Scrum 的通常被认为的中文英文中文英文敏捷的项目一个开发管理框架，它描述了有创意的集体会议、工具和角色，以帮助团队组织和其管理工作。

二、Scrum框架的构成

1、Scrum 获得成功需要的三个重要事件

Scrum 团队需要三个特定的角色：产品负责人（Product Ower）、ScrumMaster 和 Scrum 团队。由于 Scrum 团队为跨职能部门，因此除开发人员之外，开发团队还包括测试人员、设计人员、用户体验（ UX） ) 专家和运营工程师。

产品负责人（Product Ower）

主要负责构建正确的产品，确定 Scrum 交付什么并为什么解释这些工作。产品负责人是产品方面的决策者。他们专注于未来、客户和市场要求，确定工程团队需要完成相应的工作高效的产品责任人应能：

• 构建和管理产品待办事项。
• 与企业和团队监督合作，以确保可以随时了解产品待办事项中的工作项。
• 明确指导团队接下来提供哪些功能。
• 确定何时发布产品，更倾向于向地交付产品。

产品负责人并不一定是产品经理。产品负责人专注于确保开发团队为企业带来最大价值。此外，产品负责人是一个个体，这一点非常重要。没有开发团队需要多个产品负责人所提供的的混合指导。

Scrum Master

主要负责帮助产品负责人和开发团队中的每个人理解和拥抱Scrum的价值观、原则和实践。Scrum master 是其团队中在 Scrum 方面的佼佼者。

他们负责对团队、产品负责人和企业进行 Scrum 流程方面的培训，并寻找方法细调他们在此方面的实践。高效的Scrum 主管应深入了解团队正在执行的工作，并可协助团队优化其透明度和交付流程。作为最主要的推动者，此角色负责安排冲刺规划、每日短会、冲刺审核和冲刺回顾所需的资源（人力和物力）。

Scrum 团队

负责以正确的方式构建产品，执行具体工作任务。Scrum团队是具体工作的执行者，成员通常为 5 到 7 名。确定团队规模的一种方法是亚马逊首席执行官 Jeff Bezos提出的知名“两个披萨原则”（团队应该足够小，以便分享两个披萨）。团队成员具有不同的技能，并且彼此互相锤炼，因此没有人会成为交付工作的瓶颈。

强大的Scrum 团队遵循自我组织原则，且会在处理项目时采取明确的“我方”立场。团队的所有成员会互相帮助，以确保成功完成冲刺。

Scrum团队可推进每个冲刺的计划。他们将自己的历史速度用作指导，预测他们认为自己在迭代过程中可以完成的工作量。保持迭代长度固定可为开发团队提供有关其预估和交付流程的重要反馈，进而使其能随着时间的推移做出更加准确的预测。

2、Scrum 工件

工件是我们完成的事情，就像是解决问题的工具。在 Scrum 中，这三个工件分别是产品待办事项、冲刺（Sprint）待办事项，以及对“已完成”定义的增量变化。

它们是 Scrum团队中的三个常量，我们会不断地对其进行重新审视，并投入额外的时间进行改进。

产品待办事项（Product Backlog）

产品待办事项集合，整个产品的用户故事集合，这些用户故事可以来自甲方客户、终端用户、PO自己对产品的理解、研发团队等。

本质上，这是团队的“待办事项”列表。产品负责人对产品待办事项进行不断反思、重新排定优先级和维护，因为随着我们了解的更多或随着市场的变化，列表中的项目可能不再相关，或是可能会以其他方式解决问题。

产品目标：Product Goal

Product Goal 描述了产品的未来状态，可以作为Scrum Team 制定计划的目标。Product Goal 在Product Backlog 中。Product Backlog 的其余部分涌现，用来定义“做什么”将实现 Product Goal。

产品是传递价值的载体，它具有明确的边界、已知的利益攸关者和定义明确的用户或客户。产品可以是一种服务、实体产品或其他更抽象的东西。Product Goal 是 Scrum Team 的长期目标。他们必须先实现（或放弃）一个目标，然后再开始下一个目标。

冲刺待办事项（Sprint Backlog）

冲刺待办事项列表，一个冲刺目标阶段内的用户故事列表。这些用户故事来自Product Backlog，每次冲刺前，PO根据交付价值，将优先级较高的用户故事放入迭代。

每次冲刺之前，在冲刺规划会议（我们将在后文进行讨论）中，团队从产品待办事项中选择为进行冲刺而处理的项目。冲刺待办事项可能较为灵活，可以在冲刺期间发展。但是，基本的冲刺目标（团队希望通过在当前冲刺中实现的目标）不能受到影响。

冲刺：Sprint Goal

Sprint Goal 是 Sprint 的单个目标。尽管 Sprint Goal 是 Developers 的承诺，但它为实现该目标所需的确切工作方面提供了灵活性。Sprint Goal 还创造了连贯性和专注点，鼓励 Scrum Team 一起工作而不是分开独自行动。

Sprint Goal 在 Sprint Planning 事件中确定，然后添加到 Sprint Backlog 中。当Developers 在 Sprint 期间工作时，他们将 Sprint Goal 铭记在心。如果需要做的工作与预期的不同，他们将与Product Owner 协作，在不影响 Sprint Goal 的情况下，协商本次Sprint Backlog 的范围。

增量

增量是一个 Sprint 完成的所有产品待办列表项的总和，以及之前所有 Sprint 所产生的增量的价值总和。在 Sprint 的最后，新的增量必须是“完成”的，这意味着它必须可用并且达到了 Scrum 团队“完成”的定义的标准。

在完成以上三个工件的时候，团队可以选择定义很多变体，因为工件维护较好保持开放态度。比如“已完成”、“故事点”重新定义能更好的提升效率和品质，那你完全可以根据需求进行新的定义。

你应该像处理产品一样敏捷地处理 Scrum 框架，花一些必要的时间来检查事务的进展情况（无论是通过PingCode 这样的工具或者是其他），并在必要时做出调整，而不要仅仅为了一致性而强迫自己执行某些事项。

3、Scrum 仪式

Scrum 框架中一些更为人所知的组件包括 Scrum团队定期举行的一系列会议。在这些仪式中，我们可以看到团队之间的最大差异。

例如，有些团队发现举行所有这些仪式既繁琐又重复，而另一些团队则将这些仪式作为必要的登记手段。我们的建议是，在两次冲刺阶段使用所有仪式，然后看看其效果。接着，你可以进行快速回顾，看看可能需要进行哪些调整。

以下是Scrum 团队可能参加的所有重要仪式清单：

需求梳理会(Backlog Grooming Meeting)

有时也被称为待办事项梳理，它由产品负责人负责。产品负责人的主要工作是协助实现产品愿景，并持续关注市场和客户。因此，客户可根据用户和开发团队的反馈来维护此列表，以协助确定列表的优先级并保持整洁，同时准备在任意给定时间进行工作。

Sprint计划会(Sprint planning meeting)

由整个开发团队在本次会议期间规划当前冲刺期间要执行的工作（范围）。本次会议由 Scrum MAster主持，而团队则在会议期间决定冲刺目标。接着，可将产品待办事项中的特定用途故事添加到冲刺中。这些故事应与目标始终保持一致，且 Scrum 团队也承诺可在冲刺期间完成。  在规划会议结束时，每位 Scrum 成员均需清楚在冲刺期间可以交付的内容，以及如何交付增量变化。

冲刺（Sprint）

冲刺是 Scrum团队共同完成增量的实际时间段。两周是一个相当典型的冲刺时长，尽管某些团队发现一周更容易确定范围，或是一个月更容易提供有价值的增量变化。

但国外知名敏捷教练 Dave West 建议，工作越复杂，未知因素就越多，而冲刺就应该越短。但事实上，这取决于团队，而如果不起作用，团队也可以进行改变！  所有事件（从规划到回顾）都是在冲刺期间发生的。

一旦确定了冲刺的特定时间间隔，就必须在整个开发期间保持一致。这有助于团队吸取经验教训，并将这些洞察应用于未来的冲刺。

Scrum每日站会(Daily Standup Meeting)

这是每天在同一时间（通常是早晨）和地点举行的超短例会，以确保此会议简洁明了。很多团队试图在15 分钟内完成会议，但这只是一个参考。此会议也被称为“每日短会”，它强调需快速举行会议。

每日 Scrum 旨在让团队中的每一个成员都保持同步，共同朝着冲刺目标努力，并制定未来 24 小时的计划。  你可在每日短会上说出自己在实现冲刺目标或解决任何障碍时遇到的问题。  

每日短会的其中一种常见举行方法是让每个团队成员在实现冲刺目标的过程中回答三个问题：  

• 我昨天做了什么？  

• 我今天打算做什么？  

• 是否存在障碍？  

然而，我们发现会议很快会变成大家陈述昨天和第二天的日程表每日短会的。理论基础的英文：它可以分散日常会议的注意力，这样团队就可以在当天剩下的时间里专注于工作。

因此，如果它不适合每天日程表阅读会，则应果断改变以求创新。

Sprint评审会(Sprint Review Meeting)

在冲刺结束时，团队现场举行会议，以服务增量演示或增量检查。开发团队向相关者和团队成员展示当前“已完成”状态的待办事项，以征询他们反馈意见。

尽管在经常情况下发布增量，但产品负责人仍然可以决定是否发布时间。审核会议是产品负责人根据当前冲刺处理产品待办之时，当前冲刺时间事项一次冲刺计划会议提供相关信息。

为防止以后受到伤害，可以考虑将您的伤害审核时间限制为最长的冲冲小时。

Sprint回顾会(Sprint Retrospective Meeting)

是指团队集中常见的记录和讨论冲刺、项目、人员或关系、工具甚至在某些习惯中哪些有效以及哪些无效。

我们的想法是创造一个地方，让团队能够专注于哪些工作进展顺利和哪些地方有待解释，而不是专注于什么问题。

以上就是Scrum敏捷开发框架的全部内容，相信你已经知道了。